Distinguish new Macs from existing ones

[skeb1ns]

Hi,

I'm struggling for a while now to find a way to set the new Macs apart from the existing ones in Casper.

To make myself more clear: I've created a few policies that are executed when devices are enrolled (enrollment trigger). This process works fine and is still the same since I have started working with the Casper suite.

There are however now a few Macs where the Casper client got corrupt (they are not checking in anymore thus not receiving new profiles etc.).

My idea was to remove the Casper framework from those clients and simply use the QuickAdd package to re-enroll the affected machines. The problem with this method of course is that those clients will again receive the enrollment policies (re-install certain software, rebind to AD, perform some cleanup thing etc.) and I don't want that to happen because users will lose their files and settings.

In short: I wan't to separate the 'fresh new machines' from the existing ones in Casper so that policies are not triggered when I wan't to fix a corrupt Casper client.

What is a better way to organise this? Thoughts? I'm all ears!

[GabeShack]

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

[davidacland]

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.

[bpavlov]

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.

[Kaltsas]

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

[pblake]

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

[bentoms]

@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.