This is not so much a training document as outlining how I had to troubleshoot a weird error. I think the process taught me a variety of things, so I wanted to share the process of finding the answer.
I was trying to setup a new Dynamics NAV 2016 service tier in a test environment to use the NavUserPassword Credential Type.
Saurav has a most excellent guide on how to do this. I followed along and everything seemed to be fine. Until I tried to start the service. I immediately got:
Windows could not start the Microsoft Dynamics NAV Server [Example_NUP] service on Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion.
There was nothing in the log except this unhelpful little gem:
A timeout was reached (30000 milliseconds) while waiting for the Microsoft Dynamics NAV Server [Example_NUP] service to connect.
The thing is? There was no wait. The minute I hit Start Service, it would immediately stop with the “time out”.
We have customers in production on Azure using this credential type for their mobile devices, so I knew it was possible. I dug into the PowerShell scripts on the NAV Azure server and found that they used the PowerShell scripts from the NAV DVD to initialize a lot of things, including the self-signed certificate setup and service tier config.
If you didn’t know, the NAV 2016 DVD has an array of time saving PowerShell scripts. But it’s not obvious what you need and what they do. You might think (reasonably) that to troubleshoot this situation, you should study the NAVCertificateAdministration path’s contents. Those scripts are useful, but they didn’t help figure anything out I didn’t know. I already had the self signed certificate setup.
In the Azure NAV “install” script there was this interesting line:
Grant-AccountAccessToCertificatePrivateKey -CertificateThumbprint $thumbprint -ServiceAccountName “NT AUTHORITY\Network Service”
The $thumbprint variable came from the self-signed process earlier, which wasn’t illuminating. But I was curious about where this Grant-AccountAccessToCertificatePrivateKey module came from. THAT is in the DVD’s PowerShell, but hiding away with some other valuable scripts in DVD\WindowsPowerShellScripts\Cloud\NAVAdministration\Certificates folder:
So, in my PowesShell ISE, I imported the NAVAdministration.psm1 module. When I tried to run the Grant-AccountAccessToCertificatePrivateKey command, it told me that it “Could not find a certificate with thumbprint”. Odd.
But now I had a new tool: Get-CertificateByThumbprint. So, I tried that with the same thumbprint with the Verbose tag on. “Didn’t find certificate”. Oho. OK, this Get-CertificateByThumbprint is a PS1 file, so I popped open the file to see what it does. It’s fairly simple, as it turns out:
$certificate = Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $CertificateThumbprint}
So, it just runs the Get-ChildItem module with a path, piped through a filter. Easy enough! Now I know. I ran that Get-ChildItem with the same path, but no filter at all. It nicely lists all of the certificates in the Personal store of the Local Computer, with Subject and Thumbprint. And sure enough, there was my certificate. But… instead of looking like:
a7 6a 56 09 1e 3b a6 87 1a fa dc 03 df 65 20 16 4c fc 59 a8
It was listed as:
A76A56091E3BA6871AFADC03DF6520164CFC59A8
If I used THAT thumbprint with the command, then no problem. It found it. OK, let’s try this for a laugh. I copied THAT thumbprint into the NAV service tier config.
It started right up, no issues at all.
Lessons learned:
- There are some amazing PowerShell scripts tucked into the DVD folder. Since the ones I needed were hiding under “Cloud”, I didn’t look in there since this was not a cloud deployment
- PowerShell is just a part of NAV life now. I’ve used it several times this week to solve otherwise unsolvable problems.
- NAV service tier needs to add a graceful error handler if it can’t find the Certificate by thumbprint. There are essentially no clues if the Thumbprint is invalid, even though there are errors if you leave it blank.