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.
There are several conditions which must be met for the Recall feature to work:
