Troubleshooting_LUP

This page will list the most common problems people encounter with LUP.

• Certificates
• Group Policy for the WSUS client
• Using Test Groups
• User Accounts
• File and Folder Permissions
• Windows Update Agent Account
• Importing Updates
• Empty Vendor Or Product Categories
• .NET 4.0 on WSUS
• Other Ideas

Certificates

By far the most pervasive issue is getting the certificates distributed correctly. If WindowsUpdate.log reports errors such as 0x800b0109, you have certificate problems. Triple check to make sure that you have the certificates in the Trusted Root Certification Authorities and Trusted Publishers certificate stores on both the server and the clients. Another common mistake is not adding the certificates using the computer account for the local machine. Also remember that there should only be one certificate used throughout your entire WSUS system.

Recent updates to the WSUS system require that the certificate be greater than 1024 bits in length and new certificates created by the WSUS API are 2048 bits in length. Make sure that your certificate is 2048 bits in length.

Check out the instructions at [Distribute_the_certificate_to_the_server_and_a_set_of_test_machines#How_to_tell_if_the_certificates_are_installed_correctly] to verify that certificates are installed correctly.

If you are getting certificate errors from a specific client, you might also try:

1. On the client, connect to the UpdateServicesPackages share on your WSUS server.
2. Open the folder that contains your update (compare the folder name with the Package ID on the Info tab for that update).
3. Right click on the cab file, and choose Properties.
4. Go to the Digital Signatures tab.
5. Click the Details button
6. Click the View Certificate button and look for any error messages.
7. Close the certificate and open the Advanced tab.
8. Compare the "Serial number" here with the value in LUP under Tools/Certificate Info.

If the serial numbers don't match, the wrong certificate is installed on the client. Or the right certificate is installed on the client, but a different certificate was installed on the server when the update was published. You can try right clicking on the update in LUP and choose Re-sign, or simple remove and re-create the update.

Group Policy for the WSUS client

Make sure that the clients have received the correct policy that enables 'Allow Signed Content from intranet Microsoft update service location'. Use whatever tools you have at your disposal to make sure this setting is active on the client.

Using Test Groups

The WSUS clients have a locally stored cookie that stores the groups that the client is associated to. Until that cookie expires the client will not create a new one. This means that if you add clients to a group and then immediately try to force a client in that group to detect updates it will likely not find updates you have approved for your new group. You can either wait an hour or force the cookie to expire by running wuauclt with the /resetauthorization flag.

User Accounts

LUP must be ran by a user that is part of the WSUS Administrators group which is local to each WSUS server. The local Administrators group is part of the WSUS Administrators but domain accounts by default will not be.

File and Folder Permissions

The user account running LUP must be able to write to the %WSUS_SERVER%\UpdateServicesPackages folder. Try manually creating a file or folder to confirm that this is the case.

Windows Update Agent Account

The WUA generally runs under the local SYSTEM account. The only currently known exception is when an administrator runs Windows Update interactively in which case the administrator's account is used. The SYSTEM account is used to provide the installer with full access to the system but it's unlike a normal user account and can cause problems with installers making assumptions about their environment. If you have an installer that works when run manually but not when run by the WUA then follow instructions like these http://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system... to run the installer using the SYSTEM account.

Importing Updates

If you do not have the certificates properly installed on the WSUS server it is possible to get false-positive results for publishing. LUP will report a successful import and WSUS will import the package into its database but not into the content folder. Once you have properly installed the certificates onto the server you can re-sign the affected updates to properly publish them.

Empty Vendor Or Product Categories

The process of removing vendor or product categories is handled entirely by the WSUS server and there is no API call to manually remove them. The logic WSUS uses to do so is unknown but experience has shown that if the package published to a category required or superseded other packages the category will remain until those dependent packages are also removed. If you run the cleanup wizard every month it will eventually be removed.

.NET 4.0 on WSUS

Installing .NET 4.0 on your WSUS 3 SP 2 server might prevent you from publishing updates. Review this article: KB 2530678

Other Ideas

• Look at %windir%\windowsupdate.log for errors.
• Refer to the list of WSUS Error Codes: http://inetexplorer.mvps.org/archive/windows_update_codes.htm.
• If you get 0x80070570 errors distributing large updates, check out [Distributing_KB2607070].
• Consider turning on verbose installer logging (see MSDN KB958041). This will write more information to windowsupdate.log (most of it useless), and create log files in %windir%\temp for individual updates. NB: Don't leave this turned on. Make sure you shut it off when you are finished.
• You can use wuauclt /detectnow to have a client scan the current list of updates. After doing this, you can scan windowsupdate.log to see what updates are pending, check out the BITS download info, see when the next update is scheduled to run, etc.
• You can use wuauclt /reportnow to have a client send any pending activity reports to the WSUS server. This can be useful right after running detectnow.
• Check out the AppDeploy website for other people who have worked with distributing the same package.
• For general WSUS questions, you might check out the WSUS MSDN page.