After posting about my experience updating Windows 10 to Creators Update via WSUS earlier this year i thought updating to Fall Creators Update should be a breeze. Well, not exactly. There are some issues and quirks i had to deal with.
First of all, our WSUS has successfully pulled Fall Creators Update (1709 version) from Microsoft servers sometime around October 17 and started reporting Needed status for Windows 10 PCs in our network. So i went and declined an upgrade for Windows 7 and 8.1 machines as we are not doing such upgrades. And then approved en_us and en_gb updates for a special group, which i will be putting PCs in to update. We have two versions as there are a few computers in the network using en_gb version (that was a mistake, but now we don’t really want to reinstall them; i wish there were only one EN version..). Then i have added a few testing PCs to that group. When doing Check for updates it pulled the update from WSUS and started preparing it for installation. While PC was showing “Preparing” status, WSUS was showing Failed status for this machine (quirk No.1, but very minor one). After the update installation it still shows Needed status for some time, until it gets new info from PCs. Once PC has prepared Fall Creators Update (FCU or 1709) it shows a popup as shown above. It is different from what was shown last time and this popup is the usual Action Center popup. Although i would like not to have human faces in there as i have to prepare instructions with screenshots and this looks weird. Quirks No.2 and 3 – pressing Restart Now in this popup did nothing on one of my testing machines. I have waited 5 minutes, tried pressing it again, restarting the machine and pressing again. Nothing. The second PC haven’t even showed it at all for some reason. One should hope MS will fix this for the next update (actually, it should be fixed in the FCU already for it to work for the next update). So, i had to use Start > Power button > Update and Restart. This worked fine and FCU install went smoothly on both machines. It took around 10-15 minutes until seeing your desktop (with multiple reboots and waiting for it to finish once you login). As MS is now doing updates with only differences, not overwriting the whole system, it takes almost 2 times less time. This is great.
Quirk No.4. Shortly after marking 16299.15 as RTM build for 1709 version there was KB4043961 cumulative update which fixed issues with removed apps being reinstalled after a restart and a few security issues. It also bumped 1709 build version to 16299.19. After updating test PCs to 1709 i saw this update showing in WSUS as Needed for these machines. But doing Check for updates on them showed no results. I had similar problem before updating to CU (1703) on one of the 1609 PCs. It couldn’t find CU update on WSUS. I had to stop Windows Update service, remove C:\Windows\SoftwareDistribution\ folder and start the service again to fix that. Had to do this again to make it find that KB4043961 update (you can also have similar problems with new updates until you wipe this folder once). This is problematic, if you have to do this for dozens or hundreds of PCs. I sure hope MS will iron out such WU problems after big feature updates in the future. Now i’m trying to come up with some GPO script to stop the service and remove that folder automatically. But it is complicated as only stopping the service sometimes is not enough and you have to disable it and reboot the PC to be able to delete that folder (then enable it again). While playing with the script i have stumbled on the final quirk – No.5 (there may be more, i will update this article as i continue testing of 1709). Apparently, after applying 1709 update it also enables Fast startup, if it was disabled (Settings > System > Power & sleep > Additional power settings > Choose what the power button do). We have this option disabled, so startup and shutdown GPO scripts would work. If Fast startup is enabled, they just don’t run on regular boot or shutdown as the system does a special hibernation instead. In that case GPO scripts would only run on restart. But users usually don’t restart their PCs, they usually shutdown them. We also didn’t see any significant delays in boot with that option disabled. So, now i also have to disable that setting again. I have found a script which can modify registry to disable it (though i haven’t tested it yet):
REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power” /V HiberbootEnabled /T REG_dWORD /D 0 /F
But the problem is, that for this script to run say on startup or shutdown, it already has to be disabled. So, if i should try to disable it with this script, i will have to ask my users to reboot their machines once. Anyway, so far “Windows as a Service” model creates a lot of hassle for admins and it needs to be improved.
Update (2017.11.24): i’ve started deploying 1709 via WSUS in our network a few days ago and another interesting thing came out. But first, thanks to Andreas once again. I have made a GPO disabling Fast startup as he suggested 😉 So, i saw that one PC has already installed 1709 and went to check it. It was able to find and install KB4043961 update without a problem. But, this month there was another cumulative update released – KB4048955, which is now the latest update. And it wasn’t able to find and install this update from WSUS until i have deleted SoftwareDistribution folder. So it looks like not a particular update is problematic, but 1709 is not able to pull the latest cumulative update from WSUS. This doesn’t help, but is an interesting observation.
Update 2 (2017.11.27): it’s getting worse. Out of 10 PCs i have marked to deploy 1709 to 6 are not even seeing 1709 update on the WSUS. Same problem i had with a few PCs when updating from 1609 to 1703. And the solution was the same – deleting SoftwareDistribution folder.. And i guess delete it again to get the latest Cumulative update. Scripting this sounds too complex and error prone (i don’t want to end up with some machines accidentally running in the wild with WU service disabled). I will change my procedure to manual checking and fixing until PC is updated to a feature update and a subsequent cumulative update. Will describe it here.