This blog post is about remote configuration of settings in Windows server environment related to the Dynamics CRM front-end server installation.
I recently ran into a situation where on-premise Dynamics CRM front-end server was corrupted and none of the Windows management tools were accessible on that machine. For example, event viewer, Windows services controller, MMC, IIS management console, CRM deployment manager etc. did not start at all. However, the Dynamics CRM services were still running properly on this server. The deployment model in this environment was such where all the front-end server roles were installed to this corrupted server and the CRM DB’s were on a separate server. The SQL server itself and the CRM DB’s were ok without any issues. The CRM environment was configured for claims-based authentication in IFD-mode.
So, the task here was to install all the CRM front-end services to a fresh Windows server machine.
I started the Dynamics CRM installation wizard by pointing to an existing CRM deployment. When that option is used, the installation wizard gets the existing CRM deployment configuration data from the CRM configuration DB and assumes certain settings and configuration options to be the same in the new front-end server installation than in the old one. One of these options is the SSL certificate. The Environment Diagnostics Wizard (EDW) threw an error stating that existing claims-based authentication is configured to be using a certain SSL certificate and the same must be deployed to the new front-end server. Before running the EDW, I had deployed another, more recent SSL certificate on the new server. We were able to retrieve the same older SSL certificate from another server where the same was being used so luckily that issue got resolved.
Claims-based authentication and IFD
The next challenge was related to the claims-based authentication and IFD. As mentioned earlier, this is rather simple Dynamics CRM server deployment when thinking about server topology. The ADFS service was deployed also to the same, corrupted front-end server. This meant that none of the ADFS management tools were accessible either on that server. After the initial SSL certificate issue was resolved, the next error that EDW threw was related to the claims-based authentication, “The encryption certificate cannot be accessed by the CRM service account”:
My first instinct was that hey, most likely the CRM service account does not have read privileges to the private key of the SSL certificate. But it turned out that it is not the issue here. Rather this error is due to some type of an issue in CRM server installation that when installing a new front-end server to an existing CRM deployment, the IFD and claims-based authentication need to be disabled first. Then the CRM server installation can be done and afterwards, the claims-based authentication and IFD can be activated again.
It would be two mouse clicks to disable the IFD and claims-based authentication of Dynamics CRM if the CRM deployment manager tool would be available to use. But as I mentioned in the beginning, this was not the case here. None of these types of tools were available on the corrupted server.
PowerShell to the rescue
After a bit of head scratching, I realized that I can use PowerShell to disable the IFD and claims-based authentication. But PowerShell did not start either on the corrupted server. However, good old PowerShell can be used remotely as well. It requires just enabling the PowerShell remoting. This can be done by various tools, for example on the server locally (for obvious reasons not an option here in this case), by using group policy or directly by using PowerShell Direct if your server platform is Windows Server 2016 or Windows Server 2019. But in my case here, the server platform was Windows Server 2012. For that, there is a tool called PsExec which is a Microsoft’s free remote-control tool: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
So, I downloaded PsExec and within a seconds, I had PowerShell remoting enabled on the corrupted server by executing the following piece of script:
psexec.exe \\RemoteComputerName -s powershell Enable-PSRemoting -Force
You need to have certain firewall port open for this to work. I will not get into opening firewall ports remotely here but depending from the firewall provider, naturally that can be done.
Disable claims-based authentication remotely
So how to start a remote PowerShell session? Quite easily, just execute the following script and you have a remote session started:
$s = New-PSSession -ComputerName <the remote server name>
Enter-PSSession -Session $s
And now you have a remote session where you can for example browse directories of the remote server and execute scripts on the remote server.
The rest is just like sliding in the water park during the hot summer months: easy and fun. You need to be in the Deployment Administrator role in the Dynamics CRM and next register the Dynamics PowerShell snap-in:
One more thing you need to do if it turns out that in the old CRM server, the Windows registry setting of Dynamics Deployment Web Service Uri “DeploymentWSUri” registry key is not set (as it was here in my case). As the regedit tool did not work on the corrupter server, I needed to connect to the server’s Windows registry remotely. Luckily the regedit tool gives you this possibility and to configure this missing piece of registry key, connect to your old server’s Windows registry, open the following registry hive: \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and add a new key of type string with the following value:
Now you are ready to rock with the PowerShell and Dynamics CRM cmdlets. So, to check the current claims-based authentication settings, the following command can be used:
Get-CrmSetting -SettingType “ClaimsSettings”
That will show you a list of settings related to the claims-based authentication:
Next, you’ll execute the following piece of command:
$claims = Get-CrmSetting -SettingType “ClaimsSettings”
$claims.Enabled = 0
Now the claims-based authentication should be disabled:
Finally the installation of CRM
Now you are good to go and the EDW should pass all the tests without any errors. But you do need to restart the Dynamics CRM installation wizard from the beginning if you had it up and running while doing the above stuff. Just clicking back and forward to launch the EDW step of the wizard again does not do the trick.
Once the installation is completed and after patching the new CRM front-end server to the latest update level, your CRM adventures can continue with the brand-new server up and running.
I hope this blog post will help someone perhaps in a similar situation struggling with non-existing Windows tools and trying to complete things remotely.