I'm facing the same issue at the moment. Usually the "Username" field is filled during enrolment or when running a
jamf recon -endUsername BLAH
With the setting to "Collect user and location information from LDAP" in computer inventory collection settings, it should work. In fact, it doesn't. I've just raised a support case with this and let you know the outcome.
For me, it's a PI, because manually the fields are filled...
@m_entholzner Have you received any kind of update for this? I am in the same situation as I desperately need the User and location fields to get populated. Map testing works fine, they just don't populate on checkin. Any help would be appreciated.
@jttavares, for our case it turned out that there was an LDAP EA that didn't return a value, which caused the whole lookup to fail. We resolved it by removing the LDAP EA that caused the issue. Once removed, the fields were populated correctly during Enrollment or with a
jamf recon -endUsername BLAH
You also need to make sure that "collect user and location information from LDAP" is checked from the inventory collection settings.
@m_entholzner Pardon the ignorance, but when-how are you running that script during enrollment? I am not using DEP, just enrolling via URL. So do I need to run that script for every Mac as they check in somehow? Have that script running as a ongoing policy? Sorry for all the questions, but unfortunately we do not have a dedicated Jamf engineer. I would prefer to do this full time, but have other responsibilities that pull me away. Appreciate your responses, thank you.
Well, in general the command doesn't need to run at all. This is only needed when more complex scripting is involved and you need to re-assign user for a mass of devices. Depending on the amount of devices in your fleet this will also cause high load on the Jamf server when running the user assignment ongoing at every check-in.
When using UIE (URL Enrollment), you only need to make sure that the inventory collection preferences are properly set. You find them in Settings > Computer Management (or Device Management) > Inventory Collection > "Collect user and location information from LDAP".
Tick the box and wait for the magic to happen during Enrollment 😉
Well, in general the command doesn't need to run at all. This is only needed when more complex scripting is involved and you need to re-assign user for a mass of devices. Depending on the amount of devices in your fleet this will also cause high load on the Jamf server when running the user assignment ongoing at every check-in.
When using UIE (URL Enrollment), you only need to make sure that the inventory collection preferences are properly set. You find them in Settings > Computer Management (or Device Management) > Inventory Collection > "Collect user and location information from LDAP".
Tick the box and wait for the magic to happen during Enrollment 😉
@m_entholzner OK, last question. We have around 1000 devices. The Macs are constantly reassigned to different users as staff come and go, so once enrolled, we just setup another local account matching the SAM ID in Azure and go. Tracking the hardware by user and location is essential. I setup Azure CIP, mapping for user-location works fine. From what I understand now, those fields only update during enrollment. I was under the assumption, which is my goal, that the User and Location fields would update as the Macs check in so the User-Location fields would populate with the new owner of the Mac, but guess I am incorrect on that one. I did check that box to "collect user and location information from LDAP.
My systems team do not want to setup-maintain an LDAP server, so we just went with Azure Integration. Guess I need to do more digging. FYI, my Jamf instant is in the cloud. Thank you for the input.
Hello,
We needed Azure user tracking too and use the below script. It does username, full name, and e-mail address but not the other fields.
#!/bin/sh
#Get current signed in user
currentUser=$(ls -l /dev/console | awk '/ / { print $3 }')
#com.jamf.connect.state.plist location
jamfConnectStateLocation=/Users/$currentUser/Library/Preferences/com.jamf.connect.state.plist
DisplayName=$(/usr/libexec/PlistBuddy -c "Print :DisplayName" $jamfConnectStateLocation || echo "Does not exist")
if [ $currentUser != "root" ];
then
/usr/local/bin/jamf recon -endUsername $DisplayName
fi
exit 0
@A-bomb Thank you for your response. So I assume you just run this as a policy periodically on all your enrolled devices? This would help me out greatly!
@A-bomb Thank you for your response. So I assume you just run this as a policy periodically on all your enrolled devices? This would help me out greatly!
Exactly. I run it daily and it works well. There are anomalies that come back with the username as "Does" or "File" so there is a Smart Group to catch those and manually rename them.
Exactly. I run it daily and it works well. There are anomalies that come back with the username as "Does" or "File" so there is a Smart Group to catch those and manually rename them.
I know this is an old post, but is there a script to kick off a search of LDAP after the username has been updated with your script, and save all the directory details ?
I know this is an old post, but is there a script to kick off a search of LDAP after the username has been updated with your script, and save all the directory details ?
For us, it pulls in everything but phone, department, building, and room. I never got those to work with numerous field match tests.
For us, it pulls in everything but phone, department, building, and room. I never got those to work with numerous field match tests.
FYI- Department and building will only pull if you already manually created the department and building in your Jamf Server
FYI- Department and building will only pull if you already manually created the department and building in your Jamf Server
We manually created the buildings a long time ago but have never successfully pulled the building info from AAD. We have to enter it manually but have leveraged this workflow as a revocation group for certificates. Do you get bldg. to pull successfully from AAD?
We manually created the buildings a long time ago but have never successfully pulled the building info from AAD. We have to enter it manually but have leveraged this workflow as a revocation group for certificates. Do you get bldg. to pull successfully from AAD?
The environment I'm reading from doesn't pull building or dept from the state plist but if you're setup for an LDAP connection that has the information mapped to the user correctly, updating the username field should backfill the user/location information in the device record. So as long as you manually entered the dept/building names in jamf already, it should fill in that information.