Publishing Third-Party Updates to WSUS

                               WSUS vs. GPSI

Active Directory (AD) includes Group Policy Software Installation (GPSI), which gives administrators a rudimentary means of updating or deploying software to clients by using Windows Installer (.msi) files. But GPSI wasn’t designed to scale for large networks, nor has Microsoft invested in the technology since the introduction of AD 10 years ago.
 Starting with version 3.0, WSUS includes local publishing APIs that, for the first time, let developers write code to publish custom updates to WSUS. But there’s no free tool from Microsoft for leveraging these new APIs, although local publishing methods can be accessed from Visual Basic scripts or from other programming languages. Despite this, using WSUS to deploy third-party software and updates has many advantages over GPSI, 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.

WSUS Local Publishing

The following procedures demonstrate how easy it is to publish third-party updates to WSUS. All the operations in these examples, including WSUS client updates, are performed on a Windows Server 2008 R2-based computer that’s a domain member in a test environment. Before you follow these procedures, use the Server Manager wizard to install and configure WSUS to the default settings.
      Configure WSUS for client-side targeting. To be able to separate which computers will receive your custom updates in the test environment, you need to create a computer group.
1.     Log on to Server 2008 R2 as a domain administrator.
2.     Open the Microsoft Management Console (MMC) Windows Server Update Services snap-in from Administrative Tools on the Start menu.
3.     In the console’s navigation pane, expand your WSUS server and click Options.
4.     In the Options pane, scroll down the list of configuration options and click Computers.
5.     In the Computers dialog box, select Use Group Policy or registry settings on computers and click OK.
6.     In the navigation pane, expand Computer, right-click All Computers, and click Add Computer Group.
7.     In the Add Computer Group dialog box, name the new group Local Updates, then click OK.
      Configure local machine policy for Windows Update. In a production environment, the following settings would be configured in a Group Policy Object (GPO) and linked to an organizational unit (OU) that contains computers that we want to update by using WSUS. To simplify this demo, we’ll set the local machine policy to configure Windows Update on the local computer only.
8.     Click Start, type MMC in the Start Search box, and press Enter.
9.     In the new console window, press Ctrl+M to add a new snap-in.
10.  In the Add or Remove Snap-ins window, select Group Policy Object Editor under Available snap-ins and click Add.
11.  In the Select Group Policy Object dialog box, leave the default selection of Local Computer and click Finish.
12.  In the Add or Remove Snap-ins window, click OK.
13.  In the MMC navigation pane, expand Local Computer Policy, Computer Configuration, Administrative Templates, Windows Components. Double-click Windows Update.
14.  In the center pane, double-click Configure Automatic Updates.
15.  In the Configure Automatic Updates window, select Enabled, then click OK.
16.  In the center pane, double-click Specify intranet Microsoft update service location, then click Enabled.
17.  Under Options, type http:// followed by the name of the WSUS local server in both boxes. Then click OK. (Note: In this example, the WSUS server is named WINMEM1 and all services are located on one server. Therefore, I entered http://winmem1 both for Set the intranet update service for detecting updates and for Set the intranet statistics server.)
18.  In the center pane, double-click Enable client-side targeting.
19.  In the Enable client-side targeting window, click Enable. In the Target group name for this computer box, type Local Updates. Click OK.
20.  Double-click Allow signed updates from an intranet Microsoft update service location, click Enable, and click OK.
21.  Close the MMC snap-in.
22.  Open a command-prompt window, and run the gpupdate /force command to make sure that the new settings are applied to the server immediately.
      Install Local Update Publisher. Local Update Publisher is an open-source tool that you can download for free from SourceForge. The only prerequisite for the Local Update Publisher program is the .NET Framework 3.5, which you can install by using Server Manager on Server 2008 R2. You can do this quickly by opening a PowerShell window and running the following commands:

>> import-module servermanager                                

>> add-windowsfeature net-framework 

 After the .NET Framework is set up, install the Local Update Publisher tool on the WSUS server. Then follow these steps:
1.     Start the Local Update Publisher tool from the Start menu under All Programs. (Note: You’ll be prompted to connect to a WSUS server. Because you’re working on the local WSUS server, you can leave the Name field blank, then click Connect.)
2.     In the Local Update Publisher program window, click LOCALHOST under Update Services.
3.     In the No WSUS Certificate found window that displays, click Yes.
4.     In the Certificate Information dialog box, click Create Certificate. (Note: A second window opens to indicate that a self-signed certificate has been successfully created and that it must be installed on all clients that will receive local updates.)
5.     In the installation confirmation window, click OK.
6.     In the Certificate Information dialog box, click Export Cert, then save a copy of the certificate to your desktop.
7.     Click OK.
In a production environment, you should consider using a certificate issued by a Certification Authority (CA) that’s part of your organization’s public key infrastructure (PKI).
Prepare WSUS for local 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.
1.     Click Start, type MMC in the Start Search box, and press Enter.
2.     In the new console window, press CTRL+M to add a new snap-in.
3.     In the Add or Remove Snap-ins dialog box, select Certificates under Available snap-ins and click Add.
4.     In the Certificates snap-in dialog box, select Computer account and click Next.
5.     Leave the default selection of Local Computer and click Finish.
6.     In the Add or Remove Snap-ins dialog box, click OK.
7.     In the MMC navigation pane, expand Certificates (Local Computer), then expand Trusted Root Certification Authorities.
8.     Right-click Certificates, point to All Tasks, and click Import.
9.     In the Certificate Import wizard, click Next.
10.  On the File to Import page, click Browse.
11.  Select the certificate file that you saved to your desktop and click Next.
12.  On the Certificate Store page, leave the default selection and click Next.
13.  Click Finish.
After the import finishes, click OK in the notification box. The WSUS Publishers Self-signed certificate will display in the MMC window’s center pane. Repeat steps 7 through 13 to import the same certificate in the Trusted Publishers container. You can then close the MMC Certificates snap-in.
Create a local update. To create a local update, you should work with a Windows Installer file whenever necessary because the Local Update Publisher tool automatically creates rules for applying updates through WSUS. If you must use an .exe file, and if you can’t extract a Windows Installer package from it, you’ll have to familiarize yourself with System Center Update Publisher Basic Rules. You can find more information about these rules here.
To install the latest version of Flash Player via WSUS, first download the Flash Player Windows Installer file. Then follow these steps to create a local update:
1.     On the Tools menu, click Create Update.
2.     In the Import Update from File window, which shows figure 1 below, click Browse. Then select the Flash Player .msi file that you previously downloaded. (Note: All the installation files are packaged inside the Flash Player MSI installer.)

3.     Click Next. (Note: The next page, which shows Figure 2 below, already includes all the required information except Vendor and Product.)

4.     In the Vendor box, type Adobe. In the Product box, type Flash Player 10.1.85.3 or the appropriate program version.
5.     Click Next. (Note: Because we provided the Local Update Publisher tool with a .msi file to create the update, rules are automatically populated over the next few pages of the installation wizard. You can modify or add to these rules later.)
6.     On the Package Level – Installed Rules page, which Figure 3 shows, click Next to accept the default rules.

7.     Repeat step 6 on the following pages: Package Level – Installable Rules, Installation Item Level – Superseded Rules, and Installation Item Level – Rule Metadata.
8.     Review the XML information for the update, then click Finish.
After a few seconds, you should be notified that the update has been successfully published to WSUS.
      Approve the local update. One disadvantage of using local updates is that they don’t display in the WSUS admin console; you must manage them by some other means. Fortunately, the Local Update Publisher tool lets you manage and approve local updates.
1.     In Local Update Publisher, expand LOCALHOST, Updates, Adobe, Flash Player 10.1.85.3.
2.     In the details pane, right-click the update and click Approve.
3.     In the Approve Update dialog box, which Figure 4 shows, click No Approval to the right of the Local Updates group, then click Approve for Install on the menu.

4.     At the bottom of the Approve Update dialog box, click Approve.
5.     When you’re prompted to update the approvals, click OK.
6.     Click Close.
      Verify installation. The final step is to verify that the Windows Update client installed the local update.
1.     On the WSUS server, click Start, type Windows Update in the Start Search box, and press Enter.
2.     In the search results, click Check for updates.
3.     In the Control Panel Windows Update applet, click Check for updates again on the left.
4.     After about one minute, you should see the option to install an important update.
5.     Click 1 important update is available, and check the update name to verify that it’s the local update that was just published, as Figure 5 shows.

6.     After you verify the update, click Install updates to install Flash Player.
Local Update Publisher also has basic reporting so that you can see which computers in a group have successfully received updates, as Figure 6 shows. In a production environment, there should be no reason to install Flash Player directly on a WSUS server.

   
Disabling Flash Player auto update. By default, the standard installation of Flash Player checks every 30 days to see whether a new version is available. In a corporate environment, you’ll probably want to disable this feature and manage updates centrally by using WSUS. You could modify the MSI database by using a free tool such as Microsoft Orca to include the necessary configuration file. However, that’s a rather complicated undertaking if you’re not experienced in authoring Windows Installer packages. A simpler solution is to create a configuration file (mms.cfg) to disable the auto update feature. This process is explained in the Adobe article “IT Administration: Configure Flash Player auto-update notification.” You’d then use Group Policy preferences to copy the file to the appropriate location on the client computers.

Don’t Leave Updates to Chance

The October 2010 update for Adobe Acrobat Reader alone patched 23 security vulnerabilities that, in some cases, could have allowed a remote attacker to launch malicious software. In light of such vulnerability, timely updates of ubiquitous software shouldn’t be left to chance. Systems administrators often hope that users will initiate updates themselves—but such local updates typically require that users have administrative privileges, which would further increase the likelihood of malware infection.
Using WSUS to publish third-party updates or even your own custom updates can significantly reduce the chance of computer infection. Thanks to its bandwidth throttling for slow networks and its ability (if the right architecture is in place) to reach notebooks that might not always be connected to the corporate network, WSUS is a better solution for making sure that all the computers in an organization are able to receive updates.

If you’re not comfortable using free, open-source software to publish updates to WSUS, you still have the option to rely on scripting or to create your own application. In addition, EminentWare offers two commercial solutions: the WSUS Extension Pack, for publishing local WSUS updates, and the 3rd Party Updates Pack, which contains continually updated and tested catalogs for third-party applications.