I recently noticed that superseded software updates were not being expired in my new SCCM 2012 R2 environment. I first checked the site settings to be sure that I properly configured superseded updates to actually be expired and found everything looked as it should. It was time to check the logs.
Using the Configuration Manager Trace Log Tool (which I highly recommend, it makes parsing SCCM and other logs much easier), I opened wsynccmgr.log, which can be found at \\<ServerName>\sms_<sitecode>\Logs\.
Scrolling through the log, I immediately noticed several errors relating to accepting the EULA: Failed to sync update “xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx”. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted.
Google searches return several promising solutions, most of which involved clearing the WSUS classifications, running a wsusutil reset, and then re-syncing and adding back classifications. This seemed to be a bit of involved process and I didn’t feel like pursuing it as an initial troubleshooting step.
In one thread, someone mentioned checking the WSUS configurations in the SUSDB, specifically the LocalContentCacheLocation in dbo.tbConfigurationB. To do this I:
- Open the SQL Server Management Studio and connect to the WSUS DB server.
- Select New Query (or hit CTRL+N)
- Type the following query:
select LocalContentCacheLocation from dbo.tbConfigurationB
- Click Execute to run the query
- Check the results in the lower pane. In my case, the query returned D:\WSUS\WsusContent.
I checked the returned file path on the WSUS server. D:\WSUS exists, but the WsusContent directory did not. I created the directory and then initiated a resync. Almost immediately I saw the directory start to populate.
Bouncing back to the wsynccmgr.log, I saw that instead of failing messages related to EULAs, several updates indicated that EULA downloads were pending. The sync completed successfully with no errors.
At this point I went home for the night and figured I would check it again in the morning after a scheduled sync runs. By the morning, no errors were in my wsynccmgr.log. The post sync tasks appear to have run properly and I now saw expired updates.
So, for whatever reason, some portion of the SCCM or WSUS install did not create all the necessary directories. As it is, I find the integration of WSUS into SCCM to be a bit confusing, since it requires WSUS to be installed and partially configured. Hopefully the System Center team will eventually stream line the process.