Methods for blocking Yosemite

[Simmo]

As the release of Yosemite draws near, what methods do you have in place to prevent users from upgrading?

I currently have the beta blocked, but need to put in place a prevention method for once it is released to the public.

I feel this is when it shines to be in an environment where the app store is blocked.

[stevevalle]

A new Restricted Software Record with a Process Name of "Install OS X Yosemite" should do it.

I would assume that blocking the Yosemite installer would be the same way as restricting the Mavericks installer. The installer would be downloaded to the Applications folder as per previous OS's.

[Aaron]

I use the Restricted Software feature to block "Install OS X" and "InstallAssistant" (I block all upgrades, as I don't want any happening without my say-so). It worked well for Mavericks, so I'd imagine (hope) that it works for Yosemite.

[hansjoerg_watzl]

We did some tests with two Restricted Software entries: "Install OS X Yosemite" and one with "Install OS X 10.10" (for earlier DP versions)
Unfortunately, most of the time, the client check is too slow. Sometimes it takes several minutes, until the block occurs. So, it's possible, the user already started the installation and the client reboots to Yosemite BEFORE the block will active.

Clients are online and have connection to the JSS server. Check interval is configured to 15 minutes (we tried it with 5 Min. too). While the Yosemite installer is open, we forced the restricted software policy with sudo jamf -manage and then the Installer will be killed immediately. But starting the installer again...nothing happens for several minutes (or never).

Any hints? (we are using JSS 9.52)

[mm2270]

@hansjoerg.watzl - sounds like something isn't configured right or is broken with your setup to me. Once the proper files get deployed to a client for Restricted Software, the local processes, like jamfAgent and the LaunchDaemon take over and should block anything you've specified, almost immediately, or at least within a few seconds, not minutes.

As @Aaron has mentioned above, blocking "InstallAssistant" should stop it, because that's the executable inside the application bundle for the installation. Although its remotely possible Apple will change it once they release the public version of Yosemite. I highly doubt it will change much from the latest beta releases, so that should be safe to use.

If you're not seeing the process get blocked very quickly once its gotten the updated xml, then I would either re-do the Restricted Software, or contact your JAMF rep and open a ticket with them to figure out why its not working.

[golbiga]

Im also seeing a difference between the time it takes the jamfAgent to kill the Yosemite installer vs Mavericks. When I launch the Mavericks installer it's almost instant (app doesn't even launch). With Yosemite the app launches and sometimes I can get as far as dropping the OS X Install Data folder at the root of the Macintosh HD before it kills the process. I'm seeing the same thing on our 8.73 production JSS and our test 9.32 JSS.

[hansjoerg_watzl]

Found something:

Was trying to test a new Restricted Software entry for the OS X Calculator. As process name I entered "Calculato" (with asterisk) to simulate the same behaviour as with the "Install OS X Yosemite".
After deploying the rule (with jamf -manage), I could still start and run the calculator. Nothing happens. But if I enter "jamf -manage" again WHILE the calculator is still open, the process will be killed. Restarting calculator still don't block it.

Now I tried to change the Restricted Software rule with process name "Calculator" (without asterisk), entered "jamf -manage" to get the updated rule and started calculator: After some second the app will be terminated!
I repeated it several times...and the calculator was always killed after some seconds (no need to enter "jamf -manage" again).

So I guess, there's a bug with using a * as process name. It's weird as it works after using "jamf -manage", but only one time and only if the process is running while entering the command.

Can somebody reproduce it with "Calculato*"? Tnx

[hansjoerg_watzl]

btw, blocking Yosemite installer with process name "InstallAssistant" (without quotes) works now as expected.
Using process name "Install OS X Yosemite Developer Preview" (without quotes and without asterisk) works only with "jamf -manage" while the installer is opened.

Unfortunately, the process name "InstallAssistant" is more generic, as it kills Mavericks installer too.

btw....I only received a violated notification mail, after using process name without an asterisk. So even if the app was killed with entering "jamf -manage" (when using * in process name), the mail was not sent.

[mjohnston]

So am I right in saying that specifying "InstallAssistant" in restricted software will work in blocking Yosemite installs but will it also block 10.9.5 installs? I have a few users who still need to get on 10.9.5.

Will it block any other installs or just OSX installs?

Thanks,
Matt

[RVA]

My Yosemite download is in progress. It's gonna take a bit longer to finish. It appears the installer is named "OS X Yosemite.app" vs "Install OS X Yosemite.app".

Update: During download process it's called "OS X Yosemite.appdownload". Changes to "Install OS X Yosemite.app" once downloaded.

[ndelgrande]

I tried everything and can't get it to block on Mavericks 10.9.5 running Casper 9.4. I tried

Install OS X Yosemite
"Install OS X Yosemite"
Install OS X Yosemite.app
"Install OS X Yosemite.app"

I opened a support ticket on it.

[mm2270]

Are you sure the restricted software setting got pulled down to the Mac you're testing with? It's not immediate. You can trigger it to happen by doing

sudo jamf manage

Support will likely ask you to do the same thing btw.

In any event, read up the thread. Consider using "InstallAssistant" as the process to block instead of any of the ones you posted.

[ndelgrande]

mm2270, you see I have a CCA badge under my name. I knew that.

Support gave me a few options and one worked. Use the following:

Another possible method is (put in the keyword only): Process Name *Yosemite*
Name of the process to restrict (e.g."Chess", or "Chess.app"). The asterisk (*) can be used as a wildcard character

Then Do NOT check this box:
Restrict exact process name
Only restrict processes that match the exact process name. The match is case-sensitive and recognizes the asterisk (*) as a literal character

?Kill process
Terminate the process when found

[mm2270]

@mjohnston
Using InstallAssistant will block Yosemite successfully but will also block the Mavericks installer. If that's an issue for you, you'll need to block the more specific app bundle name (Install OS X Yosemite) and hope no-one tries to rename it, or, do like @sgoetz does and have it delete the app completely so they can't try to rename it without needing to download it again. Cruel, but effective nonetheless.

[mm2270]

@ndelgrande,
I posted my response from my phone, which doesn't show avatars and badges, so actually I didn't see your CCA badge.
Besides, it doesn't really mean anything. I've seen plenty of people ask questions or have problems that they may have learned in their CCA class that was later forgotten, so I never make the assumption that anyone should just "know" something. I was not attempting to belittle you.

Anyway, glad they got you a working solution.

[ndelgrande]

I didn't mean for it to come out that way. My bad. It was just frustrating when the exact process name wasn't blocking it. And I just got my CCA in 9.4 ;)

[JPDyson]

Does blocking InstallAssistant block packaged upgrades (c.f. createosxinstallpkg)?

[gskibum]

Deleting the Yosemite install app isn't cruel. That's Mac admin porn! :-)

[mjohnston]

Hi all.
I set up restrictions on both "InstallAssistant" and another on "Install OS X Yosemite" and I'm very disappointed to see that it allowed me to download and install it.
I checked all boxes in restricted software for each rule.
Anyone know what's going on???

[jhalvorson]

After you created the restrictions, the clients must update the management framework to become aware.
I believe this happens A) when you reboot with the requirement that your JSS is reachable or B) by entering the jamf manage command mentioned by @mm2270][/url above.

If your JSS is not reachable from outside your firewall and you just created the restrictions, it's highly likely that someone with a Mac at home will be able to install it because the management framework has not updated.

[ndelgrande]

Guys, like I stated in my post above, use: *Yosemite*

As the process name to kill. Make sure the exact process name box isn't checked and it will kill the installer and delete it if you have that set. It was the only thing that worked for me. Casper 9.4.

[mjohnston]

Thanks ndelgrande2.
I used *Yosemite* with no quotations and exact name disabled and it worked.
Also changed my JSS check in time from 15 to 5 minutes.
Hoping this is all I need to do.

Thanks,
Matt

[jconte]

I am blocking install assistant as well. When I type TOP in terminal it shows as the process running. If I close the Yosemite installer while viewing TOP, it closes Install assistant. I suspect they will change it with 10.9.1, but you never know. We haven't seen any adverse effects yet.

[bentoms]

Hi All,

FWIW, on our 9.4 JSS we're doing the following. This still allows the stragglers to run "Install OSX Mavericks.app"

external image link

Also seems to be pretty quick.

[spraguga]

I'm noticing that I need to restart to get the InstallAssistant kill to work.

[alexjdale]

Is there a safe/clean way to reinforce the management framework? I'm wondering if there is a reason it's not a standard policy option and why it only happens on reboot, and I don't want to wait for that (you know how often users reboot).

[Chris_Hafner]

I don't know why I'm only coming across this now. However, there should be a huge warning sign around the "delete application" when using a wildcard in the name and NOT the 'exact process name'. I've seen entire sites killed with that sort of policy in place as you can't possibly test against it completely. If you're going to use a wild card I highly recommend that you simply block it and possibly have it email you so you can follow up if need be.