For us, we're using this script to set the value of "Smelly" as "Smells very bad. Value - what you want the EA to be set as when this script is run.EA Name - whatever name you used for your EA should be entered here.Grab that ID number and put it in parameter 6.
Jamf run script pro#
Jamf run script password#
To do this format your credentials as apiuser:apipassword (meaning a username and password smooshed together with a colon in the middle of an actual user account that can write with the API, I very much hope it's not apiuser with apipassword as a password lol) and run through the terminal with echo -n 'apiuser:apipassword' | openssl base64. I tried using the Execute Command under Files and Processes by adding an & at the end of it. Run Jamf Scripts as Logged in User Hello guys, I have tried multiple ways but still no luck. Encoded credentials - take the username and password of your api account and use openssl to convert them into a base64 string.Jamf Pro Server URL - the URL of your Jamf server, such as.
Jamf run script update#
I've made a template script that uses parameters set on a policy to update an EA using the API to make this relatively painless to do. If you want want to make this a little more user-friendly, you can make a Self Service policy that runs a script that updates this value using the API. Once created you can find that pop-up menu in whatever tab of a computer record you specified (above, "General") and change the value.
Jamf run script mac#
(Maybe you can?) So you make a pop-up menu EA for techs to mark if a Mac smells on the computer record in Jamf Pro. You can't really write a script to pull smell status off of a Mac. So let's say the help desk staff notices that some Macs that come by are really smelly.
One of the handiest ways to set info ad hoc is with a pop-up menu extension attribute. Other times you just need to set a simple value for a Mac on demand for reporting purposes. Sometimes you want to snag information off of a client Mac, and for that a small script to grab the info and report it up to the Jamf Pro Server is great. So your main script should reach a successful conclusion regardless of the secondary script.Not all extension attributes (EAs) are created equally. So long as it is a totally separate script instance, and running locally, the main script is saying run this script, and reports that it has done that. You can even have it cleaned up by the main script.
If your secondary script is really short, then you can have your main script build it, save it and give it permissions to execute, then it can run it. I use composer to package up some scripts and put them in a temp location, so that I can refer to them and run them locally. I have deployed computers in our environment that have the same Deploy. This way the policies will run in order, and the secondary script can do its thing. Im looking for a way to schedule the execution of a script at a specific time. usr/local/bin/jamf policy -trigger policy2 usr/local/bin/jamf policy -trigger Policy1 Script example sh /Path/to/secondary/script.sh & Then when you run it and put the & after the line, your policy script will continue as planned and reach a conclusion. The first thing we need to do is create a new Script in Jamf by going to Settings > Computer Management > Scripts. You could possibly try putting it all in 2 scripts, use the first script to send custom triggers to Jamf to run your policies, and also in the script set it to run your background script, have this as another script, it should be set up locally.
0 kommentar(er)
