Deploying third-party software using WSUS V3.x

According with reports of the major security vendors, third-party applications were responsible for the largest increase in security vulnerabilities. Now companies can easily update some of Microsoft software using Windows Server Update Services (WSUS) – a free component of the Windows Server. Since release of WSUS 3.0 companies can use WSUS API to deploy of third-party applications (Local Publishing API) either. It’s quite interesting way to deploy software, especialy for small businesses, which can’t afford to spend a lot of money for enterprise-grade software management.

There are a lot of software (Java, Adobe Reader, Google Chrome etc.) which support their own update mechanism. Usually, update of such software using native update system is not applicable for IT administrators. The main reason – such updates needs administrative priviledges. Beside of that, some software ask user to press the button to update. Not every user want to make such operation. So, after some time there are a lot of different versions of the software in the company.

Software Deployment

There are several ways how to deploy software in the company. Firstly, we can use Group Policy Software Installation (GPSI). It’s not comfortable tool when you plan to deploy even dozens of software. Beside, in case of GPSI you can deploy only Windows Installer (*.msi) setup packages. Secodly, it’s possible to use logon scripts, but it takes some time to prepare scripts. Thirdly, there are some open source (e.g. WPKG) and a lot of commercial software (Microsoft System Center Configuration Manager, Altiris etc.).

Starting with version 3.0, WSUS includes local publishing APIs that, let developers write code to publish custom updates to WSUS. But there’s no free tool from Microsoft for using these new APIs. Despite this, using WSUS to deploy third-party software and updates has many advantages, including the following:

In addition to .msi packages, command-line executables and drivers can be deployed natively without requiring users to have administrative privileges.
The Background Intelligent Transfer Service (BITS) is used to throttle the transfer of installation files to clients by using idle bandwidth. This is ideal for slow network links.
WSUS is designed to be part of an enterprise-wide distributed architecture.
WSUS includes basic reporting features.

So, to start using WSUS to deploy third-party software you need to make some Group Policy configuraion (see WSUS Local Publishing section of the article) and install Local Update Publisher (LUP). Hereinafter I just add some recommendations for the original article.

Prepare WSUS for updates

Before you continue, you must install the self-signed certificate on the WSUS server. In a production environment, you need to install the certificate on WSUS and on all clients that will receive local updates from WSUS.

Open Group Policy ManagementMMC console.
In the new console window find suitable group policy (e.g. Default Domain Policy).
Click right mouse button and choose Edit.
Select: Computer Configuration -> Policies -> Windows Settings – > Security Settings -> Public Key Policies -> Trusted Publishers.
Click right mouse button and select Import…
Import generated by LUP self-signed sertificate: “WSUS Publishers Self-signed”.
Repeat the same procedure for “Trusted Root Certification Authorities” section.
Close MMC console.

Deployment Adobe AIR 3.1.x

At this section I discuss in details how to deploy non MSI installer, e.g. Adobe AIR. Before using the example I recommend you create update package using .msi file.

Download Adobe AIR .exe installer file.
In the LUP Tools menu, click “Create Update”.
In the Import Update from File window, which Figure 2 shows, click Browse. Then select the Adobe AIR installer .exe file that you previously downloaded.
Click Next.
In the Vendor box, type Adobe. In the textboxes enter specified information.
The most interesting textbox at the pic. – Command Line. At the textbox you should enter ARGUMENTS of the installer. You can find suitable arguments at the WPKG silent install documentation for needed software (http://wpkg.org/Adobe_Air). E.g. AdobeAIRInstaller.exe -silent.
Click Next.
On the Package Level – Installed Rules page specify 6 rules to determinate either software already installed or not. At the Adobe page: http://kb2.adobe.com/cps/407/kb407625.html is described how to determinate installed version of software. Be careful with envoronment variable, since at the machine with processor architecture x64 you should use PROGRAM_FILES_COMMONX86, while at the x86 – PROGRAM_FILES_COMMON. You can make either two different packages or use complicated rule: ([processor architecture is x64] AND [check either .dll exists at the PROGRAM_FILES_COMMONX86] AND [check either .dll version in PROGRAM_FILES_COMMONX86 greater or equal to …]) OR ([processor architecture is x86] AND [check either .dll exists at the PROGRAM_FILES_COMMON] AND [check either .dll version in PROGRAM_FILES_COMMON greater or equal to …]). You should use “Group” button to make needed rule.
To add complicated rule you shoud:

Add all 6 specified before rules.
Press “Group” button and choose OR.
Select 3 rules: processor type x64 detection, check file exist in PROGRAM_FILES_COMMONX86, check .dll version in PROGRAM_FILES_COMMONX86.
Press “Group” button and choose AND.
Select remained 3 rules: processor type x86 detection, check file exist in PROGRAM_FILES_COMMON, check .dll version in PROGRAM_FILES_COMMON.
Press “Group” button and choose AND.

I recommend to save rules using “Save Rules” button.

Click Next.
Create rule for Package Level – Installable Rules. You should make sure that either .dll file is not exists (application haven’t been installed) OR .dll version less than … Concerning envoronment variable – the same problem with processor architecture.
Click Next.
Then just skip Installation Item Level – Superseded Rules, and Installation Item Level – Rule Metadata, pressing Next button.
Set “Software Definition Package” checkbox.
Review the XML information for the update, copy its to clipboard for further investigation and save then click Finish.

Resulting XML file is here.

After a few seconds, you should be notified that the update has been successfully published to WSUS. Then you should “Approve” update for selected group.

Troubleshooting

After approving update you should go to Start -> Control Panel -> Windows Update Center to initiate update search. If there is no installed application at the PC and all rules created properly, your machine should find new update. Sometimes, it takes several minutes before PC’s Windows can find new updates. If after several minutes still there is no any new updates, probably, you made a mistake in rules.

Firstly, you can check “Software Definition Package” XML file. It’s not so comfortable, but there is no way for now to return to wizard. if you determinate mistake, just delete approved package and generate proper new one.

Secondly, go to the update package in the LUP and see “Report” tab. What’s the status for the application: installed, not applicable or something else?

Thirdly, turn on detail WSUS debug info (http://support.microsoft.com/kb/902093/en-us):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace
Value name: Flags
Value type: REG_DWORD
Value data: 00000007

Value name: Level
Value type: REG_DWORD
Value data: 00000004

After that repeat update check procedure and then see at the …Windows\WindowsUpdate.log for detail information. There are a lot of information in the text file, so it takes some time to determinate mistake.

Do not forget to turn off WSUS detail info, otherwise this log file size will increase quite rapidly!!!

References: