tisdag 16 januari 2018

CRM for Outlook and the updated TLS demands

If you're running Dynamics 365 Customer Engagement and having issues with CRM for Outlook, there's an update available which will help.

This update isn't listed on the "update and hotfixes" page from Microsoft https://support.microsoft.com/en-us/help/3142345/microsoft-dynamics-365-updates-and-hotfixes which is sort of strange. If you're running the CRM for Outlook (why is it still called CRM and not Dynamics 365 Customer Engagement for Outlook btw?) and all of a sudden it stops connecting to your online deployment, this is probably your rescue: https://www.microsoft.com/en-us/download/details.aspx?id=56327.
This applies to version 9.0 at least, maybe to 8.2 as well but I'm not sure about that.

Rickard Norström
Developer at CRM-Konsulterna

måndag 8 januari 2018

Something happened around new year with Dynamics 365 Customer Engagement Enterprise Edition

Before Christmas we did an integration between an ERP system and Dynamics 365 Customer Engagement Enterprise Edition using the Web API. This integration was running fine until January 3 at 21.32 UTC+1 and by then it couldn't retrieve any data from Dynamics 365.

The only error that was thrown was that one or more errors had occurred and in the inner exception of that it said that "The underlying connection was closed: An unexpected error occurred on a send." and at some other level "An error occurred while sending the request". Not much to go on.

I was pointed to this page by Thomas Sandsør on Facebook (from Microsoft, somewhat safe to open :)) saying that TLS 1.0 and 1.1 will stop working at some time and if you move to .NET 4.6.2 you will be fine.

Now, that didn't quite happen since I still had the same issue running .NET 4.6.2. Digging continues and to my surprise I actually found something at stack overflow (maybe a bit less safe to click on) where they said that you should be able to connect by just using "https" in the connection string but I also found this line of code:"System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;"

Adding that to my code, which it seems I can do pretty much anywhere before I do a call, solves the problem and I'm again able to connect and retrieve data from the Web API.
The funny thing is that I was able to get a token all the time so the authentication actually worked, it was just the GET and PATCH and so on, I guess since the program crashed badly at the GET so I really don't know about the rest but it seems plausable.

Hope this helps.

After reading Marius comment below I continued to search for a solution that didn't mean I hardcoded the TLS version which I agree is a ugly solution. This lead me to the following page at Microsoft which says that you have to opt in to get the TLS 1.2 version, that wasn't clear to me earlier so now it works on .NET 4.7 with the following row added to the config file
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" /> 

Rickard Norström
Developer at CRM-Konsulterna