Let me answer the question from the title before we get started, nothing is ever as simple as you think it is going to be. In a large organization there are usually lots of different environmental factors that can impact the installation of software or patches. As PFEs and Consultants for Microsoft, we usually have the daunting task of tracking down the needle in the update installation haystack and it seems like we never hit the same issue twice.
While helping our customer VDI team with the installation of the latest Cumulative Updates for Windows 10 IOT running on thin client hardware, we ran into a challenging situation. The update would install successfully, however, would fail at the reboot and would roll back the installation of the update, giving the dreaded “Failure configuring Windows updates. Reverting changes. Do not turn off your computer” message. As a system administrator, that message usually translates to “put on a pot of coffee, we’re going to be here a while”.
The very first thing to look at when troubleshooting the installation of Windows Updates is the CBS.log file, located in the C:WindowsLogsCBS folder. Reading the CBS.log file can be overwhelming so try to develop some tactics like looking for terms like “failed”, “failure”, or “error” unless you really just like reading long log files. In our case, the first indicator of failure was a message related to the creation of a temporary file during the update installation:
While obscure, the CBS.log entry above does give us a place to start to narrow down the problem.
If you have ever dealt with thin desktop solutions, you know that they usually run a minimal interface and are not configured to retain changes. Their function in life is usually to act as a window through which you view the virtual desktop.In this case, the hardware manufacturer utilizes a small portion of the system RAM to create an overlay which tracks changes to the protected storage drive of the thin client. In this particular case, the space requirement to install the latest cumulative update was too much for the flash overlay area to hold at only about 500 MB.
The solution to this issue was to temporarily modify the %TEMP% and %TMP% SYSTEM environment variables to point them from the overlay RAM Drive (Z:Temp) to the C:Temp directory where there is sufficient space. Word to the wise, make sure that you create that directory or you will be fighting this issue for a while longer. If you forget to create the above-mentioned directory, the error message and failure behavior will look exactly the same as it did when pointing to the overlay drive.
After making the change to the %TEMP% and %TMP% variables, the update installed with no issues. Many thanks to my teammates Bill Almonroeder and David Morillo for helping track this issue down to resolution. No pot of coffee was required if you were wondering.