Administering Outlook sometimes requires administrators to debug communication errors related to the Name Service Provider Interface (NSPI) protocol.

The NSPI protocol is used by messaging clients most typically as a way of communications between the clients and a data store. The data stores contain address book information that is accessed and edited by the clients. NSPI itself uses remote procedure calls (RPC) as the transport layer. Clients use interface methods to access and edit the address books contained in the data stores.

But in this process sometimes NSPI connections can fail. You will usually get an error message such as “MAPI_E_LOGON_FAILED” from a Windows Server domain controller when communicating from a Microsoft Outlook 2008 based domain controller to the controller. You may see a credential box pop up when you get this error.

The reason why you get this error is because there is a limit of fifty concurrent NSPI connections per user to any domain controller for Windows Server 2008. When attempts are made to establish more than those fifty connections they get rejected and you or your end user(s) will receive the MAPI_E_LOGON_FAILED error message.

Previous versions of Windows Server do not have this problem. The reason why Windows Server 2008 is different is because a change was made to protect the domain controllers from being overloaded with too many NSPI connections made from clients. What happens when any server – in this case the domain controller – is overrun with requests is that server resources such as CPU and memory become exhausted and the server either slows down, stops communicating or altogether crashes.

From the client side you need to review any scripts or applications that use NSPI. One of the first things to look for is proper opening and closing of connections. Just as with sockets you must have a combination of opening and closing of the connections using the NspiBind and NspiUnbind functions when NSPI connections are no longer needed. Ensure that you have a one to one relationship of the NspiBind and NspiUnbind calls within your scripts and applications. If you find any that are out of sync fix them by adding a closing NspiBind function call. Contact any software vendors whose applications or scripts might be affected by these changes.

If your applications or scripts require more than fifty connection limit then you can make changes to the registry to support a higher limit. Always backup your registry before making any changes so that you have a known working copy that you can restore from. This is very important and necessary so that you can recover from any inadvertent problems or issues that might be introduced after making changes to the registry. The worst situation you may encounter, after having made changes to the registry, is that you would have to reinstall the operating system or a known working image of the OS.

To increase the NSPI connection limit you need to run the Registry Editor. You can do so by clicking Start, Run and then type in “regedit” without the quotes. Click OK or hit enter. Locate and click on the the registry key titled:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDS

From the Edit menu point to New and then click Key. You should then type in “Parameters” without the quotes and then press enter. This will allow you then select the Parameters key and to then edit it by pointing to New and then clicking on the DWORD value. At this point you will type in “NSPI max sessions per user” also without the quotes and then press ENTER. Now you can enter your desired limit for the number of NSPI connections you wish to allow by double clicking on the “NSPI max sessions per user” parameter. Once complete then click OK or hit enter.

All you need to do now is exit the Registry Editor.

If you are wondering about how high of a limit to use you’ll have to check with your software vendors technical support people to see what they recommend. Don’t worry about setting the limit too high as there are no upper limits other than what limits exist for being a DWORD. And that limit is about four billion. After you have made this change you can expect the server to behave in much the same way that Windows Server 2003 does with the same limit on NSPI connections allowed per user.