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.