Restrict Sierra betas and retail

znilsson
Contributor II

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?

27 REPLIES 27

stevevalle
Contributor III

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

emily
Valued Contributor III
Valued Contributor III

We have this profile in place in our environment:
https://support.apple.com/en-us/HT203018

There's a download link for a mobileconfig file created by Apple that doesn't allow any pre-release software or OS's. Confirmed working with pre-release Sierra in our environment.

znilsson
Contributor II

Thanks guys, I appreciate the help.

ftiff
Contributor

This method should work for the retail version: http://macadminsdoc.readthedocs.io/MDM/CasperSuite/JSS/restrict-major-os-update/

To be tested when it is released.

znilsson
Contributor II

@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
Valued Contributor II

Do you also select the JSS option to "Restrict exact process name"?

I ask because while the installer app will likely named "Install macOS Sierra.app", the process itself is likely to be "Install macOS Sierra".

e211186f50b64c8a8e23f561e881f8e1

Here are my proposed JSS restriction settings:

a13fb9ce1d134c6e9c83083e235ecb04

znilsson
Contributor II

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

dstranathan
Valued Contributor II

Confirmed: "Install macOS Sierra.app". No surprises here.

fc5b02f07bf14eb2b59fb65d3333b2ef

howie_isaacks
Valued Contributor II

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 :)

iJake
Valued Contributor

We've also had an MDM profile in place to block betas for some time but see my post here about how we'll be blocking the actual installer process and providing our users with a walkthrough and CreateOSXInstaller package instead.

pmcgurn
New Contributor III

I pulled down the GM candidate yesterday, and noted the name as

Install macOS Sierra.app

Software restrictions don't seem to be working for this in JSS 9.96. Opened a ticket with JAMF for clarity.

monogrant
Contributor

Same. I can't get restrictions work. Checking activity monitor shows "Install macOS Sierra" as the process.

Update: I may have needed to be patient. The restriction is now working as expected.

b7a133eb173a49b997c9d1246598cc8c

dstranathan
Valued Contributor II

Restrictions are working in 9.93 for me.

I have already put the proverbial IT smack-down on 4 end users trying to install Sierra: "Denied!"

msg4karth
New Contributor III

90b1b06fbaa54f07b5d4181e3fce76a0
though of share... using "InstallAssistant" works for us..

skeb1ns
Contributor

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.

NPU-Casper
New Contributor III

@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 :)

peterlbk
Contributor

Hi all,

i managed to prohibit the install by blocking the osinstallersetupd process.

This seems an underlying process that runs the installer and its app.

jevans76
New Contributor
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?

shibao_si
New Contributor II

We set Process Name to ' Install macOS* ', it works well

tcandela
Valued Contributor II

can multiple 'process names' be added ?

by maybe using a , or ; in between each process name ??

example
Install macOS Sierra.app,Sierra,macOS Sierra

KSchroeder
Contributor

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
Contributor

Are you using Websense/Forcepoint by any chance?

KSchroeder
Contributor

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.

ftiff
Contributor

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

sburt
New Contributor III

FYI, v9.97 of the JSS resolved this by adding the "Allow installation of macOS beta releases" boolean option in the Software Update payload under Configuration Profiles. This makes it block only beta updates rather than all OS updates.

msample
Contributor II

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)

sepiemoini
Contributor III
Contributor III

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

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!