WSUS still runs old code

As a consultant I’ve seen a fair number of environments, and the story is usually the same. Most environments are not leveraging ConfigMgr to it’s fullest capabilities. Today I’m not going to talk about migrating to the cloud, and Intune today. Although some of that will be coming soon, along w/ Win 10 servicing, to include custom actions and some automation scripts that I use to perform some record keeping tasks. I’m a firm believer in data driven decisions as the reporting in service model is a bit lackluster so I’ll give you the tools to help w/ that. Also in a few future blogpost I’ll be dropping some info on cyber threat hunting, identifying breaches earlier,incident response, and how to ******** *** ******** ******. That last part was super classified so I won’t talk about that.

Anyways. Back when we started WIn 10 to Win 10 migrations to match Microsoft win 10 upgrade cadence about ~ 5 years ago there was the in place upgrade task sequence and servicing model. Many customers chose the task sequence route as there was a bit of familiarity to it, but also b/c of the amount of customization work that had to be done for their environments. The servicing model has it’s perks, but it’s not as robust I would say in comparison to the task sequence. These days (1709 forward) I’m trying to move away from task sequences, and more into the servicing model with these dynamic updates. If you aren’t aware but dynamic updates CAN ONLY BE PULLED FROM THE INTERNET. This will likely be several hundred MB of content, and with the servicing model this action is unknown to the end user, when you do the IPU process the end user is completely impacted during the time b/c of a big task sequence box on the screen. Since this can only be obtained from the internet you can’t exactly service your IPU package w/ this.

If you are in an environment where you do not have servicing enabled and you need handle some of the pre-reqs to allow for this. There are two links here to review. SystemCenterDudes and Prajwal Desai


So we enable the upgrades on your SUP, the pre-work is done, and you select sync.

…but what, what if nothing is populated, so it looks like this

Empty Servicing Node

Well, I’ve seen this frequently in the last 10 years in at-least half a dozen environments. Basically when you check your WSYNCMGR.log everything starts out fine. The normal process is the notification file is found, upstream is found, categories are synced, and then updates start syncing. If an update is already synced it will be skipped etc.

All is good until we get to the feature upgrades that we just enabled. We start seeing “The Microsoft Software License Terms have not completely downloaded and ~~cannot be accepted.”, “Too many consecutive failures. Aborting Sync.”

You can also check your event viewer for some error code information.

I’ve seen this issue before, actually several times, in many environments. Ultimately the fix ends up being to remove all classifications from the SUP > WSUSUTIL RESET > Run Sync > Add Classifications > Run Sync > Monitor Logs.

Check out this Link for how to run WSUS Reset

Once we run the reset and the sync completes we are now able to see the servicing node populated.


Ultimately I wrote this blog to cite myself to say I’ve seen this problem many times, for many years and that it is still not addressed. When you are dealing on timelines this problem adds several hours, or even days to the project b/c of having to perform the reset then download content and metadata. but let me tell you a funny joke. Why did the chicken cross the road? I don’t know but WSUS runs on old code, like 2003 code from before I was even in high school.


NOTE: I hope David James sees this, and he takes over the WSUS stuff, and makes it better, like everything else he makes better.


Disconnected WSUS – The “fun” of importing updates

, , , ,

Air gap networks have their own special challenges…


My name is Charles, I went to the Midwest Management Summit back in May 2019. It was my second time attending the conference. You might remember me as “that guy who has no remote users” 🙂

I said I would blog about a tip I talked about shortly after the conference… This blog post is about 7 months late, I’m sorry!

So for those that do not know this conference, there is a session where anyone can go up on stage and present an IT-related tip or trick.

I went on the stage to talk very briefly about a rather important detail that you need to know when you deal with a disconnected/offline WSUS server: You need to track your update approvals on your internet-connected WSUS server.

On your disconnected WSUS server, you must not approve an update that was not approved on your internet-connected WSUS server or you will have issues.


Microsoft’s official documentation regarding setting up a disconnected WSUS instance can be summarized with the following 3 steps:

  1. Matching advanced configuration:
    • Express updates: If you want to use express updates, make sure that both the internet-connected WSUS and the disconnected WSUS instances have the same setting configured
    • Languages: Make sure that you select the same languages for update files
  2. WsusContent: This one is simple, just copy the “WsusContent” folder on the internet-connected WSUS to the disconnected one.
  3. Metadata: Export & Import the WSUS metadata with wsusutil.exe import/export

The problem

OK, so you made sure that you have the same advanced configuration, you copied the “WsusContent” folder and you imported the metadata from your internet-connected WSUS server… now what?

Well, now you have a bunch of unapproved updates in your WSUS Console on your disconnected WSUS Server. You don’t know which ones were approved or declined on the internet-connected WSUS.

The next part is from my personal experience… If you approve a bunch of updates and some are missing the associated content, WSUS gets stuck. In your WSUS console, it will show that you have thousands of updates “needing files”. What’s happening here is that you approved updates for which your disconnected WSUS does not have the content. In a normal scenario, WSUS would simply download the content from Microsoft. In our case, the WSUS server simply gets stuck there because some updates are missing files. And for some &*%!$% reason, WSUS will not skip over and verify the other updates once it gets stuck with a couple of updates missing content.

This is what happens when you approve updates that your disconnected WSUS does not have the content.

The solution

Make sure that the same approvals are mirrored on your disconnected WSUS instance.

And when I say update approvals, I mean which updates were declined and which updates were approved.

“OK, I will create the same automatic approval rules on my disconnected WSUS. Done.”

Sure, that might work if you don’t do any kind of cleanup on your WSUS instance. There are various solutions online of scripts that people use to decline/delete updates they don’t need (Itanium, Ia64, superseded updates, etc.)

The automatic approval rules criteria in WSUS are very basic and you will end up approving updates on your disconnected WSUS that are declined on your internet-connected. Ask me how I know…

I personally use Bryan Dam’s software update maintenance script, see his blog posts here and here. This script was originally written to maintain SCCM software update point WSUS instances but later he added the WSUS Standalone mode which I’m using for my WSUS Servers.

I won’t go into details here about which updates I’m declining and whatnot. Just know that if you use a WSUS Server, you should probably have some sort of maintenance script running regularly or you will have a bad time…

“How am I supposed to keep track of all the updates that I declined/approved?”


With PowerShell we can get the information we want and it’s possible to script this so that we can export and import the update approvals.

When you’re ready to do an export of your internet-connected WSUS, you will have to export the metadata, copy the “WsusContent” folder and also get the list of which updates were approved. Make sure you copy all three at the same time to make sure that you have the matching metadata, content and update approvals.

My script

So where I work, the team responsible for copying content over to the disconnected WSUS server is different than the team maintaining WSUS. A procedure was written about how to perform the export and import process but it never worked really well and WSUS crapped itself… many times.

I decided that I had enough with this and tried to automate the process as much as I could.

I wrote a script that I called “Invoke-WSUSImportExportManager”

At first, I simply wanted to automate the following:

  • Exporting
    • Copy “WsusContent” to $folder
    • Copy the WSUS Metadata to $folder
    • Record WSUS information in a XML file and copy to $folder
      • WSUS Configuration
      • WSUS Computer groups hierarchy
      • WSUS Update approvals
  • Importing
    • Copy “WsusContent”
    • Import the WSUS Metadata
    • Update WSUS Configuration
      • Match the configuration
      • Re-create the same computer groups hierarchy
      • Approve the same updates to the same computer groups

And then it became bigger and bigger…

On top of doing the import and export process, it also does the following tasks:

  • Reindex the WSUS Database
  • Adds or Removes the custom indexes (Taken from Bryan Dam’s script)
  • Sets a couple of common IIS settings for the WsusPool that should be changed from its default values
  • Show locally published updates (third-party updates) in the WSUS console

All these “Actions” that the script performs are customizable.

The script is available on GitHub here. I tried to explain how the script works in the readme but feel free to ask me any questions if you need more information.

Note: My PowerShell skills are not super awesome so I’m sorry for the state of the scripts. If you have some feedback/suggestions regarding that, please let me know and I’ll try my best to improve the scripts.

Thank you.

Feel free to contact me on Twitter.