Update: How to deploy MS Hotfixes(MSU) and other Custom Updates with WSUS

This blog describes the process for deploying custom updates with WSUS. If you download Hotfixes from Microsoft in the MSU format you have the problem, that System Center Update Publisher(SCUP) only EXE, MSI and MSP supports. To deploy MSU files you have to convert them to an EXE or MSI file. With our tool/script netECM:MsuToExe which is freeware you can easily convert them.

Prepare clients

So first make sure that you have a codesigning certificate which is trusted by the clients. If you have no CA, you can use the self-signed from WSUS. To deploy this certificate you can store it in the same directory like the following script and name it WSUSPubCert.cer. Now you can deploy this script to your targed devices.

Prepare Update

Now you can download netECM:MsuToExe. It contains all tools(signtool, autoit and expand) which are needed to convert MSU files to EXE.

1. Place your MSU Files in the folder MsuToMigrate
2. Place your code-signing certificate in the certificate folder and name it wsuscert.pfx (Here is the same certificate needed like on the clients but with the private key.)
3. Modify the variable $certificatePassword in Convert.ps1 to match to the certificate password.
4. Ensure the computer has internet access(Code Signing with timestamp)
5. Start the Convert.ps1 Script
6. Your converted files are now available in the Results folder.

Add the Updates to SCUP

Start the create Software Update Wizard in SCUP. The following screen should now be displayed. Select an EXE, which you have created in the last step, as Package Source from this file are the properties received like file type and size. As download URL specify a valid path to the file, the WSUS or SCCM Server will download the update from there. Success exit codes of converted MSU files are 0 and when a reboot is needed 3010.

To separate my self created updates from others I call them always “Custom <Product> Update (<Number>) <Architecture>”. As description you can copy the problem description from support.microsoft.com.

This screen is only optional. I recommend to add the article ID.

On this screen you can specify conditions which are checked on the WSUS server before the update or some information about it are send to the client. So it’s recommended that the OS Architecture is specified here. If the Update is only for a few OS Languages they should also be specified.

Normally your update does not supersede other updates so you can skip the next step.

In the installable rules step you can specify other conditions which should met before the update is marked as needed on the system. Normally I add conditions for operating system version.

In the Installed Rules step you need to specify how WSUS can detect if the update is already installed. For MSU’s you can easily use the following Query:

SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID=”KB<ArticleID>”

Publish Update to WSUS

To make the update available to WSUS Clients or to SCCM you need to publish the update.

I recommend to always publish the full content and resign the software updates.

Check the publishing information and the continue publishing.

Refresh Updates in SCCM

To see the updates in the SCCM Console you have to synchronize the updates.

Important! Delete a Custom Update

If you would like to remove an Update do not delete it in scup until it’s already set to expired in WSUS. So the right way is:

1. Set the Update to expired in SCUP
2. Publish the Update
3. Wait Until it’s set to expired in WSUS
4. Delete the Update in SCUP or let it there