Flash Player Smart Group jargon

[llitz123]

I'm having a hard time creating a smart group to push the latest Flash player version.
All I want to do is create a smart group to the clients are missing the version installer I created and the "and/or" "is/is not" "like/not like" is confusing me. I also don't know how to "future-proof" the smart group... Meaning I dont want a user manually upgraded to a newer version to be downgraded for any reason if I flush history...
Can someone please post an example of what a smart group would look like if I wanted all users to missing the latest Adobe Flash 11.5.502.146.
I'm new to all this so if something isnt clear please let me know.
Thanks for any assistance.

[cbrewer · Accepted solution]

I use an extension attribute:

#!/bin/sh

#Extension Attribute checks to display Adobe Flash Player Version number

if [ -d /Library/Internet Plug-Ins/Flash Player.plugin ]; then
    FlashPluginVersion=`/usr/bin/defaults read /Library/Internet Plug-Ins/Flash Player.plugin/Contents/Info CFBundleVersion`
    echo "<result>$FlashPluginVersion</result>"
else
    echo "<result>Not found</result>"
fi

exit 0

Once you have that it's easy to build a smart group that looks at the version number.

[cbrewer]

external image link

[Sean_M_Harper]

I use cbrewer's extension attribute, works amazing for me.

[llitz123]

Nice. I'll get it worked out.
Thanks.

[llitz123]

One more question... What if I manually install a new version for testing (for example, v. 11.5.502.250) on computers in the Adobe Flash 11.5.502.146 Policy? I guess I should only run once on computer and not flush history on the policy - correct? Thanks for all your help.

[JPDyson]

Good you noticed that would be a problem. That's a broader question of how you do testing, really. You could set up a "testing" group to exclude from your policies, you could create a test network segment that doesn't receive policies, a separate "certification" jss where you test patches, another condition in the smart group that excludes the newer build that you're testing... or maybe half a dozen other reasonable approaches.

However, if your test machine has received the update policy already, and the policy is set to run once per computer, then it should not run again - even if it's targeted on a smart group of which said computer is a member.

[JPDyson]

A point of clarification re: future-proofing.

Arbitrary User (we'll call him Arby) has some old version of Flash, and becomes a member of this Smart Group. The Policy targeted on that Smart Group runs on his machine, updating him to your provided version of Flash. Arby later realizes there's a newer version of Flash available, and he installs it. If your policy is set to "once per computer", then it won't run on Arby's machine until you flush his log.

You, being a diligent Sys-Admin, also recognize the new version of Flash. You add logic to your Smart Group to NOT target this newer version for membership ("is not" new build number). You can now safely flush the logs and not downgrade Arby... assuming there aren't other versions of Flash going around.

You have a bigger problem. Arby is installing Flash, and you're patching Flash for Arby. These two shouldn't be going on at the same time. Why does Arby have admin rights? If he doesn't need them, revoke them. If he does have a good reason for having them (perhaps he's a developer and needs to test the new builds) then maybe you shouldn't be patching him the same way you do your muggles.

Just a thought.

[llitz123]

Thanks for your input JP.
I do have testing groups for a variety of items. I don't let users generally run updates yet there are a few users who consider themselves savvy enough to have other IT give them admin access. I stay out of political crap, yet you're gist is dead on - the tinkerers deserve any downtime they experience - including myself if I forget to add my test machines to correct groups. Thanks again for all your help.

[agirardi]

This extension attr works great for us. thanks.

[thelegendofgabe]

This is awesome, thanks.