This 11-page guide will introduce you to digital transformation and offer ideas for leveraging today’s technological innovations to reimagine the way your company operates.
How to Setup Dynamics 365 Server Side Synchronization for On-Premise to Exchange Online
Server side synchronization (SSS) is a technology that has been in the CRM world since the 2013 version of the product. Initially supported in homogeneous environments only, (online to online OR on premise to on premise) Microsoft opened up the availability to connect the CRM Online to your on premise Exchange environment shortly thereafter. Recently, the availability to connect CRM on premise to Exchange Online became available.
Microsoft has documented all of these methods
And most recently: Connect Dynamics 365 (on-premises) to Exchange Online
Some of these documents will have been updated since the writing of this post, but most are in pre-release format at this time.
The reason for the writing of this post is to document a real life implementation of the on premise Dynamics 365 to Exchange Online Server Side Sync. This document assumes some knowledge of the process for Server Side Sync in general, for instance how to edit the default methods on a mailbox and add a server profile. Access to Office 365 as a Global Admin is required. Access to the CRM Server as a Local Admin is required. Access to CRM as System Admin is also required.
Verify Prerequisites section
- IFD is required
- You must have “purchased” the Dynamics 365 Hybrid Connector. It indicates Free, but does require a billing method to be added in order to actually purchase. There may be a charge at some point in the future was what was indicated.
Sign-In – with Global Admin we will use below
Note that on the following screens, some of the information may be pre-populated
According to Microsoft, the license is automatically added despite the note to “assign users to your new subscription.”
- The last Prerequisite is for an X.509 certificate. If you already have IFD, you can use your current certificate. Export it to a file without the private key, making certain to use Base 64 encoding. You’ll also want to export your certificate WITH the private key and assign it a password
On your CRM Server, you’ll install both the features that will allow you to connect to and run Powershell commandlets against Azure Active Directory:
Note the sign-in assistant WILL prompt for a reboot, but we found that was NOT necessary.
Set up Server-based authentication section
Right click and run powershell as Admin. You will want to change your context to cd C:\Program Files\Microsoft Dynamics CRM\Tools (or wherever this is installed)
Alternatively, you can use the newly created program “Windows Azure Active Directory Module for Windows PowerShell”
Microsoft indicates to replace the contoso\administrator with your domain\account. Normally in their environments, Contoso\Administrator is the CRM System Administrator, but that IS NOT the account we want to use. Using a user account will break CRM. It removes the account that was setup during IFD to manage the Private Key on the certificate. So what you want here is the account running the CRM Application Pool in IIS.
Your commands are as follows. The first will create a variable with the command and the second will issue the command. The first should ALWAYS succeed and if it doesn’t, likely it is the directory issue, make sure you are in Tools.
$CertificateScriptWithCommand = “.\CertificateReconfiguration.ps1 -certificateFile e:\YourPFXExport.pfx -password 12345678 -updateCrm -certificateType S2STokenIssuer -serviceAccount contoso\apppoolaccount -storeFindType FindBySubjectDistinguishedName”
Invoke-Expression -command $CertificateScriptWithCommand
Once this is successfully accomplished we’ll move to the next section of the document:
Run the ConfigureCRMServerSideSync command section
Run ConfigureCRMServerSideSync command to do the following:
- Set up the Dynamics 365 Principal Name in Azure Active Directory Access Control Services (ACS).
- Configure Dynamics 365 for server-based authentication with Exchange Online.
- Set the Exchange Online tenant ID.
In your already open PowerShell window perform the following command:
- It will prompt you for the following information:
- rootDomainName – we used the fully qualified server name here.
- privateKeyPassword – this was the password we used on our exported cert (in the example above is 12345678
- cerFilePath – recall that you exported your IFD cert without the private key as a Based 64 cer file… this is it. We recommend using an easy location like the root of C: or D: or E: or whatever drive you have access to use. If you get this wrong, the error will be (essentially “The specified value of the certificate parameter isn’t valid. Please enter the path of the .cer file.”):
- pfxFilePath – your certificate export WITH the Private Key. Again, recommend an easy location like C: or D: etc.
- organizationName – this is your CRM Org name, Microsoft is typically case sensitive with this, so be case sensitive. (if you have additional orgs to set up, you will need to run command again with that Org)
- o365AdminEmail – This is your Global Admin in O365.
- Once you are ready and hit enter, the following will occur:
- You’ll select yes and then be prompted for the credentials into O365
If you are not a Global Admin, the following error will appear (essentially “Office 365 Credentials are not valid. Process Failed.”):
If you failed to add the Hybrid Connector above, you will get the following error (essentially “You cannot call a method on a null-valued expression. Process Failed.”) :
If you get it right, you will hear Microsoft Angels singing and the following screen will appear (NOTE: the Tenant ID will be displayed that you might need for the next steps, so don’t close the window) :
Create an email server profile section
Settings > Email Configuration > Email Server Profiles
Click New > Exchange Online (Hybrid)
At this point, if you have done this IN SEQUENCE, it will pre-populate your Tenant ID in the Exchange Online Tenant ID box. (redacted below)
Microsoft recommends unchecking the Auto Discover Server Location and assuring that the default setting is https://outlook.office365.com/EWS/Exchange.asmx as noted in the screenshot below.
Once this is configured you can click the Test Connection and it should connect as noted here.
Again, if you tried to create this manually and did not have the Hybrid Connector (which causes the PowerShell command to fail) the second two tests will fail.
One all this is done, you can begin to add that profile to user mailboxes that are in the associated Exchange Online and Test and Enable them. In our testing this test was almost instantaneously successful for all three methods (Incoming, Outgoing and Appointments, Contacts and Tasks). As a final note, the steps for the basic tasks above are at the end of the document Connect Dynamics 365 (on-premises) to Exchange Online.
Looking for someone to partner with on your journey to success with Dynamics 365? Contact Hitachi Solutions today.