Posts tagged ‘SCUP’

SCUPing Shockwave

At the risk of stepping on the Queen of SCUP’s toes, I’m going to write-up how I deployed Shockwave with System Center Updates Publisher (SCUP).  For the prologue on what SCUP and SCCM are see last weeks post on SCUPing Flash.

Shockwave is part of our standard config.   I’m not really sure why.   Is it actually used for anything besides basic online games.   Since pushing out a mass uninstall of Shockwave isn’t in the cards, we need to patch it since we deployed it.   Shockwave doesn’t have security updates as often as Flash but it is still necessary to keep on top of.    Since I switched to using SCUP for depoying most software updates, I’ve deployed Shockwave twice.  

The following instructions assume that SCUP is installed and working.

Open the SCUP console.

1.  Right Click System Center Updates Publisher and select Create Update.
UPDATE INFORMATION
Update Title : Shockwave 11.5.9
Description: Generally I take this from the security bulletin.   I pasted:

Critical vulnerabilities have been identified in Adobe Shockwave Player 11.5.8.612 and earlier versions on the Windows and Macintosh operating systems. These vulnerabilities, including CVE-2010-3653, referenced in Security Advisory APSA10-04, could allow an attacker, who successfully exploits these vulnerabilities, to run malicious code on the affected system. Adobe recommends users of Adobe Shockwave Player 11.5.8.612 and earlier versions update to Adobe Shockwave Player 11.5.9.615.

Classification : Security Updates
Bulletin ID : APSB10-25
Vendor: Adobe Systems, Inc.
(if you’ve deployed any Adobe updates you’ll have this in a pull down list)
Product: Shockwave
(personally I put Shockwave 11 but having a product version in product number is not considered best practice)

EXTENDED PROPERTIES
Article ID: APSB10-25
CVE ID: CVE-2010-2581, CVE-2010-2582 (these are obtained from the Adobe security bulletin)
Severity: Critical (obtained from security bulletin, or your personal evaluation)
Support URL: http://get.adobe.com/shockwave
More Info URL:  http://www.adobe.com/support/security/bulletins/apsb10-25.html
Impact: Normal
Reboot Behavior: Never Reboots
Oddly enough, Jason Lewis recently wrote that this setting doesn’t actually tell SCCM what switches to use, it tells the admin what the expected patch behavior is.   That is surprising to me.   I expected “never reboots” to add a reallysuppress type of command line switch automatically.

PREREQUISITE RULES
Windows Version
Comparison – Greater Than or Equal To
Major Version = 5
Minor Version = 1
SP Major Version = 2
SP Minor Version = 0
Build Number = Blank
Product Type = Workstation
I’m doing this based on the system requirements for Shockwave.  Also I’m only deploying to workstations, not servers.

SELECT PACKAGE
Installer Type : Windows Installer  File (MSI)
Update Package Source / Download URL.   These should be identical.   You need to download the Shockwave MSI from Adobe and store it locally on a server. 
Binary Language: english
Command Line : Blank

APPLICABILITY RULES
When you add a MSI to SCUP, the applicability rules automatically contain a single applicability rule of Product ID not installed.   This rule would install Shockwave on all computers.   We only care to upgrade Shockwave where needed rather than install on all computers.   This sort of limitation could be performed in a collection within SCCM.    I prefer to build the applicability here.

I’ve found that “file version less than” rules don’t always work by themselves.   You need to check for the file existing and the file less than.   If your environment has 64 bit computers that needs to be accounted for as well.   I tend to do file version checks rather than registry checks.    I think I get more accurate results.

The applicability rule we’re building is something like this:
(File Exists, Common Paths = Windows; Path = system32\adobe\Director\swdir.dll
AND
File Version; Common Paths = Windows; Path = system32\adobe\Director\swdir.dll; Less Than 11.5.9.615
)
OR
(
File Exists; Common Paths = Windows ; Path = SysWOW64\adobe\Director\swdir.dll
AND
File Version ; Common Paths = Windows ; Path = SysWOW64\adobe\Director\swdir.dll ; Less Than 11.5.9.615
))

It is a serious pain to get these parenthesis correct.   I believe the trick was selecting the entire row.

INSTALLED RULES
The default Product installed rule works.

 After that its just like any other SCUP update.    Hit the publish button (publishes to WSUS).   Synchronise into SCCM.   Deploy

Download CAB file
This CAB file is provided as an example without warranty.   You’d need to import it into SCUP, add your own MSI and publish.

SCUP and Flash Part 2

System Center Updates Publisher (SCUP) is a Microsoft product that allows an administrator to check third-party updates into their internal WSUS server and then deploy those updates with Microsoft patches through System Center Configuration Manager (SCCM/ConfigMgr).    Third party products can provide configuration (CAB) files to make this process easier.   Otherwise the admin can do the integration fairly easily if they’ve every deployed something before.

In August I wrote a about my deployment of Flash using the CAB file provided by Adobe.   One of the primary gotchas was the presence of redundant command line switches.   SCCM administrators wondered why Adobe continued to leave those switches in their update after update.   Each newbie stumbled across that issue and had to manually remove the switches.

It turns out the command line causing issues for SCUP was required for customers still using the older ITMU technology in SMS 2003.   To resolve this issue, Adobe has released a separate CAB file for SCUP users.  

If you haven’t previously received a license to distribute Flash to your employees or if your approval is more than a year old, you need to request that at Adobe’s website.     Look at the email from Adobe to get the Flash distribution URL.   At that site there is a link for SCCM/SCUP updates version SMS/ITMU updates.    There is a new URL for SCUP admins.   I’m not sure why Adobe didn’t announce this a bit more publicly instead of silently adding it to the site.

Sadly Adobe still has not added support for any of their other products.   Adobe Flash for Firefox should be the same product team and take 5 minutes of testing.  

The new CAB for SCUP has a couple of differences.
1.   The Package ID is different.   If you’ve already imported the latest version CAB file you had been using, you will have a duplicate update when you import the new version.    So make sure you keep those straight.   If you’ve already deployed the latest Flash update using the old cab hold off on changing CABs until the next Flash release.   Might make things easier.

2.  The installation detections are different.  
The cab file now intended for ITMU checked that a specific version of Adobe Flash was installed.

This would have issues if you didn’t keep on top of your Flash releases.  If a new version of Flash was released and SCUP was still looking for that product code, it would keep trying to install over top of the newer version.   That could lead to a lot of calls.

The newer CAB for SCUP admins has four rules.

First it is looking for the ActiveX control for Flash.   Next it’s looking at the safe versions Flash registry key.   Flash uses that to prevent installing if it is an older version.    That seems like a good idea, but I’m thinking if only Flash 9 is installed the computer might never get upgraded to 10.   Lastly they check for the Operating System version.   I find this a bit odd because if it is necessary, I would normally put that in the perquisites.  

I found out about this new CAB for SCUP too late in the deployment process to switch to using it.   But I figured I’d mention it for other SCCM SCUP admins.

- hat tip to John Marcum who let me know about this CAB

Quicktime and SCUP

When Quicktime 7.6.7 came out, I wanted to deploy it with Microsoft System Center Update Publisher (SCUP).   I’d recently used SCUP to deploy Flash (for IE) and the Dell Inventory Agent.   It made sense to look at using SCUP and SCCM Software Updates to deploy patches rather than continuing to use the old Software Distribution method.   The funny thing was, when I Googled/Binged Quicktime and SCUP, I didn’t find a lot of answers.   I found a link or two to my blog.   Well, I better actually write something since the search engine expects me to have it.

SCUP can deploy MSP, MSI or EXE.   In the past I had used a BAT file to set registry keys, copy configuration files and run the install.   So that isn’t going to happen unless I compile that into a EXE.    Quicktime also requires the update of Apple Application Support.  

I decided to use my old friend SMS Installer to package the install files into one EXE and perform the installation actions.    I decided to make it as simple as possible.   The SMS install script is something like this:

Get Environment Variable %WinDir% into variable windir
Install File \\server\sourceDIR\quicktime to %empt\quicktime\
Execute %temp%\quicktime\appleapplicationsupport.msi /qn reboot=reallysuppress (wait)
Execute %temp%\quicktime\quicktime.msi
ALLUSERS=1 DESKTOP_SHORTCUTS=0 QTTASKRUNFLAGS=0 REGSRCH_INSTALL_ASU=0 /qn reboot=reallysuppress (wait)

The command-line options seem to kept the “Q” systtray icon or desktop shortcuts from occurring.   But I didn’t manage to disable checking for updates when Quicktime is opened.   It also has the really annoying new interface.   In the past I solved those problems by dropping configuration files.   That could still be done with a bit more testing.

Compile your EXE in SMS Installer (or your favorite tool to create an install file).  

Once you’re install file is ready to go you’re ready to add it to SCUP.   Select Create Update and run through the wizard.

Update Information

Update Title: Quicktime 7.6.7   (this could be anything)
Description:  Quicktime 7.6.7 improves security and is recommended for all Quicktime 7 users on Windows.   (generally I take the description from the security advisory)
Classification: Security Advisory
Bulletin ID: HT4290
Vendor: Apple
Product: Quicktime

Extended Properties

Artcle ID: HT4290
CVE ID: CVE-2010-1799
Severity: Critical
Support URL:  could be an internal url or http://www.apple.com/quicktime/download
More Info URL: http://support.apple.com/kb/HT4290
Impact: Normal
Reboot Behavior: I left this on ‘can request reboot’ although SMS Installer is returning a 0 by default

Define prerequisite Rules

 Processor Architecture = x86
and
Windows Version Greater than or Equal to
major Version 5, SP Major Version 2, Minor Version 1
Product Type = workstation

Apple supports Quicktime on XPsp2 or greater.   Apple uses a separate install file for x64.   I chose keep things simple for now and not try to package that in here.

Select Package
Installer Type = EXE
Update Package Source = Browse to your install file (I used UNC path)   doesn’t need to be accessible to anything but your installer.
Download URL or UNC = Paste the same path as above.
Command Line = /S   (this tells the SMS installer file to run silently.   If you used a different packager you’re on your own)

Define Applicability Rules
File Version:
Common Paths – select program_files
Path – quicktime\quicktimeplayer.exe
Comparison – Less than
Version – 7.67.75.0

AND
Registry key exists
HKLM\Software\Apple Computer, Inc.\Quicktime

Define Installed Rules
File Version
Common Paths – Program_Files
Path – quicktime\quicktimeplayer.exe
Comparison – Greater Than or Equal To
Version 7.67.75.0

Now you’ve got an update that is ready to go.   Publish it to WSUS and then sync to SCCM as you would with any other SCUP update.    I always see people complaining that very few venders supply CAB files for SCUP.   The fact is before this year, very few SCCM admins were using SCUP.   Vender supplied CABs might not be configured they way you want anyway.   For example the Adobe CAB for Flash assumes you want all your computers to have Flash.   If you only want to upgrade existing Flash you need to either collection limit the update or write your own detection rules.

I hope reading thought this you understand now how to roll your own update for even a complicated update like Quicktime.   Make sure you thoroughly test your deployment.

SCUP Rule Testing

Microsoft System Center Update Publisher is a method to get third-party updates deployed through SCCM and an internal update server.   As I started working with it this summer, I had issues creating applicability rules.   When you create a collection in SCCM you get immediate feedback about the accuracy of your rules.   You either have the number of computers were expecting or you weren’t. 

With SCUP, I wasn’t getting any feedback until I published the rule to the internal update server, imported that to SCCM and waited for computers to check in.   This is not a good way to work.    Fortunately Greg Ramsey of Dell helped me out on the myitforum.com SMS/SCCM mailing list.

We’re using SCUP 4.5, but SCUP 4.0 has the ability to test the rules much more easily.  I installed SCUP 4 to a test computer, imported the update I had created in 4.5, then exported it.  The export command in 4.0 has an option to export the update to a XML with a script. 

Run the script on each computer to determine if the patch is considered applicable or not.   This is a much quicker way to verify that your update’s applicability rules are written correctly.   If you make any changes to your rules, export and bring that change back to your production SCUP 4.5.

UPDATE – As it turns out, this wasn’t as great of a tool as I hoped.   It clearly reported not applicable on machines with no Adobe Reader as I desired.   SCCM unfortunately saw the patch as applicable.   Fortunately I fixed the applicability rules before any damage was d0ne.

SCUP and Flash

I deployed Adobe Flash 10.1 through System Center UpdatesPublisher (SCUP).  Its kind of sad how excited this makes me.

SCUP is a framework that allows you to integrate third-party update deployment into your SCCM/WSUS server.   Companies can provide a CAB file that you import into SCUP, approve updates and publish them to your SCCM server.  From there, to the SCCM admin they are deployed like any Microsoft patch.   The user experience is just like Microsoft patches as well.  

While I have only deployed SCUP in a test environment.  I think it has the potential for there to be less work in deploying updates.   A more consistent user experience can be achieved by deploying these updates through the same methods.   Currently I have a separate wrapper script that tells the user an update is available.   Even if I don’t ultimately deploy all my patches using SCUP, I can use it to deploy Dell and HP BIOS, firmware and driver updates.   As people try to do more with less, computers are being used longer.   It is thus more important to not ignore security and bug fixes in these items.

When you obtain a license to distribute Flash, Adobe sends you a link to download the MSI, EXE or CAB file.   I pointed SCUP directly at the CAB file.   The first time I tried to deploy to a client the install failed.   WindowsUpdate.log reported the error as 0×80070667.   Google (or Bing) tells me that error indicates bad command line switches.   The log file showed the switches as “/qn reboot=reallysuppress allusers=1 msirestartmanagercontro=disable reboot=reallysuppress”.   That has duplicate commands.   I recalled a Jason Lewis blog entry recommending the command line switches be left blank in the CAB file.   SCUP will automatically add silent install switches.  After removing the command line switches in SCUP, I published the change back to SCCM, synced everything and Flash installed without any further problems.

While I haven’t used SCUP in-depth yet, I am excited about what I do have in place.   My thanks go out to Jason Lewis, Program Manager at Microsoft,  for his great blogcasts showing how to set up SCUP.   I also found a PDF from Dell – Dell Catalog to Support Microsoft System Center Configuration Manager for Dell Hardware Updates by Dustin Orrick and Angela Qian to be very helpful.