Restricted Mac OS v.10.12 Sierra Upgrade in corporate environment fails

Restricted applications in Casper are not dependent on a connection to your LAN. The apps are blocked by a definitions file that lives locally on your computer and is called by one of the JAMF launchagents or launchdaemons.

There are quite a few threads here about how to block macOS Sierra's installation. Refer to them and then double-check your settings on your Sierra restricted software entry. I've been using it successfully for several weeks and my students -- who take their computers home and off our LAN -- are being successfully prevented from upgrading to Sierra.

Can't a user install from a bootable USB installer and get around the Casper block?

Same here @damienbarrett - I've got ours set up to block and delete the application when found, on or off the network. How is yours setup?
@

I've attached screen shots of how I set up our blocks.

How do you have yours setup @AFlandez ? And are you on the latest version of the JSS?

If you do not have a firmware password defined for the machine in question , it is very easy to get around the macOS Sierra upgrade block...you can make a thumb drive with the installation using any number of tools including the ones Apple provides without even knowing the local admin password of the machine. Even with the restriction and the firmware block, it is still possible but much, much harder. definitely do refer to the threads on here out how to block thoroughly.

Also remember the axiom if you have physical access to something, it is likely impossible to block every possibility. I could name one way to bypass both restriction and firmware password but won't spell it out here simply because my users or yours could be watching.

After you put the restrictions in place did you run an attempt to install Sierra to verify everything was set and working as expected? If not I'd start there. As someone mentioned there are a few other discussion topics regarding this.

As @damienbarrett mentioned, the file lives locally on the client machine so it shouldn't matter if it's off the network or not. Have you looked at the logs to make sure the machine(s) in question have been checking in regularly and the JAMF client is working as expected?

@ DFeredinos - I have something similar except that I didn't Restrict Mac OS v.10.12 with the .app*. Our Production JSS is on the most current version v.9.96.

@AFlandez Your Process Name does not look right. Have you tested to see if it will kill/delete the actual app when you try to open it?

You can also block the "InstallAssistant" process.

Try blocking "Install macOS Sierra.app"

@DFeredinos @AFlandez , the correct name of the app is "Install macOS Sierra.app" as @chris.hansen.hsu said:

Thanks everyone for your valuable input and suggestions. I didn't follow the 6 or 7 P's depending on how you count them: Proper Planning Procedures Prevents Piss-Poor Performance... Period! After performing an update to our Dev JSS to JSS v9.96 our Dev JSS was hosed. Still working on a resolution with our TAM. This is besides the point. Thanks RobertHammen, I didn't have the Process Name correct. I also didn't have the correct version for Smart Group for Policy. Thanks also Brad_G; Some of the systems aren't checking into JSS regularly so I need to run the commands: sudo jamf checkjssconnection and sudo jamf recon for some systems. I suppose you do have to sometimes fail to succeed. Hopefully not too often. Much to learn I have....

@AFlandez sudo jamf manage should update the management framework and pull down the latest Restricted Software definitions...

Thanks RobertHammen for the update. This is very much appreciated.