Software Update-only mode Mavericks

[bthomason]

Does anyone know the Mac App Store Software Update-only mode command for Mavericks? This doesn't seem to work.

http://support.apple.com/kb/ht5391

[simbimbo]

Unfortunately it's broken. Here is the defect number from JAMF D-005395

[ImAMacGuy]

Just as an FYI - they removed the commands from Maverick to enable it.

the ability to enable software update only mode in 10.9 via defaults write or modifying any plist file has been specifically removed. The only way to accomplish this task starting with 10.9 Mavericks forward is via a configuration profile.

[Chris]

Is anyone using restrict-store-softwareupdate-only in a configuration profile?
It does work as in it disables all tabs except "Updates", but the Updates tab itself won't load properly:

external image link

It does realize that there are updates (it shows the badge on the App Store icon), but the page won't load.
Same profile works as intended on 10.8

[ImAMacGuy]

maybe in rumored 10.9.1 it will work?
You got farther than I did with the config profile, mine disabled all tabs :(

[bthomason]

I've tried the Restrict App Store to software updates only, and it doesn't work. All my tabs are available including the App Store.

[ImAMacGuy]

yep. we went back to blocking the app store with restricted processes until it's resolved.

[JDHatman]

I'm having the same results as Chris. After imaging the computer and applying the config profile, it disables all tabs except for the Updates, which is correct. It shows the badge icon that there are apps available, but the page never loads. I thought it was a firewall issue at first, but ML works fine.

Here's the weird thing, the exact same profile works fine if I do a clean install (not based off of an image). Maybe Mavericks doesn't like how the image was made???

[Chris]

This seems to be working now in 10.9.1:

external image link

Although the only Setting that shows up in the Profile is "Restrict Installs To Admin Users":
external image link

"Software Update Only" and "Disable App Adoption" are not shown, but the settings are applied.

[ImAMacGuy]

@Chris Thank you!

[fabian_ulmrich]

Obviously it's just working via config profile. To modify the .plist doesn't work. I still have the problem, that sometimes App Store doesn't list the updates, although I know there are updates available. Any suggestions? @Chris think you had the same probs. How did you solve it?

[ImAMacGuy]

same issue here fabsen83...

[tdurdan]

Also seeing this issue. Ive even tried creating a separate profile in Profile Manager and got the same result. Looks to me like an Apple issue. I've opened a case with Enterprise support.

[Chris]

@fabsen83 unfortunately this doesn't work consistently for us as well,
i couldn't really find a solution yet

[fabian_ulmrich]

@Chris][/url Ok, that's really sad. Especially there is no solution from Apple yet. So how are your users able to run SoftwareUpdate? I cannot leave my students with a full AppStore, because they install all free crap on their machines.

[Chris]

We're currently running Munki for Apple Updates:

http://code.google.com/p/munki/wiki/AppleSoftwareUpdatesWithMunki

[franton]

Working for me via managed preferences.

We trigger manual updates via a policy anyway.

[fabian_ulmrich]

@Chris Thanks for the link. I'll look into it. Are you using your own SUS or Apple ones?

@franton Which OS are you running? I tried several solutions to get than running on 10.9.x and it did not work for me. Would you please share how you were able to get that running? Thanks!

[franton]

@fabsen83 Use Casper's managed preferences. I'm on JSS v8.73.

System Level Enforced
Domain: /Library/Preferences/com.apple.appstore
Key: restrict-store-softwareupdate-only
Value: True
(that's key type boolean).

[fabian_ulmrich]

@franton ...and the client has 10.9.x installed? I used MCX to restrict appstore on 10.8.x clients as well successfully but not on 10.9.x.

[franton]

Yes, exactly right. I'm not having an issue with this method at all.

But then for reasons to do with our infrastructure, i'm not using config profiles at all. Local MCX all the way.

[fabian_ulmrich]

@franton Don't know what I am doing wrong, but the MCX is not applied by my clients. App Store still has all features open.

[franton]

Take a screenshot or two of how you've set things. Show me that and I can possibly point you in the right direction.

[chlaird]

Any update on this? I also can't get it working on my 10.9.x machines, so I have App Store restricted completely.

[sunny_marie]

@chlaird are you trying to make it so that your non-admin users can't update their software, or do you want them to be able to do that, but not be able to buy things from the App store?

I wanted to disallow my non-admin users from installing updates or buying apps, so I deployed a configuration profile and a script to implement it via policy (we're on 8.73 and we're not currently using MCX through Casper... long story). It alters the App Store so that an admin password is required to install apps or updates. It works well for us, but I'm not sure that's exactly what you want. What version are you using and are you using MCX?

[chlaird]

We're looking for a way to block non-admins from buying/downloading apps, but to keep the "Updates" tab enabled. We're trying to find a better way to keep our labs "current", but an "emergency" where a user in class couldn't install the newest update made us realize it might be nice if users can do updates, but nothing else

[sunny_marie]

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

[sunny_marie]

@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.

[fabian_ulmrich]

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!

[sean]

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.

[fabian_ulmrich]

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.

[sean]

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.

[sunny_marie]

@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.

[mm2270]

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.

[fabian_ulmrich]

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!