[2010][EWS-MA][PS] Error MSExchangeIS 9646 RRS feed

  • Question

  • Hello fellow forum dwellers,

    I am currently experiencing a curious error accessing and writing appointments on our Exchange 2010 Server:
    The errorlog gathers one ID9646 Error per execution, stating that my MAPI session has exceeded the maximum number of 'objtMessage' (250 objects). It does not appear to affect operations, but I would still like to know what is happening, especially as it does not occur on my lab-system (The lab system was a fresh install, the production system has been migrated from 2003, so this might be an inherited problem).

    Thus, my question really is:
    What is capable of causing this error, why does it happen and how can I compensate for it (on the coding side)?


    There's no place like

    Friday, August 23, 2013 12:21 PM

All replies

  • Its unlikely that EWS would be the cause of that error (at least not directly) as that error is a know issue when you have a MAPI clients that is exceeding the Mapi session limits http://support.microsoft.com/kb/830829. EWS doesn't use MAPI to access the store so shouldn't (in theory anyway) ever cause this issue, also unless you have disabled throttling you should never have more than 1000 objects open at a time anyway.

    The usual culprit for this type of error are Blackberry devices where the BES servers MAPI session holds a large number of object opens. Other apps that can cause problems is if you have a Virus scanner running at the Store that is using MAPI. You can use ExMon http://www.microsoft.com/en-au/download/details.aspx?id=11461 to monitor your server and see  what user/application/client is causing the particular issue when the events are getting logged.


    Monday, August 26, 2013 4:19 AM
  • Hello Glen,

    thanks again for your efforts on my behalf. I have verified that it indeed is my service that causes this. By doing a step-by-step timelogging I narrowed down the culprit to the precise function call that causes this error:


    (I appended the properties loaded, just in case they made a difference. These are all the properties loaded.)

    Also, if the number of items for which I requested properties was reduced below 250, the error disappeared. The function documentation for LoadPropertiesForItems however says it does an EWS call, saying nothing about MAPI at all.

    Also it works just fine when run against my lab environment so I wonder ... is there a situation under which the EWS Managed Api might actually go for (or evade to) MAPI?

    Cheers and thanks,

    There's no place like

    Monday, August 26, 2013 8:46 AM
  • It certainly sounds like you hitting the session limits http://technet.microsoft.com/en-us/library/ff477612(v=exchg.141).aspx but I've never seen or heard anybody hit these with EWS (and you should be able to reproduce the issue on your test server so maybe check your patch/service pack levels). You may want to read http://support.microsoft.com/kb/980049 it maybe you have multiple clients colliding on that Mailbox I would take a look at it with Exmon which will tell you exactly what's happening with the clients.  What happens when you call LoadPropertiesFromItems is it does a Batch GetItem call but EWS should manage the sessions and open items. Generally just increasing the Limit via the registry setting should resolve the log messages.


    Tuesday, August 27, 2013 2:10 AM
  • Hi Glen,

    first of all, I missed the last update of our Exchange server, which was an SP upgrade, so I'd indeed better get started updating my lab Exchange.

    As for the collision idea:
    The service uses an exclusive user-account/mailbox, the error is thrown when trying to load properties for items within a public folder to which only that account and our Exchange superadmin account have access to. No impersonation in effect, that particular scenario is replicated on my lab environment. Thus I find myself doubting that that's it.

    I'll get started on equalizing patch levels and try again. I'll report back once that's done and I have results either way.


    There's no place like

    Tuesday, August 27, 2013 8:55 AM