I’ve seen this pop up a few times in forums and even in a few SCCM implementations. It’s actually a fairly simple fix if you know which log files to look at. Check your logs and/or keep reading this post to see how to fix the wonderful Microsoft Software License Terms have not been completely downloaded WSUS Issue.

Poor Health – The First Indicator

Since you’ve probably been looking in the Monitoring workspace of SCCM and check out the component status, you’ve probably come across that the SMS_WSUS_SYNC_MANAGER was red and unhappy.

If you right click and look at the messages, you’ll find a pretty generic error:

WSUS Synchronization failed.

Message: Failed to sync some of the updates.

Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.SyncUpdates.

Time to Research – Check your Logs

There are two main logs to check on your Primary Site server:

C:\Program Files\Microsoft Configuration Manager\logs\WCM.log
C:\Program Files\Microsoft Configuration Manager\logs\wsyncmgr.log

The first log file WCM is a great log to see when the SUP updates is triggering and which SUP the Primary is dealing with.

For this issue though the real log message will show up in the wsyncmgr.log. Here it is:

If you notice the 2 GUIDs in red, they match the GUID above in the white line. This will show you the update name that is failing. Another way to get name of the update via GUID is to go on over to http://catalog.update.microsoft.com and search for the GUID there.

OK OK, you might have already found this, but you’ve been searching the internet for the answer. Keep reading!

Time to Dig Deeper – Keep Checking Your Logs

Let’s think about this for a second. We know we have an SCCM component that uses WSUS. WSUS is usually pretty stable once it’s set up. We know we’re having some issues between components, but where is the actual error coming from? How can we dig deeper? Remember those two log files I mentioned above and said that WCM.log shows which SUP the Primary Site is dealing with. Everything looks nice and happy in there. It is able to talk to WSUS on the web ports (80/443 or 8530/8531).

To me this is showing me that the Primary SCCM WSUS component is somewhat happy. Let’s log onto the server that has the SUP role installed.

Now that we are on that server, have we looked at the Event Log? Let’s try that. Open Event Viewer and click the application log. Well we know we are dealing with WSUS, so let’s filtering the log by showing only the “Windows Server Update Services” error messages.

Now let’s look at the error messages! In my case I had a lot of event ID 12072 errors. WSUS could not find the anonymousCheckFile.txt. I know recently that the SUP points had been rebuilt. I’m thinking that the wsusutil.exe postinstall path command was incorrect as the error message shows two WsusContent directories.

We can double check that the path doesn’t exist by some simple commands at the command prompt. As you see below, the anonymousCheckFile.txt is where it should be. But for some reason ours is looking in F:\WSUS\WsusContent\WsusContent\anonymousCheckFile. One directory too deep.

We can also verify this in the registry. We need to look at the ContentDir key in the HKLM\Software\Microsoft\Update Services\Server\Setup location. Again, this should just be F:\WSUS.

The Fix / Solution

Well we can change the value in a few places, but I’m sure someone usually has an issue with WSUS, tries to fix it via blog posts and just fat fingers the POSTINSTALL command. When you’re initially setting up the WSUS you usually have a direct and create an empty WSUS directory. If you have issues and reissue the POSTINSTALL command you may hit an extra tab that adds on the WsusContent directory or you may even type it. This is wrong.

Let’s fix it by running:

CD C:\Program Files\Update Services\Tools

C:\Program Files\Update Services\Tools> WsusUtil.exe POSTINSTALL SQL_INSTANCE_NAME=SCCMSQL CONTENT_DIR=F:\WSUS

Just to keep in mind, if you make any manual changes to the registry etc, it’s always best to:

Restart IIS
Restart the Windows WSUS Service (WsusService)
Check the Event log for errors
Run the SCCM Synchronize and recheck all the logs aboveForce Update Sync from SCCM

Shared Content and Database Gotchas

When running with a Shared WSUS configuration (See my post Configuring Multiple Software Update Points (SUP) in SCCM) you need to fix IIS. Keep in mind that WSUS has been around and was not initially designed to run with a shared content directory. When the post install updates the IIS Virtual Directory Content, it strips out the \\ of the server name and only puts SERVERNAME\WSUS\WsusContent\. You need to edit this and add the \\ to the start of the server name.

This is what it looks like after you run the POST INSTALL. It’s wrong!

After editing, this is correct and what it should look like:

Check Directory and Share Permissions

To allow the WSUS to work properly with a shared content directory the following share and directory permissions need to be set:

NETWORK SERVICE – Full Control
Primary Site Server Computer Account – Full Control
SUP Server 1 Computer Account – Full Control
SUP Server 2 Computer Account – Full Control
SUP Server 3 Computer Account – Full Control
Any WSUS Proxy Account that is used – Full Control
Domain Admins – Full Control (Nice to have for management/troubleshooting, but not required.

If you’re running a local content database, then NETWORK SERVICE with full control should suffice.

Let me reiterate

When you make any changes, and you’re getting generic errors. Check the overlooked components like IIS web logs, Windows event logs and filter by the components such as Windows Server Update Services.

Hope this helps troubleshoot any SCCM and/or WSUS issues!