Does anybody have the process name for the Sierra installer, so I can add it to restricted software? I need to make sure the Sierra is not installed on any of the Macs in my environment. The Sierra installer should have a unique name, right?
I have restricted the Public Beta called Install macOS Sierra Public Beta.app. Not sure what the public release will be yet!
Going from previous versions of OS X:
- Install OS X Yosemite Beta.app
- Install OS X Yosemite.app
- Install OS X El Capitan Public Beta.app
- Install OS X El Capitan.app
I can only guess that it will be called Install macOS Sierra.app
@ftiff I think the only problem with that method is that it will also block anything you try to install that uses osinstallersetupd, which as far as I know would also include older OS versions.
I already have beta releases deselected, I also have software update pointing to my OS X Server software update server which is blocking all updates so I have two go with the restricted software method to make sure people don't install it. The string I'm currently using to block processes is
Install macOS Sierra.app
And for the beta I'm using
Install macOS Sierra Public Beta.app
which works perfectly. And I understand using osinstallersetupd will block Sierra even if they rename it, but I'm not too worried about end users renaming the installer here.
@dstranathan Yeah, for example in my beta restriction, I am using Install macOS Sierra Public Beta.app, using the exact process name, and it works. In fact when I tried to install the beta on my test Mac, I had forgotten to include myself in the exceptions list, and when I tried to install the beta, Casper blocked it.
Somebody correct me if I'm wrong, but I seem to remember this issue from previous OS releases too, we had to include the .app in the exact process name for it to work.
We have setup a restriction on our JSS as well. This weekend, I'm installing the gold master on my MacBook Pro so that I can run through using Adobe Creative Cloud, Microsoft Office, and other commonly used software. Of course I will make a complete clone of my Mac before I upgrade just in case something goes wrong 🙂
Allright I'm scratching my head here. Already blocked the installer back in June using the recommended settings found in this topic (they are the same as @monogrant).
However, I noticed yesterday that somebody did upgraded to Sierra when he shouldn't be able to that. After relaunching the installer I did got the message that it's currently blocked and the process was killed as expected.
But after renaming the installer to something completely different, it launched without issues and I was able to install Sierra. Why is this possible? Shouldn't the jamf client look at the process that is running and block that? (which I presumed was the case)
I mean, now it's more "security through obscurity" because a simple rename of the .app apparently is enough to evade my policy.
@skeb1ns We had that issue with El Capitan, after watching the Jamf webinar the other day they talk about that very issue if a user has the permission to change the name they can get around it.
Try doing what @msg4karth posted, that should block it!
But of course testing in your environment is key 🙂
i managed to prohibit the install by blocking the osinstallersetupd process.
Does blocking this stop the machine from upgrading from other versions of OSX though.
i.e. If I have a ban on all OSX managed devices for the above process, would that stop them being upgraded from 10.10 to 10.11 for example? Or is that process unique to MacOS Sierra?
Any tips on how to prevent users from upgrading to a point release (i.e. Sierra 10.12.1)? Apple tightened some code up in that release, and it breaks our DLP app, so the security team has asked us to stop people upgrading to 10.12.1+ (since 10.12.2 is in beta now) altogether. Do you all know if the osinstallersetupd process is also involved in installing a point-release version?
Ultimately I'd like to stop Sierra updates until they can get the vendor issue with the app figured out, but still allow other installed apps from the AppStore to upgrade.
I'm going to test with the osinstallersetupd method mentioned above, but I'm working remote currently and only have 1 Mac which already has 10.12.1 on it. Also looking at manipulating /Library/Preferences/com.apple.SoftwareUpdate.plist to force disable allowing OS updates...
ftiff, indeed we are. Now that 10.12.2 is out, I'm proactively blocking that as well, though they told us via our TAM that they hadn't noted any particular incompatibility (more than what they had with the 10.12.1 update). They were able to give us a FP WebProxy that works with 10.12.1, but no DLP so far.
For now I'm using a softwareupdate --ignore "macOS 10.12.2 Update" to prevent it until they can verify it is compatible, and disabled updates from Mavericks/El Cap too since OS updates seem to install the very latest point release from what I've seen so far.
Thanks for the update. In short, we've had enough with websense and will move to Intel Security. Ok the MacAdmin side, it's easier to deploy, easier to administer, it's compatible with 10.12.1 (haven't checked 10.12.2 but should be) and it plays better with the system in general. Support is good, admin interface is awesome. Then it's not up to me to judge the effectiveness, but it also seems to work as good (if not better).
Just an additional observation guys... blocking the link to access the beta download
There is a link that also points to the download for the Beta which is: https://itunes.apple.com/us/app/macos-sierra/id1127487414?mt=12&l=en-us.
What I'm wondering (not having investigated this until now), if an Mac environment doesn't have the luxury of Casper Managing their Macs would blocking the links such as the one I'm pasted above also help? I understand links can be blocked by editing the hosts file also (e.g., /private/etc/hosts)
Using the Custom Settings payload when creating a Configuration Profile, I specified
com.apple.SoftwareUpdate and uploaded the corresponding property list file:
<?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>AllowPreReleaseInstallation</key> <false/> </dict> </plist>
I also had to run this command before uploading the file:
usr/bin/plutil -convert xml1 /path/to/com.apple.SoftwareUpdate.plist.
After doing this, I specified a scope and the profile installed automatically. Apple forces you to first install the
macOSDeveloperBetaAccessUtility.pkg if you aren't already enrolled into the Beta Program. From here, you're redirected to the App Store where the profile blocks the download of the macOS, in this case it was Mojave.
Apparently similar results can be reached if you simply configure the Software Update payload in the configuration profile settings as well but this works too!