The quick and easy way to update a template is to convert it to a VM, power it on, set the network settings, then open windows update and update via the internet. This is how I have always done it – it’s quick and easy. When you’re done – remove the network settings, power it down, and convert back to template. It’s best to update your templates at least once every quarter. That way once you deploy a machine from it and it connects to your patching infrastructure, it doesn’t have years worth of patches to catch up on. It will save you time later down the road.
However, this question was recently brought up: “What happens when we specifically decline an update in WSUS?” If we decline it in WSUS but install it on the template, our patching environment could become inconsistent. To stay consistent, our templates should get patched from WSUS just as our production environment is.
This brought up a few concerns and questions. My first question was: “Can WSUS patch machines that aren’t on the domain?” The answer is yes. The next concern was with the “SusClientID” – a registry key that is created that identifies the computer to the WSUS server. If we leave that in our template, WSUS won’t be able to tell any of the computers deployed from the template apart.
Here is the solution I came up with. It is a little more cumbersome but if you want to keep your production environment consistent with your template environment when it comes to updates, this will work great.
First, convert your template to a VM and power it up. Next you are going to manually set the minimum required registry settings for WSUS:
Set the following:
(WUServer and WUStatusServer = http://WSUSservername)
Once you have these set, right click on WindowsUpdate and export the key to your desktop. Next create a batch file (.bat) on your desktop with the following contents:
rem Echo Save the batch file “AU_Clean_SID.cmd”. This batch file will do the following:
rem Echo 1. Stop the wuauserv service
rem Echo 2. Delete the AccountDomainSid registry key (if it exists)
rem Echo 3. Delete the PingID registry key (if it exists)
rem Echo 4. Delete the SusClientId registry key (if it exists)
rem Echo 5. Restart the wuauserv service
rem Echo 6. Resets the Authorization Cookie
rem @echo on
net stop wuauserv
REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v AccountDomainSid /f
REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v PingID /f
REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v SusClientId /f
REG DELETE “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /v TargetGroup /f
REG DELETE “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /v TargetGroupEnabled /f
REG DELETE “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /v WUServer /f
REG DELETE “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /v WUStatusServer /f
net start wuauserv
Now that you have the exported regkey and the clean up script this is all you need to do when you want to update your template:
Convert to VM > power on > set network settings
import regkey (double click) > start the ‘Windows Update’ service (you may have to restart it a couple times)
Go to Control Panel > Windows Update > check to see that it is “managed by your system administrator” (and not going out to the internet to check for updates) > check for updates and install all
After all updates are installed and you do any required reboots, run the clean up batch script (double click) > remove network settings > power down > convert to template
I have 3 different templates (2008R2; 2012; 2012R2) so I copied the exported reg file and the batch file to the administrator’s desktop on each template.
When we [hopefully] deploy SCCM later this year, I will write new instructions for updating templates via SCCM as it will be a completely different process. For starters, SCCM introduces a client that will need to be installed rather than just configuring some reg settings.