SSL Certificate - Impossible to export as PFX

When talking about SSL certificates, expiration period and certificate renewal is something that must be managed carefully.

A few days ago, I had the “easy task” to install a renewed certificate on the ADFS and Dynamics CRM 2016 servers configured in Internet-Facing Deployment (IFD).

Confident, I get the new certificate (a .cert file) from the provider and go in the certificate MMC on Windows Server 2012 to remove the old certificate and install the new one.

Installing the certificate with .cer file is quite easy (right-click à import, …) but, once installed, I do not have the options to define the “Private Keys” for this certificate. And without private keys, the IFD configuration for Dynamics CRM 2016 won’t work, because those keys are defining permissions for the ADFS / CRM service accounts.

To be able to define private keys, I needed a .pfx file, not a .cer file, and of course, the certificate provider delivers only .cer file for Windows / IIS web servers.

The easy way to convert a .cer file to a .pfx file is to import it in the certificate MMC and then to export it as PFX … but in my case, the “Export as PFX” option wasn’t there anymore, and it took me a few minutes to understand why.

Note: There are others ways to convert certificate, some websites propose this service, but I didn’t feel comfortable to upload my certificate on a public website.

Actually, you can only export the certificate in the PFX format if you are located on the server which initiated the Certificate Signing Request (CSR) … and (of course again) this server had been deleted after a successful migration.

Fortunately, once the source of the issue identified, the solution came quickly. The certificate provider (GoDaddy in my case) offers an option to introduce a new CSR online in order to generate a new .cer file, as the new CSR was then created by the actual ADFS server, I was able to use the “easy way to convert” the .cer file into a .pfx file.

Conclusion: If you have to renew a certificate without having access to the server that generated the CSR, make sure to generate a new CSR with you current web server and to send this new CSR to you certificate provider.

Glitch when _MSCRM suffix is missing in database name

Recently, my colleague Jean-Philippe Hugo (@jphhugo on Twitter) identified a weird behavior with an imported CRM 2013 organization.

For development purpose, we decided to restore a backup of our production database with another name.
When restoring the SQL backup, we simply renamed the database name "crmdev", without the usual suffix "_MSCRM".

After some tests, Jean-Philippe identified two problems in custom Reporting Services reports:
- The auto-filtering feature was not working anymore
- The automatic replacement of the connection string (when is named correctly) was not working either

Conclusion, if you restore a SQL backup of a CRM organization, make sure to keep the _MSCRM suffix.

Upgrade to CRM 2013 - The INSERT statement conflicted with the FOREIGN KEY constraint "solution_base_dependencynode"

A few weeks ago, I (unfortunatelly) experimented a strange error while upgrading from CRM 2011 to CRM 2013.

When importing our CRM 2011 Organization into a new CRM 2013 Deployment, the import wizard was stopping with the following error:
"System.Exception: Error.ActionFailed Microsoft.Crm.Tools.Admin.PopulateDependencyNodesAction ---> System.Data.SqlClient.SqlException: The INSERT statement conflicted with the FOREIGN KEY constraint "solution_base_dependencynode". The conflict occurred in database "tst_ru18_MSCRM", table "dbo.SolutionBase", column 'SolutionId'."

The CRM 2013 Deployment had Rollup 2 installed.
The CRM 2011 Organization database was at Rollup 18, but I also tried with Rollup 6 and 14, and I got the same error.
The CRM 2011 Organization came from an acceptance environment and contained a managed solution with all the customizations.
The weird thing was that the development organization had been upgraded without issue, but this one had all customizations in an unmanaged solution.

After some troubleshooting, I identified that the import process was trying to insert records into the DependencyNodeBase table, but as those records were referencing a solution that did not exist, the table constraint "solution_base_dependencynode" was breaking the INSERT statement.

Even activating the verbose logging on the CRM 2013 Deployment but did not give more information on what records cannot be inserted.

As I was stuck on the issue, I posted a description of the issue on the Microsoft Partner Network.
Actually, that description was the basis of this article.

A technical support engineer replied quite quickly and gave me the following SQL query to identify the corrupted information. (Special thanks to Hua Chen, original post is here http://partnersupport.microsoft.com/en-us/mpndynamics/forum/mpndyncrm/error-upgrading-from-crm-2011-to-crm-2013-on/18c684c6-aa90-4a9c-ac6f-8a3d4e1382f2)

SQL Query:
select a.SolutionId, f.SolutionId, f.OverwriteTime, f.ComponentState, f.IsManaged, f.* from FieldPermissionBase f inner join AttributeView a on a.LogicalName = f.AttributeLogicalName inner join EntityView e on e.ObjectTypeCode = f.EntityName where f.SolutionId not in (select SolutionId from Solution)

The SQL did return a few records corresponding to Field Security Profiles that was obviously corrupted.
To get my CRM 2011 organization imported, I had to go back in the CRM 2011 acceptance deployment and disable the "Field Security" boolean on the fields themselves (into the Default Solution).

Hope this will help someone that would have the same problem.