WSUS on gal.vin

Installing and Configuring Windows Server Update Services (WSUS) with Windows Server Core

Mon, 20 Mar 2023 17:00:00 +0000

Windows Server Update Services (WSUS) can use a lot of resources, so why not use Windows Server Core and make the most of the resources you have. In this post I’ll go through the initial steps on how to deploy and configure a WSUS server using command line and PowerShell. This guide is also suitable for regular GUI Windows Server installations.

Installing Windows Server Core

Boot the server from the Windows Server media and on the “Select the Operating System you want to install” screen, select the option “Windows Server Standard” or “Datacenter” edition. The other options with “Desktop Experience” in brackets are the options for the other server editions with a GUI also installed.

Please note: You can no longer add and remove the GUI (Desktop Experience) with Windows Server 2016 as you could with Windows Server 2012 & 2012 R2. This is due to numerous problems with keeping the installation and removal process consistent with updates. With Windows Server 2016, the only way to add or remove the GUI is to re-install and select one of the server editions with the “Desktop Experience” option.

Initial Configuration

Once the install process has completed, you will be prompted with a command line window, and asked to set the Administrator password.

Set the Administrator password.
Type sconfig to get the Server Configuration menu. It’s pretty straight forward. In the Server Configuration menu, you can configure all the basics required for the server.
For the first Domain Controller in the new forest, you’ll need to configure at least the Network Settings - IP address, subnet mask, gateway, and DNS.
You may also want to configure the computer name. Configuring the computer name will require a restart.
After the restart, log in to the server with the Administrator password you set in step 1.

Tip: “sconfig” is also present in the GUI version of Windows Server, making initial configuration of new servers easier.

Additional Storage Configuration

You may want to configure additional locally attached disks or iSCSI/MPIO storage. Creating new volumes that are locally attached can be done via the diskpart command line tool. Here’s the series of commands to create a new, NTFS formatted volume, with the drive letter of E:\ and the name “Data”, from a second disk in the server using the diskpart tool. First, run diskpart from the command line, then use the following commands:

list disk
select disk 1
online disk
attributes disk clear readonly
clean
convert mbr -or gpt
create partition primary
select part 1
active
format fs=ntfs label=Data quick
assign letter E:
list volume

iSCSI storage can be configured using the same GUI tools you would use in the GUI version of Windows Server. The MPIO feature must be installed before the tool is available. You can do this via PowerShell:

`1`	`Install-WindowsFeature -Name 'Multipath-IO'`

When MPIO is installed you can load the MPIO utility using mpiocpl. For the iSCSI utility you can use iscsicpl. iSCSI is installed as part of the base Windows Server feature set.

Install Windows Server Update Services (WSUS)

The following PowerShell command will install the WSUS feature:

`1`	`Install-WindowsFeature -Name UpdateServices -IncludeManagementTools`

Now we need to run some post install tasks. We’ll create a directory for the WSUS content on the E:\ drive.

`1`	`MD E:\WSUS_Content`

To configure WSUS to use the directory we just created and the Windows Internal Database (WID is based on SQL Express), run the following command:

1
2

CD "C:\Program Files\Update Services\Tools"
.\wsusutil.exe postinstall CONTENT_DIR=E:\WSUS_Content

Alternatively you might want to use an external SQL server for the WSUS database, if so run the following command instead:

1
2

CD "C:\Program Files\Update Services\Tools"
.\wsusutil.exe postinstall SQL_INSTANCE_NAME="SQLSERVER\SQLINSTANCE" CONTENT_DIR=E:\WSUS_Content

WSUS is now running and able to be configured further. This is possible with PowerShell, but not as straightforward as the installation above so we’ll be using the WSUS MMC on a remote computer or on the server itself if you installed Windows Server with the Desktop Experience.

To obtain the WSUS MMC on a remote computer we’ll need to install the Remote Server Administration tools (RSAT), run the following command in an elevated PowerShell session:

`1`	`Get-WindowsCapability -Name RSAT* -Online \| Add-WindowsCapability -Online`

To view WSUS reports you’ll also need to download and install the following:

Microsoft Report Viewer 2012 Runtime redistributable
Microsoft System CLR Types for Microsoft SQL Server 2012: x64 version, x86 version

Configuring Windows Server Update Services

Once you have downloaded and installed all the software listed above on our admin PC, you can continue with the configuration.

Open the Windows Service Update Services Microsoft Management Console (WSUS MMC).
You should see a “Before You Begin” wizard. Click Next.
Join the Microsoft Update Improvement Program if you wish.
Choose Upstream server, as this is the first WSUS server we’ll choose “Synchronize from Microsoft Update”.
Specify the Proxy Server settings if needed.
Click “Start Connecting”.
Select the applicable languages for our environment.
Select the applicable Products. I recommend selecting all products as we’ll only be downloading updates that we actually need.
Select the Classifications. I recommend selecting all except Drivers and Driver Sets. Drivers in WSUS increase the size of the database immensely.
Configure the Sync Schedule. I recommend leaving this on manual until setup and synchronisation has been completed.
Check the Begin initial synchronization box. This may also take a while.
Click Finish.

Once the initial configuration is complete, now we can start to configure WSUS for every day operation.

In the WSUS MMC go to the Options node.
Setup a Synchronization Schedule. I recommend once or twice a day, out of regular hours. Click OK.
Go to Automatic Approvals.
There’s a built-in rule to automatically approve Critical and Security updates, meaning that they will be downloaded and distributed via WSUS without any admin interaction. I recommend enabling this, but don’t run the rule.
You may also want to add a rule for Definition Updates from Exchange, Office, and Windows Defender if applicable to you. Click OK.
Now go to Computers.
Set the option here to Use Group Policy or registry settings on computers and click OK.
Go to E-Mail notifications and enable them if you want status reports and Emails about the new updates that have been synchronised. Click OK.
In the WSUS MMC, go to the Computers node.
Create the computer groups that you require here. I recommend a ‘pilot’ group and a ‘regular’ group both for client devices and servers.

Configuring Group Policy

To enable our clients to get updates from WSUS using the settings above, you’ll need to configure the group policy for them.

Open the Group Policy Management MMC and go to the Group Policy Objects node.
Right click on the node and select New to create a new GPO for WSUS. Give it a name and click OK.
Right click on the new GPO and click Edit to open it.
Navigate to Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Update/Manage updates offered from Windows Server Update Service
Go to the setting “Specify intranet Microsoft update service location”.
We’ll configure both “Set the intranet update service for detecting updates” and “Set the intranet statistics server” to http://wsus-server-name.contoso.com:8530
Go to “Enable client-side targeting” and enter the name of a group that you created in WSUS.
For multiple groups, repeat steps 2 - 7 for each group.
You can use Active Directory Security Groups to control which client devices have read access to the GPO with the desired WSUS group configuration.

There are lots of other settings in GPO to configure Windows Update that I recommend taking a look, specifically “Configure Automatic Updates” located in Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Update/Manage end user experience which controls when client devices install updates.

Managing Updates

After some time (approximately 24 hours) our client devices should have contacted the WSUS server and be in the correct group. Now we need to approve the updates required for our environment.

On the overview of our WSUS server, click on “Updates needed by computers”.
Change the drop down menu “Approval” to “Unapproved” and click “Refresh”.
Right-click on the Title bar and enable the “Supersedence” column.
Click on the very tiny “Supersedence” column to sort the updates by Supersedence.
Approve the top critical, security and any other updates you want to be installed on our devices.
Once the devices have downloaded, installed, and reported back to the WSUS server, we’ll have a better idea if any more updates are required.

Maintenance and Troubleshooting

Keeping WSUS running over time requires some maintenance. I created a custom PowerShell script that runs every day to perform the maintenance on the database. More specifically it declines and deletes old updates, and old computers. It can also send a notification over e-mail or a webhook with information about it’s clean up run. I’ve posted about it here.

You can also clean up the WSUS database manually using the “Server Cleanup Wizard” found in Options. You can also run this via PowerShell:

1
2

Get-WsusServer -Name Wsus-Server-Name -PortNumber 8530
Get-WsusServer | Invoke-WsusServerCleanup –CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates

You may encounter an error when trying to connect to the WSUS server using the MMC - Error: Unexpected Error, appears as Event ID 7053 in Event Viewer.

I’ve known this error to occur frequently. One fix is to navigate to %appdata%\Microsoft\MMC and delete the wsus file and then try connecting again.

IIS Configuration

I highly recommend configuring these IIS AppPool settings relating to WSUS. In an elevated PowerShell session run the following commands:

Import-Module WebAdministration
Set-ItemProperty -Path IIS:\AppPools\WsusPool -Name queueLength -Value 25000
Set-ItemProperty -Path IIS:\AppPools\WsusPool -Name cpu.resetInterval -Value "00.00:15:00"
Set-ItemProperty -Path IIS:\AppPools\WsusPool -Name processModel.idleTimeout -Value "00.00:00:00"
Set-ItemProperty -Path IIS:\AppPools\WsusPool -Name failure.loadBalancerCapabilities -Value "TcpLevel"
Set-ItemProperty -Path IIS:\AppPools\WsusPool -Name recycling.periodicRestart.privateMemory -Value 0
Set-ItemProperty -Path IIS:\AppPools\WsusPool -Name recycling.periodicRestart.time -Value "00.00:00:00"

In the IIS Manager these PowerShell commands change the following values:

WSUS -> Application Pools -> WsusPool -> Advanced Settings

General:
Queue Length: 25000

CPU:
Limit Interval (minutes): 15

Process Model:
Idle Time-out (minutes): 0

Rapid-Fail Protection:
“Service Unavailable” Response: TcpLevel

Recycling:
Private Memory Limit (KB): 0
Regular Time Interval (minutes): 0

Finally, you can also try the following command, if needed:

1
2

CD "C:\Program Files\Update Services\Tools"
.\wsusutil.exe postinstall /servicing

Support My Work

If you would like to support me, please check out the link below.

PayPal

If you have any questions or comments, please leave them below.

Thanks
-Mike

Altering an MDT Task Sequence to Update from Windows Update

Sat, 11 Aug 2018 09:29:11 +0000

I’ve been revisiting my MDT process as I wanted to try and use Windows Update to get drivers during deployment - by itself this is not a problem, I can just remove the WSUSServer=http://wsus:8530 configuration from the CustomSettings.ini.

However as the device is added to the domain, Group Policy will configure the device to use the local WSUS for updates, this is desired as I still want to use WSUS for future updates, but I want to use Windows Update during deployment. I’ve a few options here:

Move Domain Join to later in the Task Sequence, after Windows Update

I could have done this, however some of the custom scripts might need the domain and it seems like a huge change in the process which could possibly cause more problems.

Always ensure that the computer account is created in an OU without the WSUS GPO enabled on it, or for existing accounts ensure the account is moved or deleted

This is a small task but it has time consuming repercussions if not done or forgotten about. The move could be scripted or something similar, but again it’s a time consuming task for a quick configuration change.

This is what I settled on, at least for now: In the Task Sequence, just before the Windows Update items, delete the registry keys that configure the device to use the local WSUS. Without these it will check Windows Update for updates and drivers. I wrote a short .bat script to delete the registry keys.

1
2
3

REM Remove MDT WSUS Reg Entries
REG DELETE HKEY\LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v "WUServer" /f
REG DELETE HKEY\LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v "WUStatusServer" /f

In the Task Sequence I created two items:

You should set “Continue on error” on the items, at least the second one as otherwise the Task Sequence will fail due to the script failing to remove the registry entries that may no longer exist. I’ve only tested this on a couple of newer devices, they both had a lot of drivers missing and required a few reboots during the update/driver installation process, but it appeared to work. I apologise for the hastily thrown together post, but hopefully this might help someone else.

If you have any questions or comments, please leave them below. Thank you.

-Mike

Rethinking The Need For Windows Server Update Services (WSUS)

Sat, 11 Aug 2018 09:24:27 +0000

Windows Server Update Services, along with a growing list of other traditional Microsoft server products, seems to be in ‘maintenance mode’ at best. It’s been on my mind as to whether they’re going to release a cloud based version in Azure (unless they already have something like that and I’ve missed it) or if they’re going the route that I think they are: just update from the internet and don’t worry about it, which seems to be the answer when looking at Windows Autopilot. As long as the OS is a modern Windows OS (Windows 10 or Windows Server 2016 based) updates seem to better and more focused on drivers and cumulative updates. The days of Silverlight being installed on your server seem to be over. A little while ago I saw a comment on reddit about ditching WSUS altogether and going straight to Microsoft Update over the internet - if the bandwidth was available. The commenter suggested that if you had ~500Mbps and up you should be fine, although I would suggest that another factor to consider is how many devices you have that will be getting updates. My previous job had been at a place with only 100Mbps internet for ~1000 devices, so obviously this would have been out of the question. At my current post, the bandwidth is much, much greater and so I started to seriously consider it.

Apple’s OS X Server had an update manager back in the day although I wouldn’t be surprised if that’s not available anymore, and Adobe used to have a product for managing updates too - but again I’m not sure if that’s currently available these days. Google don’t have an on-prem update service for Android devices and so I had to honestly ask myself why continue to use WSUS? Now, I’m not crazy. I accept that generally we have a lot more Windows devices than Google/Apple/or Adobe software and perhaps you do want that control over which updates are deployed and I’m not going to be dropping WSUS on Monday morning, but I have started looking at my deployment process for Windows 10 and Windows Server 2016 to use WU for updates and not my local WSUS. A benefit of this specific case is that driver installation can be done much more easily as Windows Update has a pretty good driver store and this will be a huge time saver for me. Again, I understand problematic drivers do get through into WU and so this isn’t going to work for every device, but if it saves time when preparing for new devices to be deployed then I think it’ll be worth it. For any problematic devices I can still use the ‘total driver control’ method I currently use. Also, consumer devices, Microsoft’s Surface range and another devices which are off site do currently get drivers/firmware etc. from WU and they seem to be doing just fine. Maybe this is the future, at least for some. It’s up to you.

If you have any questions or comments, please leave them below.

-Mike

Upgrading to Windows 10 1703 (Creators Update) with Windows Server Update Services (WSUS)

Wed, 23 Aug 2017 22:34:51 +0000

As Windows is now delivered ‘as-a-service’ with major updates being released biannually, you may want to push out these major updates using WSUS. In previous posts I’ve covered deploying Windows 10 1703 (Creators Update) as a clean install with Microsoft Deployment Toolkit and also how to perform an upgrade to Windows 10 1703 using MDT. In this post, I’ll walk through the process of pushing out the upgrade to Windows 10 1703 using WSUS. I’m going to assume that you already have Windows Server Update Services set up. If you don’t, don’t worry here’s a walkthrough I made previously.

Prerequisites

I have created a Computer Group in WSUS called Upgrades and assigned computers to it using Group Policy. The Windows Updates settings in Group Policy are set to automatically install any updates I approve in WSUS at a specific time, everyday. For this walkthrough I’ll be upgrading two Windows versions: a Windows 7 install and a Windows 10 1511 install, just to show the differences. Both installs are Hyper-V VM’s and are fully patched. The upgrade to Windows 10 1703 will be deployed from the WSUS server running on a fully patched Windows Server 2016 Hyper-V VM. Both the Windows 7 and Windows 10 1511 VMs have a local profile for a domain user account, with lots of data stored locally on the PC and several pieces of software installed such as Flash, Google Chrome, Office 2016, Adobe Reader and VLC.

Upgrading Windows 7 to Windows 10 1703 with WSUS

Let’s upgrade the Windows 7 install first. This update requires user interaction on the Windows 7 install, so I wouldn’t personally recommend this method to upgrade all of your old Windows 7 devices to Windows 10, but for devices that need to have software and data persevered it may be preferable to a clean install.

Finding and Approving the Update for Windows 7

We need to find the relevant update in WSUS. For my Windows 7 VM, it is listed as Windows 7 and 8.1 upgrade to Windows 10 Enterprise, version 1703, en-us, your language and edition may vary though.

Expand the server node in the WSUS console.
Right-click on Updates, and select Search in the menu.
In the Search box, under the Updates tab enter the name of the update that is appropriate for you. Please note the edition and language may be different from my example above.
When the search completes, you should have a few results.
Right-click on each of the updates and select Revision History.
You’ll want the most recent Revision Number. For my example above, it’s 201.
Right-click on the update you wish to approve, and select Approve.
Choose the Computer Group you wish to Approve the update for and click OK. Please note: depending on your configuration this will download and push out the upgrade to Windows 10 on all devices in the group.
Close the Search box, and WSUS should be downloading the update to Windows 10 1703. It is approximately 5GB in size.

Once the update has downloaded, it will be available to the devices it has been approved for.

Performing the Upgrade on Windows 7

On my Windows 7 VM, I logged in as my domain user and checked for updates. It moved to the Upgrades Computer Group I had created for it in WSUS, but the Windows 10 1703 update wasn’t downloading. In Windows Update it reported as failed with the error code: 0x80240020, and in WSUS the computer was reporting the update installation as failed with the same error code also. After waiting for 24 hours and trying a few tricks (like resetting Windows Update), I had to edit the registry to get the Update to work.

Go to the following registry key:

`1`	`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade`

Create a new DWORD (32-bit) Value with Name: AllowOSUpgrade and set the Value: 0x00000001. After creating this registry key, I went to Windows Update and it reported that it was ready to install the upgrade to Windows 10. I selected to to perform the upgrade and after downloading I was presented with a few screens asking if I wanted to proceed with the upgrade. The familiar Windows Update install screen appeared on shutting down Windows 7 and upon reboot the now even more familiar Windows 10 update install screen was displayed.

After several reboots and a screen asking about Privacy Settings, I was presented with the Windows 10 1703 log in screen. I logged in as my domain user which had a local profile on the VM and all my data and programs were there. When I logged in I was greeted by the “first run” screens that all new users receive when they log in to Windows 10 for the first time. Some of the personal customisations where there, such as the taskbar icons, but they were merged with the default Windows 10 taskbar icons. Sometime later when the VM checked for Windows Updates again, the latest updates for Windows Defender and the most recent Cumulative Update was installed, bringing Windows 10 1703 right up to date.

Upgrading Windows 10 1511 to Windows 10 1703 with WSUS

The update for existing versions of Windows 10 doesn’t require user interaction, it installs like all other Windows 10 updates preserving user data, profile customisation and installed software.

Finding and Approving the Update for Windows 10 1511

In WSUS the update for my Windows 10 1511 VM is listed as Feature update to Windows 10 Pro, version 1703, en-gb your language and edition may vary though.

Expand the server node in the WSUS console.
Right-click on Updates, and select Search in the menu.
In the Search box, under the Updates tab enter the name of the update that is appropriate for you. Please note the edition and language may be different from my example above.
When the search completes, you should have a few results.
Right-click on each of the updates and select Revision History.
You’ll want to select the update with the most recent date under the Revised heading. For me it was 27/07/2017.
Right-click on the update you wish to approve, and select Approve.
Choose the Computer Group you wish to Approve the update for and click OK. Please note: depending on your configuration this will download and push out the upgrade to Windows 10 on all devices in the group.
Close the Search box, and WSUS should be downloading the update to Windows 10 1703. It is approximately 5GB in size.

Once the update has downloaded, it will be available to the devices it has been approved for.

Performing the upgrade on Windows 10 1511

I booted up the Windows 10 1511 VM and left it on the log in screen. The VM contacted the WSUS server and moved it’s computer object to the Upgrades Computer Group. Sometime later the VM rebooted from the log in screen and began the upgrade process.

After several reboots during the upgrade, the VM booted to the Windows 10 log in screen. I logged in with my domain user which already had a local profile on the VM, and was greeted with the “first run” screens that new users receive when they log in to Windows 10 for the first time. Despite these screens appearing the data and software had been migrated and the customisation I had done as the user of the Start Menu and Taskbar had been preserved, with the exception of the Store and Edge icons had been re-pinned to the Taskbar. Sometime later when the VM checked for Windows Updates again, the latest updates for Windows Defender and the most recent Cumulative Update was installed, bringing Windows 10 1703 right up to date.

If you have any questions or comments, please leave them below.

-Mike

Windows Server Update Services Configuration Tweaks For Improving Performance

Sat, 29 Apr 2017 16:33:14 +0000

Update 2018-04-20: I’ve rolled the information in this post and updated it, into a new post about setting up a WSUS server from scratch on Windows Server 2016 Core. The post is also suitable for a regular Windows Server 2016 server with a GUI. You can read it here.

I’ve been dealing with some issues with a WSUS server recently. It services around 1000 devices, mostly Windows 10 with some Windows 7, Windows Server 2016/2012 R2/2012 and 2008 R2. The WSUS server provided updates for a variety of Microsoft products including Office, Exchange, SQL, Visual Studio, Windows Defender to name a few. The WSUS server is running on Windows Server 2016 Standard which is WSUS version 10.0.14393.1066 although I’m sure these configuration tweaks could benefit previous versions too. The WSUS database is the Windows Internal Database. The issues I’d been experiencing were the Error: Unexpected Error/Reset Server Node (Event ID 7053) issue, generally bad performance, and Windows Update timing out when searching for updates (0x8024401C).

Thankfully the issues were easily resolved, here’s what I found. Firstly to tackle the performance issue. I’d setup a Scheduled Task to run a PowerShell script, weekly, to clean up the WSUS database, but this had stopped running due to a username/password error. This was easily fixed. As the script had not run in a few weeks I sensed that the script was going to need some time to run, so I decided to increase the specification of the WSUS VM first. The number of clients that it was expected to service had increased over time too, so I felt it was only right I do this. It was running on 2 vCPUs and 4GB RAM, I increased this to 6 vCPUs and 8GB RAM. Once I’d done this, I ran the script. After an hour or so, it failed which I consider to be normal when database maintenance hasn’t been done in a while. I ran the script again and after a few hours it completed successfully. I increased the schedule of the script to run daily instead of weekly. I also updated the script to add logging and to email the log when it had completed running - something I had been intending to do but not got around to.

Here’s the completed script for you to use. The logging and email sections of the script follow the same conventions I’ve been using for my Image Factory and Hyper-V backup scripts.

# -------------------------------------------
# Script: wsus-maintenance.ps1
# Version: 1.1
# Author: Mike Galvin
# Date: 24/04/2017
# -------------------------------------------
 
##Set Variables
$wsussrvr = "wsus1"
$wsusport = "8530"
 
##Set Log Location
$log = "E:\scripts\wsus-maintenance.log"
 
##Set Mail Config
$toaddress = "it@contoso.com"
$fromaddress = "$wsussrvr@contoso.com"
$subject = "WSUS Maintenance"
$mailserver = "mail.contoso.com"
 
##Start Log
Start-Transcript $log
 
Get-WsusServer -Name $wsussrvr -PortNumber $wsusport
Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates
 
##Stop Log
Stop-Transcript
 
##Send Mail
$body = Get-Content -Path $log | Out-String
Send-MailMessage -To $toaddress -From $fromaddress -Subject $subject -Body $body -SmtpServer $mailserver
 
##END

Now that the general performance and house keeping had been done I left the server along to see how things went for a a day or two. After a day performance was better but I still had some timeouts with Windows 10 clients detecting updates. On previous versions of WSUS I’d always tweaked the IIS Application Pool settings and so far hadn’t had to do that with the Server 2016 version, so I decided to make some changes there.

Here’s the changes I made

Changed the Private Memory Limit (KB) to 0 - This actually removes the memory limit. I’d actually suggest making it slight less that the memory available on your server, but I’ve not had any issue from setting this to 0 yet.

Change the Service Unavailable Response from HttpLevel to TcpLevel - The documentation states that change this to TcpLevel will reset the connection rather than return a HTTP 503 error. I found this via a Google Search and haven’t had any issues since making this change.

Change Limit Interval (minutes) from 5 to 15 - This specifies the reset period for the CPU monitoring and throttling limits for the application pool.

Change the Queue Length from 1000 to 2500 - This increases the queue length for the application pool.

I’m not convinced that I needed to do all four of these changes. I think the changes to the Private Memory Limit and Queue Length were necessary but I’m not so sure about the others. I’d suggest that you might want to show more restraint that I did at the time and make one change at a time to see if it solves the issue.

After making these changes the performance of the WSUS server was greatly increased and the Windows 10 clients detected updates without issue, and continue to as I write this.

If you have any questions or comments, please leave them below.

-Mike

Stuck Windows Updates From Windows Server Update Services (WSUS) On Windows 10 1607/Windows Server 2016

Tue, 08 Nov 2016 19:53:50 +0000

If you’ve installed a fresh install of Windows 10 1607/Windows Server 2016 recently, you may have experienced a problem when it tries to download and install updates from your local WSUS server - specifically, it doesn’t, it gets stuck. You’ve tired rebooting, stopping the BITS and WU services, deleting %systemroot%\SoftwareDistribution but nothing seems to work. Both Windows 10 1607 and Windows Server 2016 require a cumulative update that fixes this specific issue. You can of course just download the update off Microsoft’s WU servers but if you’re using MDT then you can download the update separately, and add it to MDT to push out during the install phase of the Task Sequence. You can use any Windows 10/Windows Server 2016 Cumulative Update released for Windows 10 1607, the more recent the better.

Update 16/10/2017: If you’re experiencing stuck updates (or incredibly slow during a Task Sequence) with Windows Server 2016 but not Windows 10 1607 and they are both serviced by the same WSUS server, the cause may be due to Express Updates being enabled.

Update 25/04/2017: The previous CU I listed here is now gone from the Update Catalog. Here is the most recent one I’ve tested: https://www.catalog.update.microsoft.com/Search.aspx?q=kb4015217. As before the CU is for both Windows 10 1607 and Windows Server 2016 so you don’t need to download both versions.

KB4015217 info from Microsoft - https://support.microsoft.com/en-us/help/4015217/windows-10-update-kb4015217

Original Post To build it into your MDT install sequence, download the update from the Microsoft Update Catalog and follow the steps below. Please note that the update for Windows 10 x64 and Windows Server 2016 is the same - you only need to download one of them.

Import The Update

Go to Deployment Workbench and create two new folders under the Packages node, one for Windows 10 1607 x64 and one for Windows Server 2016.
Right click on the Windows 10 1607 x64 folder you just created and select Import OS Packages.
Browse to the location of the update (you will need to put it in a folder by itself) and click Next through the wizard and wait for the Update to be imported.
As this update is the same for both Windows 10 1607 x64 and for Windows Server 2016, you can right click on the imported package and paste it into the Windows Server 2016 folder.

Create A Selection Profile

In Deployment Workbench, go to the Advanced Configuration node and expand it, then go to the Selection Profiles.
Right click and create a new Selection Profile. Name it Windows 10 1607 x64, tick the Windows 10 1607 x64 folder under Packages and click Next through the rest of the wizard.
Repeat the steps above for a Windows Server 2016 Selection Profile choosing the Windows Server 2016 folder.

Enable The Selection Profile In A Task Sequence

Create a Standard Task Sequence to install Windows 10 1607 x64.
Right click on the Task Sequence, go to Properties, go to the Task Sequence tab.
Expand the Preinstall node, and select the Apply Patches item. In the Properties tab on the right, under Selection profile, change it to Windows 10 1607 x64.

The Task Sequence will now deploy Windows 10 1607 x64 and install the Cumulative Update as part of the build.

If you have any questions or comments, please leave them below.

-Mike

Installing Windows Server Update Services from scratch!

Fri, 28 Oct 2016 17:23:24 +0000

Update 2018-04-20

I’ve rolled the information in this post, and updated it, into a new post about setting up a WSUS server from scratch on Windows Server 2016 Core. The post is also suitable for a regular Windows Server 2016 server with a GUI. You can read it here.

Update

I’ve tested and updated this post for Windows Server 2016.

In this post, I’m going to walk through setting up a WSUS server from scratch on Windows Server 2012 R2 or Windows Server 2016. I will not be covering WSUS with System Center Configuration Manager, just a standalone WSUS installation.

Here’s the specification of the Virtual Machine I’m using for this walk through:

Hyper-V, Generation 2, V8.0 VM
4GB non-dynamic RAM
Dynamically expanding 100GB VHDx for C:\ drive
Dynamically expanding 100GB VHDx for E:\ drive
Windows Server 2012 R2 Standard/Windows Server 2016 Standard

Preparation

First we’ll download the prerequisites. To view reports from WSUS, you’ll need the following:

For Windows Server 2012 R2: Microsoft Report Viewer Redistributable 2008 - requires .NET 2.0 which is a feature installed through the Server Manager.
For Windows Server 2016/Windows 10: Microsoft Report Viewer 2012 Runtime redistributable
Microsoft System CLR Types for Microsoft SQL Server 2012 - required for Microsoft Report Viewer 2012. This is a bit trickier to find, so here’s a direct link: x64 version, x86 version.

In case the links to Microsoft System CLR Types fail in future, here is the main download page link. This page links to components from the Microsoft SQL Server 2012 Feature Pack, you have to go to the Install Instructions section and download the specific component you need. If you want to run the SUSDB in a local SQL Express instance rather than the built in Windows Internal Database, then you’ll need to download the following:

SQL Express & SQL Server Management Studio Installation

Running the SQL Express setup will give you the option of Basic, Custom, or Download Media. Click Basic and go through the installation wizard as you normally would. On my demo machine, I ran the custom install and installed SQL Express on a separate drive, where I will also put the WSUS content. So I have E:\Microsoft SQL Server and E:\Microsoft SQL Server x86 folders. When the installation is completed, restart, then run the SQL Server Management Studio install executable that you downloaded earlier and run through the install, once again restart the server when prompted.

WSUS Installation

Go to Server Manager > Manage > Add Roles and Features > Role-based or feature-based installation > Select a server from the server pool > select Windows Server Update Services > accept the defaults in the Add Features dialogue box > click Next on the Features section > click Next on the WSUS info screen.

Role Services

Select WID if you intend to use the Windows Internal Database. Select Database if you intend to use a local SQL Express installation or have an full SQL Server install.

Content

I recommend storing the WSUS content on a separate disk. For me I use E:\wsus_content.

DB Instance

If using a SQL Server or SQL Express instance, select the server and the instance name here. For SQL Express you will need to enter “Machine name\sqlexpress” and click Check connection. Click through and accept the defaults of the Web Server Role (IIS) > Role Services > Confirmation. Check the Restart the destination server automatically if required box, click Yes to the dialogue box, then click Install and go make a drink.

Post Install

After installation, go to Server Manager and click the flag and run the Post-Installation tasks.

When they complete go to Administrative Tools and open the Windows Server Update Services MMC. You should see a Before You Begin wizard. Click Next > Join the Microsoft Update Improvement Program if you wish > Choose Upstream server, as this is the first WSUS server you’ll choose Synchronize from Microsoft Update > Specify the Proxy Server settings if needed > Start Connecting, and then wait, this may take a while!

When WSUS has connected, select the applicable languages for your environment, select the applicable Products - I select all products as we’ll only be downloading updates that we actually need. Select the Classifications, I select all, EXCEPT drivers, you do not want drivers through WSUS - they increase the size of the database immensely, better to manage drivers through another method. Configure the Sync Schedule - I leave this on manual until the server is setup. Check the Begin initial synchronization box, then Finish.

Configuration

When your server has performed the initial synchronization, you can finish off the configuration.

Synchronization Schedule

You’ll want to set up an automatic sync schedule, here’s where you can do it, I usually have two sync’s per day.

Automatic Approvals

There’s a rule already here to automatically approve Critical and Security updates meaning that they will be downloaded and distributed via WSUS automatically without any admin interaction. I recommended enabling this, but don’t run the rule. I add an additional rule for definition updates for Exchange, Office, Forefront Endpoint Protection, and Windows Defender. I recommended adding in the definition updates for any products that are relevant to you. Once again, don’t run the rule.

Computers

This is something that tripped me up in the early days a lot. Clients wouldn’t appear in WSUS, even after I’d set the correct settings in Group Policy. The solution here is to set the option here to “Use Group Policy or registry settings on computers” and to create the groups in WSUS under Computers, that you’ve configured in your GPO’s for Windows Update.

Group Policy

To enable your clients to get updates from WSUS, you’ll need to configure the group policy for them. You’ll find the settings in group policy Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update. The key settings here are Specify intranet Microsoft update service location and Enable client-side targeting. For Specify intranet Microsoft update service location you’ll need to enter http://machine name:8530 in both text boxes. For Enable client-side targeting you’ll need to enter the name of the group and it must match the name of the computer group you created in WSUS.

Managing Updates

After a while your clients should have contacted the WSUS server and be in the correct group and have reported the updates they require. Now you need to approve the updates required for your environment. On the overview of your WSUS server click on Updates needed by computers and on the new screen change the drop down menu Approval: to Unapproved and wait for the list to refresh. Now, right-click on the Title bar and enable the Supersedence column and click on the very tiny column to sort the updates by Supersedence. Now approve the “top” critical, security and any other updates you want to be installed on your clients.

Take care not to approve any updates, service packs or feature packs that you do not want to be pushed out via WSUS. For example if you do not require .NET installed on your clients, then don’t approve it. All you’re doing is potentially increasing the attack surface of that device and also the amount of updates that it has to download and install in future. Scroll right to the bottom and once again approve the updates you want to be installed. All the other updates can be ignored for now. The updates you just approved should be all your clients require to be up to date. Once the clients download, install, and then report back to the WSUS server, you will have a better idea of what is required.

Maintenance and Troubleshooting

Keeping WSUS running well over time is a matter of keeping the IIS application running happily and the database clean. I currently run a PowerShell script every week that cleans up the database, declines and deletes old updates and I’ve had to increase the memory available to the WSUS Application Pool to 6GB.

Here’s the PowerShell script I’ve scheduled to run every Friday via Task Scheduler.

1
2

Get-WsusServer -Name Machine name -PortNumber 8530
Get-WsusServer | Invoke-WsusServerCleanup –CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates

The script is pretty simple. First we get the WSUS server information, the Machine name should be changed to the name of the WSUS server. The script then deletes obsolete updates from the database and the downloaded files, deletes obsolete, expired, and superseded updates from the database. You can do this all manually using the Server Cleanup Wizard, but you really need to run it regularly, and running it from PowerShell is quicker and automated. As a reminder, to run PowerShell scripts from Task Scheduler you need to run the following action:

`1`	`PowerShell.exe -ExecutionPolicy Bypass E:\scripts\wsus-maintenance.ps1`

You may get an error when trying to connect to the WSUS server one day that says “Error: Unexpected Error” and appears as Event ID 7053 in the Event Viewer.

Here are the two solutions that have always fixed that for me: Increase the memory allocated to the WSUS application pool in IIS. The server in question had the WSUS DB installed in WID and 8GB of RAM available, I increased the pool to 6000000 KB (6 GB) which is probably overkill, but it solved the issue on that system. Try running this WSUSUtil command. WSUSUtil is located in %systemdrive%\Program Files\Update Services\Tools.

`1`	`"%systemdrive%\Program Files\Update Services\Tools\wsusutil" postinstall /servicing`

In this instance the server only had 4 GB of RAM and was running the WSUS DB in SQL Express. That’s it! You should have a fully functioning WSUS server, that will stay in good health over time. Be sure to check up on your updates at least once a week and don’t forget to test them out on a small group of clients and servers before installing them on your entire estate.

If you have any questions or comments, please leave them below.

-Mike

Resolving Windows Server Update Services Connection Errors On Windows Server 2012 R2

Thu, 27 Oct 2016 20:43:12 +0000

Update 2018-04-20: I’ve rolled the information in this post, and updated it, into a new post about setting up a WSUS server from scratch on Windows Server 2016 Core. The post is also suitable for a regular Windows Server 2016 server with a GUI. You can read it here.

Update 2017-05-03: If you’re looking to resolve similar problems with WSUS on Windows Server 2016, please see this post.

If you’ve been managing a WSUS server, you may have run into the well known MMC connection error above (appears as Event ID 7053 in the Event Viewer) by now. I started experiencing it more often after installing Windows Server 2012 R2’s WSUS but was able to quickly solve my issue. Later when setting up another 2012 R2 WSUS server I had the same issue but the same fix didn’t work. I eventually solved the problem with that server though.

Here’s a small collection of resolutions and notes on this problem. On one of my WSUS servers, increasing the memory allocated to the WSUS application pool in IIS solved the problem. The server in question was a Hyper-V VM with 8GB of RAM (non dynamic) allocated. I increased the pool to 6000000 KB (6 GB) and thus far it’s solved the issue on this server.

On another WSUS server I setup recently, (which had less RAM) the issue was solved by running the WSUSUtil command line utility. WSUSUtil is located in %systemdrive%\Program Files\Update Services\Tools folder.

`1`	`"%systemdrive%\Program Files\Update Services\Tools\wsusutil" postinstall /servicing`

From what I’ve read online a common cause of the problem seems to be the installation of certain updates and the reported solution is to uninstall these updates - I’ve never had to uninstall any updates to solve this issue, at the time of writing. To give you an idea of how strange this issue seems to be, I’ve had this exact problem when I’ve installed WSUS:

After a full Windows Update run from the internet.
After a full Windows Update run from the internet.
Using a local SQL Express instance to store the WSUS DB.
Using Windows Internal Database to store the WSUS DB.
Having a small number of clients.
Having a large number of clients.

Hopefully this helps you. I’ll make a post in future on how I install WSUS servers currently and some things that I’ve learned to look out for, but until then happy WSUS’ing! I think this is the worst way I’ve ever ended a blog post ever.

If you have any questions or comments, please leave them below.

-Mike