I have long been a fan of using Sysprep's Audit Mode for building my "poor man's" Windows VHD Templates. Over the last year or so, I have had problems with Windows Update not working. No matter what I did, the server would continually hang at Checking for updates for hours, days, even WEEKS at a time (I forgot a server once). It would never time out and it never returned any updates to be installed.
I usually attributed the prolem to something odd I must have done in the lab, but eventually I would have to just give up, complete the sysprep and then later run updates in the deployed VMs. Not my favorite, but with a fresh new ISO being released so frequently I wasn't too bent about it.
Windows Update Hangs in Audit Mode
I generally build a VM, boot from the Windows ISO and then when promoted for a Admin password, I hit Ctrl+Shift+F3 so it reboots, automatically putting me in the system as Administrator while sysprep waits patiently to do my bidding. At that point I run Windows Update a couple times then defrag and sysprep the machine, compress the VHDx and copy it to my VHD Templates folder.
Not being able to install updates on my fresh install of Windows finally got on my nerves enough that I had to figure it out. I tried a bunch of things, like using Gen1 and Gen2 VMs, I tried with and without an ISO mounted, with the dvd drive itself removed, with optional updates on and off, with Automatic installation and Never checking set too. Nothing helped. I'd just see this...
So then I tried to change my process a little.
- Build the VM and boot from ISO
- Install Windows and define the Administrator password (do not enter audit mode!)
- Connect to the network and run Windows Updates (updates work now!)
- Defrag and "cleanup" any temp files
- Use Sysprep to Generalize and Shutdown
- Compact the VHDx, Detach it from the VM and copy the file into the Archive
Our resident SCCM Guru Jesse Garcia has often told me about how he prepares the Windows Client OS to be captured for Operating System Deployment and how Audit Mode is a key step in that process. His method differs from what I've been doing and what is described above, but but after looking at his method it is really tempting to enter audit mode after step 3 so I could delete a "temporary" user account that was used to perform the updates. However, with Windows Server you are actually using the Administrator account, so there's really no benefit in using audit mode here (we're not going to delete "Administrator"). That said, I could change the order of things a bit further so that after Step 2 I manually create a temporary user, then log in with that temp account before proceeding with updates. Afterwards, Audit Mode could be used to delete that temp account and it's files before generalizing.but this works too.
After a bit of digging around, perhaps not surprisingly I discovered I am not the only person to experience this issue; that Windows Update does not work when running in Audit Mode. According to this TechNet Forum thread, alanplum opened a Microsoft PSS case and was told that this is by design. Apparently in Windows 8.1 and WS2012R2, Windows Update will intentionally not install anything if the Out-of-Box Experience (OOBE) has not completed to prevent unexpected reboots during the initial run of OOBE. Since entering Audit Mode during the setup never completes the OOBE, WU never gets the signal that it needs to allow updates to happen.
So, mystery solved. Windows Update is designed to hang when in Audit Mode on Windows Server 2012 R2 and apparently Windows 8.1 as well. Since this is intentional, the onlt thing to do is apply updates first, then use Audit Mode to delete the user profile that installed the updates, then Generalize with Sysprep
Generation 2 Virtual Machines and KB2920189
One more thing I'll mention is that Generation 2 Virtual Machines seem to be throwing an error 800F0922 when trying to install KB2920189 which came out just a few weeks ago.
The problem seems to be a combination of things, but there are a few workarounds, listed below from my least to most favorite.
- The official workaround is to actually install BitLocker because the update "incorrectly expects BitLocker to be installed", but who wants to install features you don't use? https://support.microsoft.com/kb/2962824
- You could just ignore it because Gen2 VM's are not impacted by the issue that the fix addresses, but who likes to see failed updates on their servers?
- Another option is to shutdown the VM, then disable Secure Boot in the VM Firmware settings, install the update then re-enable Secure Boot.
Option #3 worked well for me.
And then, finally, Windows Server 2012 R2 is all up to date and ready for use.