This is the Windows Server Update Services support team blog. We cover all things relating to WSUS and Windows Update.
Here's an interesting issue recently discovered by Joe Tindale, one of our top WSUS Support Escalation Engineers out in North Carolina:
Issue: When trying to synchronize a WSUS 3.0 SP1 computer, it may not sync and progress may remain at 0%. When this occurs you may not see any obvious errors and the sync may never completely fail.
Cause: This can occur if the server in question has an incorrect version of Microsoft.updateservices.bits.dll.
Resolution: The easiest way to resolve this issue is to replace Microsoft.updateservices.bits.dll with the correct Service Pack 1 version from another Windows Server Update Services (WSUS) computer that has SP1 installed. Once you replace the file, simply restart the IIS services and you should be good to go. If all else fails you should also be able to just reinstall WSUS 3.0 SP1.
More Information: When originally troubleshooting this issue we looked in the softwaredistribution.log and saw errors about not being able to load a .NET assembly for BITS:
Could not load file or assembly 'Microsoft.Windows.BITS, Version=3.1.6001.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
We checked the BITS assembly in C:\program files\update services\service\bin\Microsoft.updateservices.bits.dll and found that the file version was 6.6.4000.374, indicating it was a WSUS3 RTM file, not the Service Pack 1 version we needed.
J.C. Hornbeck | Manageability Knowledge Engineer
Now, did Joe discover it? Or, did the customer discover it and Joe resolve it? :)
Opening the softwaredistribution.log you will see the exception and requesting to enable fusion logging which will be on hklm\software\microsoft\fusion. Create an entry called EnableLog dword 1 and restart the update services service and synchronize. It will stay in 0% but this time looking at the exception in the softwaredistribution.log you will see which file was requested, path and the mismatch version. The error code means version mismatch for CLR 0x80131040 on file load. Reference:
Are you sure you have the correct file name?
I have a similar issue and cannot find the file Microsoft.updateservices.bits.dll on the problem Windows 2008 server or on a working Windows 2008 server.
But both servers have microsoft.windows.bits.dll
I've done a reinstall (keeping my old database) of WSUS 3.0 SP1 x64 on the problem server and still cannot sync with Microsoft via WSUS or via Windows Update direct to Microsoft. On the problem server I can use IE to browse to http://update.microsoft.com - so I don't believe this is a DNS, firewall, or other network problem.
After the reinstall the problem server somehow found that it had a few updates needing files but the download is hung. A warning in the "to do" says non-running services: contentsyncagent
Any help would be greatly appreciated.
Take a look at the softwaredistribution.log to see if you can find the same behavior on the WSUS as the blog above. The file is located at c:\program files\update services\logfiles
Go to http://www.codeplex.com/wsus, download the audbgtrace.exe and choose the WSUS synchronization option (option 3) and reproduce the problem synchronizing from the mmc console. ( after finishing reproducing it, check for winhttp errors)
On your case the only supported installation option for WSUS is the SP1 version, so I don't think you will fall in the same problem description on this blog.
I'm not getting the same error above and I believe winhttp has been ruled out. It took a reinstall or two and a few reboots to get things normalized to where I was only chasing one problem.
I have a thread going in the WSUS forum on this. So far I have narrowed it down to a problem just with Forefront definition updates causing an HTTP 404 when WSUS tries to download them on a WSUS server that only syncs once a day. Changing WSUS setup to not sync Forefront products resolved my issue. Take a look at the thread in the forum for a more detailed explanation of what has been tried and what has been discovered. http://forums.technet.microsoft.com/en-US/winserverwsus/thread/2296beac-af3b-484b-9057-bc1c7df4cb65/
But, I'll try the audbgtrace.exe anyway and see what it produces, it might provide some clues as to why Forefront definition updates are experiencing a HTTP 404.
I'll let you know what it produces.
132 Microsoft Team blogs searched, 98 blogs have new articles in the past 31 days. 608 new articles found
Another solution to this problem is to make sure your machines have the correct date. If your servers are different by more than a day they may not sync.
Another cause for this is the machine having the wrong date/time.