Part 3.c: Publishing updates to WSUS with Local Update Publisher

January 3rd, 2012: This is a major work in progress. I realized how complex this could be and I that I really needed to re-write the whole page before moving forward.

I previously covered configuring your environment to use published updates from Local Update Publisher with your target WSUS clients.

I’ll be focusing this explanation on a program that generally has pretty good “support” from its developers for utilizing SMS/SCCM & SCUP for cohesive patch management; Adobe and their product Reader.

Why patch?
You probably already know the answer to this if you’re here; but if you need a reminder refer to the number of CVEs that contain the string “adobe reader” and understand that most of those can be used for exploitation.

Understanding which update packages you want:
One of the most important challenges is to understand the update packages you want, and how they are deployed. This can be very complex, but I will try to make it simple step-by-step process.

The Adobe Reader Update release docs note that all patch releases* are cumulative. For instance, to update within a minor version*, you only need to apply the latest released patch (MSP); to update between minor versions you will need to deploy an (MSI).

*note release versions are marked major.minor.patch (ex: 10.1.4 = major release 10, minor release 1, patch 4).

Summary of what we will do:
For this example, we will accept that we’ve created a baseline condition where the following items are in place:

1) We have inventoried all targeted computers’ software.
2) We have uninstalled all versions of Adobe Reader.

What we will do:
1) Publish and approve the minor version 10.1.0 MSI to our target computer.
2) Publish and approve the patch version 10.1.4 MSP to our target computer.

Obtaining the update from the developer:
A lot of software developers make it quite easy for users to obtain the variety of patches.

Adobe has an extensive site on patch and update administration. They make their updates available through links to their FTP site which are available on the various release notes pages.

In addition to the first FTP links, they reveal HTTP links in packages called Product Catalogs.

Finding and using existing packages for deployment:
Several vendors of software freely distribute what’s called a Product Catalog to be used with Microsoft’s set of configuration management software (such as SMS/SCCM and SCUP).

Each Product Catalog comes in the form of a CAB file containing an XML file that contains information on available updates for software. They are easily found by searching the internet.

Right now, I’m focused on Adobe Reader is patched to it’s highest levels, but there are several more Product Catalogs available for a wide variety of software.

Publishing an update from a Product Catalog:

  1. Make the decision to create a customized package or not. If you want to create a custom package, you must deploy it with an MSI, having had removed the previously installed version from the machines. Using Rundeck may assist with the uninstallation task.
  2. Refer to the documentation to understand the proper upgrade path to a patch (an example).
  3. Download the Adobe Acrobat Product Catalog file or the Adobe Reader Product Catalog file.
  4. Start Local Update Publisher from the Start menu.
  5. File> Import Catalog> Select the CAB file and click Open.
  6. In this window, check off the first unnamed column to include the update packages for 10.1.0 and 10.1.4, click import and the publish process will begin (download> convert to cab> publish).

Creating Update install rules:

  1. In Local Update Publisher, navigate the tree to: Update Service\SERVERNAME\Updates\Adobe Systems, Inc.\Adobe Acrobat.
  2. You will see the “Acrobat 10.1.0 Update” and “Acrobat 10.1.4 Update” updates you just published from the Product Catalog. Right-click on “Acrobat 10.1.0 Update” and click Revise.
  3. Here you will see part of the great stuff included with the update, such as notifications, impact, some stuff you may recognize from using msiexec.exe. You can click and adjust other updates that are prerequisites and updates for which this update supersedes. Click and adjust as necessary (which it shouldn’t be yet). Click Next when ready.
  4. If you check the “Save Software Definition Package”, it will save the final output of the Rules to an XML file that can then be imported.
  5. On this page you have the option to import rules from an exported XML, as well as add new rules, group rules, edit existing rules, and remove rules. Click Add Rule.
  6. Here you can create rules according to the specifications.

    In our example instance, we want to only apply the “Acrobat 10.1.0 Update” to a machine where the major version 10.0 of Acrobat is installed. Research must be performed to find out what rule absolutely qualifies this condition.
     

    Let’s create a condition block that the WSUS client will go through to figure out whether the update should be applied to a target computer:
    If:
    (
    File Version of common path: “PROGRAM_FILES” and Path: “Adobe\Reader 10.0\Reader\AcroRd32.exe” is greater than 10.0
    OR
    File Version of common path: “PROGRAM_FILES” and Path: “Adobe\Reader 10.0\Reader\AcroRd64.exe” is greater than 10.0
    OR
    File Version of common path: “PROGRAM_FILES” and Path: “Adobe\Acrobat 10.0\Acrobat\Acrobat.exe” is greater than 10.0
    OR
    File Version of common path: “PROGRAM_FILESX86” and Path: “Adobe\Reader 10.0\Reader\AcroRd32.exe” is greater than 10.0
    OR
    File Version of common path: “PROGRAM_FILESX86” and Path: “Adobe\Acrobat 10.0\Acrobat\Acrobat.exe” is greater than 10.0
    )
    AND
    (
    common path: “PROGRAM_FILES” and Path: “Adobe\Reader 10.0\Reader\AcroRd32.exe” is less than 10.1
    OR
    File Version of common path: “PROGRAM_FILES” and Path: “Adobe\Reader 10.0\Reader\AcroRd64.exe” is less than 10.1
    OR
    File Version of common path: “PROGRAM_FILES” and Path: “Adobe\Acrobat 10.0\Acrobat\Acrobat.exe” is less than 10.1
    OR
    File Version of common path: “PROGRAM_FILESX86” and Path: “Adobe\Reader 10.0\Reader\AcroRd32.exe” is less than 10.1
    OR
    File Version of common path: “PROGRAM_FILESX86” and Path: “Adobe\Acrobat 10.0\Acrobat\Acrobat.exe” is less than 10.1
    )
    OR
    (

    )

    Determining the Product Code:
    The absolute correct way is a little bit different.

    You can query the following registry:
    HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Acrobat Reader\10.0\Installer reg_sz:ENU_GUID and decrypt the value as described in that blog post. That’s really very annoying.

    You can also query WMI which can be very extensible. Take a look at WMI CIM Studio, wbemtest, WQL docs, and MOF standards. Please, do not use Win32_product (refer to More Information); use something else.

Where to go for more information on additional

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: