Pull Department and Building info from Jamf #41

New Issue

michael · 2026-01-19T18:31:19Z

michael commented

2026-01-19 18:31:19 +00:00

Originally created by @staze on GitHub.

Realize there's no way to do without API, but would be nice to actually pull data from Jamf for things like Department and Building. Also ability to set arbitrary EAs.

Originally created by @staze on GitHub. Realize there's no way to do without API, but would be nice to actually pull data from Jamf for things like Department and Building. Also ability to set arbitrary EAs.

michael closed this issue

2026-01-19 18:31:19 +00:00

michael commented

2026-01-19 18:31:20 +00:00

@staze commented on GitHub:

Hey @scriptingosx . So yeah, I meant pull all departments or buildings from Jamf and let user pick, rather than populating a plist. But as you say, that falls into "API Credentials". It's unfortunate that Jamf doesn't provide some secure way to interact with the API without hardcoding credentials (obscured or not).

@staze commented on GitHub: Hey @scriptingosx . So yeah, I meant pull all departments or buildings from Jamf and let user pick, rather than populating a plist. But as you say, that falls into "API Credentials". It's unfortunate that Jamf doesn't provide some secure way to interact with the API without hardcoding credentials (obscured or not).

michael commented

2026-01-19 18:31:20 +00:00

@scriptingosx commented on GitHub:

There is a way to get the Department and Building (and some other fields) for your scripts without the API.

You can create a custom profile in Jamf Pro with variables for department and building:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>building</key>
	<string>$BUILDING</string>
	<key>department</key>
	<string>$DEPARTMENT</string>
</dict>
</plist>

and push that down to the client. Jamf Pro will substitute the payload variables with the values in Jamf Pro.

You can then read the values from the profile in your policy scripts. There are a few approaches, I prefer using osascript/JXA:

MANAGED_PREFERENCE_DOMAIN="com.example.customvalues"

getPref() { # $1: key, $2: default value, $3: domain
	local key=${1:?"key required"}
	local defaultValue=${2-:""}
	local domain=${3:-"$MANAGED_PREFERENCE_DOMAIN"}
	
    value=$(osascript -l JavaScript \
        -e "$.NSUserDefaults.alloc.initWithSuiteName('$domain').objectForKey('$key').js")
    
    if [[ -n $value ]]; then
    	echo $value
    else
    	echo $defaultValue
    fi
}

mysetting=$(getPref "department")

There are quite a few caveats:

Jamf Pro will substitute the values of department and building at the time the profile is pushed. If the value is empty at the time (and it might very well be at enrollment, because the computer record is brand new) the profile will have empty values
you can pre-fill values with inventory preload
Jamf Pro will not re-push the profile when the value updates in Jamf Pro, you may have to defer pushing the profile until you know the value is set

We are avoiding features that will require API access and thus providing API credentials to Setup Manager. There is already a request for arbitrary user entry fields #24

@scriptingosx commented on GitHub: There is a way to get the Department and Building (and some other fields) for your scripts without the API. You can create a custom profile in Jamf Pro with variables for department and building: ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>building</key> <string>$BUILDING</string> <key>department</key> <string>$DEPARTMENT</string> </dict> </plist> ``` and push that down to the client. Jamf Pro will substitute the [payload variables](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/Computer_Configuration_Profiles.html) with the values in Jamf Pro. You can then read the values from the profile in your policy scripts. There are a few approaches, I prefer using osascript/JXA: ```sh MANAGED_PREFERENCE_DOMAIN="com.example.customvalues" getPref() { # $1: key, $2: default value, $3: domain local key=${1:?"key required"} local defaultValue=${2-:""} local domain=${3:-"$MANAGED_PREFERENCE_DOMAIN"} value=$(osascript -l JavaScript \ -e "$.NSUserDefaults.alloc.initWithSuiteName('$domain').objectForKey('$key').js") if [[ -n $value ]]; then echo $value else echo $defaultValue fi } mysetting=$(getPref "department") ``` There are quite a few caveats: - Jamf Pro will substitute the values of department and building _at the time the profile is pushed_. If the value is empty at the time (and it might very well be at enrollment, because the computer record is brand new) the profile will have empty values - you can pre-fill values with inventory preload - Jamf Pro will _not_ re-push the profile when the value updates in Jamf Pro, you may have to defer pushing the profile until you know the value is set We are avoiding features that will require API access and thus providing API credentials to Setup Manager. There is already a request for arbitrary user entry fields #24

michael commented

2026-01-19 18:31:20 +00:00

@scriptingosx commented on GitHub:

You could write a script using the API to generate the plist code for profile.

@scriptingosx commented on GitHub: You could write a script using the API to generate the plist code for profile.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jamf/Setup-Manager#41