When Server-Side Synchronization (Server-Side Sync) was first introduced in Dynamics CRM 2013, I imagine that lots of application and email server administrators breathed a huge sigh of relief. The feature greatly simplified the amount of effort involved in integrating On-Premise/Online CRM instances with their equivalent Exchange Server versions. Previously, the only way of achieving such an integration was via the E-mail Router, a cumbersome application that provided limited integration between email servers and CRM (i.e. no synchronization of items such as Tasks, Appointments, and Contacts). Granted, the E-mail Router was desirable if you were running a non-Exchange based Email Server, but having to provision a dedicated computer/server as the “intermediary” for all email messages to flow through could start to make a simple application deployment grow arms and legs very quickly.

Since the addition of Server-Side Sync, the feature has been continually updated to make it more versatile and the de facto choice for getting your emails tagged back into CRM & Dynamics 365 for Enterprise (D365E) – to the extent that the Email Router will shortly be extinct. Server-Side Sync now supports hybrid-deployments (e.g. D365E Online to Exchange On-Premise and vice-versa), has been expanded to include other Email protocol types and is now tailored to provide easier mechanisms for diagnosing mail flow issues from within the application itself. The last of these developments is best epitomised by the introduction of the Server-Side Synchronization Monitoring dashboard, introduced in CRM 2016 Update 1:

With this Dashboard, Administrators now have a simplified means of monitoring the health of their Server-Side Sync settings, facilitating the easy identification of problematic mailboxes, mailboxes that have failed a Test & Enable and those that have a recurring error being generated on them. Having all of this information at our fingertips enables CRM administrators to much more proactive in managing their health of their instance.

When recently working within some D365E organizations, which were originally provisioned as Dynamics CRM Online 2015 instances on the same Office 365 tenant, I noticed that the above Dashboard was missing:

Therefore, when clicking on the appropriate button in the sitemap area, an alternative Dashboard is loaded instead (either the user’s favorite Dashboard or a random one instead). So the question was – where has the Dashboard gone?

It turns out that the reason for its absence is down to an error as part of a previous major version upgrade, and is an issue that may be encountered by CRM Organisations provisioned a few years back. After escalating to Microsoft Support for further assistance, we were able to find a workaround to make the Dashboard available on the instances that were missing it. The steps involved are relatively straightforward, but in our case, we did have to resort to a spare trial/demo instance available that had the Dashboard installed successfully. The workaround steps are as follows:

  1. Log into an instance that contains the Dashboard. Go into Customizations and rename the Dashboard (doesn’t matter what you call it, as long as it’s not the same as the default name).
  2. Create a new unmanaged Solution and add in the renamed Dashboard. Export the solution as an Unmanaged Solution.
  3. Import the Solution into the instance that is missing it.
  4. Attempt to access the Dashboard and verify that it loads successfully.

You may be wondering why the Dashboard needs to be renamed before exporting. When attempting to import this Dashboard into any target instance with its default name, the component is automatically skipped during the import process. A Microsoft engineer advised that this is because an instance with the missing Dashboard actually thinks it is there and therefore does not try to import and overwrite a system component with the same name.

For the benefit of those who may also be experiencing the same issue and do not readily have access to another CRM/D365E instance, I have uploaded below two unmanaged solution files for the previous two versions of the application:

Version 8.1 (Dynamics CRM Online 2016 Service Pack 1)

Version 8.2 (December 2016 update for Dynamics 365)

The solution is a simple 1 component solution, containing a renamed version of the Server-Side Synchronization Monitoring Dashboard:

Once you have downloaded your Solution of choice above, follow steps 3-4 above and then go into Solution and the Dashboard to rename it from Copy of Server-Side Synchronization Monitoring -> Server Side Synchronization Monitoring. The application will accept the changes and it will be as if you always had the Dashboard there in the first place 🙂

It seems strange that this issue occurred in the first place, and I suspect I may not be the only one who has faced it recently. The Microsoft engineer I spoke to seemed to confirm that they’ve had this type of issue crop up several times previously, which makes it strange that this has not been acknowledged as a bug, either within the application itself as part of the twice-yearly upgrade processes. Notwithstanding this fact, it is good that an established workaround can be applied to fix the issue.

Microsoft Dynamics CRM comes with a number of out of the box Security Roles that can be used in order to give users the correct permissions. Whilst this is helpful, they generally won’t be a good fit for most organisations and a custom security role will be required in order to get the correct mix of permissions. These can be either created from scratch or be based off one of the system defaults. Regardless of how you go about it, the dreaded risk of permissions errors is ever present and it can be very difficult at times to figure out which CRM feature relates to what security permission; it doesn’t help as well when some of the system entity logical names are entirely different from their display names!

A good case in point is Server-Side Synchronisation, a brilliant feature that takes a lot of the headache out of setting up your colleague’s e-mail addresses on CRM. But, if you decide to create your own custom security role in Dynamics CRM 2015 or earlier, you may end up running into this very frustrating error message when attempting to test and enable your users’ mailbox:

ServerSideSyncError

Well, at least we’ve got an error message – what does our best friend Google say? Rather annoyingly, there isn’t much that comes back search wise, not even an official page from Microsoft that provides a list of the permissions that are needed in order to use this feature.

A (not so quick) support case with Microsoft in order to find out just what permissions I need to increase/add onto my role will likely result in an answer similar to this:

“In order to resolve the issue, make a copy of an existing security role and then reduce the privileges accordingly, as there are some hidden privileges within these roles that affect this feature.”

“Hidden permissions” you say? That smells suspicious and is something that I have never come across in my working with CRM (though I am of course happy to be stood corrected). Also, what if in reducing the permissions to suit my businesses requirement, I accidentally remove the privileges that are needed for this work? Looks like I’m going to have to find out which privileges are needed the hard way.

So, after some trial and error, I can now provide a complete list of all the permissions that you need to have on your security role in order to Server Side Sync to work successfully. Please note the below assumes that you already have a separate security role setup that gives relevant permissions on the Appointment, Contacts and Activities entities within CRM:

Incoming/Outgoing E-mail

  • Email Server Profile
    • Organization level Read
  • Mailbox
    • User level Create, Read & Write

ServerSideSync_IncomingOutcomingPrivileges

Appointments, Contacts and Tasks

  • Organization
    • Organization level Read
  • Sync to Outlook
    • Full Privileges

ServerSideSync_ACTPrivileges_1

ServerSideSync_ACTPrivileges_2

 

With all of the these privileges assigned, our test and enable of the mailbox works successfully:

ServerSideSync_SuccessAlerts

Hopefully this helps someone who has spent countless hours pulling their hair out on how to get this working.

For those of you that are upgrading to CRM 2016 in the near future, there’s some good news relating to this: an extra button has been added on the error message that lets you expand it and view the system privilege name that is missing:

ServerSideSyncError_2016ErrorDetails

So based on the above message of “prvReadOrganization privilege”, we know that we need to give Read Privilege on the Organization entity! This is definitely a big help and a welcome new feature to have, as you can then go through and gradually add the permissions missing until everything is working. It’s little things like this which is making me more and more excited about upgrading to 2016 in the near future.

Does anyone else have any tips or advice on how to get certain features within CRM and what privileges are needed? Please use the comments below to share.