Closed staze closed 3 years ago
Nevermind... jamf may have just been taking its time...
Hmm, maybe not. My sample size just happened to show ones that updated.
Thoughts on this, or should I just run a policy to grab owner, then push back to jamf via "/usr/local/bin/jamf recon -endUsername $username"
Thanks!
Hey, good question.
The intended behavior here is a little odd, and is probably what you’re seeing.
Basically, MUT just sets the username. Jamf Pro is what pulls the data from LDAP, and that happens on a recon/inventory update.
When you enter the username manually, it pulls the data at that time, but using the API (MUT or otherwise) it doesn’t pull LDAP data at that time. It will update as soon as a recon happens tho.
I’m not sure what the binary -endusername behavior is, or if it matches the API but probably not. Either way, they should update on their own given time. :)
The above is, of course, dependent on you having the option selected to pull data from LDAP—but given your initial belief that this issue was resolved, I’m assuming at least some have updated, which means the rest should as well, as soon as they recon.
This is also obviously dependent on the username on the device matching one in LDAP exactly, and your mapping being correct—but again, if you’re seeing some update, that’s all probably good. :)
Hi Mike,
Yeah, sadly I have that update ldap on inventory unchecked for "reasons". Now I'm wondering if any method will really work for this.
Going to see if I can push via policy and see if it pulls info. Also going to see if I can just kick off an inventory for a machine and see if it pulls the info.
Thanks!
I'm fixing years of bad usernames in part of our jamf instance, and I noticed that it's updating the username, but not triggering jamf to look up the other LDAP info based on that username.
Is there a way to do this?
Thanks!