Windows Deployment – Advanced Part 2: Using WSUS to inject updates during OS deployment

In this article, I’m going to demonstrate how to configure WSUS to work with MDT (or rather MDT to work with WSUS).

Now, updating the odd computer with the latest updates isn’t really an issue, even on the slowest of internet connections. But what if your trying to update tens, or hundreds of client computers during your image deployment? Every one of those clients is going to individually attempt to contact Microsoft and download necessary updates. You’ll find this quickly bottlenecks your internet feed, even on the fastest of connections.

What’s a WSUS?

No, cast that image that weedy person to one side!


Because we’re talking about Microsoft WSUS!!


Now, hands up who’s installed a fresh build of Windows recently… ? Performed any updates on that build?

Of course you did,  and let me guess, you were presented with several GB of updates to perform!?

Building the odd machine at home, or in a small office isn’t really an issue, it may only take a couple of hours to update, even on a slow connection.

But what if your trying to update tens, hundreds or even thousands of client computers during your image deployment?


Think you’re going to update that lot using your 2mb ADSL connection?

Every one of those clients is going to individually attempt to contact Microsoft and download necessary updates. You’ll find this quickly bottlenecks your internet feed, even on the fastest of connections.

Why not simply download all of those updates ONCE to a central server, and use the bandwidth of your LAN to distribute those updates?

That sounds good! What do I need?

You could configure WSUS on an existing server (say an AD server perhaps, or your Deployment server), but in the interests of simplicity for this series, we’re going to have a standalone server dedicated to WSUS.

We’ll assume you have the necessary server running Windows 2012 R2, and approximately 200GB of free HDD space. I would also suggest 4GB as a minimum in anything other than a lab situation; and for ease of management, the server should be join to AD (make sure your DHCP is using your AD for DNS).

Let’s begin…

On our new domain joined 2012 R2 server, launch Server Manager.

Click on Add roles and features


Run through the wizard and select Windows Server Update Services (from server roles), and then step through the wizard, accepting the default settings, until you reach the content selection screen.


Once you reach the content selection screen, select where you would like to store your updates.

Ideally, you’ll want a 200GB partition for this!


Step through the rest of the wizard until complete.

Next, open WSUS.

On first login, you’ll be asked to confirm where your updates are stored.

Confirm and click run. This may take a few minutes to complete.


Once complete, select close.   You won’t be notified other than the close button becomes clickable. Don’t miss it or you’ll be waiting for a long time!


Run through the wizard that pops up.


Click on Start Connecting. This will pull details down from Microsoft’s update platform. You may find that this takes several minutes, depending on your connection.


What you’ll see next is a set of options asking you how you connect to the internet, what products you want updates for, what languages…

Don’t worry too much about your choices (or if the wizard crashes), you can easily alter these settings from the WSUS Options screen. Either step by step, or clicking on WSUS Server Configuration Wizard.

wsus icon

Click Options from the left menu.


Update Source & Proxy options.

In our demo, we’re leaving these settings on default.

In a corporate environment, you’d likely use WSUS not only to patch your deployment images, but to also keep them patched during their lifecycle.

If you’re running the IT for a multi-site business, you can configure multiple WSUS servers (one in your main office, and one for each remote office). These settings allow you to receive updates, and your approved / blocked update settings from a central source.

You may also use a proxy server which you can configure WSUS to use


Products and Classifications

This screen allows you to choose which products to patch.

I don’t need to tell you, the more products you check, the more space you’re going to need on that WSUS server, and the longer its going to take to download that initial tranche of updates.

For the purposes of this demo, we’re only interested in the products relevant to Windows 8.1.


Flip to the classification tab, tick All Classifications (again, in the real world, you might decide to be a bit picky and only rollout critical updates and security updates).


Update Files and Languages

I’ve unchecked the “Download update files to this server only when updates are approved” option. This server is going to automatically approve all updates (you might not want to do this if you use WSUS to patch your live clients, we’re using WSUS purely to update our deployment images)

Also, do improve install times on our deployment images, check “download express installation files”


Click on the Update Languages tab

I’ve decided that we want only English language updates. This will reduce the amount of patches needed.


Synchronization Schedule

As we want to automate this as much as possible, we didn’t really want to have to perform a manual update to get our patches,

Select automatically, and a time that suits. I’ve also upped this to perform 2 syncs per day, in-case any new patches are released or if the first sync fails.


Automatic Approvals

Click Edit under the update rules tab.


Click on the hyperlink text (step 2), When an update is in….


Select All Classifications, hit ok.


Hit ok.


Tick the Default Automatic Approval Rule, hit ok.


We don’t need to worry about the other options (Computers, Server Clean-up Wizard, Reporting Rollup, E-mail Notifications, Microsoft Update Improvement Program, Personalization, or WSUS Server Configuration Wizard).

Click on your WSUS server name in the left menu, and on the main page, hit Synchronize Now


This will take a while to update (even on a good connection, the first run will take several hours)…

wsus status

Whilst we’re waiting… lets logon to our Deployment server and configure it to use WSUS.

Configuring MDT

On the deployment server, open MDT 2013.

RMB on deployment share, select properties


Add to the rules tab, the [Default] section:


Click Apply, then OK


Select Task sequences,

Select your task, RMB and properties


Task sequence tab

Under State Restore, select Windows Update (Pre-Application install)

Select options and uncheck disable this step

Repeat for Windows update (post-application install)


Click ok.

Update the deployment share.


Launch WDS; and replace your existing boot image.


Testing your WSUS server

Simplist method here is to deploy an image to a VM…

Set the deployment going,  it wont look any different to your usual deployments until….


… you reach the last stages of deployment.

MDT will then look at WSUS for any available updates and inject them into your OS image near the end of the deployment.

The VM is likely to reboot several times to install all the updates.


You can check WSUS to see which computers have connected, and what updates are missing.


of course, you dont have to use WSUS to update if you dont wish to.

Simply dont add the line:  WSUSServer=http://<yourdeploymentservername>:8530 to your your MDT rules.

MDT will then look at Microsoft’s update servers rather than yours.

Of course you dont get the benefit of having a local cache of updates, but at least it still saves you from manually performing the updates.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s