WSUS Fails to Connect

Recently I had a WSUS server which had to be rebooted.  Upon restarting the server, I noticed that I could no longer get into the WSUS console.  When trying to connect I was receiving the following error message:

Checking the Event Logs, I found two events which showed the following:

My next step was to check the health of WSUS with the following command:

WsusUtil.exe checkhealth
This was run from "C:\Program Files\Update Services\Tools" directory

Running this command gave me the following result:

Upon looking into this further, I noticed that there was a Windows Update which has caused some issues in the past for some people.  The update is KB3159706.  I checked my server and I did not  have this update installed, but thought I would humour it and try the fix anyway.  The fix mentioned in the KB article actually resolved the issue.  I did the following to get it back up and running:

1. Install the HTTP Activation role under .NET Framework 4.5 Features through Server Manager.

2. Restart the WSUS service

Yep...it was that easy!  After doing that, adding the WSUS server back into the MMC console worked fine and everything was back up and running again.

WSUS Not Downloding Updates

I recently had a client who had WSUS setup on Server 2016.  It was trying to downloading some updates after a synchronisation, but it would freeze at 100% and not go any further.

Synchronisations were fine, and it would download the data that's required, however these 5 updates would just sit there.  Checking Event Logs, I saw the following error:

After running the following command I found the following event

"C:\Program Files\Update Services\Tools\WsusUtil.exe CheckHealth"

It looks like the particular file it's trying to download is corrupt.  Checking WSUS to find out what the update is, KB3172989 is actually a CU for Server 2016 Technical Preview.  In this case, it's not needed so it was declined through WSUS.  After doing this, I did a search for all the Technical Preview updates, and declined them as well.  After running a Synchronisation again, it worked well. 

Do you need IT Support in Perth, or other states of Australia?  Contact Winthrop Australia today!

WSUS downloads slow | BitsDownloadPriorityForeground

Recently I configured WSUS to download updates (about 150GB worth) and I noticed it was taking a very long time to download.  This little tip will save a lot of time waiting for the download to finish.

Run the following command on the WSUS Server in PowerShell:

(get-wsusserver).GetConfiguration().BitsDownloadPriorityForeground

This will show you whether the setting has been enabled or not.  We want it to say 'True'.

It will most likely say "False" if you're experiencing slow downloads.  Once you've confirmed this, type the following to set this to 'True":

• $Config = (Get-WsusServer).GetConfiguration()
• $Config.BitsDownloadPriorityForeground = $True
• $Config.Save()

Once you've used these three commands, run the first command again to confirm that this has changed over to 'True'.  There's no need to restart the services.  You should see that the downloads will speed up now.

Contact Winthrop Australia to find out how we can help you with your IT Support needs.

Windows 7 clients automatically rebooting for updates - no notifcation - WSUS

Recently I had a call from a client saying that they're having computers randomly reboot (without warning) to install Windows Updates.  All machines were Windows 7, and they were all on the client's domain.  They had WSUS installed and configured, with GPOs to define the backup settings etc.  In this case, the GPO stated that machines will automatically download and install updates at 4pm each day, and only reboot if there was no active user.

After checking the GPO, I was confident that the issue was not related to that, as it clearly stated that the computers won't be rebooting automatically.  I remoted into the workstations to ensure that they're actually applying the GPO (gpresult /r), which they were.  So it wasn't GPO, and it wasn't the workstations as far as I could tell.

I logged into WSUS itself, and checked the automatic approval settings.  That was all setup and was approving certain updates (such as Critical Updates and Security Updates etc).  When looking further down the Automatic Approval rules, I noticed that there had been a deadline set for installing the updates.

The deadline had been set for 5am on the same day that the Windows Updates were approved.  This means that the when a workstation turns on in the morning (which is usually after 5am...), it will realise that it has some updates available.  Because it's already past the deadline, the workstations starts installing the updates as soon as it can, and applying them immediately.  

The WSUS settings here overwrite the GPO settings, so even though it may have been defined in the GPO to not reboot, the computer knows that it's already past it's deadline to have these updates installed, so it ignores the remainder of the settings, and applies the updates straight away.  If the updates require a reboot, it will do the reboot immediately as well.  This was what was causing the 'random' rebooting of computers throughout the day.  

To resolve this issue, one could change the deadline to perhaps allow a couple of days after the update has been approved, or in my case, completely remove the deadline requirement.  The GPO will get machines to install updates each day anyway, so it's not needed in this case.

Increase Package Size - WSUS

Recently I was looking at an application called CSI, which ties into WSUS, and releases packages through WSUS for 3rd party applications (such as Java etc).  This is a really good way to ensure that all applications are kept up to date, and managed through existing WSUS infrastructure.

I noticed that some packages were larger than the WSUS limit of 384mb.  This is obviously a problem, as WSUS wouldn't be able to package and push this out.  In order to get around this, I've had to tell WSUS that the package size can be larger than that.

The following Power Shell commands will get this job done:

• Import-Module UpdateServices

• [reflection.assembly]::LoadWithPartialName

• ("Microsoft.UpdateServices.Administration") | out-null

• $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();

• $serverconfig = $wsus.getConfiguration()

• $serverconfig.LocalPublishingMaxCabSize = 1024

• $serverconfig.Save($FALSE)

In these commands, the 1024 is the newly updated maximum package size.  

Note: WSUS cannot go larger than 2048mb, so don't set the size to above that.

Windows 10 showing as Vista in WSUS

There is a bug with WSUS where Windows 10 machines are showing up as Windows Vista.

There is a hot-fix released by Microsoft, and it can be downloaded here:

https://www.microsoft.com/en-us/download/details.aspx?id=51534