Location information resetting

I'm having the same Issue

Ditto… However, it changes "building" to a real value, but a different one than the one I had already given it.

I am seeing the same problem and have not been able to track down a fix or a workaround for it yet.

Anyone else figure out how to get around this problem?

Edit: I'm also seeing this happen when a machine updates its inventory.

Hello!

Version 8.6 released a new feature that will do an LDAP lookup with every inventory submission. With environments that utilize LDAP, this helps keep continuity between what is in LDAP and what is listed in the JSS (e.g. an end user changes departments, or a new phone number, etc).

We can turn off this functionality by going to Settings->Inventory options->Inventory Collection Preferences->Location and unchecking the box there.

Does that change the behavior you're seeing?

I've been playing a bit since I first saw this problem. It seems like the jamf enroll command is removing all information from the JSS, then reapplying it. In my case, the network segment has multiple types of machines in it, so there is no default department to use when repopulating the location information.

Is there any specific reason why the enroll command removes this information and is it something that can be changed?

Hello Mr. Miller!

Unfortunately not, the box was already unchecked…

Good find with the enroll command, Mr. Scott.

Same issue with jamf enroll. I find it happens only on certain subnets here. I double checked our JSS and none of our defined network segments have any defaults regarding building or position and the override box is unchecked. Really strange issue.

You might like to vote this one up then:

https://jamfnation.jamfsoftware.com/featureRequest.html?id=778

Bump.

Why the bump? It's a known issue, non-issue, meaning the enroll command is doing what it was designed by JAMF to do. However, it's doing what it is designed to do at times others don't want it to do what it's suppose to do. I was never told a defect ID because it was both a defect and not a defect. It was the most bizarre thing. =D

The bump was because Mr. John Miller asked us to check a thing that might solve the "problem", but it did not, at least not in our case. Also, it seems quite odd that it doesn't happen on all subnets, just like bajones says…
And I did vote on the above link. ;)

I have noticed that with 8.6, it is resetting the Location information and the PO Date back to N/A.

I voted up on your feature request.