Sorry in advance for being verbose, but we're stuck and support has been unable to sort this out.
We've tried migration from on-prem to Jamf Cloud twice and have had to rollback both times due to issues with dynamic updating of User & Location information that works fine while on-prem. Here's our config and what we're trying to do:
OS: Windows Server 2016
Jamf Version: Jamf Pro 10.28.0
LDAP Source: On-Prem Microsoft Active Directory
Jamf Version: Jamf Pro 10.28.0 (issues also occurred on 10.27.0 for first migration attempt)
LDAP Source: Okta LDAP Interface (confirmed on both migration attempts to be configured properly per various articles).
What we're trying to do and why:
1) We run a policy once per day that executes https://github.com/macmule/SubmitUsernameAtReconForLDAPLookup which is dynamically updating User & Location information. This works great on-prem without issues.
2) We're leveraging the data in the User & Location information for each computer to import into our ticketing system. So the data here needs to be consistent and accurate.
We migrate to the cloud, hook up the Okta LDAP Interface instead of on-prem AD for our LDAP source, do all testing and everything tests fine.
As a test under User & Location, we change the username ONLY of a user assigned to a computer (to a username of someone NOT logging into the computer) and click Save. Username updates as does all subordinate LDAP information (building, email, etc.).
We manually kick off the Policy on a few machines that is calling the script from https://github.com/macmule/SubmitUsernameAtReconForLDAPLookup. Checking the computer entry, the username updates with the proper information for the user currently logged in as expected, but none of the other LDAP attributes update.
So what we end up with is a username for the currently logged in user but the rest of the attributes for the user are the ones that existed when it was changed previously as mentioned above. We can replicate this 100% of the time. Deleting users from the users table in Jamf doesn't work. Okta LDAP logs show no problems. Jamf logs are inconclusive but as a workaround they disabled LDAP Pooling on the backend (which seemed to help, until our 2nd attempted migration yesterday when it failed 100% of the time).
We have spent over 150 hours with support on this issue and we thought that disabling LDAP Pooling was the magic fix, until we attempted a 2nd time yesterday and were met with the same frustration.
So.... our questions are:
1) Is anyone successfully using the Macmule script to dynamically update User & Location information while in Jamf Cloud? If so, what is your LDAP source?
2) Is anyone running the Macmule script and leveraging the Okta LDAP Interface and having this work properly?
We don't want to put a JIM in place if we don't have to, but we are stuck and dead in the water. We are desperate for any help on this at all. Support is stuck, we're stuck on-prem and we've invested way too many man hours to this at this point.