In last week's Exchange & Outlook UPDATE, I wrote about Service Principal Names (SPNs), which are Active Directory (AD) attributes used to provide globally unique names for services that can be authenticated with Kerberos ("Microsoft Exchange Server and SPNs, Part 1," January 3, 2008). I also mentioned Microsoft's list of Exchange Server–related SPNs, which you might want to refer to while reading the rest of this week's UPDATE.
I've run into an odd problem a couple of times with Exchange Server 2007 unified messaging (UM): sometimes the UM server won't send messages to the Hub Transport server. When this happens, the UM server still answers the phone, plays greetings, and records messages normally, but the messages never arrive in the recipient mailbox, and you'll typically see event ID 1082 logged by the MSExchange Unified Messaging service. The description for this event ID says the message couldn't be submitted "because there is no Hub Transport server available to process the request." This error message can be misleading, especially if you're certain that there's actually a Hub Transport server available.
During Exchange 2007 beta testing, it wasn't uncommon to see this error because of problems establishing a Transport Layer Security (TLS) connection from the UM server to the Hub Transport server. In my experience, almost all instances of this error stemmed from problems with the certificate assigned for use by the SMTP service. However, I've now run across a few baffling cases where there was nothing wrong with the certificate, but a TLS connection still couldn't be established. Removing and reinstalling the Hub Transport role usually fixed the problem, but that's akin to burning down and rebuilding your house because the kitchen floor squeaks: a bit of overkill, and not really a practical solution in most environments.
Recently I was setting up a lab system with the Hub Transport and UM roles on the same server. When I finished the setup, I built a Microsoft Office Communications Server 2007 environment to go along with it, then started doing tests. Wouldn't you know it? My test recipients didn't get UM messages, and my event logs showed event ID 1082 for each message. Everything else was working fine, and the Hub Transport server correctly routed other messages, so I was skeptical that the problem lay in the Hub. I double-checked the certificates, and found that they were OK.
A tip from Microsoft's Ray Fong led me to check the SPNs registered to the SMTP service on the Hub Transport server. When I ran the Setspn command-line tool with the -L switch, everything looked OK. However, a search with the Ldp utility revealed that there were also SPNs registered for the SMTP service on the built-in Administrator account. That discovery led directly to the cause of the problem: The SMTP service instances on the UM and Hub Transport roles couldn't correctly authenticate each other because they were using different SPNs. Using Setspn didn't reveal the problem because it only shows SPNs registered for the machine account of the specified computer, not the Administrator account (or any others). I had to use Adsiedit to remove the extra SPN attributes from the Administrator account, but after I did this (and rebooted the server), UM messages flowed normally.
Thankfully, SPN-related problems are rare. However, you'll have to become proficient with SPNs to use Kerberos and constrained delegation. For example, you'll need to create SPNs if you want to use Kerberos authentication for SharePoint; see Martin Kearn's explanation of how to do so on his blog. Adding SPN checking to your toolbox of troubleshooting strategies is a good move, particularly as you deploy Exchange 2007 more widely.