Comments on: Unattended installs of Flash Player 11.3

By: I’m renaming this blog to managingflash.wordpress.com « Managing OS X

I’m renaming this blog to managingflash.wordpress.com « Managing OS X — Wed, 22 Aug 2012 00:14:29 +0000

[...] 11.3.200.257 installed. I was aware that version 11.3.200.271 was available, but due to the issues here, I had not yet widely deployed [...]

By: New topic: Flash Player 11.4 « Managing OS X

New topic: Flash Player 11.4 « Managing OS X — Tue, 21 Aug 2012 16:46:47 +0000

[...] last week’s post here, I outlined some of the issues with Adobe’s recommended “silent” install method [...]

By: TGB

TGB — Tue, 21 Aug 2012 12:57:31 +0000

I always just make my own installer with Composer. It’s easier, and I can add my own mms.cfg that will turn off auto-update. Two plug-in files, one prefpane, one mms.cfg. Done in 2 minutes, no screwing around.

http://helpx.adobe.com/flash-player/kb/administration-configure-auto-update-notification.html

By: FTBZ

FTBZ — Mon, 20 Aug 2012 05:50:23 +0000

Here, we simply disable the auto-update when we deploy Flash with the package. Our users are not allowed to update their computers themselves.

By: More on Flash Player 11.3 « Managing OS X

More on Flash Player 11.3 « Managing OS X — Mon, 20 Aug 2012 03:12:30 +0000

[...] Managing OS X Trials and Tribulations of an OS X Administrator « Unattended installs of Flash Player 11.3 [...]

By: GregN

GregN — Mon, 20 Aug 2012 02:21:38 +0000

I’m actually not going to any effort at all. I’m currently still just installing the package that’s inside the app. What I *am* doing is pointing out that Adobe’s supported deployment method is half-baked and full of holes. But nothing is forcing you to use Adobe’s recommended deployment mechanism; if some other method works for you, by all means use it.

By: Not this either...

Not this either... — Sun, 19 Aug 2012 23:08:39 +0000

*confused* Why are you going to this effort when you only need to Compose /L/IP-Ins/Flash Player.plugin & flashplayer.xpt, /L/PP/Flash Player.prefPane as a .dmg?

By: Tim Sutton

Tim Sutton — Sat, 18 Aug 2012 18:05:25 +0000

Adobe also documents a piped command on page 72 of of the CS Enterprise Deployment guide to get the process PID (which may be the same as what Joe originally posted, the Adobe blog link in your post from 2010 doesn’t seem to work anymore). That guide’s linked to here:

http://www.adobe.com/devnet/creativesuite/enterprisedeployment.html

The command is:

launchctl bsexec `ps auwwx |grep [l]oginwindow | awk ‘{ print $2 }’` /path/to/installer -with -undocumented -command -flags

However, this ps command would return multiple results if it is run when multiple users are logged in, and may mean the command is run more than once (it definitely would in a shell environment).

Have you noticed if it is safe to run the installer in this bootstrap context even if a user is logged in, assuming one also makes the necessary UIElement modification in the bundle plist to suppress the appearance of the dock icon?

Something like ” | tail -n 1″ could be added to the end to return only the first result in the case of multiple loginwindow processes, assuming it doesn’t matter which one it’s running in.

The command provided by Adobe is the way I’ve been handling AIR updates in Munki using a forced logout, although it’s been reported by at least one person on munki-dev (Jim Zajkowski) that this approach was too unreliable. I believe I’ve seen a small number of failures, but in the single-digit percentages. I rarely need to update the AIR components, so it hasn’t gotten much use in the field – but I get the impression that’s about to change.

By: GregN

GregN — Fri, 17 Aug 2012 23:05:07 +0000

I’d guess the reason is related, yes. Of course, that’s a reason why you should _not_ turn on automatic silent updates just yet.

By: Patrick Fergus

Patrick Fergus — Fri, 17 Aug 2012 23:02:16 +0000

Is this the reason that the FP silent updates fail at the login window as well?

https://bugbase.adobe.com/index.cfm?event=bug&id=3295751

- Patrick