SVM Publishing to WSUS: Troubleshooting Guide

[#1]

Summary

This article is a deeper-dive guide to troubleshooting problems with publishing Flexera SPS packages to Windows Server Update Services that can also be installed in configuration with System Center Configuration Manager as a "Software Update Point" [SUP]. It provides you with the required logic to follow problems with publishing to their root cause and eliminate it efficiently. 

Symptoms

The user receives an error message from WSUS along the lines of 'failed to publish' with a 32-bit unsigned integer as the error code.

Example:

[06/09 13:42:55.495] Failed to create package: : -2147352567 , In 'Publisher.invoke'
Code: -2146233079

Failed to sign package; error was: 2147942421
--> System.InvalidOperationException: Failed to sign package; error was: 2147942421
...

Cause

WSUS errors can have a number of causes depending on the different scenarios created by the infrastructure in question. In order to better understand the problem, you should work through the following list of factors to investigate.

The basics:

• Is the WSUS service on the WSUS server running?

• Is the WSUS server connection information correct?
  
  
  • This can be found by using a remote Snap-In connection to your WSUS server interface

Is the code-signing certificate correctly placed at the Trusted Publishers, Trusted Root Certification Authorities, and WSUS stores?

• This can be found using the Certificates snap-in [Run > certlm.msc]

• Or via Powershell  [dir cert:\LocalMachine\ -recurse]

NOTE: You can also try using Powershell ISE and some where {} clause filtering:

dir cert:\LocalMachine\ -Recurse | where {$_.HasPrivateKey -eq $True} | select Subjectdir cert:\LocalMachine\ -Recurse | where {$_.HasPrivateKey -eq $True} | select Subject

Continue further if the keys and placement of your code-signing certificate was by the books. 

Does the certificate in the WSUS store contain the private key?

• This can be verified by double-clicking the certificate inside the WSUS store.

Is the WSUS code signing certificate valid? Error 2148204810 usually indicates that the certificate has expired. Check and renew if needed. 

[07/16 12: 46: 04.202] Failed to create package:: -2147352567, In & # 39; Publisher.invoke & # 39;
Code: -2146233079
Error signing the package: 2148204810
  - & gt; System.InvalidOperationException: Error signing package: 2148204810

More troubleshooting options:

If the above checks don't seem to indicate where the problem lies then you should try some more advanced troubleshooting techniques. The items below describe some pitfalls that can cause problems with WSUS integration.

• Is there enough space on WSUS?
  • Check the storage space available on the volume where the UpdateServicesPackages directory is located
    
    
• Privileges (UpdateServicesPackages directory)?
  • Does the user account context being used with CSI via Internet Explorer have write access to this directory?
    
    
• Has the update store been moved recently? (UpdateServicesPackages directory/WSUS Local Content Cache location)
  • This can cause problems if the move wasn't done according to Microsoft's guidelines
    
    
• Is there an alias record for the WSUS server that's different than the computer name?
  • Here you'll want to check to see where your DNS record is pointing to.
    
    
• Check the UpdateServicesPackage location (WSUS Local Content Cache location) defined in WSUS database
  • If your WSUS server uses the default internal database then install MS SQL management studio. Open SQL Management Studio and then use one of the following two possibilities depending on the version you're running for the instance name: \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query (2003-2008) or \\.\pipe\MICROSOFT##WID\tsql\query (2012) . This style of instance name is required because connecting to the Internal Database requires named pipes.
    
    
  • If you're running your WSUS DB on another instance you'll want to open SQL Management Studio and connect using the instance name and authentication settings that fit to your environment.
    
    
  • You'll then run the following query:
    • USE [SUSDB]
      SELECT
      [LocalContentCacheLocation]
      FROM [dbo].[tbConfigurationB]
      
      
    • Which should give a result similar to the following:

Check the registry value for the UpdateServicesPackages Directory to ensure it's correct.

• This can be found under HKLM\Software\Microsoft\Update Services\Server\Setup

If you require more information to troubleshoot further in-depth than this guide provides details for, you'll need to look deeper into the error code for your specific issue. If you take a look at the example error message from earlier in the article: "[06/09 13:42:55.495] Failed to create package: : -2147352567" you can see that you get an interesting number back from WSUS.

You can make use of the following javascript function to translate it into something a bit more useful:

function DumpHR(hr)
{
if (hr < 0 )
hr += 0x100000000;
if (hr & 0x80000000)
console.log("Error code");
else
console.log("Success code");
var facility = (hr & 0x7FFF0000) >> 16;
console.log("Facility " + facility);
var scode = hr & 0x0000FFFF;
console.log("SCode " + scode);
}
DumpHR(-2147352567);

In the example above, the Facility Code is 2 and the SCode is 9. What this tells us is that the error comes from the COM Dispatch Facility and the error code of 9 tells us that the problem is a 'bad address block'. The Facility code reference can be found here and the SCode reference here.

What the example results imply is that there was a problem writing to disk on the WSUS server during the publishing process. In most cases, one of the causes described above is the culprit, however, if you happen to have one of the odd cases that are outside these bounds this information might be useful, especially if you open a case with Microsoft.

Resolution

The solutions to these problems will vary depending on which path brought you to a conclusion. However, these scenarios can be broken down to provide some fairly easy fixes:

• Is the WSUS service on the WSUS server running?
  • If not, try to start it again. If that doesn't work a reboot and/or tracing the event log to find a cause will be necessary.
    
    
• Is the WSUS server connection information correct?
  • If not you can adjust the information you're using in the CSI console to match what you found in the WSUS snap-in.
    
    
• Is the CSI console/Internet Explorer running with administrator privileges?
  • Make sure to run the CSI console or Internet Explorer by explicitly right-clicking and choosing "Run as administrator".
    
    
• The User running the Internet Explorer is part of WSUS administrator group.
  • Make sure to add the user under which Internet Explorer is running is added to the WSUS administrator group which is the local group on the WSUS server.
    
    
• Is the code signing certificate in the Trusted Publishers, Trusted Root Certification Authorities, and WSUS stores?
  • If the certificate is not in the appropriate stores you can either create a new one or, if the export is available with the private key, it can be imported into those stores on the WSUS server.
    
    
• Does the certificate in the WSUS store contain the private key?
  • If not then create a new certificate with the appropriate key, or if the export is available to import it into the appropriate stores.
    
    
• There isn't enough space available for WSUS
  • In the case where this is the problem you simply need to increase the size of the volume that contains the UpdateServicesPackages directory (WSUS Local Content Cache location)
    
    
• NTFS Permissions for the UpdateServicesPackages (WSUS Local Content Cache location) directory are incorrect:
  • Here you'd need to adjust the NTFS permissions for the user(s) accounts making use of the CSI console so that they have write access to this location. They should also be in the WSUS Administrators group on the WSUS server.
    
    
• The update store moved since publishing worked (UpdateServicesPackages directory)
  • Ensure that one uses the guidelines specified by Microsoft when moving the store. Use those steps to verify that all of these tasks have been accomplished.
    
    
• There is an alias record for the WSUS server that's different than the NETBIOS computer name
  • You should verify your DNS configuration and make use of the appropriate DNS name when making use of the CSI console.
    
    
• The WSUS Local Content Cache location for WSUS is incorrect in the WSUS internal Database
  • This can be corrected with the following query example. Bear in mind this is an example and must be verified on your own infrastructure.
    
    

    • USE [SUSDB]
      
      Update dbo.tbConfigurationB 
      
      set LocalContentCacheLocation = 'C:\Updates\WsusContent'

      
      
      • In the above example, the location I've placed in quotes is one possibility (and the default value). This may need to be different in your environment.
        
        
• The Registry value for the UpdateServicesPackages Directory (WSUS Local Content Cache) is incorrect.
  • Using Regedit to edit the key at HKLM\Software\Microsoft\Update Services\Server\Setup should fix the issue.