Skip to main content
Solved

Policies showing in API but not in web interface?

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.

View original
Did this topic help you find an answer to your question?

6 replies

mm2270
Forum|alt.badge.img+16
  • mm2270
  • Legendary Contributor
  • 7880 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
jrwilcox wrote:

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?

Reply


Most helpful members this week

Terms & ConditionsCookie settingsAccessibility statement

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings