Hey @chlaird][/url, I'm going to test something and get back to you. I'm modifying one of the boolean elements in my mobileconfig file to see if it will work for you. Additionally, we (and many others) have an option in Self Service that grants users temporary Admin access for just such occasions as the one you mention.

/url">@brockma9][/url wrote a great post (and provided scripts) on how to do that here: [https://jamfnation.jamfsoftware.com/discussion.html?id=6990

@chlaird OK, so what I tested worked, with some caveats. The profiles utility (terminal) ignores the PayloadScope key when you run it, and so if you install the profile via /usr/bin/profiles as an admin or root user, the profile will take effect for all users. Run as the user, the profile is scoped solely to them. This could be accomplished by running the install as the user ($3 value).

As I said before, we're not using Casper's MCX capability currently. What I did was created a package to drop the mobileconfig file in place, then created a simple script to install it. Where you put your config file doesn't matter. We use a hidden directory on the root of our drives for such things. If you want to install the profile per user though, their account is going to need rights to the location of the mobileconfig file.

Here is a link to Apple's document on deploying configuration profiles in Mac OS X: http://training.apple.com/pdf/wp_osx_configuration_profiles_ml.pdf

Here is the data for the mobileconfig file (props to gregneagle at github for the original, I just modified it slightly)

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>PayloadContent</key>

    <array>

        <dict>

           <key>PayloadType</key>

           <string>com.apple.appstore</string>

           <key>PayloadVersion</key>

           <integer>1</integer>

           <key>PayloadIdentifier</key>

           <string>com.github.gregneagle.config.appstore</string>

           <key>PayloadEnabled</key>

           <true/>

           <key>PayloadUUID</key>

           <string>87885FB9-E4EA-40F5-9077-DA8C6940CDAA</string>

           <key>PayloadDisplayName</key>

           <string>App Store Configuration</string>

           <key>restrict-store-softwareupdate-only</key>

           <true/>

           <key>restrict-store-disable-app-adoption</key>

           <true/>

           <key>restrict-store-require-admin-to-install</key>

           <true/>

        </dict>

    </array>

    <key>PayloadDescription</key>

    <string>App Store configuration for Mavericks.</string>

    <key>PayloadDisplayName</key>

    <string>App Store Configuration</string>

    <key>PayloadIdentifier</key>

    <string>com.github.gregneagle.config.appstore</string>

    <key>PayloadOrganization</key>

    <string></string>

    <key>PayloadRemovalDisallowed</key>

    <false/>

    <key>PayloadType</key>

    <string>Configuration</string>

    <key>PayloadUUID</key>

    <string>8E0D9AB3-7C0E-4D1F-8180-FB089A304F54</string>

    <key>PayloadVersion</key>

    <integer>1</integer>

</dict>

</plist>

To install the profile it's a simple one-liner:

/usr/bin/profiles -I -F /Path/To/Config/File.mobileconfig

Hope this helps a little bit.

Hey there,

@chlaird So for me the MCX worked fine - you just have to re-apply the MCX settings to the user or machine depending on what you have scoped it (User level / Computer level).

Remove Managed Prefs Folder first.
`rm -Rf /Library/Managed Preferences/`

To remove MCX for the computer:
`dscl . -mcxdelete /Computers/localhost`

To remove MCX for user
`dscl . -mcxdelete /Users/username`

So I did a little script which I can run via SelfService policy to delete the users as well as computer level MCX settings.

If you would like to use a profile, definitely do it the same way as @sunny.marie - deploying the profile via .pkg with imbedded postinstall script. This is something what works always, usually :)

Cheers!

FWIW, we completely block the App Store and we use an internal Software Update Server, really doesn't matter which of these you use, Reposado, Munki, Apple Software Update Server.

Even with the above blocked, the command line works and non-admins have the ability to update since 10.9

softwareupdate

If you have an internal server, then they can only update what you've allowed and you can wrap the command into your own interface using Pashua, CocoaDialog, etc or add it as a Self Service item in Casper.

Both is possible, but if you are working with VPP you can't block AppStore at all, unless you like to do everything manually right!? We also use it like @sean - just a little SelfService policy again.

Our software supplier provides us with a VPP code for the software we purchase. I download them, package them with Composer and then distribute the app with our deployment software; no manual process client machine side.

@chlaird if you've enabled MCX in your Casper setup, I'd definitely go that route, as @fabsen83 said. It'll be the simplest and cleanest overall. I like the idea that Sean had about adding a Self Service software update option. You can use that with Apple's SUS, but you'd have no way of validating updates before users got to them, which is where something like Munki comes into play. That would be a major concern in my environment, but may not be an issue in yours.

softwareupdate -ia

That short string will install all available updates on the machine. You could also use an -ir attribute to install recommended updates. If you wanted to make it totally hands off, you could create a policy to run outside business hours to install updates on all lab computers.

If you're looking to bypass the App Store for Apple updates and wanted to use a custom process, there are plenty of those around. Threads here on JAMFNation for example have tons of examples you could look at.

I also have a script I published awhile back located here:
https://github.com/mm2270/CasperSuiteScripts/blob/master/selectable_SoftwareUpdate.sh
I think a few people may still be using it, although I only created it as an experiment in 'recreating' the older Software Update type of look and feel. I don't actually use it myself because all our users are admins. We do use an internal SUS, but they have full rights to the App Store and Software Update tab within it.

Oh woooow, that's a complex one - nice! @mm2270

Instead of using an internal SUS, I also can recommend to use a 'Caching Server'. Especially if there are iOS devices to update, too!