• Twitter
  • FaceBook

Exchange Server Forums

Forums | Register | Login | My Profile | Inbox | RSS RSS icon | My Subscription | My Forums | Address Book | Member List | Search | FAQ | Ticket List | Log Out

RE: Event ID 9694

Users viewing this topic: none

Logged in as: Guest
  Printable Version
All Forums >> [Microsoft Exchange 2003] >> Information Stores >> RE: Event ID 9694 Page: <<   < prev  1 [2]
Message << Older Topic   Newer Topic >>
RE: Event ID 9694 - 18.Feb.2005 7:20:00 PM   


Posts: 423
Joined: 24.Feb.2003
From: India
Status: offline
Had replied a while ago for same issue cited in "GENERAL" section....

830829 is the support article if i am right.


A single instance of MAPI has a restriction of 32 sessions (or) 250 Messages Objects sent.

The issue in my case was owing to an incorrect setting of anti-virus on the client side, which never released the sessions and of course the user with Send as permissions blasted to a DL that had 1200+ recipients.

Keep the 9646 Evt. ID's open as you need to create a Reg key for each object in the error message.


- objtMessage (in my case.)



(in reply to m_arrabi74)
Post #: 21
RE: Event ID 9694 - 24.Feb.2005 4:46:00 PM   


Posts: 4
Joined: 24.Feb.2005
From: usa
Status: offline
Is there not a way to simply disconnect users, rather than restarting the store? They provide that capability with the IMAP virtual server, and SMTP but nothing for HTTP/WebDav or MAPI clients...

(in reply to m_arrabi74)
Post #: 22
RE: Event ID 9694 - 10.Mar.2005 8:24:00 PM   


Posts: 2
Joined: 10.Mar.2005
From: Vancouver, BC, Canada
Status: offline
FYI ... I was getting the same exceeded 32 MAPI sessions error. The KB articles don't include a work around for this.

I ran into this post on MS NG's that was the resolution necessary. You can see an archive here:
Usenet Archive

I'm still trying to investigate why certain users have that many MAPI sessions opening up [Confused] and why this change in behaviour was not documented anywhere! [Mad]

(in reply to m_arrabi74)
Post #: 23
RE: Event ID 9694 - 30.Mar.2005 7:32:00 PM   


Posts: 2
Joined: 10.Mar.2005
From: Vancouver, BC, Canada
Status: offline
I got a PM saying someone couldn't get to the Usenet message archive link I posted so I thought I would paste the content here just in case:
Dear Mr. Ken,

Thank you for posting here.

This behavior may occur if both the following conditions are true:

1. You have installed Exchange Server 2003 Service Pack 1 (SP1) on your
Exchange Server computer.
2. A program that is running on a client computer opens many MAPI sessions
to the Exchange Server computer. The number of MAPI sessions is greater
than the permitted limit.

Exchange Server 2003 SP1 imposes a restriction on the number of permitted
MAPI sessions per user. By default, the maximum number of permitted MAPI
sessions per user is set to a hexadecimal value of 0x20 after you apply
Exchange Server 2003 SP1.

Note A hexadecimal value of 0x20 converts to a decimal value of 32.


To resolve this behavior, we recommend that you first investigate if the
MAPI session limit is reached because of potential abuse, because it is
the result of a bug in a client program, or because of client program

If the behavior is triggered by a bug in a client program or by a client
program design, we recommend that you contact the vendor to determine if
you can do either of the following:

- Obtain a fix.

- Grant the View Information Store Status Exchange permission to the
account that the program runs under. Programs that run under an account
that has this permission are not affected by the MAPI sessions per user
limit. To grant the View Information Store Status permission, follow these

1. In Exchange System Manager, right-click the Exchange Server object or
the mailbox store that you want to grant the permission to, and then click
2. Click the "Security" tab.
3. Click the account that you want to grant the permission to.
If the account is not listed, click "Add", click the account name, click
"Add", and then click "OK".
4. Under the "Allow" column, click to select the "View information store
status" check box if it is not already selected.
5. Click to clear the check boxes for any permissions that are not
required, and then click "OK". You may have to perform this step because
if you clicked "Add" to add the account in step c, every check box in the
"Allow" column is selected.

If you cannot obtain a fix and you cannot configure the account to run with
the View Information Store Status permission, you can adjust the number of
permitted MAPI sessions per user in the registry. If you raise the MAPI
session limit, 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 can potentially affect the performance of the
Exchange Server computer.


To change the value of the maximum permitted MAPI sessions per user from
the default, you can configure the Maximum Allowed Sessions Per User
registry entry. To do this, follow these steps.

Warning If you use Registry Editor incorrectly, you may cause serious
problems that may require you to reinstall your operating system. Microsoft
cannot guarantee that you can solve problems that result from using
Registry Editor incorrectly. Use Registry Editor at your own risk.

1. Click "Start", click "Run", type "regedit" (without the quotation marks)
in the "Open" box, and then click "OK".
2. Locate, and then click the following registry subkey:


3. If the "Maximum Allowed Sessions Per User" entry does not exist, do the

a. On the "Edit" menu, point to "New", and then click "DWORD Value".
b. Type "Maximum Allowed Sessions Per User" (without the quotation marks)
as the entry name, and then press ENTER.

4. Right-click the "Maximum Allowed Sessions Per User" entry, and then
click "Modify".
5. Click "Decimal", type the value that you want to set in the "Value data"
box, and then click "OK".
6. Quit Registry Editor.

Hope this helps. Please let me know if you have any other concerns or
questions. Thanks and have a nice day!

Thanks & Regards,

Lee Li
Microsoft Online Partner Support

(in reply to m_arrabi74)
Post #: 24
RE: Event ID 9694 - 23.May2006 5:19:10 PM   


Posts: 4
Joined: 23.May2006
Status: offline
We had an issue where Backup Exec for Windows 10d would fail each night with access denied errors to a user mailbox.  I then noticed this event ID
in the application log and that the MAPI was using the administrative account for Backup Exec.  Followed the instructions on the MS support site and quadrupled the registry entry from 500 to 2500.  Problem solved.

(in reply to dwysocki)
Post #: 25
RE: Event ID 9694 - 5.Oct.2006 9:47:04 PM   


Posts: 3
Joined: 29.May2006
Status: offline
This is an issue here on my Enterprise as well. The one commonality I have with all the folks that have this failure is that they also use AOL instant messaging client on their machines and AIM gets knocked out at the same time that the user mailbox locks. And these folks never seem to have an issue when they are out of the office and working via the VPN. ONLY when they are in the office. I don't have server side Antivirus, just antivirus at the gateway and on the client machines. I am confident that Exchange is working as it should and that the issue really is at the client. Any thoughts on how IM could be the culprit? I understand that MAPI sessions are what the issue is...I am concerned now about my perimeter security.

(in reply to cytogenadmin)
Post #: 26
RE: Event ID 9694 - 18.Oct.2006 12:18:15 PM   


Posts: 8
Joined: 17.Oct.2006
Status: offline
I'm having the same issues.  I've made the registry change and I am still maxing out at 32 sessions.  It happens to all my SSLVPN users if they stay on too long. Any other place where to look?

(in reply to deannie)
Post #: 27
RE: Event ID 9694 - 18.Oct.2006 2:24:39 PM   


Posts: 3
Joined: 29.May2006
Status: offline
Making the registry change did not make a difference for me. Using this article from Microsoft: http://support.microsoft.com/kb/842022 I also gave the user that was having issues 'view only' privileges to the Information Store. The issue I have with AIM remains unresolved but for the moment, the mailbox is no longer locking out.



(in reply to trtjj)
Post #: 28
RE: Event ID 9694 - 12.Nov.2006 12:07:25 PM   


Posts: 2
Joined: 12.Nov.2006
Status: offline
I have also experienced this problem last Wednesday. We logged case with Microsoft and confirmed this behaviour is caused by firewall setting. However, this might only applied to those have multi VLAN environment.

By default, Windows KeepAliveTime is set to 2 hours which means Windows will reset idle session exceeded 2 hours. In this case, for those that has enable max session to 2500, most likely server has reset the idle session before it reach the max again.

So, we have contacted the firewall vendor and found that the default timeout value for MSRPC is set to 1 minute which causes the Outlook client reconnect to Exchange again (which open another 3-4 sessions every time this happen) where else the previous one remain as idle. As recommended by MS, we have reduced the KeepAliveTime from 2 hours (default) to 5 minutes. (http://support.microsoft.com/kb/315669/en-us) and increase the MSRPC timeout to 30 minutes at this point. Everything seems to work fine.

(in reply to m_arrabi74)
Post #: 29
RE: Event ID 9694 - 1.Dec.2006 11:46:44 AM   


Posts: 1
Joined: 1.Dec.2006
Status: offline
I had the same problem with exchange and with a all the machines on the network running slow. I also noticed a lot of activity on the switches. this whent on for four days before we figured out that a change made to the DHCP server mest up the database. we could see the correct ip configuration. but when we looked at the DHCP server the subnet mask was all mest up. once we deleted and recreated the configuration on DHCP every thing came back to normal. hope this helps some of you. good luck. 

(in reply to dwysocki)
Post #: 30
RE: Event ID 9694 - 8.Dec.2006 2:56:53 AM   


Posts: 1
Joined: 7.Dec.2006
Status: offline
i hope the KB 912811 can solve your problem


Melwyn Dsouza
MCSA+MCSE Messaging

(in reply to dwysocki)
Post #: 31
RE: Event ID 9694 - 11.Dec.2006 6:23:28 AM   


Posts: 10
Joined: 15.Sep.2005
Status: offline
Using tcpview allows to close the sessions without restarting the information store.
But it is only a workaround and doesn't explain why it happens.

I'm experiencing this too, most of the time, it affects the same users but I can't find why: they have the same outlook versions as the others, similar os config, ...

So any idea is welcome...

(in reply to melwyn)
Post #: 32
RE: Event ID 9694 - 12.Apr.2007 3:54:17 PM   


Posts: 1
Joined: 12.Apr.2007
Status: offline
I have been trying to solve this same behaviour with a customer and we still haven't solved it. Microsoft is involved as well. The things I have seen so far:
  • Some users are more affected than others (some never have problems)
  • On the client side Outlook (in cached mode) keeps losing connectivity to the Exchange server and re-establishes it later
  • Effectively, every time is re-establishes a connection, an additional session is opened
  • After 32 open sessions, additional connections are denied
  • The problem seems to re-occurr at specific times
  • A network trace shows many retransmissions, out-of-order or duplicate TCP packets between the client and the server
  • When Outlook fails, many other applications start to fail as well
I don't think Microsoft has a solution, but it appears there are more companies experiencing the same problem. As soon as I have more news, I will update this post.


(in reply to dwysocki)
Post #: 33
RE: Event ID 9694 - 29.Apr.2007 6:20:08 PM   


Posts: 106
Joined: 25.Aug.2005
Status: offline
I started having these problems after I recently upgraded to SP2 on my windows 2003 server standard edition. Does anyone else still have this issue?

(in reply to dbarto)
Post #: 34
RE: Event ID 9694 - 30.Apr.2007 5:56:07 PM   


Posts: 1
Joined: 30.Apr.2007
Status: offline
We recently had this error turn up, max sessions 32 limit was the listed parameter and it was associated with a GUID that we can't seem to locate (tried using ADFind already).  We've also ruled out the firewall and DHCP causes mentioned previously.  Some users also get the "Outlook is trying to retrieve data for the Exchange server" popups a number of times a day, wondering if the two problems might be connected?  Any ideas?


(in reply to machoman013)
Post #: 35
RE: Event ID 9694 - 19.May2008 11:23:03 AM   


Posts: 6
Joined: 21.Aug.2007
Status: offline
Read this article. http://msexchangeteam.com/archive/2007/07/18/446400.aspx

This typically has to do with windows server 2003 scalable networking packet which is incompatible with certain network card drivers and causes this symptom.

(in reply to jras)
Post #: 36

Page:   <<   < prev  1 [2] << Older Topic    Newer Topic >>
All Forums >> [Microsoft Exchange 2003] >> Information Stores >> RE: Event ID 9694 Page: <<   < prev  1 [2]
Jump to:

New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts

Follow TechGenix on Twitter