Microsoft KB Archive/945536

= Client computers can no longer synchronize with Windows Server Update Services after you import many third-party product updates =

Article ID: 945536

Article Last Modified on 12/11/2007

-

APPLIES TO


 * Microsoft Windows Server Update Services 3.0

-



SYMPTOMS
After you import many locally-published, third-party product updates in Microsoft Windows Server Update Services (WSUS), client computers can no longer synchronize with WSUS.

You experience this issue after you import many third-party updates that have distinct product names or that have distinct vendor names.

WSUS provides APIs to import and to manage locally-published updates. However, WSUS does not provide a user interface (UI) to import or to manage these updates. Therefore, you are more likely to experience this issue when you use a tool that uses the WSUS APIs to manage locally-published updates. These tools include the following:
 * Microsoft System Center Configuration Manager 2007
 * Microsoft System Center Essentials 2007
 * Third-party tools



CAUSE
This issue occurs if too many categories are published in WSUS.

When you import a catalog of third-party updates into WSUS, WSUS uses the product name together with the vendor name to create a category. This category is associated with a particular update. During a synchronization operation between a client computer and WSUS, all the locally-published categories are sent to the client computer for evaluation. If too many distinct categories are published, the synchronization process fails.



RESOLUTION
To resolve this issue, you must perform the following operations:
 * 1) Delete the update metadata from WSUS.

Update metadata that references the categories that correspond to the third-party catalogs in WSUS. When the last update that references a particular category is deleted, the associated category is also deleted.
 * 1) &quot;Unwedge&quot; client computers that may have cached the existing categories.

If a client computer has cached the existing categories, the client computer cannot synchronize with WSUS until the cached update metadata is removed. In this scenario, the client computer is considered &quot;wedged.&quot;
 * 1) Delete the binary files that correspond to the updates from the server.

After the update metadata has been deleted, the update can no longer be used by WSUS. You may also want to remove the update content from the server to reclaim hard disk drive space.

Note Step 3 is an optional step. It is not required to resolve the issue that is mentioned in this article.

To perform these operations, follow these steps.

Step 1: Delete the update metadata
Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure. However, they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements.

Run the following scripts to delete all the updates together with the references to the catalog that was originally imported.

Note These scripts require Windows PowerShell. For more information about how to obtain Windows PowerShell, see the &quot;More Information&quot; section.

Script 1

 * 1) enum-local-categories.ps1
 * 2) tprabhu 20071019 - WSUS v. 3.1

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.UpdateServices.Administration') | out-null
 * 1) Load administration

write-host &quot;<<< Connecting to WSUS server >>>&quot; -foregroundcolor &quot;yellow&quot; $updateServer = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer
 * 1) Create update server

write-host &quot;<<< Getting all categories >>>&quot; -foregroundcolor &quot;yellow&quot; $categories = $updateServer.GetUpdateCategories
 * 1) Get all categories

write-host &quot;<<< Dumping locally published company categories >>>&quot; -foregroundcolor &quot;yellow&quot; write-host &quot; Company categories &quot; write-host &quot; ================== &quot; write-host &quot;&quot; $i = 1 foreach ($category in $categories) { if ($category.Type -eq [Microsoft.UpdateServices.Administration.UpdateCategoryType]::Company) {   if ($category.UpdateSource -eq [Microsoft.UpdateServices.Administration.UpdateSource]::Other) {     write-host &quot;  Category #&quot; $i write-host &quot;  &quot; write-host &quot;  ID    = &quot; $category.Id      write-host &quot;   Title = &quot; $category.Title write-host &quot;  #Subcategories = &quot; $category.GetSubcategories.Count write-host &quot;  #Updates = &quot; $category.GetUpdates.Count write-host &quot;&quot; $i++ } } }
 * 1) Print out the local 'Company' categories

trap {   write-host &quot;Error Occurred&quot; write-host &quot;Exception Message: &quot; write-host $_.Exception.Message write-host $_.Exception.StackTrace exit }


 * 1) EOF

Script 2
Note This script deletes all the updates that belong to a particular category.
 * 1) delete-update-in-category.ps1
 * 2) tprabhu 20071019 - WSUS v. 3.1

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.UpdateServices.Administration')
 * 1) Load administration

write-host &quot;<<< Connecting to WSUS server >>>&quot; -foregroundcolor &quot;yellow&quot; $updateServer = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer
 * 1) Create update server

write-host &quot;<<< Getting all categories >>>&quot; -foregroundcolor &quot;yellow&quot; $categories = $updateServer.GetUpdateCategories
 * 1) Get all categories

write-host &quot;<<< Ready to delete all updates that belong to a category >>>&quot; -foregroundcolor &quot;yellow&quot; $categoryToDelete = read-host &quot;Enter category Id&quot; write-host &quot; All updates belonging to category &quot; $categoryToDelete &quot; will be deleted!&quot; $sure = read-host &quot; Continue? (y/n)&quot;
 * 1) Delete updates belonging to a category

if ($sure -ne &quot;y&quot;) { exit }

write-host &quot;&quot; write-host &quot;<<< Searching for updates belonging to category >>>&quot; -foregroundcolor &quot;yellow&quot; foreach ($category in $categories) { if ($category.Id.ToString -eq $categoryToDelete) {   $updatesInCategory = $category.GetUpdates break } }
 * 1) Get all updates that belong to category

foreach ($update in $updatesInCategory) { write-host &quot;Deleting update &quot; $update.Id.UpdateId &quot;...&quot; $updateServer.DeleteUpdate($update.Id.UpdateId) write-host &quot; Done!&quot; }

write-host &quot;&quot; write-host &quot;All updates belonging to category &quot; $category.Id.ToString &quot; are deleted&quot;

trap {   write-host &quot;Error Occurred&quot; write-host &quot;Exception Message: &quot; write-host $_.Exception.Message write-host $_.Exception.StackTrace exit }


 * 1) EOF

Step 2: Unwedge client computers
To unwedge client computers that can no longer synchronize with WSUS, you must cause each client computer to clear the cached update metadata. One method to cause a client computer to clear the cached update metadata is to change the ID of WSUS. To do this, use one of the following methods.

Method 1: If you use the default instance of Microsoft SQL Server on the local computer
By default, WSUS uses the default instance of SQL Server on the local computer. In this scenario, enter the following command to set a new WSUS ID:

%programfiles%\Update Services\Setup\ExecuteSQL.exe -S %Computername%\MICROSOFT##SSEE -d &quot;SUSDB&quot; -Q &quot;UPDATE dbo.tbConfigurationA SET ServerID = newid&quot;

Method 2: If you use a named instance of SQL Server
If you use a named instance of SQL Server, enter the following command:

%programfiles%\Update Services\Setup\ExecuteSQL.exe -S \  -d &quot;SUSDB&quot; -Q &quot;UPDATE dbo.tbConfigurationA SET ServerID = newid&quot;

Step 3: Delete update content
Note This step is an optional step.

Step 1: Delete the binary files from the content folder
The content folder contains a .cab file that contains the published binary files. To delete the files from the content folder, follow these steps:  Start the WSUS management console. Click the Options tab, and then click Server Cleanup Wizard. In the selections page, click Unneeded update files, and then follow the remaining steps to delete the files.

Step 2: Delete the binary files from the package folder
The package folder contains binary files that are not packaged in one or more .cab files. To delete the files from the package folder, follow these steps:  Start a command prompt. To do this, click Start, click Run, type cmd, and then click OK. At the command prompt, type the following command, and then press ENTER:

“%ProgramFiles%\Update Services\tools\wsusutil.exe”

 Delete the directories that are listed. To do this, use the rmdir command together with the /s and /q options.</li></ol>

Note You may want to leave the package folder intact for Windows Installer (.msi) updates. This is because clients that have installed packages continue to use the particular folder for .msi repair operations.

<div class="moreinformation_section">

MORE INFORMATION
WSUS provides APIs to allow for the distribution of updates from sources other than Microsoft Update. However, WSUS does not provide a user interface (UI) to distribute these updates. You can use the IUpdateServer.DeleteUpdate API to remove the update metadata for these kinds of updates. However, the corresponding update content remains in the package folder.

For more information about how to obtain Windows PowerShell, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/bb905330.aspx

For more information about local publishing in WSUS, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/bb902470.aspx

Keywords: kbtshoot kbprb kbexpertiseinter KB945536

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.