Time for another “think outside the box” moment. How many of us have gnashed teeth and pulled our hair over trying to manage popular web plug-ins which are primarily designed with the consumer in mind and provide little or limited means to manage them in a corporate/business environment? Well hopefully quite a few of you out there have. This blog post will hopefully enable you to better manage the behavior and settings of one of the most popular web plugins Adobe Flash Player. Like most of my forays into using SCUP beyond the mundane world of updates this was spurred on by yet another challenge from one of teammates. More and more frequently now as I deliver SCUP based solutions I get asked more and more the question – “Angie Can you SCUP this?”
So let me give you the scenario and then the step by step on how I constructed yet another creative SCUP Solution for my company.
Scenario: We wanted the ability to disable the pesky and annoying Adobe Flash Updates nag which is enabled by default in the base installer for both the IE Activex and Plugin Flash Player. Luckily Adobe has anticipated this need and given us a means to do this through the use of a file called mm.cfg. The bad news is this file needs to be created and distributed outside of the player installation. The use of the mms.cfg file is pretty well documented on Adobe’s Web Site – links are as follows:
Configuring Auto Update:
Flash Player Admin Guide (takes it beyond disabling auto updates and actually configuring security features – go straight to Chapter 4):
Basically we wanted to disable the auto update nag since many of our users lack local admin rights and we want the ability to control what updates are applied when. Now there are plenty of ways you can approach this – repackage the base installation to include the mms.cfg, or you can use traditional software distribution and just simply copy the file down in a persistent re-occurring mandatory, group policy, etc. etc. Well we want a method by which we can enforce the existence of this file as well as control the settings contained within. Software Updates scans every 24 hours (default) or when a change in software update policy is detected for an active deployment. So we can avoid an overly aggressive persistent reoccurring mandatory or avoid gaps because we live with a longer cycle on a persistent mandatory re-occurring. We can repackage Flash to be offered with mms.cfg but we have no guarantee that Flash Player might be installed via other means. That scenario is becoming more prevalent as our workforce migrates to a more mobile one. So by using software updates to deliver the mms.cfg file we can make it a compliance based item and persistent. If you have an environment that is even more tightly controlled (or needs to be) I encourage you to explore that other settings you can enable through the use of mms.cfg (i.e. privacy, local storage access, security, etc.).
Now that I’ve laid out the requirement let’s see how we go about getting this done.
Payload How To:
1. Alright time to dust off ye olde SMS Installer – It’s a fairly simple way of repackaging and encapsulating the mms.cfg file as well as copying to specific location so for my purposes it does what I need it to do. You can use any means to package up the mm.cfg – Just remember you need to be able to deliver the file itself as well perform an action to copy it to the required location. SCUP can only deliver a single file binary payload.
As you can see from the above image it’s a very simple installer routine – Compile your ipf – I compiled it into an exe because it’s basically just a simple file copy and I don’t need all the bells and whistles an msi compile might give me.
Now that you have a payload ready time to create that update….
SCUP How To:
Side Note: I’ve done a few of these blogs now so I’m going to gloss over most of the details but will provide screenshots you can use an example – the real meat of this post is in devising the detection rules.
Flash Note: Use of the mms.cfg is supported for Flash Player Version 8 and above – In the following example I am using it for Flash Player 10 but the update is generic enough to be used with any version of Flash Player.
We are defining the package as FLASH.EXE created via SMSInstaller
Because we are using SMSInstaller to create the executable please take note of the Success Code (0, zero) and Success pending reboot code (1, one). Also note we are passing the /s switch to enable the binary payload to execute silently.
NOTE: I am using the Adobe KB Article URL which details how to use the mms.cfg file to disable the AutoUpdate Feature.
Best practice – Always give you Update both an Article and Bulletin ID This makes it easier to locate in the various console views.
Prerequisites – This section can be skipped – Its used to select updates/dectoids that need to be present in order for this update to be evaluated for Installable/Installed Rules.
Superceded Updates – This section can generally be skipped – It is used to flag previously published updates as superceded by the update you are creating. If you are changing the mms.cfg file and have previously published an update wihcih delivered a mms.cfg file then you should consider superceding the previous update for that purpose.
OK Now for the fun part –
First let’s define some detection requirements (Installable Rules):
1. We only want to apply the mms.cfg file where Flash has already been installed – whether that be the Activex or Plugin
- 1. To detect if Flash has been installed I am using a File Detection Rule to detect if FlashInstall.log exists in either the SYSTEM\Macromed\Flash directory or in the case of a 32bit Flash install on a x64 OS the Windows\SYSWOW64\Macromed\Flash directory.
2. We don’t (necessarily) want to copy over an existing mms.cfg
- I am using a NOT File exists Detection Rule and as described above again accounting for a 32bit install on a x64 OS – This time of checking to see that the mms.cfg file does not exist.
3. We do have to account for both x86 and x64 installs as the file structure is slightly different for architectures.
NOTE: We do not use msi detection rules because every time the Adobe Flash team releases an Adobe Flash Update they release it in the form of an msi and that msi GUID changes with each new release.
The Installed Rule is very straightforward – If the mms.cfg file already exists then the Update is installed.
Complete the creation of your Update. Assign it to a publication, publish and your DONE!
As always TEST TEST TEST!!!!!
To make things a little easier on you – I will post the FLASHCFG.CAB file and the FLASH.EXE payload – keep in mind this is Use at your own risk.