Patch management is one of those often thankless tasks that all too often gets assigned to whomever happened to draw the short straw. I mean if you think about all the different WSUS administrators you’ve ever met, how often do you find them just raving about the job they have to do? Most people really dread the monthly patch cycle with Microsoft, and even though the technologies and the tools to use them are much easier than they were back in the day, still, doing patch management is, in many ways, a tedious exercise in making sure that the right updates end up on the correct machines.
In windows server the WSUS role is taking care of the upadate part. WSUS stands for Windows Server Update Services, which we should take to mean that WSUS runs on servers even though it provides updates to both servers and clients. Now before Server 2008 R2, WSUS was a separate chunk of software you’d download for free from Microsoft. But as of that OS, it was elevated to the status of a built-in server role. So WSUS provides the ability to stage and control updates from Microsoft so that, for example, the IT managers/admins can review update metadata, and the updates themselves before approving and distributing them to designated groups of computer.
This is important because there have been a few occasions in some organizations where certain updates from Microsoft had unintended consequences, something that most IT professionals are severely allergic to.
The approval mechanism is really the main one, but WSUS also lets us perform a certain amount of bandwidth management so that our networks aren’t inundated with update traffic when a large new update becomes available. Also the ability to monitor the updates, see who’s getting them and who isn’t, and to spit out reports on that kind of information is pretty much a requirement in a world where non-updated systems are vulnerable to ever-increasing threats.
Now we should don’t want to have to scan the event logs of individual Windows computers to find which updates got installed and which didn’t. And, by the way, tools such as WSUS become even more useful given the fact that Microsoft in Windows 10 no longer gives users the chance to specify which updates they do or do not want.
Difference between updates and upgrade
An update is a patch for security, reliability, or a bug fix. By contrast, an upgrade contains new features and may even remove some old features. With Windows 10 upgrades issue two or three times per year. Microsoft recently decided to start calling upgrades feature updates, but they don’t do so consistently, so you have to look at the context to figure out what’s being discussed. Anyway, the important point in the context of WSUS is that WSUS can now synchronize and distribute Windows 10 upgrades or feature updates, and this capability is baked into the Server 2016 flavor of WSUS. If you have windows server 2012 and you want to enable support for Windows 10 upgrades then you will need to install KB3095113 update on your wsus server. This update is not required to enable WSUS to sync and distribute servicing updates for Windows 10.
WSUS DEPLOYMENT TYPES
A simple deployment is one in which the WSUS server gets update metadata and updates from Microsoft. An administrator performs testing and approval of those updates after which point they get distributed to WSUS clients. And just as a reminder, a WSUS client can be a server because servers get updates too. And when they do, the server is a client of the WSUS service. Now by the way in terms of the approval process, administrators can also create auto-approval rules for low-risk updates like anti-malware definitions.
A so-called autonomous WSUS deployment is one in which each server can be set up independently with their own WSUS groups and synchronization rules and lists of products and so forth. And each server can get updates and update metadata either from Microsoft or from another WSUS server. Each server can have different administrators who can perform different approvals at different times.
If we want to centralize WSUS administration and management, we might prefer to set up a downstream WSUS system as a replica server in which the files, group definitions, and approval statuses flow from parent to child, although it is relevant to note that the group members do not actually flow to the replica server. You can’t create new WSUS groups on a replica server, nor can you approve updates for distribution or configure auto-approval rules.
WSUS DATA MANAGEMENT
You may ask your self where does the data live in WSUS? To answer on that question we have to distinguish between update metadata and the update files themselves, which reside in two different places.
Database –> The database is where we maintain the metadata about Microsoft Updates. This metadata can live in an instance of the Windows internal database (WID) or SQL Server. Metadata provides information about the update and supplies information for the properties of an update, which helps you determine the usefulness of an update. Metadata also includes Microsoft Software License Terms. The metadata package that is downloaded for an update is typically much smaller than the actual update file package.
Content Location –> The content location is where the actual update files reside assuming we’re staging them, which is optional. Obviously, the actual updates will take more space than the update metadata, so we’ll need to allocate plenty of space. If we don’t have the space, we’re not required to store the updates locally. But if we don’t, then we depend on WSUS clients having decent internet connections so they can retrieve the update files from the internet in a reasonable time.
Microsoft classifies updates in a taxonomy that we can use to restrict what we actually need to download based on what we care about. We can also use classifications to define the scope of automatic approval rules.
- Critical Updates — ( Better name for this should be non-security updates)
- Security Updates — Any important security updates show up under the security updates classification. So stuff that you may see in the security updates category may very well be critical in terms of its importance to your organization’s IT security, but they won’t fall under the critical classification.
- Updates (Non-critical, non-security)
- Definition Updates (anti-virus)
- Drivers (only metadata based on inventory) WSUS actually only downloads metadata for drivers based on the hardware, otherwise, the driver metadata downloads would be humongous and largely unnecessary.
- Feature packs, tools, rollups, and service packs
- UPGRADES ( This is a new category in 2016)
One more thing to discuss before we jump into server manager and install WSUS role.
WUDO (Windows Update Delivery Optimization)
Now for those of you who may have deployed Windows 10, you’re probably aware of something called WUDO or Windows Update Delivery Optimization. This is an operating system service in Windows 10 Enterprise and Education editions that permits peer updating that is the ability of a computer to receive and provide Windows Updates to peer PCs on the same local area network. So this can help keep more traffic on local links and avoid overloading links to your WSUS servers, and it can result in more rapid update deployment that PCs require at least 4 GB of RAM and 250 GB of disk space to participate in the peer updating scheme. So WSUS works with WUDO.
Now when we know all of that we are ready to install WSUS server role and start playing with it.
INSTALL WSUS 2016
Now just like with any service, installing a new role onto a machine requires actually installing that role, and its associated role services. Open server manager and click on Manage –> Add Roles and Features
Before you begin page will pop-up. Click Next
Click next accepting the defaults until you come to Select server roles. Scroll down and check Windows Server Update Services. When we click it, we can see that we’re going to get various other features, .NET Framework, RSAT tools, etc. so go ahead and choose Add Features and Next
We don’t need to add any additional features beyond this, so we’ll click Next again.
On Windows Server Update Services windows click next
Here we have the opportunity to make a decision about how we want to store the database WSUS uses for containing the information that it requires. Now, by default, and in most situations, the Windows internal database is just a perfect location for your WSUS database.
If you would like to store it on SQL server you would need to choose SQL Server Connectivity which corresponds essentially to a copy of SQL server that is either on this machine, or some other machine in your environment.
Once done, click next
Content location selection window, Here we have to determine where we want to store the content that WSUS will be using. If you clear checkbox then updates will come from Microsoft but approvals will still come from WSUS. This might be a good approach if the client systems have a slow WAN connection to the WSUS server but a reasonably zippy connection to the internet.
I will choose to download updates and I will specify the location
Once we’re done with that, the rest of the wizard is relatively straightforward so go through it and complete this installation.
Once that is done you will notice the link called launch post-installation tasks. This launch post-installation tasks view gives me the ability to then go through that post-installation config here for WSUS. Click on it.
Once done click Close.
We still do have a couple of things to configure, we need to configure WSUS to operate in the way that we’re looking for it to do. In order to accomplish that click on Tools –> Windows Server Update Services.
One of the very first things you’ll see, the first time you try to launch the console here, is this configuration wizard that WSUS will make available for you. It’s here where we can make some of the decisions about how we want this server to get its information, how we want it also to disseminate that information, and then also what kinds of information we care about. What kinds of languages, what kinds of products, what kinds of classifications that we’re interested in using the server for.
We can choose whether we want to join the Update Improvement Program. For our purposes, I’ll say No. Click next
Here we can determine where we want to synchronize our updates from. This is my first WSUS server so I will choose Sync from Microsoft Update, click next
I won’t choose a proxy server, because I have no outbound proxy server
here in the next screen, WSUS will complete an initial synchronization, in order to understand exactly what kind of updates are available, so that I can make the appropriate selections. I’ll click the start connecting button to go through the process of essentially just connecting up with Windows, and figuring out what those new categories are and then once we have that updated metadata, we can use that information to help us determine what exactly it is that we’re interested in updating.
Once done, click next
It’s here where we can choose the languages that we’re interested in. Curious little piece of trivia, some of the earlier instances, or versions of WSUS, had far more than just U.S. English as the available language, that was selected by default here in the interface. However, that decision on Microsoft’s part actually created a bit of a problem for early WSUS implementers. Because each additional language you select adds a significant amount of additional data that has to be downloaded every time you download an update. If you think about it, there’s an update for English, there’s an update for French, and another one for German and so on. So be very careful here with this screen. Do not select the top item (Download updates in all languages…), unless you’re absolutely sure that you require it. Because downloading updates only in the languages you require, will greatly reduce the amount of disk space you’ll need to store those updates locally. As you can see here, at least with this version, the English language is the only one that is selected, that’s the only one I’m interested in as well. Click Next
Also in terms of the number of products that you’re interested in downloading, it’s generally a good idea to right-size the number of products that you’re selecting, with the ones that you actually have. And so what this means is that if you don’t have, I don’t know, a BizTalk server in your environment, well then you probably don’t wanna be downloading the updates for BizTalk server. You will notice that all the updates for Windows are selected. I am only interested in Windows 10 and Windows Server 2016 so I will select only those.
In this next screen I can identify the types of classifications for the kinds of updates that I wanna keep under management. Critical updates, definition updates and security updates here will help you for those MSRC alerts that pop out on every patch Tuesday. If you have a need for, for example service packs or feature packs, you can add them. A lot of people don’t necessarily include the drivers for a lot of very good reasons. A lot of time your manufacturer drivers are gonna be more updated than those you’ll see here in Microsoft Update. But these provide you again, the ability to determine exactly what you’re interested in. I tend to at least at first, leave these as the default, because at least it gets me through that monthly patch cycle that has to do with protecting myself against security-related incidents.
Then lastly here, is where I can identify how often I want WSUS to synchronize itself with Microsoft. It is generally a good idea to go through an automatic synchronization at least once a day, if not more. Microsoft tends to release these updates on an every-month cycle, although in later months and years, there’s been a bit of a sea change for Microsoft releasing updates faster than what has, for many years, been the traditional second Tuesday of the month, Black Tuesday release of new updates. I’ll set our first synchronization here to be sometime early in the morning so it happens when I’m not around, and other people are not attempting to use server. And I’ll set a single synchronization per day at that time.
And now we can begin the initial synchronization and click Next and Finish to begin the implementation of WSUS. Sync will take some time so be patient.
When you open console again you will see sync status. Right now mine is at 28 %. You will have to wait until it finish with sync before you move forward.
That’s it. In the next part we will explore the WSUS console, create groups, configure synchronization and move forward with WSUS and update configuration.
Thanks for reading!