Restricting users from updating to High Sierra 10.13 issues

Are you using wildcards or forcing it to match the string exactly? I restrict "Install macOS High Sierra.app" with "Restrict exact process name" checked but I understand that someone can rename their installer if they want to get around it. It's a more casual block because I don't want to start blocking all macOS installers.

I will give that a try. Thank you!

We're still using "InstallAssistant" as the process to block and it works with High Sierra in my testing.

I am also having issues with this. I am using the exact example from the JSS webinar about it, so confused why it isn't working.

@mm2270 : Wouldn't blocking "InstallAssistant" block any upgrade? Our environment is all over the place and we just want to block High Sierra.

Thanks!

Just a note that if you use the above as shown by @Taylor.Armstrong , if a user is smart enough to rename the app, it will install.
If you use what @mm2270 posted above, changing the name won't allow the installer to run, regardless of name (the x.app).

I setup a bunch of methods used before and saw this on the test JSS today (9.101.0).

edited: I think what was just posted by @monosodium also is true - if you use "InstallAssistant", it will block macOS updates as well.
edited: I just downloaded and was able to run "macOSUpdCombo10.12.6.pkg" with "InstallAssistant" as the restriction. I thought at one time this also did more blocking, but maybe Apple changed it? So, it seems "InstallAssistant" so far is the best of the bunch...but it would likely block other OS upgrades.

I also just tried "osinstallersetupd" and it works, but the installer doesn't just quit, it gives an error message (along with the JSS restricted message) and the user has to click it to finish the process.

I've used the method that was posted here, and it still not working in my production. Though it works in my dev environment.

We can confirm the [ ] Restrict exact process name box needs to be off, else the exact process name is not blocked.

¯_(ツ)_/¯

Could this be a product issue? Regression?

@donmontalvo Which JSS version are you seeing that behavior? I'm assuming 9.101.

@JesseNCSD we're on 9.97, but that'll change soon.

I am wondering if this setup actually kills a process, or merely an app name when launched?
I setup a Restriction like this:
Process Name:

*High Sierra*

Do NOT restrict exact process name.

In testing, it works great - with the release and the betas. Yet, you could still run the "Sierra" installer OK.
However, if you change the name of the installer to omit "High Sierra", the installers (release and beta) will launch and run.

Looking at Activity Monitor while doing this, I see the exact process "Install macOS High Sierra" there, but not being quit.

So, to me, it's looking for a running app with the name, and killing it, not the process itself. Hoping I am able to make sense here...?

I modified my existing Sierra policy for High Sierra. This is working for me.

Install macOS High Sierra*

Restrict Exact Process Name is unchecked.

@gskibum Yes, but a simple renaming of the app bundle will bypass your restriction. That's the whole reason for this discussion. It's unfortunate, but the only surefire way to block it is to use the "InstallAssistant" process name, but as mentioned, this does block other OS installations, like Install macOS Sierra.app, Install OS X El Capitan, etc.

Fortunately, when using scripts like the one at https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh for OS upgrades out of Self Service, it does not get blocked because it doesn't call it the same way as double clicking on the application bundle. The InstallAssistant binary only gets run when using the GUI upgrade method as far as I can tell.

Process Name: High Sierra
Restrict Exact Process Name = Disabled

...is working for me thus far in my limited testing.