Check out the latest features available in Dynamics 365 for Customer Engagement, including LinkedIn Connect, Voice of the Customer and Universal Resource Scheduling.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
Back in September Microsoft gave us all notice that for 9.0 orgs they were going to start blocking TLS 1.0 and 1.1 and only accept SDK connections from TLS 1.2. The time has arrived where this blocking is in place. You can read the full blog post here. Hopefully by now you have completed the task of making sure your application is running on .NET 4.6.2 or later. If you haven't worried about this yet because you are on 8.x, you probably should be careful because someone may schedule the Customer-Driven Update (CDU) when they come available and you might be surprised when they upgrade to 9.x, and your stuff starts to break.
When this breaks, it most likely won't wave a big error that says "Update to TLS 1.2 version of .NET" it will more likley give you a very weird error that you won't associate with the removal of TLS 1.0 and 1.1. To give you an example we ran into, was on a site that we actually had mitigated already to .NET 4.7 and it was running in Azure under .NET 4.7. We thought we were good to go. Then one day we started getting failures on calls to CreateFromResourceUrlAsync in order to do OAuth to a Dynamics 365 instance. The exception generated was "The underlying connection was closed: An unexpected error occurred on a send". A simple console app testing the same thing worked fine. Calls to 8.x organizations worked fine; just the 9.x got that error (hint hint). But still what could be causing it...It turns out the site had a httpRuntime tag with a TargetVersion="4.5.2" so even though the project and Azure was configured for .NET 4.7 the httpRuntime dropped it back to 4.5.2
Another error that you might encounter that you could tie back to this change is "An error occurred while making the HTTP request to https://orgnameapi.crm.dynamics.com/XRMServices/2011/Organization.svc/web. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case". Now this one gives you a little more hint it has something to do with a secure connection. This can occur if you try to execute a call to the service using TLS 1.0 or TLS 1.1
This change can also impact other tools you might use, for example, USD issued an update early in November to support it - details here You also might want to make sure you have the latest SDK tools including Package Deployer. If you have built your own Package Deployment package there is a good chance the binaries you packaged up with it need to be updated from the 9.0.7 or later SDK tools.
Business Applications communities