Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

RECON: Bring back the verbs!

Back in version 6 of the suite you could run the something like the following:

jamf recon –skipApps –skipFonts -skipPlugins

This was identified as a bug, & changed so that recon now always follows the JSS set inventory options.

However, this comes in very handy when deploying apps via self service so that only apps would be reconned. Which would reduce recon time massively.

(i created a feature request for this on 26th June 2010)

Comment
Order by:

Posted: by tlarkin

Also while we are at it, add this:

jamf recon -onlyrunxattr

so you can recon and only run extension attributes.

Like

Posted: by andrewseago

I can think of a few use cases for this.

Like

Posted: by Apfelpom

Yes, I already searched this feature and didn't find it: only recon Extension Attributes...

Like

Posted: by Bukira

yeah i agree also

Like

Posted: by Cisco

Running a complete inventory is not practical in many instances where we must take other short-term actions based on extension attribute values. We could use the ability to:

• Run all or selected extension attribute scripts
• Get extension attribute values from the API

Like

Posted: by ernstcs

*bump* Cuz I only want to update Extension Attributes often.

Like

Posted: by mm2270

Totally agree. We have a ton (relatively speaking) of Extension Attributes we use for a variety of purposes, and it would amazing to be able to run a recon that only pulled those in on a set schedule, multiple times a day, if needed.

Like

Posted: by BaddMann

Please Bring Back the Verbs, that way we don't have to write workarounds that take away our time from real Administration.

Case in this point: I needed Our helpdesk to be able to find computers by the users using them.
Casper Remote doesn't Search EAs and if you can make it search EAs it's not documented.

So I had to write the script located here https://jamfnation.jamfsoftware.com/discussion.html?id=7271, just to provide the functionality that should be either built into casper or, be provided with a few clicks.

Like

Posted: by mm2270

Hmm, well, I can certainly see how this could produce inaccurate Smart Groups if not used carefully. Say if an EA field is updated to report some new information but Application data is not collected and a Smart Group is created using both of these items as criteria. Even knowing that, I'm somewhat sorry to see this won't be implemented.
That said, I'm glad some work is being done to improve inventory collection times. We would love to see it made as efficient as possible.

Like

Posted: by PeterClarke

I can see mm2270's point.

Surly some compromise is possible, such that EA's are updated, along with Application Lists.. ?

Depends of what the EA's are for I guess..
skipFonts and skipPlugins would be handy \- since both those two would be time consuming.

Like

Posted: by mm2270

@PeterClarke, yes, I sure would like to see a controlled compromise. Perhaps something like 2 inventory collection options \- a Full and Basic. The Full one collects all data as defined in the Inventory Collection Preferences, and the Basic only collects a subset that is predefined by JAMF so there aren't a hundred different possible combinations which would lead to the above problems. Perhaps even that would lead to the same issues, but perhaps not.
This wouldn't really satisfy every Casper Suite admin since I'm sure that everyone would want something different, but being able to pull a limited set of inventory would be nice. Kind of how system_profiler allows you to do mini reports or pull only a subset of categories.

That said, I'm hopeful that inventory times will improve quite a bit once v9 is out as per Zach's response.

Like

Posted: by lastdanstanding

We want to calculate home directory sizes, but it massively slows down our recons. It would be nice to have more granularity in how frequently that attribute is collected.

Another option would be for the jamf binary to calculate the home dir size in the background, and cache that data locally, so that when recon runs it just reads the cache.

Like

Posted: by AKuzenkov

I agree please add this functionality.

I have each Mac run inventory after any software update, however this adds 2-3 minutes to the whole process (depending on the Mac and the connection to the JSS). The only information I know has changed is just the version number on an application, and that’s all I want to update in the JSS.

Being able to exclude or force only certain operations to run would be very useful.

Like

Posted: by evarona

Late to the game here but here's my 2¢. I'd love to see a more granular recon process or maybe a new feature that updates inventory items. Something like

jamf updateInventory [-computer {item_names}] [-location {item_names}] [-software {item_names}] [etc…]

Basically, it would allow scripting application info updates after a deployment or minor updates like seeing what the last IP address was without a full recon. Either could look something like this

jamf updateInventory -computer {lastContactTime, ipAddress}
jamf updateInventory -software appTitle="Firefox.app"
Like
JAMFBadge

Posted: by jake

Hi Everyone \-

As Zach mentioned above, we have been working on a few ways to make the inventory collection process faster and less impactful. A few enhancements in the 9.23 release have been made to address this.

The biggest change was made to the inventory collection process. It is now threaded and significantly faster when collecting inventory on machines.

We have also implemented FR-771 and FR-708 to reduce the impact of recon running in multiple policies.

There are a few more plans to continue to reduce the time of the inventory collection process that we expect to be in a future release. Thanks for the suggestions!

Like

Posted: by krichterjr

Thanks guys!

Like

Posted: by jcompton

It would still be nice to have more granular control over this. What we would really like to do is only inventory /Users and unix apps and fonts once a week. But inventory /Applications with every inventory.

However \- it would be critical that the daily inventories do not remove data collected from the weekly inventories.

I had hoped to set up inventory collection options with the smaller data set, but then run a weekly policy with script \- jamf recon -AddAppPath, etc.

Like

Posted: by alex030cc

We need this feature! Thanks.

Like

Posted: by jcarr

external image link

Like

Posted: by PeterClarke

The ability to update EA's, without a full system recon, in particular would be very useful.

Because the full system recon takes so long (I am still on Casper Vn 8.73 at the moment),
for staff Laptops, I have to set the recon to be infrequent \- we got too many complaints otherwise..
\- But that then means that the DB gets out of date.. and info gets stale..

I know JAMF were working on ways to speed up recon.
Often we need a recon, to solve a specific problem \- e.g. To update a specific smart list, who's criteria is looking for specific versions of some application \- we want to ensure that the version info is not stale, before the smart list is used.

However the Extension Attribute update is the most glaring option. Since thats a non-native, custom set of attributes..

Like

Posted: by alex030cc

Or update API to handle all available SQL attributes. Thanks.

Like

Posted: by mm2270

I didn't get to post anything here the other day, but I have post here: https://jamfnation.jamfsoftware.com/discussion.html?id=10615 that details some scripts and processes I came up with to help address the need for collecting Extension Attributes without doing a full recon. Its not a perfect solution, but it may be useful to some of you interested in doing that.

Like

Posted: by PeterClarke

One of the issues is to "Update the Status" of some specified action.
Another is to "Get the latest status" of some element prior to tacking action.

Almost always, in the cases where we want this, we have one-specific target in mind.

eg: Verify what version of: /Applications/Firefox.app is installed.. Then if it's older then some version, update it, else exit.

To do that requires a full system recon..
Where as the action logically, only needs to check the version of that specific application.

What we actually wanted for this test was something like: jamf recon app-version /Applications/Firefox.app

( Then we know we have the latest state, we can test it.. Confident that it's accurate..)

So it's the ability to do a very targeted pre-check prior to engaging a targeted action..

The other side of the coin would be, to update the post-status of some specified action.
eg: say we had a policy that installed some application:

/Applications/wombat.app

Now 'we know' that (if successful) we have just done that..
i.e. we are only interested \- in this instant \- of the status of wombat.app
And we want that specific change status 'registered' in Casper

So we would like to do: jamf recon app-version /Applications/wombat.app
In order to 'instantly register' in Casper, the presence of this application on that CPU

But instead we can only do: jamf recon...
We are not able to take advantage of high efficiency, known, precise, targeted, status updates.

It's a bit like wanting to go to the local shops \- for a carton of milk..
-- But instead only being allowed to do \- the whole weekly shop..
-- and not get just what we wanted at that time..

Of course if something like: jamf recon app-version /Applications/wombat.app
actually existed..

Then we would have 'no right' to expect it to return the status of something completely different.
\- since in this context it's only looking for a specific named target.
and it becomes our responsibility to only use it in such a targeted context.

The rational for this, is to achieve a high-effeciency (very fast) very-focused status update.
In a very specific context.

Without it, we either have to do a complete recon
or suffer the situation of potentially working with out-of-date status info.

Though I note that in Casper Vn 9.4, and later,
Casper Inventory updates -- in Self Service policies -- are now performed in the background.
This allows the policy to run faster, and it allows users to close Self Service while the inventory update is still in progress.
In addition, when Self Service runs multiple subsequent policies, inventory is only submitted once for the entire batch of policies.

That of course only applies to self-service..

The problem still applies to 'general policies' ( i.e. those NOT in Self-Service)
and the status info that they rely on, or that they may generate, and the currency of that status info.

For instance we have Laptop users, who may have been off-site for a month..
When they come back on site \- some new policy may want to know the status of some specific element. (Though you could argue in that case a full recon would be a good idea..)

Where as a full-recon 5-times a day would be overkill..
Even if 5 policies had run on a target that day..

It's the: "we have just done this" \- now record that specific status change in casper for this CPU
kind of action that we are after, without incurring the penalty cost of enduring a full recon.
or enduring the penalty cost of NOT doing a recon at that time, and suffering 'out-of-date' status.

Like

Posted: by chris.kemp

BUMP!

We have a BYOC program where, because of possible legal implications, we want to restrict what information is collected on computers not owned by the company BUT still be able to enroll them in the JSS to deliver software and keep very limited information.

Like

Posted: by Snickasaurus

August bump!

Like

Posted: by tfoggi

I'm surprised there isn't more action on this request. I'd love the ability to be able to script specific recons to various inventory items, but would settle for the ability to recon only extension attributes. Would add even more power to the almighty smart group functionality.

Like

Posted: by arschebl

Adding my request for this - I need to update extension attributes only without the rest of the recon..

Like

Posted: by Account Deleted

+1 for only updating extension attribute(s).

Like

Posted: by NightFlight

I think I could totally write just triggering the EA's in PHP.

Like

Posted: by robmorton

Extension attributes can be very useful, but they lose some of it if you have to wait for them to run.

Like

Posted: by scheb

I need to run extension attributes at a quicker cadence than the full recon.

Like

Posted: by tlarkin

Since this FR is very old and technology has definitely changed a lot since then I'd like to toss in a few extra concepts for handling device inventory.

Instead of managing inventory at just a device level I'd also like to see managing an Application Catalog as well. I want to assume something like this is going to be coming to the new patch features that are TBA. The reason I bring this up is I'd like to see something that manages the application state of a device instead of gathering every app up is that I would like to see it more organized, and only inform me when an application updates. So, there would be sort of a delta model of updates. I don't need hardware information unless it changes and to be honest how often does hardware data change? In a large scale environment recons are expensive data wise. Also being able to set something like an application catalog state to a device allows for a device to install an app, escrow that specific app data (like version, name, etc) back to the Jamf Pro server with out having to wait for a recon. During a provisioning workflow, like say using DEP, if you are trying to manage the specific application state of a device (i.e. standard app installs) there could be times where your process may be halted because you need to perform a recon to build data into an extension attribute. This also would allow to send and receive deltas which would scale better.

I'd also like to see inventory to be managed by the number of records over a date stamp as an option. For example maybe I only want to keep the current 15 records of a device, but I don't want to retain anything after that. When using a date stamp model, if I set it to two weeks of data retention but my current workflows or say a specific business need some devices may recon more than 15 times in a two week period. Right now the log_actions table gets very large as well as the Application tables.

Another nice thing would be able to scope inventory collection preferences say through a layered framework setting. For example, every device gets the Org-wide inventory settings, but specific business units or groups of customers/users in your Org may have different needs due to their jobs. Inventory collection is currently a monolithic all or nothing sort of thing. Allowing specific groups of devices or users to be scoped specific collection settings or specific extension attributes allows me scale out the collection of inventory and only deploy it on a per need basis. Since there are typically departments with in most Orgs that will have different needs than the rest of the fleet. So being able to collect additional items in inventory to specific groups of devices or users would help every Jamf Admin out there in my opinion.

I just figured I would toss these few things out there since this FR is pretty old and a lot of things have changed over the years.

Thanks for reading,
Tom

Like

Posted: by NPU-Casper

We would very much like this feature!

We are re-imaging our lab machines and we are using the JSS/Management to push out the apps using smart groups and ongoing policies. If we could add the update inventory specifically just for apps when these policies are run would make the workflow very efficient and not overwhelm everything with a lot of logs.

Thanks!

Like

Posted: by luke.reagor

Having to run full inventories on login to update our extension attributes is extremely wasteful. And for school districts that has large amounts of devices logging in at the same time, this causes unnecessarily large loads on our JSS frontends and database during these login periods.

Like

Posted: by NightFlight

I've learned to use the API to populate EA's and then smartgroup actions on them.

Like

Posted: by ChrisJScott

+1 for this - it'd be a great way to speed up the recon process AND lighten the load on the server.

Like

Posted: by PeterG

+1 Bump!

Are we still under review?

Like

Posted: by jonathanwilson

This would be great - being able to only update apps and extension attributes would be hugely helpful.

Like

Posted: by Sanchi

Ditto

Like