Extended Attribute at Enrollment

rhowell
New Contributor III

I have an attribute for "In Storage" that I have configured in all of our policies to not use. I was thinking it could be helpful for this to be set automatically to "Yes" during enrollment so nothing runs on the device in Jamf. We have several different static groups that get different configurations so ideally nothing would happen to a device until we assign it a group. There are some things that ALMOST everything gets that isn't scoped to specific groups but we would prefer these get paused until after we set which group it should be in. If there is a better way to accomplish what we are trying to do please let me know!

1 ACCEPTED SOLUTION

sdagley
Esteemed Contributor II

@rhowell The manual adding of a device to an "Is Deployed" static group which is required to enable your "almost everything" polices would definitely work. And not to throw another option out late in the conversation, but another approach if all the devices you're talking about are Macs you could have a "fingerprint" file created somewhere in a persistent area the file system at the end of your enrollment script, a corresponding Extension Attribute which checks for the presence of that file, and a Smart Group whose criteria is the file does not exist. Then use that Smart Group as an exclusion for your "almost everything" policies.

View solution in original post

5 REPLIES 5

sdagley
Esteemed Contributor II

@rhowell You could have a Smart Group with the Criteria Last Enrollment is < 1 day ago and use that as a Scope Exclusion. The downside is that would defer those policies for a day, not just until the enrollment process completes.

rhowell
New Contributor III

@sdagley thanks for the reply. I am wondering what best practice overall is. I have all my smart groups based off of "not installed" and scope policies accordingly based on what I was told during our Jamf jumpstart. Should we have a static group that all computers get placed into once enrolled that is part of the not installed scope?

sdagley
Esteemed Contributor II

@rhowell That would work, but it requires having a script running on each Mac during enrollment to use the API to add itself to that group. Jamf discourages using the API from every endpoint in this manner since the credentials required to call the API can only be obfuscated rather than truly encrypted.

rhowell
New Contributor III

@sdagley I was just thinking our IT team manually adds it to the appropriate group once enrolled? We currently configure, asset, then pass device on to staff so touch them as well.

sdagley
Esteemed Contributor II

@rhowell The manual adding of a device to an "Is Deployed" static group which is required to enable your "almost everything" polices would definitely work. And not to throw another option out late in the conversation, but another approach if all the devices you're talking about are Macs you could have a "fingerprint" file created somewhere in a persistent area the file system at the end of your enrollment script, a corresponding Extension Attribute which checks for the presence of that file, and a Smart Group whose criteria is the file does not exist. Then use that Smart Group as an exclusion for your "almost everything" policies.