Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 2Check out the latest updates and new features of Dynamics 365 released from October 2022 through March 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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
Connect Dynamics 365 (online) to Exchange Online
Connect Dynamics 365 (online) to Exchange Server (on-premises)
Connect Dynamics 365 (on-premises) to Exchange Server (on-premises)
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
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.”
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:
Microsoft Online Services Sign-In Assistant for IT Professionals Beta
Note the sign-in assistant WILL prompt for a reboot, but we found that was NOT necessary.
Azure Active Directory Module for Windows PowerShell (64-bit version)
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:
In your already open PowerShell window perform the following command:
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.
The post How to Setup Dynamics 365 Server Side Synchronization for On-Premise to Exchange Online appeared first on - Hitachi Solutions America.
Business Applications communities