Extension attribute updates

[#1]

Hello all.

I could probably find this somewhere in the documentation, but figured I would ask here:

What causes the extension attributes to be updated and how often does it happen?

The reason I'm asking is that I created a policy scoped to a smart group/extension attribute, which notifies users if their computer has been up for more than 7 days. It seems to work fine, but I wasn't sure how and when the uptime extension attribute gets updated. I know jamf recon does it manually, but am not sure what else does it.

Thanks!
Aaron

[#2]

I believe it happens only when the computer runs inventory.

[ernstcs]

Correct. A recon cycle updates extension attributes.

[tlarkin]

I suggest if you are using extension attributes via shell script (or whatever script) you should always run recon as the last command in the script.

[#5]

The problem is that people won't be restarting their machines immediately...

If I pop up a message to restart,, people won't be restarting for hours. If I were to update the extension attribute via recon right after displaying the message, the uptime would have updated.

The only issue that I have is that some people will get a message, restart later, then the next day, they will get the message again since the attribute hasn't updated again.

Not a big deal, but it would be nice to know exactly when an extension attribute would update.

[milesleacy]

Hey All,

Just some random thoughts that might be helpful…

If you want to know when (in time) extension attributes will update, you could make sure that only one policy includes the "Update Inventory" task. Then create a custom scheduled task to execute that policy at your desired interval. This doesn't seem very elegant though. I may have missed a message in this thread, what is the problem you're trying to solve?

Re: running recon as part of an extension attribute script – It sounds like a great idea at first, but on thinking about It a bit, I'd be concerned about this workflow. It sounds like it sets up a loop. Recon causes extension attribute scripts to run > extension attribute script causes recon to run > lather, rinse, repeat until your clients are perpetually generating inventory reports.

I hope this is helpful.

--

Miles Leacy

Technical Training Manager

Mobile +1 347 277 7321

miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>

....................................................................

JAMF Software

1011 Washington Ave. S

Suite 350

Minneapolis, MN 55415

....................................................................

Office: (612) 605-6625

Facsimile: (612) 332-9054

....................................................................

US Support: (612) 216-1296

UK Support +44.(0)20.3002.3907

AU Support +61.(0)2.8014.7469

....................................................................

http://www.jamfsoftware.com<http://www.jamfsoftware.com/>

[#7]

So that still leads me to question: what event triggers the extension attributes get updated and how would that be controlled?

It's not a huge issue, but it is annoying that I don't know a good way to ensure a machine's extension attribute is up-to-date. Running the update as part of the policy isn't going to work when I'm asking users to restart their machines. If they haven't restarted it in 7 days, they aren't likely to restart immediately after getting a message popping up onscreen.

[ernstcs]

an inventory update triggers extension attributes that you have configured in your JSS to update.

So that's a:

command sent to the binary from a script
/usr/sbin/jamf recon

In a policy or casper remote session that's the advanced tab doing an Update Inventory

Craig E

[#9]

Not only are they perpetually generating inventory reports, those reports will never be completed, and thus never submitted. This sort of infinite recursion is commonly known as a "fork bomb": One process spawns another, which spawns another, which spawns another, ... eventually bringing the machine to a halt. (I'm not sure if the Mach kernel is smart enough to kill an offending process when it runs out of resources; if so, it will eventually finish. Still...)

On Feb 3, 2011, at 11:01 PM, Miles Leacy wrote:

Hey All,

Just some random thoughts that might be helpful…

If you want to know when (in time) extension attributes will update, you could make sure that only one policy includes the "Update Inventory" task. Then create a custom scheduled task to execute that policy at your desired interval. This doesn't seem very elegant though. I may have missed a message in this thread, what is the problem you're trying to solve?

Re: running recon as part of an extension attribute script – It sounds like a great idea at first, but on thinking about It a bit, I'd be concerned about this workflow. It sounds like it sets up a loop. Recon causes extension attribute scripts to run > extension attribute script causes recon to run > lather, rinse, repeat until your clients are perpetually generating inventory reports.

I hope this is helpful.

--
Miles Leacy
Technical Training Manager
Mobile +1 347 277 7321

miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>
....................................................................
JAMF Software
1011 Washington Ave. S
Suite 350
Minneapolis, MN 55415
....................................................................
Office: (612) 605-6625
Facsimile: (612) 332-9054
....................................................................
US Support: (612) 216-1296
UK Support +44.(0)20.3002.3907
AU Support +61.(0)2.8014.7469
....................................................................
http://www.jamfsoftware.com<http://www.jamfsoftware.com/>

[tlarkin]

Correct me if I am wrong, but doesn't inventory update every time a
policy is ran in Casper version 8, or is it just the location/network
information that updates every time a policy is ran now?

[ernstcs]

The binary does a log everytime it talks back to the JSS now, but it does NOT run a full inventory cycle.

[msimpson]

This might be helpful - a script that doesn't rely on inventory data:

https://jamfnation.jamfsoftware.com/discussion.html?id=11476

Cheers,
Matt