You could set policies based on Enrollment Date...so any machines after or before xx/xx/xx enrollment date would get the policy.

Just an idea..

Gabe Shackney
Princeton Public Schools

That's a tough one. If you aren't flushing the policy logs then the once per computer setting would work.

Our personal preference is to include a manual step in the process, which might sound backward, but works well for us. We either use a static group that the devices get added to or a smart group populated by a drop down menu extension attribute. For our education sites this is normally a "type" field with categories like "student", "staff" etc. selecting one of these activates the appropriate policies, profiles etc.

If you are removing the computer from the JSS and the framework from the client, I don't think there is any straightforward way to distringuish new devices from re-enrolled devices though.

Here's how I deal with this and how I've planned to avoid it (thanks to CJ at JAMF for the tip when we were doing some troubleshooting a few months back).

In your policy, make use of the Exclusion tab under Scope. Create a smart group that has the software you are looking to deploy (and if you want to get specific, the version as well). This way even if the computer is somehow re-enrolled it won't re-install the software because it's already on the computer.

As for policies that aren't deploying apps, that's perhaps a bit more tricky but I would take a step back and re-evaluate what you're doing because really nothing should be getting wiped.My first boot script is such that if I were to run it again on a computer, it would not affect a computer because it's not wiping or setting up any settings. Most if not all preferences I need to set up are also managed by config profiles so I don't have to worry much about those since those are set to ALWAYS. But even profiles set to ONCE would be OK too because if the preference already has been set it should be getting reset. Anyways, if you were to share what some of those other non-app deployment/enrollment policies are doing I'd be willing to (and perhaps others) take a look and see if there's a way to do it where things aren't getting overwritten.

write an invisible file at deployment of new computers. something like

touch /.thisisanewcomputer

Then you can check for the presence of the file with an EA.

Checkout macmules post flight policy. https://macmule.com/2014/12/21/my-casper-imaging-workflow/#Postflight_Policy

Plus 1 for @Kaltsas that was going to be my suggestion.

@rschenk i'd look at how those policies you're worrying about re-occurring are scoped.

A combination of smart groups & the dummy receipt but that @Kaltsas & @pblake mentioned should work.