Error updating CCE public Edge certificate

Digicert mailed me this week to advise that the public Edge certificate on my Lab’s Cloud Connector Edition was about to expire. Duly forewarned I set about updating it, but I hit an unexpected error when I tried to activate it in the CCE:

CCEError-Set-CcExternalCertificateFilePath

SetCcExternalCertificateFilePathlnternal : The property 'Commond' cannot be found on this object. Verify that the property exists.

“Commond”? Surely that’s a typo!

I eventually managed to fix* it – and I’ll get to that shortly. (* It’s a bit kludgey).

The process – replacing the External Edge cert

Having updated the certificate (thank you Digicert!) and exported it as a .pfx file I copied it to the CCE, placing it in the folder C:\cce\SiteRoot\

The CCE steps are outlined in this TechNet article:

  1. Put the appliance in maintenance mode by using the Enter-CcUpdate cmdlet.

  2. Run the following command:

    Set-CcExternalCertificateFilePath -Target EdgeServer -Path <Full file path of new certificate including filename> -Import
    
  3. If the password of the new certificate is the same as the old, the import will be successful. If the password is different, you will receive an error that the password is wrong, and you will need to reset the password by running the Register-CcAppliance cmdlet with the -Local parameter, and then repeating step 2.

  4. Take the appliance out of maintenance mode by using the Exit-CcUpdate cmdlet.

Seems simple enough, huh?

The reality

Enter-CcUpdate went OK.

For step 2 above I ran this command: Set-CcExternalCertificateFilePath -target EdgeServer -path “C:\cce\SiteRoot\cceedgepool_gis365lab-12Jan2018.pfx” –import

… and as foreshadowed by Step 3, it returned an error:

CCE-CertPasswordWrong

SetCcExternalCertificateFilePathlnternal : Password for C:\cce\SiteRoot\cceedgepool_gis365lab-12Jan2018.pfx is not correct. Run 'Register-CcAppliance -Local’ to input the right password then run this cmdlet to import the certificate again.

As directed, issuing “Register-CcAppliance –Local” provided the opportunity to enter the new cert’s password – but then failed, this time with the puzzling error:

CCE-Register-CcApplicance-Fails

In the vague hope that all this red wasn’t a show-stopper, I repeated Step 2 to find that it no longer reports issues with the password – good – but is now also stuck on this “Commond” error. (That’s actually the first image up the top of this post).

Fortunately the CCE PowerShell module consists of a stack of scripts, making some of this debugging a little easier. It didn’t take me long to search through the PS folder (using the tips I recently blogged here) to find where “Commond” appears. You’ll find it in C:\Program Files\WindowsPowerShell\Modules\CloudConnector\Internal\MtHostCommon.ps1:

if ($job.State -eq "Failed") {
         Write-Error "Backgroud job failed at $($job.Commond). CceService credential file may not updated. Run current cmdlet again." -ErrorAction Stop;
     }

By looking at the $job variable I was able to determine this was indeed a typo, however correcting the reference back to “$($job.Command)” didn’t actually get me anywhere further – it still died, but just with more red on the screen than before:

CCE-Set-CcExternalCertificateFilePath-Verbose

The Fix

I spent a while trying to figure out what was going on, but ultimately I couldn’t determine the root cause. It was clear that $Job.State was failing but I couldn’t figure out why. I was also unsure if this seemingly recursive reference to $job was legit or another bug:

$job = Get-Job -Id $job.Id

In the process of debugging it also became apparent that even though $job.State was reporting failure, everything seemed to be working fine! In the end, I simply commented-out the write-error line that was causing my problem and the scripts continued on their merry way: the cert was copied to the Edge server, Set-CsCertificate ran and the new cert was applied:

CCE-Set-CcExternalCertificateFilePath-OK

That only left me to close out Step 4 in the TechNet process with “Exit-CcUpdate” and we were all back up and running!

CCE-Exit-CCUpdate

Postscript

Fellow MVP Ståle Hansen has since shown me the error of my ways. It seems .NET 4.6.1 is a pre-req for CCE v2.1.0, and having updated my host accordingly, $job no longer reports failure.

References:

Notes

  • The above took place on a “DIY” CCE, running on an old Dell PE-2950 & CCE 2.1.0.
  • If you’re trying any of this debugging for yourself, every time you change any of these PS1 files you’ll need to reload the module. I chose to close and re-launch a fresh PS window. If you don’t, your code change won’t have taken effect. An alternative to a fresh window is to execute “import-module CloudConnector –force” in the current window.
  • Keen eyes scouring the screen-grabs might see the odd instance of text like “made it to here”. Those are breadcrumbs I added into the modules as I was stepping through the debugging process, trying to narrow down the issue. You won’t have them in your deployment.

Revision History

14th January 2018: This is the initial post.

14th January 2018: Added the Postscript.

 

– G.

Leave a Reply

Your email address will not be published. Required fields are marked *

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.