This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 64%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC8%3C/text%3E%3C/svg%3E)
Hi all,
We've been experiencing issues with our public folders for a few months now and I'm struggling to get to the root of the issue. I am running Exchange 2016 hybrid within a DAG. I have created a new 2016 Exchange server and migrated the data to that and the issue still persists.
What I have been seeing is whenever the following perfmon metric exceeds around 2 or more, this causes our on-premise public folders to hang momentarily:
MSExchange Store Interface(_Total)\RPC Requests outstanding
From what I gather this metric should be close to 0 if not all the time, yet for me can spike up to 15 for around 10 seconds a time every minute or two. Reading up on this, sources tend to say this is a resource issue, though I have had a VMWare specialist take a look our infrastructure to confirm there's no issue there.
Any suggestions on what I can look at further would be very much appreciated :)
What is the impact on the Outlook client and whether there is a specific error for this one?
I also suggest you try to logon OWA on your Exchange server with "https://localhost/owa", check whether there exist issue with it. If there doesn't exist issue when access public folder from OWA on your Exchange server, I guess this phenomenon related to network settings, such as firewall.
Thanks for getting back @KyleXu-MSFT When we see a spike above 2 like we do in the following screenshot:
Outlook will freeze (often going into a white state) for any end user who has the Public Folders open. Often it can come up with the pop up trying to connect to mail.xxxx.com. As soon as the spike drops, Outlook and the public folders are responsive again.
So in the case of the screenshot above, the w3wp PID relates to the MapiMailboxAppPool as seen here:
With regards to your comment regarding the firewall; I have turned this off and the server is running no third party software either.
When the issue is occurring, I have tested accessing the public folders using OWA and the Public Folders appear to be responsive, which has now made me believe there's something wrong with Mapi as that's how Outlook is connecting to our on-prem Exchange.
You could follow this article to recreate MAPI virtual directory, then check whether it could solved this one.
Is MAPI over HTTP enabled?
https://learn.microsoft.com/en-us/exchange/clients/mapi-over-http/configure-mapi-over-http?view=exchserver-2019
That always seems problematic for on-prem Exchange
Indeed, we enabled MAPI over HTTP as a potential workaround because we had the issue when using RPC over HTTP previously.
Do you mean this phenomenon doesn't occur when using the MAPI over HTTP?
It was happening previously when users were connecting over RPC over HTTP using Outlook, which prompted me to enable MAPI over HTTP to see if that resolves the issue but unfortunately not.