Windows 10 Feature Update Fails with Error = 0x80240022. Commit Result = 0x00000001 (or 0x80070522: A required privilege is not held by the client)

Using Bryan Dam's excellent Software Update Installation Failures by Update report, I discovered almost a thousand systems failing to apply the 1709 Feature update that I'd deployed via ConfigMgr. 

The error was seemingly random since over 3000 systems had successfully updated. All were 1607 (though I think this symptom could apply to other versions).

The error was either:

0x80070522: A required privilege is not held by the client

or

0x80240022. Commit Result = 0x00000001

The feature update would not install. Moreover, it failed almost instantly in Software Center. UpdateDeployment.log and WUAHandler.log both reporting 0x80240022.

Cue lots of log-trawling and internet searching (and even an opened case with Microsoft) all without success - shame on you Microsoft! I then noticed that using 'Check online for updates from Microsoft Update' was also immediately failing; usually with error 0x80070006. This led me to this site: https://superuser.com/questions/1195688/windows-update-error-0x80070006

Comparing the sc query wuauserv results for broken and working systems showed a difference in the TYPE:

Broken

 Working

I set the process Type to be shared using: sc config wuauserv type= share

Then restart the computer (or you could use sc sidtype wuauserv none if you're doing all this via a remote command prompt using PSEXEC!)

The Feature update then installed successfully from Software Center with no errors.

Error Deploying CDP: ERROR: Communication exception occured. Http Status Code: BadRequest, Error Message: The private key for the remote desktop certificate cannot be accessed.

My environment: Single primary site, recently upgraded to 1802. I want to deploy a CDP.

I first created two self-signed certs, one with PFX and one CER (for the Azure Management portal) as per the documentation.

Then start the create CDP wizard. Walking through the create Cloud Distribution Point and entering my Subscription ID and Management certificate and then the additional details (Region, Site and Certificate file) everything was fine. However when provisioning started cloudmgr.log logged error and it failed to provision:

ERROR: Communication exception occured. Http Status Code: BadRequest, Error Message: The private key for the remote desktop certificate cannot be accessed. This may happen for CNG certificates that are not supported for Remote Desktop., Exception Message: The remote server returned an unexpected response: (400) Bad Request.. SMS_CLOUD_SERVICES_MANAGER  13/04/2018 09:28:56 10808 (0x2A38)

More errors would be created such as: 

ERROR: Communication exception occured. Http Status Code: NotFound, Error Message: No deployments were found., Exception Message: There was no endpoint listening at https://management.core.windows.net/[mystuff]/services/hostedservices/[mystuff]/deploymentslots/Production that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.. SMS_CLOUD_SERVICES_MANAGER  13/04/2018 09:28:56 10808 (0x2A38)

but the indicative error is the first one specifically: "...The private key for the remote desktop certificate cannot be accessed..."

Everything looked fine with my pfx certificate - it was exported, passworded and PSS could see nothing wrong either, so this was annoying!

Reason: The cloud service server certificate (in the second screen of the wizard) private key isn't exported (or readable perhaps).

Solution: Use Open SSL to export the private key and then create a new pfx and reimport back as a new pfx 

• Download openssl
• Export the PFX to a file from your mmc e.g. mypfx.pfx 
• Extract the Key:    openssl pkcs12 -in mypfx.pfx -nocerts -out key.key   <--this is the key obviously..
• Extract the certificate:    pkcs12 -in mypfx.pfx -clcerts -nokeys -out mycert.crt  <---cert without key
• Combine back to pfx and export:     pkcx12 -export -out newpfx.pfx -inkey key.key -in newcert.crt 
• Take newpfx.pfx and use that in the your wizard
• 
  

Cloudmgr.log reports all is well and completes, deploying your CDP.

It's not just me who has had this, see here http://blog.configmatt.com/2017/06/sccm-cloud-management-gateway.html but that page doesn't give the openssl stuff. My PSS engineer said they don't get a whole lot of CDP requests for things, so this may be something they'll update documentation with.