Skip to main content
Solved

Policies showing in API but not in web interface?

  • March 3, 2017
  • 6 replies
  • 20 views
J
Forum|alt.badge.img+3
  • Javy
  • New Contributor
  • 9 replies

When using the API to pull out some policies, I discovered a good amount of policies that don't show in the web front end. They appear to be old policies but all have the naming scheme similar to "2016-07-29 at 9:42 AM | user-name | 1 Computer". If I enter the ID in the policy URL I'm able to view them. They appear in any policy API call, e.g. ../JSSResource/policies. Some of them still have a scope and enabled is checked which is concerning.

Has anyone come across this? Is this on purpose for deleted policies? Is my DB messed up? Are they still active?

Best answer by mm2270

Those are Casper Remote "policies" What's that you say? Well, you see, whenever you use Casper Remote to "push" something or run some commands against a device, its technically creating an invisible policy in the JSS, temporarily scoping that Mac or group of Macs to that temp policy, and then directing them to "check-in" to run that policy. In essence, Casper Remote isn't really reaching out to devices, its telling devices to check in with the JSS.
Unfortunately those invisible CR policies remain in the JSS and will show up in the API.

Short story is, you can safely ignore these, though you may have to account for them in any scripts that try to pull policy information since they may foul up your results. I do wish Jamf would include some flag to exclude these in an API pull so we wouldn't have to work around them.

6 replies

mm2270
Forum|alt.badge.img+24
  • mm2270
  • Legendary Contributor
  • 7886 replies
  • Answer
  • March 3, 2017

Those are Casper Remote "policies" What's that you say? Well, you see, whenever you use Casper Remote to "push" something or run some commands against a device, its technically creating an invisible policy in the JSS, temporarily scoping that Mac or group of Macs to that temp policy, and then directing them to "check-in" to run that policy. In essence, Casper Remote isn't really reaching out to devices, its telling devices to check in with the JSS.
Unfortunately those invisible CR policies remain in the JSS and will show up in the API.

Short story is, you can safely ignore these, though you may have to account for them in any scripts that try to pull policy information since they may foul up your results. I do wish Jamf would include some flag to exclude these in an API pull so we wouldn't have to work around them.

J
Forum|alt.badge.img+8
  • jrwilcox
  • Contributor
  • 82 replies
  • March 3, 2017

If you have a very old JSS, you might want to think about cleaning the out. We recently deleted over 8000 of them. Now the GUI loads much faster. These policies will never be flushed by JAMF. They stay around forever.

J
Forum|alt.badge.img+3
  • Javy
  • Author
  • New Contributor
  • 9 replies
  • March 3, 2017

Thanks guys... I was nervous about where they came from, nothing to see here.. all cleaned up.

J
Forum|alt.badge.img+3
  • Javy
  • Author
  • New Contributor
  • 9 replies
  • March 7, 2017

@jrwilcox - Just out of curiosity, how did you flush so many of them? I'm assuming you didn't do it one by one.

J
Forum|alt.badge.img+8
  • jrwilcox
  • Contributor
  • 82 replies
  • March 7, 2017

I have a script I got from one the JAMF professional services people. It works well and really helped our policy load times in the GUI.

T
Forum|alt.badge.img+3
  • TJeff
  • New Contributor
  • 7 replies
  • October 6, 2022

I have a script I got from one the JAMF professional services people. It works well and really helped our policy load times in the GUI.


Would you be willing to share the script?


Terms & ConditionsCookie settingsAccessibility statement