Applies to Exchange 2003
Event Type: Error Event Source: MSExchangeIS Event Category: General Event ID: 9646 Description: Mapi session "/o=<org>/ou=First Administrative Group/cn=Recipients/cn=<userName>" exceeded the maximum of 32 objects of type "session".
Seen these in your environment? Sometimes they are caused by desktop search engines opening too many MAPI sessions, other times they are because your Exchange server is keeping open connections from the client that the client for whatever reason thinks are closed.
For example, say you have users connecting to Exchange over a poor network connection or VPN. When Outlook connects, it establishes MAPI sessions. If the users drops the VPN connection without closing Outlook first, those connections are going to stay open on the Exchange server for 2 hours. If the user connects again, more connections get added to the Exchange server for that user. See where we're going with this? If you max out, new connections will fail, resulting in an unhappy end user.
So how do you fix this?
Well, one of three ways.
You can try to prevent your clients from doing so many connections by educating your users, making changes in Outlook 2007, correctly configuring Network Accelerators to not keep connections open, etc.
You can tell Windows/Exchange that 2 hours is far too long to keep a session open without activity. To do this you follow the instructions in this document, specifically the TCP KeepAliveTime, set that to 5 minutes.
KB324270 How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003.http://support.microsoft.com/default.aspx?scid=kb;EN-US;324270
Or finally, and the last resort, you can add additional allowable sessions by following KB842022. Note that this is a last resort, as in many cases you are merely delaying your pain for later. Note the warning: "If you do this, try to determine the minimum value that you can use so that the client program can run without problems. If you raise the limit too high, the client program might affect the performance of the Exchange Server computer."
Event ID 9646 is logged in the application event log of your Exchange Server 2003 computer when a client opens many MAPI sessions.http://support.microsoft.com/default.aspx?scid=kb;EN-US;842022.
Jeff, Awesome post! We are in the midst of rolling out cached mode to 70,000+ machines and are getting flooded with these 9646 events on our servers. I have been scouring premier, Google, TechNet, etc and finally landed on your blog with this clearly outlined and explained. Would you agree that a predominantly cached mode baed environment would cause MAPI sessions to be depleted more rapidly than a non-cached mode based environment? We have users that leave outlook open in cached mode when jumping between network connections/states (mostly laptop users going in and out of standby, docking/undocking and switching between wired and wireless connections, and jumping between access points while navigating the campus) that I think is contributing to the depletion more than we had when all the users were not in cached mode.
Hi Seth, thanks for the comment. I do believe that Cached Mode creates more connections than Online mode, but I can't find any material to back that up.
Some ways to reduce connections would be to reduce the number of third party add-ins in Outlook (you mention going to Cached Mode is what seems to be causing this, are you also implementing a new client setup with a new archiving product or the like?), properly configure things like Riverbeds or other WAN accelerators, reduce the TCP Keepalive of course, or engage Premier with an escalated case.
I don't recommend raising the ceiling on the number of connections (32 being the default of course) since you're just delaying the pain, not treating it, you know?
You reference Outlook 2007 throwing these errors.
And in the Microsoft articles I've read they also point 2007. However, the 70,000+ machine rollout that SethB referred to are Outlook 2003 clients. Any thoughts on that?
Outlook 2003 has the same problem, yes.
I am seeing a similar issue with Exchange 2010, we get errors when adding users to our Blackberry Server, and everything points to this error in the logs on the Exchange server hosting our mailboxes. Has anyone seen this with Windows 2008 Server R2, & Exchange 2010 yet?
Check out the following link for instructions on setting up the Exchange 2010 admin account. specifically setting up the View information store sync permissions for admin account should help bypass the limit.