We've recently been seeing an elevated number of cases where networking issues are adversely affecting performance and causing other problems with messaging technologies. The common thread in many of them is that the problem only started to occur after Windows Server 2003 SP2 was installed. I recently learned that we shipped a new feature in SP2 and turned it on by default. This new feature is called Scalable Networking Pack, or SNP. It was actually originally shipped as a download for SP1, but was included in SP2 by default.
The Exchange team has posted an article on how SNP affects Exchange and also gives a good list of links and troubleshooting steps.
SNP was built to increase performance on the networking stack, and does for newer network adapters that support it. However, for older network adapters, it can cause significant delays which cause timeout problems and connection problems leading to various problems.
The basic troubleshooting steps at this point are
- Read the Exchange team's post linked above and pages they reference so you understand the issue
- Install the hotfix at http://support.microsoft.com/kb/936594
- Upgrade your network adapter drivers to the most recent version
Disable the SNP features by setting the following registry keys:
I've just had another case where SNP was the culprit. The customer had clustered Exchange 2003 boxes with recently applied SP2. They were using backup software which was using CDOEXM to get information about the environment. These calls were failing with 0x8000FFFF (E_UNEXPECTED) but after debugging we saw that RPC was getting RPC_S_SERVER_UNAVAILABLE (1722 0x6ba) errors. This prompted me to ask about SNP. Disabling SNP via the steps above resolved the issue.
Yet again, another customer with clustered Exchange 2007 boxes. They had a MAPI application which was unable to OpenMsgStore on mailboxes that had migrated from Exchange 2003 (MAPI_E_FAILONEPROVIDER). Debugging the process I could see RPC_S_SERVER_UNAVAILABLE errors. Sure enough, they had SP2 installed. Disabling SNP resolved the issue. The reason nonmigrated mailboxes worked was that MAPI was just guessing the ServerDN since resolving against the DS didn't work. If the mailbox had never been migrated, this guess ended up being correct; for migrated mailboxes, it was wrong and the failure bubbled up.