Paul's Down-Home Page

As part of my grand unified communications adventure (more on which later), I needed to get reverse number lookup (RNL) working with LCS. RNL is a simple concept: when you get a phone call from extension 1001, you want your computer to identify the caller as John Smith, not as ‘1001’.

Communicator looks up numbers using one of two sources:

• the address book produced by the Address Book Service on the LCS server; this is generated daily from whatever you’ve got in Active Directory.
• contacts in the user’s local Outlook address book (or Windows address book)

When you place a call to a Communicator user, the PBX sends a CSTA message that includes a device identifier, like this:

<deviceIdentifier>tel:1001; phonecontext=pbx.litware.com</deviceIdentifier>

(or maybe <deviceIdentifier> tel:+16175552702;ext=52702</deviceIdentifier>

Communicator will try to match the device identifier against one of the numbers it can see in the address book or the Outlook contact. If it matches, it displays the caller info; if not, you just get the number. You can add this information manually, but the preferred way to do this is to put the callers’ numbers into a multivalued attribute called proxyAddresses. However, we were in somewhat of a hurry. The simplest solution for us was to add the “TEL” URI of the associated extension into the “home” phone number field of each user object. This would more sensibly be done by a script, but for our lab environment, which only has a handful of extensions, it was a quick solution.

Continue reading →

I’m a huge fan of the Exchange team’s blog because it includes a wealth of technical information that you can’t find anywhere else. They don’t waste a lot of time with marketing fluff, and the folks who post there run the gamut from product support to developers to product managers. The Unified Communications Group at MS recently launched their own blog, which I hope will live up to the same standard.

Since I’m used to seeing my byline in print magazines, I don’t usually get too excited about it. However, I was surprised (and pleased!) to see that the Solution Accelerator for Exchange Consolidation and Migration won an Honorable Mention in Windows IT Pro‘s Readers’ Choice awards. This is especially cool because it was a write-in nomination! Missy Koslosky, Devin Ganger, and I worked really, really hard on this guide, and it’s great to see that it’s been useful to people.

Argh. This bit me, even though I knew better. I set up a managed custom folder, created a folder policy for it, and waited patiently for the folder to appear in a user mailbox. It didn’t. Why? Because I hadn’t set a schedule for the managed folder assistant, that’s why. Fortunately, a quick run of start-ManagedFolderAssistant solved the problem.

Cool! EMC (perhaps you’ve heard of them?) is launching an expanded service offering to help their customers migrate applications and data from Lotus’ collaboration platform to Microsoft’s stack. If I get time, I’ll watch their webcast and see what’s what.

Jason Mayans, one of the Exchange 2007 team’s product managers, has a new blog in which he discusses (among other things) how the new calendaring and scheduling features in Exchange 2007 came to be. It makes for interesting reading.

As Ed pointed out, Jack Dausman has a couple of articles about Exchange storage, and I finally have cycles to respond.

First, I find it a little sad that there’s so much effort being expended to help Chris Bordeleau tune his Domino server in the absence of any real data. Where are Domino’s performance monitoring and load testing tools? Are there no equivalents to jetstress and loadsim? Surely if Chris could post some actual performance data values the folks at Ed’s place would be able to help him out more directly.

Now, on to Jack’s postings. The Storage Magazine article he cites is, sad to say, old news to experienced Exchange administrators: using an archiving tool against Exchange won’t shrink the database unless you compact it. There are relatively few reasons why you’d actually do a compaction in practice, though:

• you move a lot of mailboxes from one database to another, thus reducing the amount of data needed for the source database
• you do a first run of an archiving / vaulting tool that removes a significant amount of message data
• you’re running so low on disk space that you need to reclaim white space, even though you know the store will grow again.

You certainly don’t need to run a tool like GOexchange regularly, as I’ve said before. Most sites don’t ever need to run it at all; after all, there are very few companies where the amount of stored e-mail is shrinking (don’t I wish!)

As to a couple of Jack’s other points:

• He says that Domino supports larger mail files than other systems. I think we’re having a semantic disconnect here: Exchange supports very, very large mailbox databases, but it’s uncommon to see individual mailboxes much larger than 6 GB or so. That’s not because of any hard-coded limit; it’s mostly because of poor client performance with older versions of Outlook. The big killer here is actually the number of items, not the mailbox size.
• He mentions turning off transactional logging to increase performance on Domino servers. Exchange doesn’t let you turn off transaction logging for the simple reason that it’s a key DR capability. I’m not sure under what circumstances it would make sense to trade off a small speed boost for degrading your DR capability.

Jack and Charles Robinson represent (IMHO) the best of the Domino community: they deal in technical discussions, not infantile bashing, and they understand their chosen products well enough to have intelligent discussions about them.

At first I thought this was a joke, but apparently not: Sametime doesn’t support LDAP paging, so in very large Active Directory environments IBM tells you to increase the result page size on your servers. Haven’t they ever heard of LDAP paging?

I had this flagged for blogging, and now that I’m back from vacation, I’m finally getting around to clearing out some of my queue! Anyway, Neil pointed out that Microsoft has released the Microsoft Official Curriculum (MOC) courseware for their LCS 2005 course, 7034A: Implementing Microsoft Office Live Communications Server 2005 SP1. If you’re interested in learning more about LCS, this is a good no-cost way to get an in-depth look at how it works and how to set up and manage it.