Deploying Windows 7 - Part 28: Managing Software Updates

by [Published on 20 July 2010 / Last Updated on 20 July 2010]

This series of articles on deploying Windows 7 continues by showing how you can manage software updates during the deployment process.

If you would like to read previous articles in this series, please go to:

You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I am the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit with answers to questions posted by readers, as well as links to the latest resources on Windows 7 deployment, administration and troubleshooting.

When you deploy Windows to target computers, you want those computers to be fully patched right after deployment so they can be secure from the start. This can be a challenge however because security updates and other types of updates are released by Microsoft on a regular basis for their products. Fortunately, you can use Windows Server Update Services (WSUS) to manage the distribution of such software updates during the LTI deployment process and afterwards as well. This article examines how to install and configure WSUS and how to incorporate WSUS into your MDT 2010 deployment infrastructure.

Using WSUS in Build vs. Production Environment

You should use WSUS in both of your MDT deployment environments: build and production. Your build environment is the isolated lab where you deploy and capture images of your master (reference) computers and then test deploying the captured images to all the different types of PCs present in your production environment. Using WSUS in your build environment enables your master images to be patched up to the date of creation of the image. If you don't patch your master images like this, your production deployments will take longer to perform since all available updates will need to be applied to them during deployment.

It can be a chore however to try and keep a master image up to date with patches after the image has been captured. You can use DISM for this purpose, but it takes time and effort to do this (see article 2 in this series for how to use DISM). As a result, you'll probably also want to use WSUS in your production environment so that patches are applied to target computers as they are deployed by MDT. That way, whatever patches aren't already present in the image will be applied during the deployment process so that once deployment is finished the computers are fully patched and secure. On the other hand, another approach you can follow is to use MDT to recreate all your master images each time new software updates are released by Microsoft. If you only have a few master images to maintain, this might be the best approach to follow. In that case, you only need to use WSUS in your build environment and not your production environment. Either way, the steps that follow for installing and configuring WSUS and configuring MDT to use WSUS apply to both build and production deployment environments.

Installing WSUS

On the Windows Server 2008 R2 platform, WSUS is available as an installable server role. For earlier Windows Server platforms, you must obtain WSUS from the Microsoft Download Center. In this walkthrough we're going to install the WSUS role on a member server named SEA-MDT-01 in the CONTOSO domain, which is the server we've been using as our MDT 2010 server throughout this series of articles. Before you install WSUS, you need to install a database for use by the service. This can be either Microsoft SQL Server 2008 Express or the Standard or Enterprise Edition of SQL Server 2005 SP2 or SQL Server 2008. If you don't have an SQL Server or SQL Server Express database available, WSUS will automatically install the minimal Windows Internal Database for its use. Because we'll be installing the WSUS role on our MDT server SEA-MDT-01, which already has SQL Server 2008 Express SP1 installed on it for hosting the MDT database, we'll use this existing database during our installation of WSUS. See article 15 in this series for details on how we installed SQL Server Express on our MDT server.

Begin by launching the Add Roles wizard from either the oobe.exe screen or Server Manager, and select the WSUS role at the bottom of the list of available roles (doing this also automatically installs the Web Server role on your server):

Figure 1: Step 1 of installing the WSUS server role

Begin the WSUS Setup wizard by selecting a location where downloaded updates will be stored on the server (in this walkthrough we are using volume U which is a dedicated volume for storing updates):

Figure 2: Step 2 of installing the WSUS server role

Select the installed SQL Server Express database instance on the server:

Figure 3: Step 3 of installing the WSUS server role

The next screen shows that the WSUS Setup wizard has successfully connected to the SQL server instance SQLEXPRESS:

Figure 4: Step 4 of installing the WSUS server role

We'll use the Default Web Site for the WSUS role:

Figure 5: Step 5 of installing the WSUS server role

Click Next on the confirmation page to finish installing WSUS:

Figure 6: Step 6 of installing the WSUS server role

Configuring WSUS

Once WSUS has finished installing on your server, the WSUS Configuration wizard automatically launches:

Figure 7: Step 7 of installing the WSUS server role

Click Next and optionally join the Microsoft Update Improvement Program if desired:

Figure 8: Step 1 of configuring the WSUS server role

The default configuration is for WSUS to download updates from the Microsoft Update (MU) website:

Figure 9: Step 2 of configuring the WSUS server role

Large companies may choose to set up a hierarchy of WSUS servers so that servers at branch offices obtain their updates from a server at headquarters, which obtains its updates from MU.

Moving forward, specify a proxy server if you have one:

Figure 10: Step 3 of configuring the WSUS server role

Click the Start Connecting button to connect your WSUS server to an upstream server, which in this case will be the MU website:

Figure 11: Step 4 of configuring the WSUS server role

Now select the language(s) for the updates you will be downloading:

Figure 12: Step 5 of configuring the WSUS server role

Select only those Microsoft products for which you want to apply updates during the deployment process. In this walkthrough, we will only download updates for Windows 7:

Figure 13: Step 6 of configuring the WSUS server role

By default all critical and security updates are downloaded, plus definition updates which apply to WSUS itself:

Figure 14: Step 7 of configuring the WSUS server role

If desired, you can download other types of updates to install during the deployment process. A good choice here would be the last two items in the list above, namely Update Rollups and Updates.

The next screen indicates that the default configuration is for you to manually synchronize WSUS when desired:

Figure 15: Step 8 of configuring the WSUS server role

If you want, you can change the option in the previous screen so that WSUS synchronizes on a schedule, for example each night at 2 am.

The next screen is configured by default to begin synchronization immediately, but we're going to deselect the checkbox so that we can perform further configuration:

Figure 16: Step 9 of configuring the WSUS server role

Once the wizard is finished, open the WSUS admin console from Administrative Tools and select Options:

Figure 17: Step 10 of configuring the WSUS server role

Click the Automatic Approvals link on the right hand side of the above screen to open the Automatic Approvals dialog:

Figure 18: Step 11 of configuring the WSUS server role

Click the Edit button to edit the Default Automatic Approval Rule:

Figure 19: Step 12 of configuring the WSUS server role

Click the first hyperlink in the Step 2 box at the bottom. This opens a new dialog that lets you choose which updates should be automatically approved so you don't have to manually approve them. Automatic Approval will be the best choice for organizations that don't have the IT staff resources to be able to verify and test every released update against the matrix of all installed applications (in reality this is most organizations). By default, only critical and security updates are approved automatically:

Figure 20: Step 13 of configuring the WSUS server role

If you configured WSUS earlier to download Update Rollups and Updates, then you will probably want to select the last two checkboxes in the above dialog as well. Click OK to return to the Automatic Approvals dialog, and select the checkbox indicated to enable the rule that automatically approves the types of updates you have specified:

Figure 21: Step 14 of configuring the WSUS server role

Click OK to finish configuring WSUS. 

Synchronizing WSUS

The next step is to synchronize your WSUS server with the upstream server, which in this case is the MU website. In the WSUS admin console, right-click on the Synchronization node and select Synchronize Now:

Figure 22: Synchronizing WSUS

When synchronization is complete, you'll see the result in the details pane of the console:

Figure 23: Results of synchronizing WSUS

Note that "Succeeded" does not mean that all updates have been downloaded. Because WSUS uses BITS to download updates in the background, this can take some time. To check on the progress of downloading updates, select the All Updates node under Updates. Any updates that have an icon in the first column like the bottom two in the figure below are still being downloaded from MU and are not yet available for deployment:

Figure 24: Updates have been downloaded and approved

By selecting the Updates node you can get a quick picture of different categories of updates:

Figure 25: Overview of updates

Additional information can be generated from the Reports node if desired:

Figure 26: Generating reports

At this point WSUS has been configured and updates for Windows 7 have been downloaded.

Configuring MDT to Use WSUS

Now we need to configure MDT so that our target computers will pull updates from WSUS during the LTI deployment process. Open the Deployment Workbench and select a task sequence for either build or production deployment, depending on which environment you are working in. Open the properties of the task sequence and select the Task Sequence tab. Select the Windows Update (Pre-Application Installation) task within the State Restore task group, and on the Options tab for this task clear the checkbox indicated below to enable the use of WU (or WSUS in this case) to patch the target computer during the deployment process:

Figure 27: Configuring a task sequence to use WSUS

Apply the change, then do the same for the Windows Update (Post-Application Installation) task two steps down in the task group, then close the task sequence properties.

Now open the CustomSettings.ini file for your deployment share and add the following line to the [Default] section:


This tells the target computers which server they should pull updates from during the deployment process:

Figure 28: Configuring CustomSettings.ini so that target computers will use WSUS during the deployment process

Click OK to apply the change and we are done. Now try using MDT to deploy Windows 7 to a target computer, and after deployment is finished open Programs and Features from Control Panel, click the View Installed Updates link on the left, and you should see that a bunch of updates have been installed on the computer during the deployment process:

Figure 29: Updates were installed on a target computer during LTI deployment


In the next and final article of this series, we will add Windows Deployment Services into the mix and tie everything together for our LTI deployment infrastructure.

If you would like to read previous articles in this series, please go to:


Featured Links