Posts tagged ‘SCCM’

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

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.