Server-Side Synchronization Series Part 1: History of other Sync methods and why you should be using Server-Side Sync

Introduction

This multi-part blog series is intended as a deep-dive into topics related to Server-Side Synchronization for Dynamics 365. We will be exploring various topics such as how Server-Side Sync works, Exchange properties, correlation methods, authentication, advanced configuration and common issues seen with the service.

Although this blog series is focused on Dynamics 365 Customer Engagement (online) to mailboxes residing within Exchange Online, I will be creating supplementary articles covering hybrid, POP3, and on-premises topics.

Why is Server Side Synchronization better than other synchronization methods such as Email Router or Dynamics 365 for Outlook?

In order for older versions of Dynamics CRM to connect to Exchange, you had two options: Email Router or Dynamics CRM for Outlook. Both of these synchronization methods have inherent benefits and disadvantages.

Email Router existed as a machine-in-the-middle, configured on a server (normally) not part of a Dynamics 365 server deployment. This server had the Email Router application installed on it, and afterwards was configured to talk to Dynamics on one side and to whatever Email integration was being used on the other. You could connect Dynamics users to an SMTP endpoint (among others) to allow users to both send and receive email (and only email) within Dynamics. The below flow is shamelessly taken from my colleague Aaron Richard's blog regarding Email Router found here (https://community.dynamics.com/crm/b/dynamicscrmsupportblog/posts/email-router-demystified-explanation).

The disadvantage to the Email Router was that it had to be constantly maintained. New users had to be loaded within and configured/published, the application itself had to be updated, and the configuration parameters to keep the application efficient went beyond what is available through the graphical user interface. The application ran into failures caused by corrupted configuration files, local service/server interruptions and other issues typically associated with applications running from within the context of a client machine. The Email Router was officially deprecated with the release of Dynamics 365 version 9.0, and although Microsoft provides a version 9 update for the Email Router, this is to continue to allow organizations to move to Server-Side Synchronization without seeing interruption in services.

By contrast, Dynamics CRM/365 for Outlook (colloquially referred to as "the Outlook Client") exists as an application installed within the context of each end user client machine. A user or administrator would install Dynamics for Outlook as a COM add-in on top of a local installation of Microsoft Office Outlook. Once installed, the COM add-in was able to access the user's cached mailbox files (stored within PST files on the local machine) and point to a Dynamics server URL to authenticate from the context of a Dynamics user.

The advantages of using Dynamics for Outlook over Email router (or a combination thereof) were numerous. The Outlook Client used fetchxml user queries tied to Exchange item types to be able to not only track in Appointments, Contacts, and Tasks, but to also synchronize changes made by users to those records on either side (such as updating a start time on an Appointment). Because the Outlook Client was installed on each end user's machine, issues were mainly restricted to specific user contexts instead of everyone using the service. The Outlook Client could also be configured to work offline, using cached versions of pre-defined record types to be able to work in remote areas or on-site, and changes made to the records would merge back to Dynamics once connection was restored.

The disadvantages of Dynamics for Outlook were unfortunately numerous as well. Outlook and the COM add-in had to be running in order for synchronization to take place. Because it was a locally installed Outlook add-in, it ran into frequent memory and performance issues. Hard conflicts with other COM add-ins, such as those to do with voicemails and encryption methods caused the add-in to run into exceptions or hangs. Features were tied to and sometimes hindered by the version of Outlook installed locally, such as multiple monitor support.

Dynamics for Outlook was also reliant on several other technologies to be able to function, one of which being SQL Server Compact. The most recent versions of the Outlook Client were reliant on SQL Compact 4.0, which had an end of life date of 7/13/2021. 

Due to this, Dynamics 365 for Outlook is being phased out, replaced by Dynamics 365 App for Outlook, which uses Server-Side Synchronization as its platform. Support for the Outlook Client will stop on October 1st, 2020. More information on this can be found here:

https://powerapps.microsoft.com/en-us/blog/the-future-of-outlook-integration-for-dynamics-365-and-power-apps-customers/

I appreciate the history lesson, but isn’t this supposed to be about how Server-Side Sync works?

It's important to reference these earlier synchronization methods so we can compare them with Server-Side Sync. As noted above, Email Router and Dynamics for Outlook are both essentially machines that act as intermediaries between Exchange items and Dynamics SQL data. Server-Side Synchronization eliminates this, allowing Dynamics 365 servers running the Asynchronous Processing Service to talk directly to Exchange through Exchange Web Services and REST API:

Due to this, there is no reliance on a single server or needing to leave Outlook open in order to ensure synchronization. When properly configured, Server-Side sync runs in the background, automatically reaching out to Exchange on set intervals to detect changes since the last time Exchange was talked to and evaluating the delta items to determine if they should be promoted to Dynamics.

Promoted? Should we be saluting Major importance emails?

"Promoted" within Dynamics refers to the attempted creation of an activity record within Dynamics (such as an Email or Appointment) using data within Exchange items. Promotion can occur through several different mechanisms (such as manually via tracking in the App for Outlook) or automatically (such as meeting correlation method promotion criteria, which we will be covering in the next blog in this series).

How do we configure Server-Side Sync for first time use?

This blog series won't dive into basic configuration, as detailed articles are available here:

Set up server-side synchronization of email, appointments, contacts, and tasks

Great blog post by Neil Parkhurst that has detailed step-by-step instructions

The next blog in this series will cover how Server-Side Sync reaches out to Exchange and the properties it uses to determine the time frame it looks for emails to promote.

Part 2,  Part 3,  Part 4,  Part 5, Part 6