by gustaf | Sep 5, 2018
The server side sync is a technology for connecting Dynamics 365 CE to an Exchange server. When connecting an Online Dynamics 365 to an onprem Exchange there are some requirement that need to be met. These can be found here: https://technet.microsoft.com/sv-se/library/mt622059.aspx
However, I just had a meeting with Microsoft and based on the version shown 2018-09-05, they have now added some new features that they haven’t had time to get into the documentation yet.
Some of the most interesting parts of the integration is that the it requires Basic Authentication for EWS (Exchange Web Service). Of the three types of authentication available Kerberos, NTLM and Basic, Basic Authentication is, as the name might hint, the least secure. Hence it is also not very well liked by many Exchange admins and may be a blocker for enabling Server Side Sync in Dynamics 365.
In the meeting I just had with Microsoft, they mentioned that they now support NTLM as well! That is great news as that will enable more organizations to enable Server Side Sync.
There is still a requirement on using a user with Application Impersonation rights which might be an issue as that can be viewed as having too high rights within the Exchange server. For this there is currently no good alternative solution. I guess making sure that the Dynamics Admins are trustworthy and knowing that the password is encrypted in Dynamics might ease some of that. But if the impersonation user is compromised, then a haxxor with the right tool or dev skills could compromise the entire Exchange server.
Microsoft also mentioned another common issue that can arise with the Outlook App when using SSS and hybrid connection to an Exchange 2013 onprem. It will show a quick alert saying “Can’t connect to Exchange” but it will be able to load the entire Dynamics parts.
This might be caused by the fact, according to Microsoft, that Exchange 2013, doesn’t automatically create a self-signed certificate that it can use for communication. Hence this has to be done.
This can be fixed by first creating a self signed certificate and then modify the authorization configuration using instruction found here . Lastly publish the certificate. It can also be a good idea to check that the certificate is still valid and hasn’t expired.
I will see if I can create a more detailed instruction on this later.
Gustaf Westerlund
MVP, Founder and Principal Consultant at CRM-konsulterna AB
www.crmkonsulterna.se
by Gustaf Westerlund | May 30, 2007
As some of you might have experienced the easiest way to deploy MS CRM 3 is to have SQL Server and SQL RS on the same machine, this will let you duck from a lot of problems, so if you don’t know better and have no reason not to, choose this setup.
However, this is not always what is best. The most common scenario when this is not the case is when a company has a large SQL Cluster (or just a dedicated SQL Server) and for several reasons (mainly licensing and maintance) want to have the CRM database and CRM reports on the central SQL server. Now, I am not an expert at this, but I have tried to dive in to it a bit and I have found the following:
If you are running the application pool of CRM, application pool of SQL RS and the main SQL server as Network Service, you will usually be fine, it will probably work more or less out of the box.
However, if not, you will get a warning in the installation of CRM saying something like “SPN not set correctly” for SQL RS. You can, if you like, install CRM anyway, but reports will only work when running them directly using Report Manager/Report Server or when running IE from the CRM server. Since it is not best practice to have the CRM server double as a terminal server, this is not often very nice.
So, what’s wrong? The problem lies in that all requests from SQL RS to the SQL database, are done using the technique “impersonation” which means that all requests in the database are run as the “current user”/the user that is running IE. This is a very good feature since it among other things enables the Filtered Views in the SQL database the only returns the items that the current user has access to. The problem is that CRM is acting HTTP proxy for the SQL RS and as such cannot send the current users credentials to the Report Server.
What needs to be done? Well, the CRM server user must be set up to enable trust delegation (i.e. forwarding of credentials) and the service users running the CRM apppool, SQL RS app pool and SQL must have the correct SPN:s set for them.
There are several documents and blogs describing how this can be set up, Sonoma Partner has one and the document with the short title: Additional Tasks When Microsoft SQL Reporting Services is installed on a separate server from Microsoft CRM or Microsoft SQL Server by Microsoft is also a good help.
The biggest problem usually is that you will have to run the “setspn” tool on the service account that is running the SQL Cluster/dedicated SQL machine and even though that shouldn’t cause any problems, if it does, and you are running x number of business critical applications on the SQL server, you might be in for a long night…
My suggestion is that you first try to set this up in a demo environment and when you got it working, then redo it on the live environment on a late friday afternoon, and make sure you havn’t got anything planned for the weekend…
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
by Gustaf Westerlund | May 21, 2007
Today I held another crash-course in Extending MS CRM 3 with .NET. It is a very comressed version of the MOC (Microsoft Official Curriculum) course with the same name. The attendées were 4 very sharp CRM professionals from Cybernetics and Releye. If you are interested in attending this course please contact Informator at www.informator.se.
We were discussing the problems with kerberos double-hopp trust delegation when using a SQL RS on a different server than the CRM server. It dawned on my however that a similar problem might acctually arise if you choose to host your custom aspx-files on a separate server from the CRM-server. I am no expert at this kerberos stuff but would find it quite possible that you might get this problem. I havn’t tested this, so treat it as a hunch. If anyone has confirmation or the opposite, please comment this posting.
In short, to avoid potential problems, make sure your website for you custom websites are hosted on the same server as CRM. (please note that it is not supported to use the same website as CRM).
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Microsoft also mentioned another common issue that can arise with the Outlook App when using SSS and hybrid connection to an Exchange 2013 onprem. It will show a quick alert saying “Can’t connect to Exchange” but it will be able to load the entire Dynamics parts.
Recent Comments