Exchange 2010–Public Folder RPC Connections not stable

Recently in our environment, we were facing issue or challenges with Public folder connectivity. After long days of troubleshooting & search we found a resolution for same described below.

Issue: Public folder RPC connections do not remain stable.

Exchange Version: Exchange 2010 SP2 UR3, Exchange 2010 SP1


  • Users unable to expand public folders OR public folder access is very slow.
  • When checked in connection status, Outlook shows connecting to a random public folder store which is not configured for user’s mailbox database OR its referral.
  • User might notice Double Byte characters on top of their Outlook client.
  • You’ve to restart RPC Client access service on Public folder server to resolve the connection issue.


  • Increased event logging for Public folder components of Public folder server.
  • Nothing reported in event logs.
  • No issue/error logged in RPC Client access logs for mailbox / public folder server.
  • Test-MAPIConnectivity doesn’t reports any error against public folder database.


The reason for this issue can be manifold:

  • Availability service calls made against public folder database have used up all available RPC connections and hence the database is not able to respond to new connection requests.
  • Internal bug with .Net code which stops responding after several HTTP requests are aborted.


Please refer to below KB article around this issue which presents two methods to resolve this issue.

Outlook client applications cannot connect to public folders after you install Exchange Server 2010 SP1

After you’ve finished reading the article, you’ll have few questions in your mind which may include:

  • Do I need this hotfix?Answer depends based on your current environment needs. If you are not seeing this issue in your environment, still I’ll recommend this fix to make sure you do not see this issue in future as well.
  • Which method should I prefer? This was the question I had and un-fortunately I couldn’t find answer to it anywhere. Answer is that you need to use bothmethods mentioned in KB.
    • If you apply only .Net Hotfix: After applying the .Net hotfix for Windows 2008 R2 server, you’ll start seeing that public folder connection remains stable. However, you’ll notice that free busy calls are still slow in response on Outlook clients.
    • If you apply only registry: The connection issue will still persist. Registry fix alone doesn’t helps at all.
    • If you apply both: Once you apply both methods, public folder connection will remain stable as well as free busy calls will be made faster than observed only with .Net hotfix
  • Where do I place registry – MBX/CAS? This question was asked by lot of my colleagues when I shared article with them, that DisableAvailabilityServiceCalls registry is required on Mailbox server or CAS server. Answer is, this registry should be added on all CAS role. That will ensure CAS will not overwhelm public folders with free busy calls. If you’ll put this registry on MBX role, free busy will stop working all together.
  • .Net hotfix says its not applicable? This error was generated on few servers while we were working on issue. This is because the .Net hotfix only applies for Windows 2008 R2 SP1. The issue is seen without SP1 as well though, just .Net hotfix requires you to be on Windows 2008 R2 SP1 before installation.

Hope this saves your time with troubleshooting this issue OR prepares you in advance while deploying Exchange 2010 environment.


Join the Forum discussion on this post

November 3, 2012  Tags: ,   Posted in: Exchange Server 2010

3 Responses

  1. MSFT - July 2, 2013

    The info about the regkey placement is incorrect. The regkey has to be set on all MBX servers containing PF databases and not on CAS. Furthermore, you don’t need the registry key if you deploy the hotfix 2497453 on your CAS. Setting this key means that you are reverting back to Exchange 2010 RTM behavior. This way Outlook 2003 clients that normally query Public Folders for free/busy will continue to do so, but the request will be serviced by Public Folders, and will not be intercepted and routed to Availability. This is confirmed by MSFT.

  2. LazyAdmin - July 6, 2013

    Thanks MSFT, but pretty sure this is how it worked, as mentioned with post, if we put registry on MBX servers, the free/busy information basically stops for all Outlook clients altogether. If we put only .Net Hotfix, the public folder connection stays stable, however the free/busy calls to backend are very slow from Outlook clients.

    it was tricky to setup hence I shared the details here. The way you’re saying is way MS asked us to implement this as well, but in the end above was how it worked as we expected it to be.

    Please feel free to try on your side and let us know how it goes.

    Thanks !

  3. Phillip Lyle - July 3, 2014

    I have to concur with MSFT –

    Free/busy does not stop if you put this on the mailbox server. Please refer to the official KB:

    “Note You may have to follow these steps on the public folder server.” <– This is the MBX server. It should not be needed on the CAS, as the clients are not connecting to the CAS at all for public folder connectivity.

Leave a Reply