Have you ever read the Address Book log file on a Client Access Server for Exchange 2010? Its quite interesting.
Well, not really.. It’s the log-file that is beeing produced by Microsoft Exchange Address Book Service – and details any attempts to use the address book (duh) – such as when connecting a client and looking up if the user is actually a user within the organization.
The below is an extract that occurred when all that the Outlook 2007 client connecting to the Exchange 2010 SP1 environment via RPC over HTTPC;
Too Many Connections? Apparently there seems to be a limit to the to the amount of connections a specific user can have – as only one user was experiencing the problem. As opposed to the usual suspect of Client Throttling Policy – which we temporarily applied a custom one with no restrictions did not impact the behavior. Why did this occur?
Well – a single mailbox was heavily used by about 10 people. From it, they connected to several other mailboxes, and they also used mobile devices to synchronize their mail. That apparently hits a limit somewhere. Unfortunately it wasn’t to easy to find where the MSAB-service had a limit imposed – but it could be spotted in the article Configure Static RPC Ports on a Exchange 2010 Client Access server. In the article there is an Exchange 2010 Address Book Service section that details how to configure the RPC ports primarily. However, the section also contains a screenshot of a .config-file which is used by Exchange 2010 RTM and especially contains the value MaxSessionsPerUser. Perhaps this could be something?
As it seems – the environment currently in question was an Exchange 2010 SP1 environment and apparently the previously used .config-file was now moved to the registry. However – nothing in the article (or any other article that was read) explained exactly what values could be entered. Some guess work where performed and MaxSessionsPerUser where simply entered as a DWORD value under the Address Book service configuration. As the .config-file had the default value of 50 – we simply entered a decimal value of 100 to see if the situation would improve.
Restarting the service – would of course close all connections. So we had to wait one day to confirm this would really resolve the problem…