How to disable software update check in Mountain Lion? ASUS

[steventhemacman]

Hi,

I am new to this, but I cant figure out how to stop our client machines (10.8.2) from checking for updates. I used composer and make a software update .dmg with my settings (set to not check) and FUT, etc. And that does not seem to work. We don't want them to check at all for any system updates or App store updates.

Any help would be appreciated.

Thanks!

Steve

[jarednichols]

The ScheduleFrequency attribute of the com.apple.SoftwareUpdate.plist file controls the scheduling (in days) in Mountain Lion. I don't know if setting it to zero would disable it, but it's worth a try.

[steventhemacman]

Is that a user setting only isn't it? I believe using composer did what you recommended, but I want to disable it so it does not check when at the login screen or during "power nap" or something.

[jarednichols]

You should be able to do it in the global setting.

[franton · Accepted solution]

We have a policy that runs the following command once per machine:

/usr/sbin/softwareupdate --schedule off

[steventhemacman]

So as simple as creating a policy (under the Advanced tab, run command)? I will have to give that a try too. Sorry, I am very new at this whole thing...a bit overwhelmed!

[franton]

Exactly it!

[steventhemacman]

Awesome, thanks! I will get the hang of it eventually...

[steventhemacman]

Apparently the command is not working, as we are still seeing the machines with that policy applied running out to apple's site....

[jarednichols]

Just curious, but why not run your own SUS and not bother with this setting? I assume you want to vette updates anyway...

[steventhemacman]

Hi Jared,

We will be getting one up soon hopefully. I am really new to this, in the beginning of this discussion you say to do a global setting edit on a .plist file in the global setting. Where is this file to edit globally, then if I change the days to zero, I just push that file out I assume?

Thanks

[gregneagle]

For Lion and Mountain Lion I use a script that does this:

/bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.softwareupdatecheck.initial.plist

/bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.softwareupdatecheck.periodic.plist

-Greg

[steventhemacman]

m

[acdesigntech]

i just packaged /var/db/launch.db/com.apple.launchd/overrides.plist after making the necessary changes on a test Mac.

[plawrence]

These are the commands i've used with success

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate ScheduleFrequency -int -1

sudo softwareupdate --schedule off

[robo]

For Lion and Mountain Lion I use a script that does this: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.softwareupdatecheck.initial.plist /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.softwareupdatecheck.periodic.plist -Greg

That looks like a nice way to do it. Does the disabled key stay that way reliably, or have you seen this needing to be re-run following point updates etc?

Just wondering if this is something we can safely run once on a fresh build, or if it should be recurring.

[donmontalvo]

@robo wrote:

That looks like a nice way to do it. Does the disabled key stay that way reliably, or have you seen this needing to be re-run following point updates etc? Just wondering if this is something we can safely run once on a fresh build, or if it should be recurring.

I was thinking the same thing, and I'm surprised it's not a System or Library level defaults command. :(

Don

[gregneagle]

It turns out that

/bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.softwareupdatecheck.initial.plist

/bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.softwareupdatecheck.periodic.plist

is exactly equivalent to

/usr/sbin/softwareupdate --schedule off

Back with Snow Leopard and earlier, `/usr/sbin/softwareupdate --schedule off` affected only the current user.

But with Lion and Mountain Lion, `/usr/sbin/softwareupdate --schedule off` causes the two LaunchDaemons to be unloaded and disabled (and therefore affects all users of a machine).

Use either approach; but it seems to me you should stick with the higher-level approach as it is more likely to continue to work for future OS releases.

[donmontalvo]

@gregneagle Thanks for confirming, may the force be with you.