Windows update services installing
- Install Windows server 2012R2/2016/2019, Update to the latest security patches and service packs.(reboot)
- Give the server a Static IP, gateway. DNS address according the IP Schema for the site.
- Give the Server the correct name and update description.(reboot) SRVSITEWSUS
- Make the server a member of the domain. (reboot)
- Create a separate partition of 250GB to store the updates.
- Check servers’ policies are applied.
- Add the Server in your monitoring tool.
- Make sure the server has an internet connection.
- On your Server, open Server Manager, on the Dashboard, click Add Roles and Features then click next 3 times untill you get “Select server roles box”. In Select server roles box, select the Windows Server Update Services (In the pop-up window, click Add Features)… then click Next…
- On the Select features box, click next…
- On the Windows Server Update Services box, click next…
- On the Select role services box, verify that both WID Database and WSUS Services are selected, and then click Next. (you can run your own database but why? WID is doing fine)
- When the installation completes, click Close…
- Open Windows Server Update Services console, in the Complete WSUS Installation window, click Run, and wait for the task to complete then click Close…
- When asked for the store location point to the second parttion.
2.Configure Wsus Main
3.Configure Wsus Replica
4.Upgrading 2019 and Cleanup
Wsus server upgrade 2019 1809 LTSC
Reason to upgrade
To keep servers secure and compatible with the latest systems within the Company.
Windows update servers are now running the OS 2012R2 or Windows 2016.
The Goal is to upgrade all the servers to Windows Server 2019 1809 LTSC.
WSUS How to Migrate or Upgrade WSUS
There are 3 different types of ways to upgrade WSUS.
- Install the new Server OS, install the WSUS role synchronizing with Microsoft Update, creating your groups, adjusting your settings, and then changing your GPOs over to the new server.
- An In-place upgrade of the server OS, where you just upgrade the OS over top of the current OS, thereby upgrading WSUS to the latest version. You then should check to make sure WSUS uses the same ports (a change from 2008 [80/443] to 2012+ [8530/8531])
- A migration from the old WSUS server to the new WSUS server. This is my recommended way. It is the easiest, and most efficient when not doing an in-place Server OS Upgrade. You get all of the updates, all the approvals, all of the groups, and all of the configuration from the old WSUS server locally so that you don’t have to redownload any of the updates. The sync to the old WSUS server should be fairly fast and you don’t start from scratch, but rather start off where you left on the old server.
To accomplish the migration, install the new WSUS Server as a downstream replica server getting it’s updates from the old WSUS Server (Synchronize from another Windows Server Update Services server in replica mode). Let the downstream sync with the upstream and finish syncing all of the data from the upstream. Then promote it to an upstream by changing the “Update Source and Proxy Server” options window back to Microsoft Update by deselecting replica server, and then changing the radial dot to “Sync from Microsoft Update” and click OK. You’ve now made an exact replica of your WSUS server – change your GPOs over to your new server and you’re done. Don’t forget about those pesky ports – Server 2008 uses ports 80/443 and 2012+ uses ports 8530/8531. Let your systems re-connect with the new server and then you can turn off your old server.
An In-place upgrade of the server OS, where you just upgrade the OS over top of the current OS, thereby upgrading WSUS to the latest version. You then should check to make sure WSUS uses the same ports (a change from 2008 [80/443] to 2012+ [8530/8531])Normally the in-Place upgrade is not the best option but policy’s are pointing to al this servers and groups are in place. Therefore, changing that will have an impact. For the Server its only one role that needs to be upgraded.
The version number comes with the OS, windows 2012R2, 2016 and 2019 has its own version numbers. The Services is a role and therefore integrates in the OS.
Below the screenshots of the different version numbers.
2019 2012R2 2016
- Download Windows Server 2019 1809 LTSC.
- Log on the (one off the) Wsus servers.
- Mount the ISO and Run setup with administrator rights.
- Follow the wizard and choose for online upgrade.
- After installation, reboot the Server and wait for the final configuration.
- Open the Wsus console (start run/Wsus) and start the console local.
- Finalize the pre-post installation and point to the old in place Directory. ( E:\WSUS)
- Run in the Wsus console a new synchronization.
- Run the Cleanup Wizard , one by one each task and final all task at the same time.
- Reboot Server and due another synchronization.
Once a month we need to clean up the database from Wsus. Under options click “Server Cleanup Wizard.”
The Wizard will clean:
- Unused updates and update revisions.
- Computers not contacting the server (30days)
- Unneeded Update files.
- Expired updates.
- Superseded Updates.
To speed up superseded updates to be removed follow below instructions and follow up with a clean-up database wizard.
Although you can use the server clean-up wizard, you may want from time to time to clean manually all superseded updates to clean your WSUS infrastructure.
Open the Windows Update Services MMC then select the All Updates View as you can see below.
Set the display to show the Approval status of ‘Any except Declined’ with a Status of ‘Any’, then Click Refresh.
Right-click in the title bar and Enable the ‘Supersedence’ column to make it visible.
The updates to be declined have one of two particular flowchart symbols for their updates pictured in the attached image. Select the correct updates and Decline them by either right-clicking the selected updates and clicking decline or by pressing the decline button in the action pane.
- No icon: update doesn’t supersede another one nor is it superseded by an update.
- Blue square on top: this update supersedes another update, these updates you do not want to clean…!!
- Blue square in the middle: this update has been superseded by another update and superseded another update as well, this is an example of an update you may want to clean (decline).
- Blue square in the right below corner: this update has been superseded by another update, this is an example of an update you may want to clean (decline).
Make sure you have all the options selected in the wizard and let it run. It will delete the files from the declined updates.
Optional: Automatic Approval Options
In the automatic approval options, under the advanced tab, there is an option to automatically approve update revisions for previously approved updates and subsequentially decline the now expired updates. Company has switched on this option but you still need to decline this once in a while.
After above settings are complete we need to catch up on the windows OS itself.
A straight forward process to update.
Click start and go to Settings. Click update and security and final click Check for Updates.
It needs to make a couple of round trips to come up with the first updates.
If there are no update’s or get and error message, retry “Check for Updates”. Finally you can restart the server and check again for updates.
Once updates are installed, restart the Server.
Sometimes a restart will not work in 2019 1809 from this screen. Restart the server from the start menu.
Check Synchronizations between the Wsus servers.
The Main-Wsusserver needs to sync with Microsoft and the rest of the Wsus servers needs to sync with Main-Wsusserver. After upgrading check the sync and check if Scheduled sync is working after a couple of days.
Final cleanup database after a couple of days.
Run after a couple of days the full Server Cleanup wizard. These should not take longer than 15 minutes.
Installing script to run cleanup wizard and send email to support_windows@Company.com
Microsoft best practice is first clean the databases on the lowest replica servers and work from there to the top.
There are paid scripts and free scripts to automatic clean-up the Wsus database.
We use a free script. (off-course)
The Script itself is a bit outdated but working.
The Scripts can run on the Main Wsus server and run from the down to the replica servers.
We did not choose the script running in that mode as Microsoft best practice is vice versa.
We run the script locally on each Wsus server starting from top down replica servers.
On Sunday we schedule the maintenance for the replica servers on 5:00 in the morning.
The Main-Wsusserver server can be scheduled after, at 11:00 to keep sometime between to finalize first the replica servers.
Main-Wsusserver SRV–Replica servers
- Open task scheduler.
- In task scheduler library right click and choose new task.
- In the general tab, choose name, description, run on system and with the highest privileges.
- highest privileges means in administrator mode.
- On the trigger tab, choose weekly, Sunday, and be sure its Enabled.
- On the Action pane create new and add the program to it.
Program/Scripts is Powershell. The Option highest privileges give powershell the “run as Administrator rights”. Start in C:\Scripts\ and run the add argument to the scripts with the needed options. C:\scripts\Start-WsusServerCleanup.ps1 -email
- Leave conditions and settings on the default.
- Create on all Wsus servers in the C:\ a folder “script”.
- Download the script and copy the script to the folder c:\scripts on all C drives.
- Edit the script and replace the settings with the following below.
$WsusServer = ([system.net.dns]::GetHostByName(‘localhost’)).hostname,
[bool]$TrialRun = $False,
[string]$SmtpServer = “outlook.com.Company.com”,
[string]$From = “wsus@Company.com”,
[string]$To = “windows_support@Company.com”,
[string]$Subject = “WSUS Server Cleanup.”,
There is no need to give server name’s in the scripts as all scripts run locally on the server.
The Script can be download from the website and is stored in the Company Store$ folder.
- Open task scheduler
- Right click the task and choose Export.
Choose a location to save the xml file.
- Copy the *.xml to all Wsus servers.
- Open a remote desktop session with all the Wsus servers and import the task.
Be sure to change the time in the task after importing the task to separate the Main and Replica wsus servers.
The option -email in the command line will sent an email to windows_support@Company.com together with the script email server settings.
The task is running on every Sunday. The task runs on every Wsus server so from every Wsus server we will receive and email.
Subject: Wsus Server Cleanup
The script will keep the database in a reasonable good shape but once in a while (3 month’s) we still need to cleanup and decline superseded update’s. These superseded updates are no longer needed and will give a lot of dataspace back for use.
To cleanup and decline superseded updates, follow above instructions in this manual.
The script has been updated, the information directly below is for the current version of the script.
This script can be scheduled to run the Server Cleanup Wizard on your WSUS server and recursively against all downstream servers. The WSUSServer variable will default to the machine the script is run on if it is not specified:
.\Start-WsusServerCleanup.ps1 -WsusServer “wsus01.company.tld”
Pass the Recursive switch and the script will recursively retrieve and cleanup all downstream WSUS servers:
.\Start-WsusServerCleanup.ps1 -WsusServer “wsus01.company.tld” -Recursive
Not all WSUS servers in a hiearchy neccesarily need to use SSL or the same ports (the previous script assumed this was the case). This version uses WMI’s StdRegprov to read PortNumber, UsingSSL and (if using SSL) ServerCertificateName from HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup. This way the script should be able to work out your WSUS servers settings before calling GetUpdateServer: http://msdn.microsoft.com/en-us/library/aa349325(v=vs.85).aspx
There is a TrialRun parameter that is set to $True in the script. As it stands, the script will not perform the cleanup and will return the following properties:
WsusServer, PortNumber, UsingSSL, Version, Start and Finish. If you included the Recursive switch there will also be a ParentWsusServer property. To give the script teeth set TrialRun to $False. You can either do this in the script or on the command as below:
.\Start-WsusServerCleanup.ps1 -WsusServer “wsus01.company.tld” -Recursive -TrialRun $False
With TrialRun set to false, the cleanup wizard will be called against each server it connects to. Cleanup statistics will be returned with the following additional properties in the output: SupersededUpdatesDeclined, ExpiredUpdatesDeclined, ObsoleteUpdatesDeleted, UpdatesCompressed, ObsoleteComputersDeleted and DiskSpaceFreed.
If you configure the variables below and add the -EmailLog switch, the script can e-mail the results to you.
$SmtpServer = “smtp.company.com”
$From = “email@example.com”
$To = “firstname.lastname@example.org”
$Subject = “WSUS Server Cleanup.”
The column headings will be based on properties returned in the output (dependant on the TrialRun and Recursive parameters).
The complete list of properties are: ParentWsusServer, WsusServer, PortNumber, UsingSSL, Version, Start, Finish, SupersededUpdatesDeclined, ExpiredUpdatesDeclined, ObsoleteUpdatesDeleted, UpdatesCompressed, ObsoleteComputersDeleted, DiskSpaceFreed
The script has been updated, the information below is for the previous version of the script (WSUS_Cleanup_All_Servers.ps1). The script has been attached if you have any issues with the new version.
Based on the following 2 scripts to automate running the Server Cleanup Wizard against WSUS. This script runs cleanup against the parent WSUS server and recursively against all downstream servers. It’s been tested against a single server environment as well as an environment with a parent server, a number of direct downstreams servers and one of the downstream servers had a downstream server of its own. This script sends an e-mail with an HTML table including the following columns for each server it processes:
WSUS Server, Parent WSUS Server, WSUS Version, Start, Finish, Superseded Updates Deleted, Expired Updates Declined, Obsolete Updates Deleted, Updates Compressed, Obsolete Computers Deleted, Disk Space Freed (MB)
There’s a few variables that need tweaking at the top of the script to get it working in your enviroments. See below. If the $TrialRun variable is set to $true, the script will run, collect all the servers it would cleanup including their parent and WSUS version without actually running the cleanup.
#Upstream WSUS server to cleanup and retrieve downstream servers to cleanup
$WsusUpstreamServer = “wsus.company.com”
$UseSSL = $false
$PortNumber = 80
$TrialRun = $false
$SMTPServer = “smtp.company.com”
$FromAddress = “email@example.com”
$Recipients = “firstname.lastname@example.org”
$MessageSubject = “WSUS Server Cleanup.”
The download from and to replica server can be large and therefore can take an amount of time.
To avoid wsus making a long download and ending up downloading in day working time we set the wsus servers to download at:
Main Wsus server: 18:00 Nederlandse tijd.
Replica Servers: 18:00 Time.
The download from the Wsus servers are starting 18:00. When the download is taking longer then the night, we want to reduce the data traffic limit in workhours. If we don’t limit the traffic and there are more replica servers still downloading, the dateline will be overloaded. Therefore unusable for users to work with.
To reduce the Dataline.
- Create a NTFS Group. “GPO GBL Wsus Servers Background Intelligent Agent”
- Make all Wsus servers member of this group.
- Create a Group policy called: “GPO GBL Wsus Servers Background Intelligent Agent”
- Set the policy: Computer Configuration -> Policies -> Administrative Templates -> Network -> Background Intelligent Transfer Service (BITS)
- Configure the settings as below. Ignore bandwidth limits if the source and the destination are on the same network.
- Let the Policy replicate to all domain controllers by waiting 30 minutes.
- Run on every server GPUPDATE and reboot.
- Run gpresult /h result.html to verify if the policy has been applied.
Below is a description on how to create WMI filters for wsus servers instead of using groups.
How-To to Limit WSUS downloads during business hours. The issue is those instructions need to be applied on each WSUS server. With correct WMI filtering and a GPO this can be done across your entire network automatically.
Open GPMC (Group Policy Management Console) and navigate to WMI Filters. Then right click the filters window and select “New” to create a new WMI Filter.
In the new WMI Filter dialog give your filter a name and description. Then click the “Add” button and create the filter itself. Use the Namespace root\CIMv2. The query text is
Select * from Win32_ServerFeature where Name = “Windows Server Update Services”
Save the filter.
Next select the Group Policy Objects, right click an open area and select New to create an empty policy. Give your new policy a descriptive name.
Double-click your new policy to open it. Then set the WMI Filter to be the filter you just created.
Right click the policy and edit it. Then drill down to Computer Configuration -> Policies -> Administrative Templates -> Network -> Background Intelligent Transfer Service (BITS). You will edit the “Set up a work schedule to limit the maximum network bandwidth used for BITS background transfers”
Policy item and enable it. Check the “Ignore bandwidth limits if the source and the destination are on the same subnet. Select your Work Days. Select the Daily Work Hours. In the Work Hours, start the time period one hour before the normal start of the day and end one hour after the normal end of the day. Do this to give Windows a chance to complete a background file transfer prior to the start of the day. Schedule changes only occur between files. (The settings shown are for my home network.)
Set all limits to 10 Kbps. You want a small amount of transfer to occur during the day so you can confirm that updates are downloading. Setting the bandwidth to 1 or 2 Kbps will result in 2 Kbps. Setting to 0 will stop transfers.
Set the non-work hours to the default of 0/Unlimited for all settings. This will download as fast as your internet pipe will support.
Click OK to save and close the settings and then close the policy object editor. Since this policy has no User Configuration you can improve performance by selecting the GPO Status “User configuration settings disabled”.
Since this policy will only impact WSUS servers you only need to link it to those OUs that have WSUS Servers. You could also link it to the root of your domain and that will still only apply to WSUS servers but all your workstations will need to process the WMI filter to discard this policy.
WSUS servers with local update storage are a perfect example of using local disk caching to prevent your workstations from flooding your WAN with downloads. The problem is that even a single WSUS server can flood a WAN unless you throttle the WSUS server as well. You don’t want to throttle all your systems because Windows Updates uses BITS to download from the WSUS server. Throttling the local download will effectively prevent your workstations from receiving updates from WSUS.
For the curious, the registry settings impacted by this GPO are in HKLM\Software\Policies\Microsoft\Windows\BITS\Throttling. By default this registry key doesn’t exist.