Skip to main content
Solved

Push Policy on Changing State of EA

  • July 31, 2018
  • 3 replies
  • 29 views
H
Forum|alt.badge.img+7

Hey Jamf Admnis.

Just searching for a way to push a policy on the changing stat of a EA. In detail i have a computername_individual extension attribute witch is set via jamf pro web gui by an admin. If this EA is set or changed i want to run a policy witchs checks the computername_induvidual EA of the client and rename it. I have build a script with jamf api commands that is checking the EA and renames the computer if needed so far. So i created a smard group with computername_individual is set and a policy with the script + smart group. If some is changing the EA again i have set the policy to ongoing once a week/once a day.

Is there a way to push this policy to the clients instead of runnung it every day?

Thank you for some tips.

Best answer by hinrichd

My final solution is to reset the extension attribute at the end of the script via api command. Doing that will remove the client from the smart group and the policy will only run once when EA is set to a value even thought the policy is set to ongoing and recurring check-in. Next time someone is setting the EA again, the policy runs as soon as possible again.

3 replies

C
Forum|alt.badge.img+16
  • chriscollins
  • Honored Contributor
  • July 31, 2018

Since everything revolving around communication between the jamf binary and the jamf pro server is based on a pull from the client, it really depends on the client checking in. So the shortest amount of time you could set it to run is the shortest amount of time you have between client checkins and to change your policy to ongoing every check in which would probably be too much.

The only way you'd be able to probably do what you want would be to actually have a script with a launch daemon set to run locally on the client independently and to use the api to check if the name set in the extension attribute in jamf is different than the clients and rename it.

There are obviously plenty of potential issues with going that route as well including having to save API credentials on the local machine for the script to use.

Obviously you could also just use the built in "Reset Computer Names" under the maintenance payload in all of your policies and make sure the tech sets the computer name in the actual normal field in the computer's inventory field in the JSS, so that whenever a policy is run it makes sure the name is set properly.

H
Forum|alt.badge.img+7
  • hinrichd
  • Author
  • Contributor
  • August 1, 2018

@chriscollins thanks for your detailed tips.
Not shure witch way i will go as every solution has some downsides or have to many dependencies to work bulletproof.
For this szenario of dep computernaming i wish jamf to implement a native feature. There are already some feature request online:
https://www.jamf.com/jamf-nation/feature-requests/6193/dep-computer-naming

H
Forum|alt.badge.img+7
  • hinrichd
  • Author
  • Contributor
  • Answer
  • August 1, 2018

My final solution is to reset the extension attribute at the end of the script via api command. Doing that will remove the client from the smart group and the policy will only run once when EA is set to a value even thought the policy is set to ongoing and recurring check-in. Next time someone is setting the EA again, the policy runs as soon as possible again.

Terms & ConditionsCookie settingsAccessibility statement