My understanding is that the Smart group membership would change live, but the list of Apps installed would only change on a recon.

The end result is that Macs would only get added to that group after a recon (probably however often you schedule yours to run) and that you'll need another recon / Inventory to run as part of the install policy to remove the Macs from that group and to stop the ongoing install.

Just my understanding, YMMV.

Darren

Yep, set the policy to Ongoing, with a Recon at the end.

Once the software installs, and recon runs, they drop out of whatever smart group you have scoped the policy to.

You probably have an Update Inventory policy which runs once a day... depending on how many clients you have, and how well-configured your hardware is, you may want to run this policy more frequently. Otherwise the students could uninstall the software and it may take a day or longer for Casper to notice/have it re-enter the smart group...

Awesome, Thanks. I was hoping that is how it would work.

Last year I had a real problem with the JSS crashing. After much head scratching and early morning starts (to screen share with support who are generally go home about an hour before I start work for the day) it came down to some policies which were set to ongoing and installed software before doing a recon to get them to drop out of the smart group that triggered the install. We never really figured out what was going on but it appeared that policies set up this way were failing, possibly due to other policies running at the same time doing a recon and triggering a second attempt of the install. We ended up with a perfect storm where processor use was maxed out on the server and memory use climbed until it hit the maximum for tomcat and then the JSS would crash. The fix was to set these policies to 'once a day' rather than ongoing so they wouldn't trigger again while they were already running. Problem solved.

I now do not use ongoing in installation policies and have had no further trouble. So I suggest 'Once a Day' with a recon in the poicy. Unless your students are going to remove the policy several times a day. What you definitely don't want is for the policy to trigger a second time while still installing from the first trigger.

Just a thought.

Lincoln

Thanks for the tip. I will monitor it for a bit and see how it goes.

The software is for monitoring web access, and being an all boys school, they like to try and exploit any loophole they can find. We do have boys who will happily sit there and remove it every 15 mins if the need too... we are attacking this from a pastoral care perspective as well as a technical, so hopefully once it settles down a bit, we can reduce the frequency to once per day (or, if it starts causing drama's, I will try your suggestion of once per day)

I guess the big consideration if using ongoing with an install policy is that the install time needs to be shorter than your 'any ...' period. Then it should be ok. The other problem you may strike is that until the machines do their next recon, Casper will assume that the application is still installed, so if they remove it 5 minutes after the install policy finishes, and the next recon isn't till the next day, or week, the machine won't find it's way back into the smart group until then, meanwhile the student is running without your software installed.

There must be a way to make it harder for them to remove the software... Do they have admin rights?

Lincoln

Unfortunately they do have admin (against my very strong advice to our management)

We have tried several ways to lock it down, but we have some pretty savvy (and determined) students..... at least it keeps me busy I guess lol

The piece of software is very small, and our network is speedy enough that it downloads and installs in a matter of seconds. So, I don;t need to worry about it clashing with our "Any" period too much.

Creating a Launch Daemon?