Angie Stahl at myITforum.com

SCUP: Adobe Reader 9.3.4 Update - How to create a MSP based Update

2010-08-20T17:08:00Z

Hey gang - Been awhile since I posted a blog and once again I am back at it :) And why not Adobe just dropped another reader Update on us :) Ive attached the sample cab file at the bottom of this post for those of you not yet in the DIY mode of creating custom updates but to borrow from an old Chinese proverb (liberally) - " Give a IT tech a CAB he can patch that specific update - Teach an IT tech how to create a CAB and they can update anytime they need too...."

So in that spirit here is the step by step on how to create a custom update with a msp payload -

Step 1. Download the Adobe reader 9.3.4 Update (http://www.adobe.com/support/downloads/detail.jsp?ftpID=4761) and copy to C:\temp (You may choose to copy it to a network share or some other location depending upon your own internal source file process - to use the sample cab you'll need to download it to c:\temp)

Step 2. Fire up you SCUP Console - You'll need to make sure you have a Vendor defined as well as the Reader product defined.

Step 3. Right click on the correct product (Reader 9.3) and select Create Update from the pull-out menu

Step 4. Fill in the Update Information (Ive highlighted the mandatory fields in the screenshot - but I also like to add the Adobe Bulletin ID and set the classification

Tip: For the description I generally browse to the Bulletin Web Page and cut and paste what has been provided by the vendor - no need to reinvent the wheel....

Step 5. Extended properties - by field:

Article ID: I usually use the same value as the Bulletin ID - This just makes it easier to see and sort and filter by in the SCUP Console(Console doesn't expose the Bulletin ID as a column - yet....) - Its not required

CVE ID: (Common Vulnerabilties and Exposures - http://cve.mitre.org/) generally also available from the vendor bulletin - again not required

Severity: Assign the appropriate Severity - generally the vendor should supply a rating but you may have an ISO which dictates that rating - not required

Support URL: Best pratice - I usually put the URL where you can obtain the actual update bits - Not required

More Info URL: Best practice - Use the vendor Bulletin URL in this field - Unless you have internal policy that dictates you direct users to a Service/help Desk page - required

Impact: Select the impact this update has on an applicable system - I generally use normal (default)

Reboot behavior: This actually doesn't do anything - the update it self and the return codes etc will dictate reboot behavior - but its good practice to select never reboot unless your certain the update your applying requires on - The default is can request a reboot.

Step 6. Define prerequisite rules - You dont have to define pre-requisite rules - Here's the golden rule on RULES......

You can create a update without a pre-req rule and it will evaluate to true on a client, however if you also do not have an applicability rule it will evaluate to false rendering the update invalid (there is no warning message). And if you do not define a installed rule the update cannot be published.

Best practice - Its a high level rule - If the pre-req evaluates to false no further scanning for the update will be done on the client - I generally use the Basic Rule - Processor Architecture and then add x86(32bit) and x64(64bit) if its supported for the application I am patching - if you have separate flavors then select the appropriate architecture.

Step 7. Select package - by field

Installer type: Select the correct installer type for the update - in this case its an msp (Windows Installer Patch) - My favorite kind BTW!
Update Package Source: Enter the appropriate location of the source package (network share or local drive where you've downloaded the bits to be consumed by SCUP. In our example and the attached CAB sample that location should be C:\temp.
Download URL: You can define this as the external source for the update bits - In this example and in the sample cab I am using the Adobe ftp URL (ftp://ftp.adobe.com/pub/adobe/reader/win/9.x/9.3.4/misc/AdbeRdrUpd934_all_incr.msp)- You can also use UNC pathing for an internal network share.
Binary Language: This should be scraped from the update - but if not select the appropriate language - Default is English
Success and Return Codes are scraped from the msp - In the case of other update type you may need to supply this info
Command line(quiet): Add any command line parameters you want passed - NOTE: In the case of msp and msi the /quiet and /norestart are passed automagically and are not required to be entered!

Step 8. Your DONE!!!!!!!!! - Thats right your done - The Applicability Rules and Installed Rules are scraped right out of the msp - So you dont need to do anything more but click Next/Finish and then of course publish(remember to set the publish flag to full content) and synch to deploy.

So now you have the Step by Step! The AdbeRdrUpdate934.cab sample file is attached(download and change the txt file extension to cab) and can be downloaded below - At some point Adobe will be in the business of publishing their own catalogs once again but for now hopefully this post empowers you to get busy creating your own.

SCUP: Adobe Reader & Acrobat Standard & Pro 9.3.3

2010-06-30T15:34:00Z

I'm going to keep this blog post short :) But Adobe just announced the release of a security update for Adobe Reader & Acrobat(Stand. & Pro) - You can read about here http://www.adobe.com/support/security/bulletins/apsb10-15.html and obtain the binary payload files here: http://www.adobe.com/support/downloads/product.jsp?product=10&platform=Windows.

Adobe patches are not cumulative for a given major release and there is a very specific order in which they need to be applied in order to successfully upgrade one version to the next. A very good KB on Reader & Acrobat 9 can be found here: http://kb2.adobe.com/cps/498/cpsid_49880.html.

The cab file I am providing for download (as an attachment to this blog post) applies to updating Adobe Reader 9.3.2 and Acrobat 9.3.2 only - If you need to patch or level to release 9.3.2 or 9.3.3 your going to need to develop some other strategies to get your environment leveled. You'll need to download the msp files from Adobe from the link provided above and you'll need to revise the package source and download URL to match the location you may use internally to deploy the updates. You can download the cab file below - rename the .zip to cab and import it into SCUP.

The most exciting thing about the 9.3.3 release by Adobe is that they have FINALLY addressed the msp authoring issue for both Reader (to be fair was fixed in release 9.3.2) and Acrobat. This makes it considerably easier to create a custom update and deploy it in your environment.

SCUP: Deploying Mandatory Persistent Agents via SCUP

2010-06-24T17:59:00Z

I was given an interesting challenge from one of my teammates recently. He (Greg "the Rockstar") suggested that I convert all of re-occurring mandatory advertisements into SCUP updates. So I took him up on the challenge as it makes sense to me to leverage a vehicle like SCUP plus I love a good challenge.

So why does it make good sense to use SCUP and software updates to deploy and maintain persistent software? Well there are a couple reasons which come to mind as follows:

1. Gets you out of the business of maintaining complex query-based collections for install targeting thereby reducing the load on the collection evaluator

2. Clients should be configured to scan regularly for applicable updates so you have a better shot at currency of agent installs - you don't need to rely on a collection refresh interval .

3. Clients will only install the agent if applicable - avoid inadvertent installation based on poorly constructed query or collection bleed (it happens).

A couple of challenges that you need to keep in mind when deciding to go down this road - SCUP/Software Updates limits you to a single binary payload so if you have an installer with multiple files for install you'll need to repackage it (consider using SMSInstaller - See my previous post on Patching Adobe Acrobat Standard and Pro). Also if you have a well constructed msi based binary payload a lot of your public properties can be passed via command line.

For the purposes of this blog I am going to use our 1E Nightwatchman Agent as an example. But consider any mandatory install scenario (i.e. Anti-Virus software, other security related packages, VPN Client, de-facto installs for web based plugins etc.).

First I have some deployment considerations I need to account for as follows:

We have both fresh installs and upgrade deployments - Fresh installs are for those computer systems completely lacking the agent install in the first place and our second deployment scenario is for computer systems with older version of the install. The upgrade scenario takes into account the power management policies or exclusions have been configured from previous agent installs and we do not want that configuration information overwritten.
The agent has two flavors of the client install 32bit and 64bit
We have some region specific settings which need to be accounted for when installing the agent - so I need region based installs for the agent

So the first thing I'll run through is the Fresh Install(32bit) Scenario for our AMERICAS Region:

So fire up your SCUP Console - Make sure you have defined a Vendor (1E) and a product (Nightwatchman) - The screenshot below if a finished catalog but if your doing this for the first time you'll want to Create an Update

Update Information Screen - You'll need to give your update a title, provide a description - this explains what the update is to the user if they highlight it when clicking open the systray popup (see screenshot below the Update Information screenshot). I selected a classification of Tools and used the agent version as the Bulletin id - You dont need an bulletin id but it does help you when your trying to locate stuff in the console.

Just an example of how the user see an update thats been properly SCUP'd - Yes its Flash - Thats a future blog post.....

Extended properties - Again I used the agent version in the article id field - Not required and I also added a region indicator - again just makes it easier to find and identify in the console. Just one other item of note - the More Info URL is what is presented to the user in the systray popup and something they can click on if they want more info on the update/tool and its a required field.

For my Prequisite rules I simply used my favorite Basic Rule - Processor Architecture Rule and selected x86 - Remember Pre-requisite rules are very high level and are used by the client to determine if it should even scan for applicability.

Select package - 1E provides a very well engineered msi as an agent installer but we have some pretty gnarly public properties we want to set - Our traditional package used an mst Transform file to make sure that all got set but I wanted to avoid repackaging the agent msi and mst so I opted to use the command line to pass my properties - NOTE: For reasons unknown to me the SCUP GUI has a command character limit of 100 characters and I had to pass command line parameters in excess of 100 chars. The next bit is totally unsupported but it does work - You can edit the XML after you have created your update and extend the command line beyond the 10 character GUI limit - It will then display in the GUI but you will not be able to edit it. If you have to change you command parameters you'll have to edit the XML and import into the SCUP console.

Our command line:

ALLUSERS=1 COUNTDOWNSECS=1800 LOGOFFACTION=ACTIVE PENDINGSMSJOBWINDOWSMINS=30 PIDKEY=XXXXXXX-XXXX-XXXX-XXXX-XXXX REPORTINGSERVER=yourreports.webs.dell.com RETRYATTEMPTS=0 SYSTEMTRAY=OFF

Total characters = 186

So using your favorite XML Editor you can edit the section as highlighted below - Sorry I had to redact some corp specific info but hopefully you get the idea.

Applicability Rules -

If you'll recall earlier in this post I mentioned I had some conditions I needed to account for for a variety of different install scenarios - So Ill break them out by scenario:

Fresh Install in a specific Global Region - This is a scenario where a client is scanned and there is no evidence of a previous install of the NWM Agent - Ill use three rules to accomplish this.

MSI Rule - Most likely not required given Rule 3 but just to ensure there isn't a current install of the MSI and its created automatically because of my package type so we will keep it.

WMI Query - To determine region of of computer being scanned - I need this because I have region specific command line parameters that I want set at install

Registry Key Entry - To determine if no previous NWM Agent Install exists - Not enough just to have the MSI product key detected(or not) as I have fresh installs with certain configuration items and upgrades scenarios which may have other configurations items set for the agent.

Upgrade Install in a specific Global Region - This is a scenario where a previous installation of NWM Agent is detected - We have a mix of power managed and not power managed systems as well as scripts where we have enabled end users to customize their hibernation schedule and we don't want a fresh install overwriting those configuration settings. I use the same set as above but Ill need one more rule.

MSI Rule - Most likely not required given Rule 3 but just to ensure there isn't a current install of the MSI and its created automatically because of my package type so we will keep it.

WMI Query - To determine region of of computer being scanned - I need this because I have region specific command line parameters that I want set at install

Registry Key Entry - To determine if no previous NWM Agent Install exists - Not enough just to have the MSI product key detected(or not) as I have fresh installs with certain configuration items and upgrades scenarios which may have other configurations items set for the agent.

File Version Rule - This is rule to verify that the NWM Agent installed is in fact a previous version

Installed Rule - As we are using an msi to deploy all we need is the already provided msi Product Code rule. I have provided the 1E SCUP Catalog as an attachment to this post - Just unzip the cab file and import into your SCUP Console. (NOTE: The cab file has been redacted to remove any company specific references so you need to edit the info URLs, the package source location and command line parameters -its provide as a sample ONLY) - It includes metadata for their Nightwatchman, Wakeup and Shopping products - You can import this cab into your SCUP Console - You'll need to download the msi binaries from 1E if you wish to actually test deployments. 1E provides their products as evaluation installs if your not paying customer.

SCUP: Deploying SCCM R3 BETA Client Hotfix KB977384

2010-05-28T19:45:05Z

So the company I work for is always on the bleeding edge of new SCCM technology, we are in every TAP etc. As such my most recent challenge was the task of deploying the SCCM R3 Beta Client hotfix - KB977384.

Feeling flush with the success of my Adobe patching efforts I thought why not use SCUP and deploy the hotfix as an update. Now there have been a couple of posts suggesting that you approach the hotfix deployment by using the more traditional software distribution methods - You can find them here:

http://blogs.msdn.com/b/shitanshu/archive/2010/05/04/part-1-configuration-manager-r3-beta-deployment-in-microsoft-it.aspx

http://scug.be/blogs/sccm/archive/2010/05/14/sccm-2007-r3-beta-refresh-installation-howto.aspx

http://fabien-lange.blogspot.com/2010/04/be-green-with-sccm-2007-r3-power.html

And a teammate of mine was pretty certain that an attempt to deploy using SCUP/SUM/WSUS would result in a spectacular failure. His reasoning was that in order to apply the hotfix the ccm service must be stopped and restarted.

But I felt pretty feisty and since I knew windows update agent actually does most of the heavy lifting during a software update deployment I was confident this deployment method would succeed.

Which it did and I was awarded a Thor for my efforts :) There was a little bit of complaining in the windowsupdate.log as the Windows Update Agent tried to report back to SCCM Client on its status but as soon as the SCCM client service restarted everything was fine.

So its pretty easy to create this update in SCUP. The hotfix comes in msp flavor which is the most preferred (IMHO) type of update binary. The logic for applicability is built into the msp - Its not going to apply if its not applicable. In this case the update will only apply to SCCM Client Agents at SP2 (4.00.6487.2000).

So here's how I did it:

NOTE: A word about Classifications - DON'T use the Classification type of hotfix. This is the only classification type which will not be visible in SCCM.

First lets keep things tidy shall we - Add a vendor and call it Microsoft Custom Updates. Then create a product called System Center Configuration Manager.

Now you can create your update

Update information - I've highlighted the areas you'll need to complete in the screenshot below - Use a classification type of Updates (see note above). I'm trying to spare you some of my pain.

Extended properties - I used the KB article ID for both Bulletin ID (screenshot above) and for the Article ID as well - This just makes is easier to view and sort once the update makes it into SCCM - Also you'll need the more info URL - I used once of the links from blog posts above as MS has not officially published the KB yet as R3 is still in Beta. Your company may want you to use an internal Help Desk page or something else - Its your choice. Impact is not really all that important. Reboot behavior doesnt really do anything either but as best practice I generally select never reboots - your deployment properties as well as the return codes for your binary will drive the reboot behavior.

Prerequisite Rules - KISS (Keep it Simple Stupid) - Remember these are high level rules which will instruct windows updates to even bother scanning the system for this update. Leave the fancy detection logic to the applicability rule. In the example below I used the Basic Rule for processor architecture and included both x86 and x64 - The SCCM Client Agent is still only 32bit but I do want this applied to both 32bit and 64bit systems.

Select package - Here comes the fun part and the main reason I prefer msp installer types over other installer types

Notice when you create a brand new update you have Applicability Rules and Installed rules listed in the left frame - Now take a close look at my screenshot examples above - yep that's right - If your msp is properly engineered you don't have to worry about defining either one of those rules for your update - See why I like msp's.......

OK So back to our package selection - You'll need to select the installer type and provide locations - I've provided a recommended command line parameters you may want to pass along as well - Just a quick note here the GUI is limited to 100 characters BUT you can pass longer command line parameters is required - Look for a future blog post on the how-to for that (that's a teaser folks.....).

Command Line: REINSTALL=ALL REINSTALLMODE=mous FSP=yourfsp.fqdn.com SMSSLP=yourslp.fqdn.com

I was a bit surprised about adding the FSP to the command line but this is an extract from the first blog post on deploying R3-Beta -

Note: Based on implementation experience, ensure that FSP command line is appended to the installation parameters of R3 hotfix deployments and SLP name as missing FSP parameter in command line would remove existing FSP entries from the clients.
Alrighty then!
Click through the remaining wizard windows and your DONE!!!!!
Then its simply a matter of PUBLISHING - SYNCHRONIZING - DOWNLOADING & finally DEPLOYING :)
BTW - You don't need to be all that fancy about your target collection when deploying either - If the client is not SCCM SP2 the update will scan as not applicable.
This should be a workable approach for any RTM code that's forthcoming as well but Ill post a follow-up once that code is released. And you should be able to leverage this for other hotfixes you might feel the need to deploy as well.

SCUP: Patching Adobe Acrobat Standard and Professional to 9.3.2

2010-05-17T21:16:19Z

Adobe products are notoriously difficult to patch and manage. And Adobe hasn’t done us any favors by incorrectly authoring their latest msp release 9.3.2 so that it cannot be consumed by SCUP (System Center Update Publisher). The purpose of this post is to provide a work around to leveraging SCUP to consume improperly authored msp updates. I make no claims that it is a pretty work-around but it works and that’s what counts in the end.

I dusted off my old friend SMS Installer and my intent is to wrap the Adobe Acrobat msp in an exe. A screenshot of my installer script follows – I decided it was best to wrap the payload in the exe as well so I used the Install file option. I know I could have wrapped in an msi but I didn’t want to risk SCUP balking at an improperly authored msi and the exe was the simplest to create.

OK now that I have it all wrapped up in an exe it was back to SCUP and creating the actual update.

So for my Pre-requisite Rules I used the Basic Rule for Windows Architecture and included both x86 or x64 – remember pre-requisite rules are high level rules so keep them as simple as possible and as high level as possible – Essentially when Windows Update scans for an update the first rule it evaluates is the pre-requisite rule if the system doesn’t evaluate to true no further scanning for that update is done.

Next I needed to define my Applicability Rule – Now all of this could have been much simpler for me had I been able to consume the msp directly as SCUP simply scrapes the applicability logic right out of the msp (msp know whether or not they can update or not). I decided to use the MSI Patch Installed Rule – Ill need two of these rules since the 9.3.2 msp can patch both 9.3 and 9.3.1 versions of Acrobat – Also keep in mind that if you have multiple products ids for the various installs of Adobe Acrobat base you’ll need rules for those as well. Lucky for me in this scenario I only had the single base install product code to deal with. The example of one rule follows.

Now the msi product code is fairly easy to grab and if the msp was engineered nicely you might be able to scrap the patch id from the registry. But nothing comes easy with Adobe – I used ORCA to look at the details of the msp’s for the previous patch versions (you’ll need to look at both 9.3 and 9.3.1 to capture the patch ids.

And finally I needed to define the Installed Rule – I decided to go with two detection rules – File Version and MSI Patch Installed – An example of the file version rule follows:

OK now we have a Adobe Acrobat Standard/professional patch ready to inject into SCCM and deploy using Software Updates.

My apologies to all the ConfigMgr Admins out there who are outraged by my wrapping a perfectly usable msp into an exe – I know it screams against everything we prefer as far as deployable and manageable – The solution is provided as a quick and dirty work-around to a very annoying problem with an incorrectly authored msp.

The GOOD NEWS is Adobe did manage to correct that problem with its Reader 9.3.2 msp and that can be consumed just fine using SCUP and the msp as is unwrapped.

Adobe is working to correct some of these things as announced at MMS2010 this year but they are a big company and the product groups inside Adobe are silo’d so getting all the dev teams on the same page can be a challenge – in the meantime I hope my work around helps someone. Just one little disclaimer – This shouldn’t be your standard nor regular approach to creating updates in SCUP – By order of preference when creating updates in SCUP they should come in one of the following forms:

MSP – The BEST if authored correctly – SCUP does a schema check and will fail if the msp doesn’t pass mustard – For guidance on creating msps – check out this website: http://msdn.microsoft.com/en-us/library/aa370578(v=VS.85).aspx

MSI – The next best option

EXE – Binary payload type of the last resort

The Lurker has awakened!

2010-04-28T18:05:00Z

Hello Everyone!

Im Angie Stahl - I am a L3 Systems Engineer at Dell Inc. and been working with SMS/SCCM since way back in the dark ages of 2.0. Ive been a longtime lurker on the myITforum community and rarely posted if ever. And it seems that after every MMS Ive attended I have returned home with the best of intentions of coming out as it were and contributing my experiences to share with the community. Well it seems this year is the magic one for me. Time to step out of the shadows and into the fire!

I have the great good fortune to work with a bunch of smart dudes here at Dell and many of you are familiar with them (Greg "the Rockstar" Ramsey and Donnie "fumble hands" Taylor to name a couple).

I also hope this blog will serve as my personal memory respository - Cant tell you how many times I run across an issue Ive resolved in the past only to have forgotten the fix. Its either I have been in this business too long and computers have rotted my brain or I have drunk entirely too much wine (those who know me would vote on the latter.....).

Im also super passionate about Pugs and serve as Treasurer for the Pug Rescue Austin - But Ill try to keep the pug gushing at a minimum - But cute pug photos are sure to present in my photo gallery.

So thats my brief intro and I look forward to many more blog posts in the future on things SCCM and related!