Casper Remote policies appear in results

[homebysix]

It looks like one-time package installs that occur through Casper Remote are appearing in the results of the installs verb. For example, on my JSS, jss_helper installs 86 produces this:

Policies with SomeWidget.dmg:
ID: 38  NAME: 2014-03-18 at 9:03 PM | john_doe | 1 Computer
ID: 95  NAME: 2014-05-07 at 8:26 PM | john_doe | 2 Computers
ID: 77  NAME: 2014-06-23 at 11:53 PM | john_doe | 1 Computer

Perhaps some admins will care about whether packages are used in Casper Remote, but I only care about whether they are used in the policies listed in the Policies section of the JSS web app.

What do you think?

[sheagcraig]

I don't think I've ever even opened Casper Remote. So it basically just creates a policy object and tells the computer to run it with some custom trigger, I'm guessing? But then they just sit on the JSS as Policy objects indefinitely?

[homebysix]

Yep, looks that way. I pulled a list of all my JSS policies using the API, and a full 801 out of 973 are Casper Remote policies. The names are all similar to the ones above.

[sheagcraig]

As you've probably noticed, I'm busy implementing as many of these as possible!

Is there any differences that you can see between a "regular" policy and one of these Casper Remote policies other than the name following a specific format?

I can write a regex to differentiate between the two, but if there's an easier attribute to compare that I'm missing, that would really help!

[sheagcraig]

It seems like they don't show up in the Computers/Policies page of the web interface, which is annoying.

I'll need to add a command to Spruce to clean this cruft out too!

[sheagcraig]

Ugh... Any suggestions about how to handle this in terms of UI?

I can't think of any reason to ever use these orphaned policies (but maybe I don't know since I don't use Casper Remote) so I feel like one could happily exclude them from the different commands which deal with policies. But then do I add a --include-remote option for each of those?

While I have every intention of adding these policies to a feature of Spruce, I wonder if adding a remove_remote_policies action in jss_helper might be helpful. That way, if an admin were to get sick of all of the Casper Remote cruft in their results, they could cleanse them, rather than trying to exclude them from results.

[homebysix]

The only difference between the Casper Remote leftover policies and the "normal" policies, as far as I can tell, are the naming convention and the fact that Casper Remote policies aren't visible in the JSS. Maybe there's an added distinction in the SQL database itself? (Otherwise I'm not sure how the JSS knows to hide those policies.)

Interesting: Although the Casper Remote policies don't appear in the JSS list of policies, you can still go to the URL of the policy on the JSS (https://jss.pretendco.com:8443/policies.html?id=XXXX&o=r) and view/edit the details.

I can't think of any reason why JAMF would leave these Casper Remote policies hanging around in the database. It's not like they provide any way to view the policy logs. I have removed them all from my JSS with no ill effects.

I agree, omitting these remote policies by default is the safest bet. And yes, that probably means you'll need an --include-remote option for each verb. And remove_remote_policies seems useful too (a --dry-run option would also be useful).

[cjduckk]

It looks like the API was updated in 9.97 to allow excluding Casper Remote policies. See this post on JAMF Nation:

Policy retrieval via JSS - exclude Casper Remote policies

Sure would speed promotions up if jss_helper only had to look at 30 policies instead of 736...

[betty02]

Did anyone figure out how I can clean out all these Casper Remote policies? We have nearly 300- according to JSS Helper, when in theory we have less than a quarter of that!

[homebysix]

I ended up writing a script to clear out Casper Remote policies: https://gist.github.com/homebysix/ee4a7d615f755ee6eaa68043cdb1ddff