Public Folder use causing non-throttled RPC backoffs and major client-side delays

I have a production Exchange 2013 CU8 environment spread across two Active Directory sites each with their own DAG.  Each DAG is a 4-node DAG and each site has 2 CAS servers sitting behind a Windows NLB of SiteEmailNamespace.domain.com.  This used to be a single DAG in a single site, and the addition of the second DAG and second site came with it a large amount of Public Folder data and heavy Public Folder users.  There are now significant client issues for people accessing these folders.

On the server-side, you can see RPC requests build until a slew of RPC backoffs appear in the Exchange logs.  We've enabled logging for RPC throttling, and these backoffs do not appear to be Exchange throttling policy related.  Through testings, we've seen that these backoffs coincide with the degraded client experience.

On the client-side, Public Folder browsing takes a very long time.  Some users with a lot of Public Folder favorites also have general Outlook performance issues, where just browsing their inbox and composing messages can take 5-20 seconds for each item to load.

This behavior is the same whether the Public Folders live in a mailbox on their site's server or on the cross-site server.  

Does anybody have any insight as to what could be causing these RPC backoffs and performance issues? Thanks.

July 27th, 2015 3:51pm

How much public folder data and how many users? 

If the public folders are primarily used by users in one site, then make sure the public folder mailboxes are in databases mounted in that site.  If some of the public folder subtrees are used in the other site, ensure that they're in mailboxes that are in databases mounted there. 

Consider adding more public folder mailboxes to serve up the hierarchy and splitting up the content into multiple public folder mailboxes in different mailbox databases.

Free Windows Admin Tool Kit Click here and download it now
July 28th, 2015 2:17am

Hi Ed,

It's about 700 users, 450GB of Public Folder data, and 1400 folders in the hierarchy.  This was from an acquisition, and the previous Exchange 2010 Public Folder architecture was fed through Microsoft's Exchange 2013 PF migration scripts. We took those recommendations on the number of Public Folder mailboxes (9 total) and where in the hierarchy those are split.  The PF mailboxes are spread between the sites by useage (PF mailboxes in site A are used primarily by users with mailboxes in site A), and these latency issues occur even when users are accessing PF's in their own site.  

Do you recommend splitting the PF's into more mailboxes?  If so, would those mailboxes need to be on separate mailbox databases, or is it alright to use the same mailbox database?  Have you ever seen that cause RPC backoffs before?  Thanks!

 


July 28th, 2015 2:06pm

Hi Ed,

It's about 700 users, 450GB of Public Folder data, and 1400 folders in the hierarchy.  This was from an acquisition, and the previous Exchange 2010 Public Folder architecture was fed through Microsoft's Exchange 2013 PF migration scripts. We took those recommendations on the number of Public Folder mailboxes (9 total) and where in the hierarchy those are split.  The PF mailboxes are spread between the sites by useage (PF mailboxes in site A are used primarily by users with mailboxes in site A), and these latency issues occur even when users are accessing PF's in their own site.  

Do you recommend splitting the PF's into more mailboxes?  If so, would those mailboxes need to be on separate mailbox databases, or is it alright to use the same mailbox database?  Have you ever seen that cause RPC backoffs before?  Thanks!

 


Free Windows Admin Tool Kit Click here and download it now
July 28th, 2015 6:05pm

I haven't, but I haven't yet had a customer who's that heavy a user of public folders.

Splitting across databases might offer better performance, particularly if they are on different physical volumes.

July 28th, 2015 8:26pm

They would be on the same physical volume.  We aren't seeing any indication at all of disk being a problem though, and we've looked pretty intensely at it.  

Is there anything else that jumps out at you as a possible cause? Thanks.

Free Windows Admin Tool Kit Click here and download it now
July 29th, 2015 12:55pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics