Restricted software does not remove / update on scoped machines

You need to have any Macs in the Cleared group run a jamf manage. That's the command that will update the Restricted Software settings on it. Restricted Software stuff is cached locally so it can be active whenever the Macs are away from the JSS as well. The 'manage' command will pull down the new settings.
I would just make a policy set to either once per computer or ongoing that is scoped to that Smart Group that runs that command. That way it will take effect as soon as possible.

In my experience, the restricted software list would update on just a simple check-in. So with your criteria, you would need recon to update that, then a jamf policy command to lift the restriction. Yeah, recon and policy alone should do it. There's a file in /Library/Application Support/JAMF called '.blacklist.xml' which lists software which is restricted. Just keep an eye on that and play with recon and policy.

Restricted Software is not a policy, so how exactly would 'jamf policy' have any affect on this? Maybe someone in authority at JAMF can chime in with the correct answer, but pretty sure its the jamf manage command that does the update for Restricted Software, at least I've never been able to get it to update without that running on them. If its supposed to update with just a recon or policy command, then something might be broken.
That being said, I will run a quick test when I can to see if I can replicate the issue or debunk what I'm saying.

Edit: Ok, maybe I'm wrong. Just ran a very quick test, and it did update, but not right away interestingly, after running jamf recon and jamf policy one after the other. But I don't know that's specifically a policy item that is doing it. I still think its reapplying the management framework that seems to get things updated. I say that because in the jamf.log I see the following lines showing up after the policy lines:

The management framework will be enforced as soon as all policies are done executing.

and

Enforcing management framework... Enforcing scheduled tasks... Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.1.plist...

etc.

So its the management framework being applied that is lifting the restriction, not specifically running a policy of any kind. But this happens automatically after doing check-ins it seems from log entries, so that's why it gets updated. You might want to look at your jamf.log on any machines where the restriction is not being lifted to see what shows up there.

@mm2270 I just did a quick test - modified the message on a restricted app, then watched the .blacklist file while I ran jamf policy and yes, it updated it.

EDIT: I'm not saying that Restricted Software is a policy, but the agent seems to download the .blacklist.xml file about 2 seconds after completing a policy check. And it seems to apply immediately.

I appreciate the quick responses from everyone, and given the evidence it does suggest that the restricted software does update on its own intermittently - I can also confirm the behavior after running jamf recon first, followed by jamf policy - but it does not produce the same results each time.

The only 100% way for sure to enforce the change is to jamf manage machines that enter the smart group. Thanks for the replies!

I wonder if this could be considered unintended behavior? I would think a check-in should also update any blacklist changes.

I have some machines that have done several days of recon (once per day) and policy (every 15 minutes) and they are still restricted despite being in the cleared smart group and showing no restricted software in the JSS. 'jamf manage' manually is the only sure way to enforce the new restricted software that I know of.

Apologies for tickling an old thread, but since I recently ran into an issue with Restricted Software settings not updating in timely manner I though I'd mentioned I was cautioned by Jamf Support that running the jamf manage command could break User Approved MDM in macOS High Sierra.

@sdagley Did JAMF support give you any more info on how User Approved MDM could break when running the 'jamf manage' command that you could expand on? I'm seeing the same issue where the software restriction isn't updating properly and apps are being blocked, even when the Mac is reporting as not being restricted in Jamf and all smart groups are up-to-date.

@dajackson Since jamf manage resets the framework it removes any existing approval and you'll need the user to re-approve the MDM profile in macOS High Sierra or later.

Thanks. I haven't seen this behaviour in our environment yet but good to know.

Running into the same issue. I've blocked MacOS Catalina through Restricted Software and scoped it to 'All Computers'. I attempted to exclude one laptop today for testing and even though Jamf reflects its no longer adhering to restricting the software update it's still acting as if it's restricted. I'm constantly getting an error that the installer was deleted. I've gone through and attempted sudo jamf manage to update the framework but this didn't appear to make a difference for me. Any ideas what could be going on?

Anybody have a solution? I'm seeing the same thing with my Big Sur Restricted Software.

Thanks
C

Are the restricted titles still showing in /Library/Application Support/JAMF/.jmf_settings.json (macOS 10.14.0 onwards)?
The jamf manage commands should recreate this, but ive had instances that only a manual removal of the file first before running a manage command to restore it with a fresh updated copy

I personally have found that calling a softwareupdate —reset-ignored will work when removing a os update/upgrade.

For macOS 10.14 onwards, you can remove /Library/Application Support/JAMF/.jmf_settings.json then kill the process JamfDaemon. That causes the process to reload and recreate a new .jmf_settings.json that is now void of all the restricted software. You would then need to create a launch daemon that would reference a script that would run during startup and run a manage command against the framework and then delete the daemon and script itself at the end. That'll effectively remove the software block just for the OS upgrade without you having to exclude specific computers.

So prior to the weekend, my Restricted Software policy for Big Sur was working flawlessly. I have a Static Group that is excluded from it; the group also runs the policy I have to reset ignored software (sudo softwareupdate --reset-ignored). Now, when I add a machine to the group and try to upgrade to Big Sur, I get an error when trying to download "Updated not available. The requested version of macOS is not available because this update is managed by your system administrator." Previously, if the machine wasnt added to the group, I could still download the OS and then the policy would block it from running. Big Sur now shows as restricted, even for the machines that I've previously upgraded.

@Jason33 Sounds like you have a Configuration Profile with a Restrictions payload configured to defer updates installed

@sdagley Thought of that after I posted, and checked my config profiles. Somehow the group got added to a policy that has the software updates delayed for 30 days. Not sure how that happened, since the group was excluded from that policy initially. I'll have to confer with one of my team. Removing that profile allowed this to work as normal now.