Restricted software does not remove / update on scoped machines

glopez1
New Contributor II

In our environment we've blocked the execution of the 10.11.x installers for El Capitan until we update relevant core software on the machines to support it.

Machines that check in and eventually update software to meet these requirements fall into a smart group more or less called "Cleared for 10.11 El Capitan".

We have the restricted software policy set to "All Machines, Exclude 'Cleared for 10.11 El Capitan' ". The restriction functions as expected, but when the machines do eventually meet the requirements and are moved into the "cleared" smart group, the software is still restricted on the machine. If I check on the machine in Casper, it does not show that it has any restricted software in scope (as expected), but when attempting to run the software in question it is still blocked. The machines check in several times per day and update inventory daily, they also always have connectivity to the jamf server - yet the restriction is never lifted.

I have run jamf policy and jamf recon and no change takes place. Intermittently, after several hours or days the restriction is lifted on some machines, but not all. What triggers the updated restricted software list on client machines? The only way I have found to reliably lift the restriction is to 'jamf manage' the machine, but I feel this is unnecessary and should not be required. Why is this software list not updated locally with a 'jamf policy'?

17 REPLIES 17

mm2270
Legendary Contributor III

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.

thoule
Valued Contributor II

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.

mm2270
Legendary Contributor III

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.

thoule
Valued Contributor II

@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.

glopez1
New Contributor II

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.

sdagley
Esteemed Contributor II

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.

dajackson
New Contributor

@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.

sdagley
Esteemed Contributor II

@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.

dajackson
New Contributor

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

david_concannon
New Contributor

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?

gachowski
Valued Contributor II

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

Thanks
C

garybidwell
Contributor III

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

mcgroartymj
New Contributor

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

coaty_obrien
New Contributor II

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.

Jason33
Contributor III

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.

sdagley
Esteemed Contributor II

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

Jason33
Contributor III

@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.