For the last few weeks we’ve been suffering from numerous error messages on our SCCM 2012 R2 Software Update Point. I knew they were all somehow related but it took quite a while to figure out how they were all linked together.
I first noticed that the SMS_WSUS_SYNC_MANAGER component was throwing the following error with Message ID 6703.
WSUS Synchronization failed. Message: Failed to sync some of the updates.
Seeing this error, I decided to check the WSUS log file (C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log) where I found the WsusService.20 error had been logged many, many times.
EventId=364,Type=Error,Category=Synchronization,Message=Content file download failed.
Reason: Error calling [kernel32.dll]:CreateDirectory(D:\Sources\WSUSContent\WsusContent\14)
So it was here that I knew I had an issue with WSUS being able to create directories in which to download the update content. So I decided to use the trusty wsusutil checkhealth command. The “wsusutil.exe” – which can be found in the “c:\Program Files\Update Services\Tools\” directory – is very helpful. You run the utility in a command promt with Administrative priveledges and it generates log entries in the Windows Application log. What I found was what led me to my answer.
Windows Server Update Services Event id 10012: The permissions on directory D:\ are incorrect.
Windows Server Update Services Event id 12072: The WSUS content directory is not accessible…
There was my answer: security permissions on the root volume.
So, if you find yourself with similar issues and the same error messages, try checking the SCCM/WSUS root volume’s security permissions and make sure that the following permissions are set.
- SYSTEM: Full Control – inherited from the root volume
- Administrators (local server): Full Control – inherited from the root volume
- Users (local server): Read & Execute, Create Folders, Create Files – inherited from the root volume
A side note regarding this SCCM installation: A local consultant was contracted to design and install Configuration Manager. Apparently, when he setup the Windows Server VM, he changed the security permissions on the volume that SCCM was installed onto – in this case D:. Needless to say, we’ve since discontinued our relationship with this consultant.