Adobe Flash Player auto-updating

Posted on Updated on

When Adobe Flash Player is installed, notifications for auto-updating are enabled by default. Starting from version 10.3 this behavior can be changed through the Control Panel applet “Flash Player (32 bits)”, which is actually the so-called Flash Player Settings Manager. Beware though that this is a per user setting, so when you want to disable those notifications for many/all users (typically in an enterprise scenario) it seems you will have a hard time as a system administrator… Or not?



You could ask yourself if it’s such a bad thing for your users to receive update notifications:
• at least they know there are some updates and as you all know: knowledge is the base for wisdom (ahum)
• users could warn you, so you could execute the update as an administrator. Without their warnings you were still playing games on your Windows Phone Mango and Adobe Flash Player wouyld never be updated 😉
• and even if they want to install anyway, it won’t work because they don’t have the right to do so (except when they are administrator, which isn’t the case in most situations).
• …
Well, despite these few benefits there are many more disadvantages:
• your users will freak out when they see those notifications
• the service desk will have to calm down hundreds of users and eventually the service desk people will freak out too
• Your users should stay focused on their core tasks, not on Adobe Flash Player updates. With other words: it distracts them from their real work, which decreases productivity.
• it’s not really professional, isn’t it? And perhaps your users will even think their IT staff consists of amateurs! (well, probably they already think that, but hey, lets’ assume they don’t ;-))
• if some or all of your users do have administrator permissions, they do have the right to update. In that case nothing is wrong, except when you still want to keep as much overhead away from them (for many obvious reasons, see above), but also to minimize their update failures. In some environments users are administrators, but IT staff still has the task to do as much as possible for them.
• …

Ok, well, you got the point: don’t let them see those Flash Player update notifications. You could of course ask all your users to disable those notifications through the Control Panel applet, but this implies a few problems and risks:
• not all your users would obey you; I guess even most of them would ignore your recommendation/policy
• some of your users are scared to death when they have to do something Control Panel related, so it’s a bad thing for the general health of your people
• probably some of them who have tried to change the setting think they have done it right, while that not being the case… Sight…
• many of them will ask you to do it for them, because they have no time, don’t understand what you mean, etc. It means a tough time for the service desk, isn’t it? 🙂
• even if they do what you ask (or you do it for them), they still have the right to undo this change and enable the notifications again
• and so on, and so on…

First thing to do is discover where the setting is stored. Well, you can skip this part, I’ll tell you right away: in a config file called settings.sol, which is stored in %APPDATA%\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys. If you open such a file you see a few things which aren’t very readable, so I guess it’s best to set the Adobe Flash Player settings through the Control Panel applet for a certain user and then use that user’s settings.sol as a base. For example, you can copy this file to the just mentioned folder of the default user profile; well, you also have to copy a few parent folders of this file as macromedia.com and below don’t exist by default in the default profile. So you have to copy macromedia.com and everything below from your users’s %APPDATA%\Macromedia\Flash Player to the default profiles’s %APPDATA%\Macromedia\Flash Player. Every user which gets a new profile based on the system’s default profile will now have no Flash Player notifications. Be aware though new users can still re-enable the notifications, so they can still run the applet, see a non grayed out setting for update notifications and enable it. But at least new users will start without such notifications and most users will never take a look at that applet, so at least it’s a good start.

Besides of the fact your new users can reconfigure the update notification setting there is another thing which isn’t solved: what about users who already have a profile, with update notifications enabled? If you’re building a complete new environment this isn’t such a big deal, but it is if hundreds or thousands of your users already have a profile… We have already agreed on the fact that it’s not such a good idea to let your users change the setting themselves (as a general rule: please avoid telling your users where to configure something ;-)) and it’s one hell of a job to take over their screen and do it yourself. With the preconfigured settings.sol we can copy the file to existing user profiles though, which goes a lot faster and is much safer. Is it? Well, perhaps… Don’t underestimate the difficulties with roaming profiles: to be 100% sure your config file will be kept and not synced out, you have to copy it to every instance of your profile (that is, on every system that profile is loaded plus on the profile server). If you don’t know what I’m talking about, just remember that the syncing mechanism for roaming profiles can be quite confusing (although I think it is logical at the same time) and can make the distribution of settings.sol more hell than heaven, especially if you don’t know exactly what you’re doing. A solution can be to include the copy in a logon script: I guess this is the simplest, easiest and safest way, but of course you include an extra step in your logon script (copy settings.sol), which isn’t ideal for optimal logon performance…

There is another option than settings.sol. That 2nd option is another config file, called mms.cfg, and is not present by default. It should be created explicitly and be stored in %windir%\SysWOW64\Macromed\Flash on a 64 bit Windows system or in %windir%\system32\Macromed\Flash on a 32 bit Windows system. The difference with the first config file is that mms.cfg contains system wide settings. You could easily create mms.cfg as a text file and put one single line into it:
AutoUpdateDisable=1
This disables the update notification mechanism of Adobe Flash Player for every user, so for the whole system. This is a very simple, immediate and safe way of disabling those notifications, much better than settings.sol. Well, in most cases…

It all depends on what exactly you want:
• do you want to disable the notifications for the whole system? Simple: use mms.cfg.
• do you want to disable the notifications for some/many users, but not all of them? Use settings.sol and if you don’t feel confident distributing this file to existing roaming user profiles through an “external” copy, use a logon script. If even that’s not okay for you, ask your users to change the setting GUI wise themselves (if it really has to occur this way…). If there are only a few users to configure, perhaps the service desk can do it for the users?

There is one drawback to the first scenario… Even if you disable Flash Player update notifications through mms.cfg, users can still open the applet and see their own personal settings.sol values… For example, suppose the update notifications are enabled for a certain user (because there is no settings.sol (then the notifications are enabled, it’s the default behavior) or because that’s defined in the settings.sol file), but disabled in mms.cfg. In that case mms.cfg has a higher priority and overrides the corresponding setting from the user; so at the end the update notifications are certainly disabled, including for that user. The problem is the user doesn’t see this when he/she opens the applet: the setting is grayed out and shows the value from the settings.sol file (or if not present: the default value), which is enabled update notifications. The user thinks he/she should receive notifications, while that’s not case…
As this is confusing my personal vision is the following: if you want to configure the notifications for the whole system, configure it through mms.cfg, but also configure a settings.sol file with the same settings and distribute it to your default profile and your existing profiles. This way you have 1 forced setting and all your users see that setting when they open the applet, as it’s also their own personal setting. Although the setting is grayed out in the applet’s GUI and cannot be changed this way, it is possible for a user to edit its own settings.sol file of course, although I guess this would be extremely rare, as this file is almost absolutely unknown, difficult to find and very hard to edit (well, to edit in a correct way, so it’s easy for a user to screw up of course…).

Note that this drawback can sometimes be a benefit: if it’s your intention that users still can see their own personal settings, which could become active when not overridden by mss.cfg settings, then this is a good thing. In that case you want your users to see their “personal settings which become active when the administrators decide to take the system-wide setting away”. I think a desire for this behavior is rather rare, but if

Conclusion: it all depends on what you want and what your situation is. In most cases though administrators want to lock down the systems the users work on and want to disable notifications for every user on those systems. The combination of mss.cfg and settings.sol is ideal for them, although the applet can show users a confusing configuration. If the applet had been more clear about personal and system wide values, everything would be perfect. Well, that’s obviously not the case for now, but still you can disable update notifications and give users the default personal value you want! I guess this is acceptable for most environments, although certainly not perfect. I hope Adobe improves this, even if the future of Flash isn’t that clear anymore with the rising of HTML5 and less support from Apple and Microsoft (the Windows 8 Metro style IE won’t support plug-ins anymore, although the desktop version of IE will still support them).

Ciao, Pedro!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s