Unable to execute process when Installer is part of "Restricted Software" policy without multiple manually/delayed initiated executions

[CAJensen01]

This process uses the standard Mac OS installer.

If you're blocking/restricting users from using this installer via Jamf Pro's Restricted Software, and attempting to run this script as part of an upgrade policy, they will not be able to due to the restricted software entry.

In most environments, there need to be prerequisites installed as part of the upgrade, such as updates to the antivirus client, and perhaps other changes that happen at the time of the upgrade.

Subsequently, if you do this as a series of chained policies, it won't work. If you install the prerequisites, and then run a recon (to put the machine in an exempt group for that restricted software record), the machine still gets hit with the restricted software record. This is because the machine needs to execute a "jamf manage" to refresh the restricted software blacklist.

You cannot run a "jamf manage" during the policy execution (even on an earlier chained script), because it will yield: "The management framework will be enforced as soon as all policies are done executing.” --which means it won't complete that operation to update the blacklist until all of chained scripts/policies are completed.

As a result, if you do have the installer as restricted software, and want to run a bunch of prereqs as part of the upgrade process/policy and then move the machine to a restricted software exempted group (either smart or static), the only solution I've found is that you're forced to break the policies up into multiple, manually initiated policies. (or a second automated policy that just runs later if you're executing it based on caching the installer, etc.)

[kc9wwh]

@CAJensen01 I'm setting up my test device to play around with this today. I don't know if we want to circumvent the restricted software, but I'm gonna look at a way to get it updated on the client sooner.

[kc9wwh]

@CAJensen01 So there are few options you have with this scenario...

1. The simplest option is to just rename the installer or even just remove the spaces (i.e., "Install_macOS_Sierra.app") and your Restricted Software policy wouldn't be affected.
2. You could add a sudo rm /Library/Application\ Support/JAMF/.blacklist.xml to the script, but keep in mind this removes all restricted software policies, plus you'll want to tag on a sudo jamf manage so when it downloads the updated .blacklist.xml file when everything else is finished.
3. The other option you could do is create an extension attribute to read/tail the .blacklist.xml file and look if the Install macOS Sierra.app policy is still listed and once it isn't it can fall into the group for allowing the install script. You could also create a policy that would run sudo jamf manage every check-in until the above conditions are met, but I'd try to avoid that piece.

Do those work for you?

[CAJensen01]

Very outside the box thinking on these solutions. Will give some of these a go tomorrow and see if they work well.

[CAJensen01]

Look like the first two worked fine. Thanks for the ideas/solutions.

[krispayne]

This might should be added to the documentation somewhere? I feel it's a common thing that us admin's are restricting the OS upgrades as strongly as possible.

[Lotusshaney]

You blocking the installer incorrectly in the JSS. You should not be blocking the Install macOS Sierra.app or Install macOS High Sierra.app but instead block the InstallAssistant process. This stops the GUI from running but allows the CLI startosinstall to run

[krispayne]

@Lotusshaney I wasn't aware that there was a process to block other than the app itself. Can you provide the process name I should be blocking instead? From my research, the process name that comes up is the app name.

I've done step one from above and it's working fine. Just had to change some things around to get the underscores out of the dialog prompts.

Thanks for working this up @kc9wwh