Restricted Software policy for Exclusion not seem to work.


Hopefully this isn't a question that's been repeatedly asked and answered, however I haven't found exactly the situation we are running into.

Situation is that we are using JamfCloud, and we have a Restricted Software policy which includes "All Computers" and in the Exclusion list I have a some computers defined which work fine, however I also have a Smart Computer Group which is defined from users who have completed an install task and should now be exclude from this Software restriction. However this does not seem to work. Those users who are not explicitly defined in the list can not run this software installer. It's as if the system ignores the Smart Computer Group. Is this the case? Can I not use SCG's in the Exclusion list?


Contributor III

We have been noticing this as well. We have a number of MB Pro units and that SCG has been added to the exclusions to restrict the upgrade helper. But those devices are still not able to upgrade.

Contributor III

I assume the smart group are picking theses devices up OK?
(i.e. recon has been run to update the inventory so it falls into the smart group scope)

If so, then it could be an issue ive been running into recently where the .jmf_settings.json isn't being automatically updated on its next scheduled update

I'm having to run a jamf manage command to force the restricted app blacklist to get updated


Yes the devices are showing up in the SCG fine, that's how I'm monitoring who has completed the task.

I will need to see what this .jmf_settings.json files is, since we are using cloud we don't usually have to poke around at the server portion of this. What command are you mentioning to force the update of the Policy exclusion list?

Legendary Contributor III

@bmcdade The .jmf_settings.json file is a local file on each Mac, not something on the server side. It's something Jamf transitioned to a few versions back. It used to be called the .blacklist file, but it was renamed and reworked into the .jmf_settings file now. It contains information about Restricted Software settings and a couple of other things. You can run this command to see the contents of the file:

sudo python -m json.tool /Library/Application Support/JAMF/.jmf_settings.json

The sudo is required because it's protected from casual examination, so it's protected from standard user tampering.
It should be easy to spot if your Restricted Software item is still being applied by examining the file contents.

To force updating as discussed, you can try doing sudo jamf manage on an affected machine to see if it helps.

Valued Contributor II

You are not alone in this, I'm on Jamf 10.16.1 - we have a restriction scoped to all managed devices & excludes a static computer group.

I have a policy to install the restricted software that runs from self service, when the user clicks the policy an api script kicks off & puts them in the excluded static computer group - then runs a sudo jamf manage - then goes to install the software (but you can't add users to exclusion list via api)

It is hit or miss. Wish this would work all the time but it doesn't, of course by placing the individual computer into the excluded list & running a sudo jamf manage works flawlessly everytime.

It is a problem with groups & restrictions scope. I hope this is fixed soon.

Looking for a Jamf Managed Service Provider? Look no further than Rocketman

Virtual MacAdmins Monthly Meetup - First Friday, Every Month


We saw this in many version (going back to 9.x even, maybe prior), where a SCG would update, but the exclusion to the SR wouldn't apply. Didn't push on it too hard as we don't have many of those, and worked around it be opening the SR policy and re-saving it (which maybe forced the SCGs to update). I thought this was addressed in a recent version, maybe 10.17? We haven't upgraded yet though.

Valued Contributor II


Thanks to everyone for the info. I will use the work around that you all seem to be using already. I would say that devices in the exclude list do work correctly however the SCG (which is a bit more dynamic) doesn't. I suppose I could use a static group and build them but that sort of defeats the use of smart groups and automation (along with Self Service).

I would say that PI-007097 looks that it just addresses any users not explicitly the Smart Computer Group. Users who are added to the exclude do work, just not those who are in the SCG.

Thanks to all for verifying that I'm not crazy.

New Contributor

Still not addressed in version 10.19

New Contributor II

I seem to be having the issue in 10.20.1 too.

New Contributor II

Bummer I was hoping they would have fixed this by now.

New Contributor III

As said above exclusions work differently, we’ve been having a good success running the following after adding the device to the exclusions in Restricted Software. You could add it as a before script:

sudo jamf manage


Having this issue with Static Groups currently, on 10.21.0. If I run a jamf manage do I then have to get the user to approve the MDM profile again?

New Contributor III

Issue still present in VERSION - 10.18.0-t1576686828 - Can see above its still in later versions as well. In our case exclusion list is from an EA derived smartgroup which was up to date. The restricted software stayed in place until 'jamf manage' was re-run.

New Contributor II

Still happening on 10.21

I have Font Book restricted on All Computers, with a static group of two computers excluded. But they aren't excluded.

I'm just going to let it through for everyone until this is fixed - if it ever is, if this thread is anything to go by its been a problem for at least 6 versions now. I haven't got time for constant workarounds.

New Contributor III

Thanks @mm2270, your advice to do a

jamf manage

is a good workaround.

I have a static group defined as exclusion in a restricted software policy scope and the issue is still there (10.21)

A new policy running a script (targets scope based on the same static group) in order to run "jamf manage" (and others commands) does the trick and saves us to interveen manually.


Edit : I should clarify that these are computer groups and not user groups.
So it's not strictly the same issue mentionned before in the present thread ( [PI-007097]) by @dan-snelson