Monthly Archives: June 2019

Improving Server Side Sync performance

The following blog was created after helping a customer of mine to drastically improve their server-side-sync performance by modifying the polling intervals of the mailboxes. let’s go 🙂

Understanding the mechanism

Server side sync polls mailboxes for Emails and ACT’s (Accounts, Contacts, Tasks) in sync cycles. In each sync cycle a mailbox will be inspected for new items and according to your settings for that specific mailbox it will sync these items to Dynamics.

This mechanism has an internal prioritization logic that increases and decreases the time between each polling for each mailbox according to activity that is observed on that specific mailbox. This behavior is described briefly in the SSS whitepapers and I will expand on this in this post.

A busy mailbox that has constant activity on it should be polled for items (emails) approx. every 5 minutes. But when there is no activity on the mailbox for several consecutive cycles – The mechanism will kick in and start increasing the time between each poll. At this point the mailbox enters a state of an IdleMailbox – and for these mailboxes type the sync cycle can increase to up to 6 Hours. That’s right, 6 hours. This same behavior is also relevant for ACT’s and has a separate setting with separate intervals.

This means that you can end up in a scenario in which a mailbox becomes Idle at 7:00 AM because there were no emails flowing in, and from that point the mailbox will be polled again only at 13:00 (1:00 PM) 6 hours later in the worst case scenario.

This mechanism is in place for a reason – to decrease the utilization on the email integration servers and unnecessary calls to EWS. Without it a customer that has for example 5,000 configured mailboxes but only few of them actually active – would end up with massive utilization of the servers and huge amount of calls to EWS. ((5000 x 12 email polls per hour) + (5000 x 5 ACT polls per hour)) = 85,000 polls per hour.

Luckily – we can control these settings, and it helped me solve an issue for a customer that actually needed to poll ~1000 mailboxes at a very high and consistent rate, without any delays or surprises. As explained above changing the setting caused the Async servers to soar in terms of resource consumption, so this is something you need to take into account and make sure your infrastructure can handle the change.

Explaining the parameters

The actual polling settings are stored in the DeploymentProperties table in the MSCRM_CONFIG database and are represented in seconds.

Although the Minimum values for Emails and ACT’s are 1 minute & 5 minutes – In reality Iv’e always seen that the MaximumBackoff values for polls are being used for the Active mailboxes.
Default Values

Changing the setting

You can use PowerShell on your Dynamics servers to adjust the settings. In this example we will change the IdleMailboxMaximumBackoff time from 21600 (6 Hours) seconds to 1800 seconds (30 minutes)

Add-PSSnapin Microsoft.Crm.PowerShell
Get-CrmSetting -SettingType ServerSideSyncEmailSettings
$set = Get-CrmSetting -SettingType ServerSideSyncEmailSettings
$set.IdleMailboxMaximumBackoff = “1800”
Set-CrmSetting -Setting $set
Get-CrmSetting -SettingType ServerSideSyncEmailSettings

Result after change
* not that the column name is ECidlemailboxMaximumBackoff

You could also change those settings on the DB but for safety and supportability reasons it would be a better to do it VIA PowerShell.

MailboxstatisticsBase

The MailboxStatisticsBase table is an excellent source of insights regarding the internal works of the polling mechanism. Download and run This query to see all the polls that were done on all the mailboxes and how many items were processed in each poll.  You can also filter it by a time interval to show you all the times in which a single sync cycle on any mailbox took more then X minutes – This is very useful when you need to troubleshoot sync issues. Just read the comments in the SQL query.

Additional Notes

If your MailboxStatisticsBase table is empty and not populating then it’s probably disabled for data collection – You can enable it with the OrgDBSettings tool by setting the MailboxStatisticsPersistenceTimeInDays to the number of days you want to save data for (Lot’s of data!) 0 means no data is collected.

Needless to mention – Those changes are only applicable for Dynamics on-premises deployments. And as mentioned above – If you make changes be sure you are ready for the extra resource consumption on the servers.

It’s been a long post! hope you find this useful 🙂

Michael

Back to business…

It’s been a while,

2.5 years to be precise since I wrote my last post here, and quite a few things have changed. First of all I started to work for Microsoft – a big accomplishment and a personal goal that I was very happy and proud to achieve. I’m a Dynamics 365 Premier field engineer and am enjoying my work very much – So an update to my “About” section is also coming. And Of course many changes to the product, the movement to Dynamics 365 online with it’s Azure & Office 365 ecosystem, New versions and features for on-premise versions, The relatively new V9 and Unified interface, App for Outlook for both online and on-premises deployments and much much more – In other words, lot’s of stuff to write about 🙂

So as the headline above implies, I’m going to start writing again and already have some great ideas in mind that will hopefully help you out with your Dynamics 365 ventures, whether it’s online or on-premise

Watch this space & see you soon!

Michael