Recon wiping extension attributes previously set using a popup

Are you talking about during a inventory report jamf recon of currently enrolled computers or are you speaking about when running the Recon.app?

I know there are ways to tell the SQL database to retain or flush certain data during a Reconing (re-enrolling) of computers with the Recon.app
.

Hi, Sorry I didn't spot your reply earlier.
The answer is a little complicated - since I have been doing both..

But the issue was arising with the 'normal' regular scheduled recon process.
It's clear now to me that my JAMF DB is at least partly corrupted, and this is one side effect of that.
A very large number of machine movements, with incorrect process handling is partly to blame for this.
Casper is in fact mostly still working well, despite this.

My main resolution will be to re-enroll the majority of machines, which will hopefully fix the problem.
Meanwhile, I've noticed that 'Static' info in some Extension Attributes, set via pop-down menu, is now frequently going missing.

And if I re-enrol a machine, then it always goes missing.

I was hoping the someone might be able to give me some hints, about how to preserve these attributes, so that they are not flushed by the standard periodic recon of already enrolled machines.

Meanwhile a partial solution I've come up with, and a process improvement, has been to introduce another set of extension attributes for some items - which are now filled in via scripts.
Though that's not possible of all combinations, some items really can only be set manually.

I am planning to 'clean up' the DB as far as I can. Hopefully then it will be OK.
An alternative of restoring from an older version of the DB, would need to take the system back some way in time.
– and the very large number of changes since then, would make that a poor solution.

Later, I plan to update Casper, so the issue of Extension attributes is likely to arise again there.

Any info or advice you have would be of interest to me..

I've been told that if you run a few recon's close together, it can have this effect. Once I got rid of most of the "update inventory" selections on our policies, this cleared itself for us.

Hi thanks for the advice.
That's possible. I did recently have a startup policy, with a recon, but where the startup policy caused a restart, so recon got terminated. And with the daily startup set to do a recon.

I have since changed that so that startup policy no longer does a recon.
Also the problem we encountered started before that startup policy, but the policy did seem to extend the problem.

I am now planning to do a wide-scale recon, (in a series of steps) to try to resolve the problem, and bring the DB back into sync. But I may not be able to do that for a little while.

When I do, I'll let you all know how I get on.

I'll preface this by saying I'm no expert on this. I can only provide this info as I recently worked on changing some of these preferences with support.

There is a way you can tell the Recon (re-enrolling) to not flush certain data such as the Location information, policy history, etc. You may want to contact support depending on how much you know about working with the MySQL database.

I would start by taking a look at the preferences of your database. You can do this by opening up the SQL Command line utility on the server.

Navigate to the proper database with this command.

use jamfsoftware

Run this command to see what the preferences are set to.

select * from management_framework_preferencesG

1's = true
0's = false

To change a setting such as telling Recon to not flush the location data you can run this command.

update management_framework_preferences set flush_location_information_on_remanage =0;

Again, I'm know very little on this but I'm happy to share the little I know. I would be careful changing much but if you take a look at something is set differently than you would expect you could give this a try.

Hope that helps some.