Subscribe to Windows IT Pro
January 19, 2011 10:50 AM

Publishing Third-Party Updates to WSUS

Use local publishing APIs to secure non-Microsoft applications
Windows IT Pro
InstantDoc ID #129241
Rating: (1)

In the first quarter of 2010, according to reports from industry security leaders Secunia, Symantec, and McAfee, third-party applications were responsible for the largest increase in security vulnerabilities—even overtaking OS flaws. Microsoft provides Windows Server Update Services (WSUS) as a free component in Windows Server to update third-party apps; Windows Update is the consumer equivalent. But small companies that don’t have access to enterprise-class management systems are left without a simple means of updating third-party applications that are installed on Windows systems.

 Even though many popular applications such as Adobe Macromedia Flash Player and Google Chrome have their own update mechanisms, such third-party software might be limited by certain conditions. For example, third-party update mechanisms might not be enforceable, or they might not be able to be centrally managed. In addition, they often require users to have elevated privileges. Considering that several update mechanisms can be running on each device, the landscape soon becomes muddled.

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. (See the sidebar “System Center Updates Publisher and Windows Server Update Services Partner Catalogs” for more information about local publishing tools.) 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.

 

Related Content:

ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.