Seeing all of these new benefits Windows 10 1607 had brought to the table, I thought it would be a good idea to finally get something running in my lab environment through SCCM via the Windows 10 Servicing Plans. Initial experience was quite positive as everything went according to the book without the prior issues experienced in SCCM 1511, where the servicing plan would attempt to download every single copy of Windows 10 on every language known to man kind. Thanks Microsoft, my drive was not worthy of that much data so it filled up.
However, this time the challenges started right away by having to patch WSUS once again with KB3159706 which includes a set of additional annoying steps. Then I experienced additional problems on the client side that led me through loops of depressing troubleshooting steps. This time errors 0x8024200D, 0xC1800118 and 0x80240022 kept coming up on my client machine causing a lot of headaches.
Starting from the beginning, the first thing that was noticed was the new Windows 10 Servicing Pre-requisite Microsoft conveniently added onto the SUP component properties window. This was welcome notification instead of having administrators find out they missed a pre-requisite patch after countless hours spent on troubleshooting. Unfortunately the KB3159706 patch required additional steps through the “Server Manager Add Roles and Features wizard” followed by additional configurations changes necessary to the WSUS web.config file explained in the KB article.
Once everything was patched on the server side and configured, the Windows 10 servicing policy could created and scoped down to a specific test client.At this point everything looks good until it is deployed to the machine, the client downloads and fails within the first minute or two. So digging through the logs I found the following errors:
I went through a series of basic troubleshooting steps, and continue expanding further while exhausting my choices noted below.
- Delete, re-create job and re-publish also resulted in the same failures.
- Deploy to another machine also resulted in the same failures.
- Performed the following steps around the same time that appeared to have resolved the 0x8024200D error
At this point I still had no solution and had made a few other angry attempts that nearly destroyed my server. Luckily I backup all my servers and easily reverted to the backup prior to the frustration event. Additional research online found that other folks are having similar problems to what sounded like an issue with the file being encrypted and no key was available to open/access as it was noted on a TechNet Forum post.
The solution? A new Microsoft patch that was being developed around the first time I ran into these issues. However, it is now available through KB3194588 and appears to work quite well. The key item was the initial SQL query that was provided, the first time I ran it I found approximately 400 items and after running the clean-up Powershell commands it came back to zero, which is the ideal number of encrypted updates you want to have.
As explained in the KB article, it appears this behavior impacts those who may have been playing around with their SUP role settings prior to 1607 coming out and not having the KB3159706 patch installed during a sync time. This is quite an unfortunate issue for folks trying to be pro-active at trying out the latest settings. I can only hope that Microsoft continues fine tuning their servicing process through SCCM.