Why So Much Unusable Data in the JSS?

I AGREE! I would love to make smart groups that contain computers with certain certificates that are expiring soon. JSS definitely gathers this data because I can click on the computer record to view the certificates but I have to manually do this for each and every computer. If JSS collects it, we should be able to access it and use it.

There be a couple other rants, er, ideas in this thread as well.
A couple of FR's worth up-voting near the end.

I think there is an open feature request for this and I would bet big money that Jamf wants this too.. I bet they get many helpdesk request for issues from admins that mess up the database accessing it directly and have full access to all the data in the GUI is the best way to stop those issues... : )

It's got to be just a question of how fast Jamf can make the changes : )

C

@scottb thanks for the link!

I had searched for something related to this prior to posting and hadn't seen that thread. I'll dig back into that and be sure to add any FR that are needed.

Hmm... Apparently this issue, which has been an issue now for some years, is beginning to reach a boiling point with the JAMF client base. Examples here, here, here and here. All of these were posted within the last day, but there are certainly more like these going back.

I seriously hope JAMF has something good in the works to expose as much information that is captured for reporting as possible. I continue to be frustrated that there are items I can only look at in the JSS UI and do nothing else with them. For so many of these, we end up writing an Extension Attribute to recapture information that is already being captured (assuming its even possible to recapture it that is) just so we can run a report and include it as a column, or build a Smart Group from it, etc.
I heard once that for every EA we write to recollect something already being collected natively, an angel falls from heaven, or is it a puppy dies.. something like that. Anyway, its kind of a crime to have to keep doing EAs for these.
Please JAMF!! Think of the angels! ...and the puppies!

^^ Post Of The Week™ @mm2270

optional image ALT text

Rant is fine. Not being able to run searches or create smart groups based on the info already being collected in the JSS is a major over site. It would be different if we were asking for info that the JSS is not already collecting.

Rant is fine. Not being able to run searches or create smart groups based on the info already being collected in the JSS is a major over site. It would be different if we were asking for info that the JSS is not already collecting.

That's why I always spend at least 3x the time when I'm in a place where there is data, but I can't find a way to utilize it. It feels like I'm just missing something - which does happen - and that's the real time waster.

Yes JAMF does like to store all the data but then make sure you can't use it form the GUI or the API.

@mm2270 LOL! whew... that was awesome! You said it exactly right though.... this is something that's been a times a minor annoyance, and other times prevented me from addressing a time critical issue in our environment. This latest case was just the final straw for me, so I had to reach out to my fellow IT Nerds about it. I'm so sick of creating EAs to pull data back that is clearly already in the JSS. All that does is slow recon down, and unnecessarily store redundant data in the DB.

Forgetting for a moment that the data in the DB isn't usable when it comes to creating smart groups. The fact that I can't even report on some of it, just absolutely blows my mind. Quite frankly this oversight alone makes JAMF look as though they are not focused on the Enterprise at all. Because as someone who works for a a large enterprise that is highly regulated, if I can't report on something, then it never happened. I'm 100% sure I'm not alone with that one either...

Let me add another example here... With Application Utilization; I've found no way to generate reports on how often X app is used, or to run any reports on that at all. Because of that we've stopped collecting that data. Again, if the data isn't actionable, then it's worthless and just slowing down recon.

@Sobchak , @scottb , @jrwilcox -- Glad to hear we're on the same page here, and that I'm not alone in my frustration.

...if the data isn't actionable, then it's worthless and just slowing down recon.

This is actually a very important point, I mean about slowing down recon. JAMF has publicly stated on the boards here that they are interested in making the recon process as least impactful for their clients as possible. See the "Bring back the verbs" Feature Request thread as an example. If that's the case, it would really behoove JAMF to make as many items available to us to use in Smart Group creation and advanced reporting as possible. I would happily dump around 10-15 Extension Attributes I have right now that are capturing data redundantly so we can make use of it in reports, if JAMF made the built in captured data available to us for the above scenarios. That would help reduce the recon time on my clients, which, according to JAMF's statements, is something they also want.
I'd therefore like to request that JAMF to make good on their promise to help reduce our inventory collection times and make as much of the default collected data available to us for use that are currently not available.

The worst part of this is that JAMF has never responded to this in any way that I am aware of. They can't be so out of touch that they don't realize this is an issue yet nothing is said or done about it.

@tomt I had something also written up with my post above yours that said exactly the same thing, but I decided not to post it in the end. I don't want to come down on JAMF too hard on this, but I do agree with you. The silence on this issue and many others is deafening at times. No-one wants to feel like they are just talking to themselves on things that are important. I'd love to hear officially from JAMF about this topic. I suspect they are listening and are working on it, but with no information from them, we're just left to wonder if we're being heard here. If there are some technical issues making this more of a challenge than we're aware of, I'd like to hear that too. I can take that if there's a valid reason, but with nothing to go on, its hard to feel the lack of movement on this is valid.

@mm2270

but I decided not to post it in the end. I don't want to come down on JAMF too hard on this, but I do agree with you. The silence on this issue and many others is deafening at times.

Agreed whole heartedly. And I'm reserving my personal rants and/or frustrations, as it's non-productive and does not paint a positive view on the vendor who is without compare of of the best I've ever worked with. Adobe on the other hand, I've got no problem joining the @donmontalvo Adobe Hate Club.

While these threads are monitored, it will be more productive if we all simply create the feature requests needed with clear examples and impacts, and reach out to our TAM's and other JAMF contacts to illustrate how important these needs are.

I agree with what folks are saying here. I would like to add one other feature request that might add a bit more flexibility.

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

The following are just guesses. I can't help but wonder if this is all due to the fact that the more querying is being done on the database for each smart group the heavier the load will be on the the JSS itself which is why JAMF has been reluctant in making some of the data in the DB accessible as criteria. That's just a guess and perhaps it's not really an issue. Maybe it just means you need to throw more cores and RAM at the server running the JSS so that it can handle the increased load. Maybe this just doesn't scale well and so while it may not be huge for smaller deployments of the JSS, it becomes an issue for companies like Apple or IBM who are probably deploying in the hundreds of thousands of Macs/iOS devices. Perhaps its a limitation of MySQL? Like I said these are all just guesses. Would be interesting to hear from JAMF on this directly though.

@mm2270 , well said... Hearing something back from JAMF would be a step in the right direction for sure. As you pointed out, this thread does not represent a new point of view, it's only the most recent on the subject.

In this case I know the info I wish to utilize (UID of user accounts on the Mac) is located in the 'user_receipts' table. Since we know that some of the other information is that table is usable today (Home Directory Size, FileVault status, etc) it's just that much more frustrating that all of it isn't.

I've also had a post similar to this one typed quite a few times in the past, but like you chose not to post it at the time. However as competitors continue to bolster their Mac system's management solution, it's becoming rather hard for me to respond to questions internally about things similar to those mentioned in this thread, and continue to defend why JAMF is the best.

Because to those people who's whole world is bar graphs and pie charts (sad existence I know:), this really does not make JAMF seem very Enterprise focused.

• 1,000,000 on all of this

@john.miller I hope I'm not abusing the tagging system on JAMF Nation here. ducks for cover

@bpavlov Some of the points you make above are reasonable assumptions. Just assumptions as you mentioned, but it may be the case that some of the missing items that are being collected would add some unwanted overhead with Smart Group calculation. Its fairly certain the last thing JAMF is interested in is adding additional reporting capability at the expense of hurting overall server performance and increased memory utilization.

However, there are a few omissions that just baffle me to no end. A simple example is why we can't search on and create groups based on the Casper management account. This information is clearly there in the computer record, yet, the only thing we can do when creating searches is Managed = Managed or Unmanaged. The management account could not possibly add any overhead to the JSS. Its a simple string of characters!! What are we talking about? A few bytes of info? Why do I need to create an Extension Attribute that uses the API to pull this information so I can report on it? As mentioned in some posts on this thread, some admins in high security environments are concerned about leaving read API account credentials in plain text in an EA script just to grab this information. I can understand the concern. Maybe its a little overblown, but still, there's no logical reason we should need to do this for such a simple basic piece of information. The corresponding Feature Request to add this as searchable criteria has been out there for several years now, and yet we're still waiting for this simple string of data to be something we can search on? I just don't get it anymore.

To JAMF: I'm sorry that these posts come across as rants. I don't want to rant about things, because overall I do love the Casper Suite. Its just that, while no-one would reasonably expect a Feature Request to be implemented by JAMF immediately, I think 3 1/2 years is enough time to add something like the above into the product. That request was filed back when the Casper Suite was still in the 8.x series. When the move to 9 happened, I had hoped that this would have been added, so its really discouraging that something as seemingly simple as that has yet to make it there. I would really welcome any feedback from you guys on these requests.

I wish I could "Like" individual posts. I hope (am sure) that JAMF is hearing us. We're just over a year into our adoption of Casper and my management are relatively happy - but now they want more information. Specifically information I KNOW is in the database, but have no way to (easily) get it out for them. :(

@cwaldrip -- I was tempted to mark each response as the solution, since I wasn't able to 'like' them. :D

@mm2270 , I couldn't have said that better myself...

I've been tempted to write queries that would pull the information I need from the various tables within the DB and use sql statement to create 'Static Groups' with the machines that matched my initial search criteria. There were 2 reasons I decided against that. 1) There is no guarantee that schema of the database will remain constant from one version of the product to the other. So something that works with this version, may fail once the JSS is upgraded.

2) I just couldn't bring myself to doing custom work directly against the DB, when the JSS should (in my opinion) be handling it.

I've also noticed there are Feature Requests out there that would pretty much cover this, however I haven't heard from JAMF on what their strategy is to address it. On the surface this seems as though it would be a relatively easy change to adopt, especially since the information we're talking about is in tables that contain data elements that are currently accessible to admins.

Let's give them a bit of time to respond, then we can start making 'JSS Reporter/Custom Group Maker 1.0'. ;)

The only response I have received from JAMF on this subject is that it would clutter up the User interface if they allowed us to access all of the data they have in the database.

@jrwilcox But we're admins, not regular users. That's a rather weak excuse. Just because more data is available does not mean you need to make an ugly UI/UX.