Preventing unmanaged Lion upgrades

[xenedar]

While it seems like a Good Thing for consumer availability, the installation of the Lion upgrade via the App Store has me somewhat concerned.

We make use of a Power User group to allow installation of additional software, while still maintaining management of the workstation via MCX, login scripts, etc (not my choice, don’t get me started). We also do not prevent users from installing applications via the App Store, since frankly, I don’t care, and it’s not IT’s problem to fix/restore them when the computer needs to be re-imaged (the App Store has its own features to re-install).

However, I now have this panic that the douchebag element in our user base – the ones who I know daily install untested updates and basically seem think their job is spend their days installing the latest-and-greatest instead of doing what they’re paid to do and actually [i]teaching[/i] – will go out and install the Lion upgrade as easily as they install McSolitaire or Twitter from the Store. And all hell will break loose when unexpected crap happens.

Historically there’s been the inconvenience of having to get a DVD to upgrade from 10.5 to 10.6 (for example). However the Lion upgrade via the App Store seems to take this away and now makes it far too easy – and at $30, far too tempting – for someone to root up their machine, or at least put it into an unexpected state (eg: printers won’t deploy, drivers won’t work).

I’ve logged a bug with Apple about this, asking for an MCX key which will allow apps to continue to be installed, but allowing IT to retain control of OS upgrades.

Anyone else’s thoughts?

[tw002]

Hi!

I’m not a developer so haven’t used Lion yet, so anyone correct me if I’m wrong – however, the way I believe it works is that the app downloaded from the App Store is simply an installer – which will download as per a normal app store app, run, then require admin credentials to actually upgrade the OS.

T.

[captainulf]

I’ve tried one way by using the Applications preferences in Workgroup Manager and denying launch of the Lion Installer by way of its bundle identifier. It seems to work for network accounts even when they’re admins on the machine. Locally defined users that are admins appear to have the option of overriding the denial by providing their password so if your users are local on the machines it may not be ideal.

Also apparently denial by bundle id is a deprecated Tiger feature although it seems to work in SnowLeopard. I’ve append the MCX settings I manually injected into the appropriate directory service object. You’ll have to substitute “com.apple.Chess” for the appropriate bundle id of the Lion installer.

[code]


mcx_application_data

com.apple.applicationaccess

Forced


mcx_preference_settings

AllowUnbundledApps

ApprovedAppLaunchesOthers

DenyList-Raw

com.apple.Chess

editable


com.apple.mcx.using.disallow.list


OpenItemsInternalDrive

SystemLaunchers-Raw

com.apple.dock

com.apple.finder

mcx_union_policy_keys


mcx_input_key_names

DenyList-Raw

mcx_output_key_name
DenyList
mcx_remove_duplicates
mcx_union_as_dictionary


mcx_input_key_names

SystemLaunchers-Raw

mcx_output_key_name
SystemLaunchers
mcx_remove_duplicates
mcx_union_as_dictionary

[/code]

[Author]

Posts