Hi All, Been getting this event id 9646 for one particular user. Event Type: Error Event Source: MSExchangeIS Event Category: General Event ID: 9646 Description: Closing Mapi session "/o=Organization/ou=Administrative Group/cn=Recipients/cn=Recipient" because it exceeded the maximum of 32 objects of type "session". The user won't be able to connect to the Exchange server after that. If i restart the MSExchange Information Store service, then the user would be able to connect. Microsoft KB article 842002 is the only one that mentions about the session object type but it is only applicable to Exchange 2003. Wonder is i can use the same for Exchange 2007. Anyone got any idea ? Thanks.....

I am seeing this same issue with two users that have move over to the exchange 2007 from there legacy mailbox. It came up about 2 weeks since they were moved off their legacy mailbox. anybody have any ideas on this yet????? Thanks......

ya, my user's mailbox was migrated over from exchange 2003 and she start getting this problem. Seems to be the only person in the company having this issue. Read somewhere that Blackberry is causing this error. Any one can confirm this ? Thanks..

Did you ever find a solution for this problem? I'm getting errors like this for 3 different users who can't connect to Exchange 2007. Is there a way to see what the user is doing? I saw an exchange user monitor tool but it was for Exchange 2003. Does anyone know if that will work for Exchange 2007? Thanks all, chris

not yet found a solution. All the possible fixes seems to be for Exchange 2003 only. Any Microsoft ppl in here that can confirm if this is a known issue with Exchange 2007 and is the fixes for Exchange 2003 will work on Exchange 2007 ?????

Hey I was able to fix a newly report problem that matched this description. Today it was an executive Admin assistant that reported the problem, so it instantly escalated the problem. First I logged her in to owa so she could check for new emails while I applied office updates (she only needed some security patches). While office was updating I went back to web searching for a possible solution. There was one really interesting post on another forum that said the problem was a firewall timeout value for MSRPC that was 1 minute. The post said that MS exch used 2hours as the default timeout while the firewall was using 1minute for the default. They were uising juniper and I'm using cisco, but it was an interesting posting. I plan on opening a smartnet support ticket with cisco (I'll post the result if anything comes of it). the fix for her was: After windows update finished I recorded her IP address and use tcpview on our Exchange 2007 serverto kill the two "sessions" that matched the workstations IP. Then fired up Outlook 2003 and it connected like expected. I tried the same thing with one of our developers machines that still won't connect to Exchange 2007 with Outlook 2003. It didn't work for him but he's changed IPs since he first started having the problem so I'm not sure if there are still sessions from his vpn connection. I still have some questions for any MS ppl that may be hanging arround.? 1) the error in Event Viewer says "max of 32 sessions" I didn't see this many tcp connections from the one workstation that I was able to get working. I think there were only 2 still connected in an Establised state. Is a session not a single TCP connection? Or is there a bug in Exch 2007 that may think there are more "sessions" than there really are? 2) Is there a way to match a "session" with an IP or a process so I can use TCP viewer or another tool to kill off these sessions after a user changes dynamic IP addresses? 3) If a mismatch between the timeout values is found between the firewall and the Exchange server which should I change? How do you view/change the default timeout in Exchange 2007? I'll keep you posted as I find out more. Thanks all,

Hey I was able to fix a newly report problem that matched this description. Today it was an executive Admin assistant that reported the problem, so it instantly escalated the problem. First I logged her in to owa so she could check for new emails while I applied office updates (she only needed some security patches). While office was updating I went back to web searching for a possible solution. There was one really interesting post on another forum that said the problem was a firewall timeout value for MSRPC that was 1 minute. The post said that MS exch used 2hours as the default timeout while the firewall was using 1minute for the default. They were uising juniper and I'm using cisco, but it was an interesting posting. I plan on opening a smartnet support ticket with cisco (I'll post the result if anything comes of it). the fix for her was: After windows update finished I recorded her IP address and use tcpview on our Exchange 2007 serverto kill the two "sessions" that matched the workstations IP. Then fired up Outlook 2003 and it connected like expected. I tried the same thing with one of our developers machines that still won't connect to Exchange 2007 with Outlook 2003. It didn't work for him but he's changed IPs since he first started having the problem so I'm not sure if there are still sessions from his vpn connection. I still have some questions for any MS ppl that may be hanging arround.? 1) the error in Event Viewer says "max of 32 sessions" I didn't see this many tcp connections from the one workstation that I was able to get working. I think there were only 2 still connected in an Establised state. Is a session not a single TCP connection? Or is there a bug in Exch 2007 that may think there are more "sessions" than there really are? 2) Is there a way to match a "session" with an IP or a process so I can use TCP viewer or another tool to kill off these sessions after a user changes dynamic IP addresses? 3) If a mismatch between the timeout values is found between the firewall and the Exchange server which should I change? How do you view/change the default timeout in Exchange 2007? I'll keep you posted as I find out more. Thanks all, chrisj

http://support.microsoft.com/kb/925815/en-us?spid=10926&sid=global Check this link out I had problems with the MAPI default of 32. regards

Hi guys, Found this in the MS Exchange blog which seems to help solve the problem. http://msexchangeteam.com/archive/2007/07/18/446400.aspx the command i use is Netsh int ip set chimney DISABLED. So far after i applied this command, the problem has not surfaced again. Hopefully it solves it once and for all.