Retrieved Properties

1

(imported topic written by SystemAdmin)

There was a post (http://forum.bigfix.com/viewtopic.php?id=4054) way back that references what we want. In that post, it was asked “Are you aware of a way for me to put multiple values from this analysis into multiple columns…” and the reason stated was “love to have multiple values go into multiple columns yet on the same line in the console”.

We couldn’t agree more. We want to grab multiple properties from a single object and display it in appropriate columns in the console and web reports. Manually parsing the data is not a true solution - it should be out of the box functionality - in terms of solving this request. Perhaps this has made it into version 8 :slight_smile:

2

(imported comment written by SystemAdmin)

I’m not sure I understand your request. Could you provide an example?

3

(imported comment written by tscott91)

I’m guessing he means, for example, IP address… If you have a PC with multiple IP’s you get “Multiple Results” in the column instead of one in each column…

4

(imported comment written by SystemAdmin)

Splitting up multiple results into multiple columns seems a little weird to me. Should we choose the correct number of columns to show all results for all computers automatically? That could be a problem if one computer has a lot of results for a property. Maybe the number of columns should be configurable?

In 8.0 web reports, we solve this problem by allowing you to expand a cell with multiple results. When the cell is expanded, all of the results are shown inside of the cell instead of just the first result.

This is definitely something that we want to do better, so I’m interested in hearing feedback about how you guys think this feature should work, and whether the solution in 8.0 web reports meets your needs.

5

(imported comment written by SystemAdmin)

Brian, tscott is on the right track. We want the ability to return multiple results in multiple coumns. Perhaps just for certain inspectors, perhaps having a limit on the number of columns.

I don’t know the best way to pull this off, perhaps a property that returns all the values in an array format? Like a file property (lets call it FileXYZ) that when run against a file would return the File Name, File Create Date, File Mod Date, File Owner, File Path etc. And then we could access that data by using FileXYZ[1] or FileXYZ.1 for the first attribute, etc.

6

(imported comment written by SystemAdmin)

jspanitz

And then we could access that data by using FileXYZ[1] or FileXYZ.1 for the first attribute, etc.

Are you talking about using session inspectors to access the data? Or are those column names?

7

(imported comment written by SystemAdmin)

Brian - I think the answer is session inspectors. The column names could be base of those as well - perhaps the name after the decimal.

So if the property was FileXYZ and it used the (I am making this up) FileInspector session inspector and the FileInspector had attributes of .Name, .CreateDate, etc, then we could access them as FileXYZ.Name, etc. And for reports they could be the same name (perhaps with the optional ability to filter out (hide) the FileXYZ part of the name.

In trying to make this fit with how the current console looks / operates, an Analysis would then need a “root” property that was based on the session inspector and then sub properties that were the session inspector attributes.

Then each could be displayed in individual columns or hidden from view - just like the current properties can.

I’m expecting great things from you guys now that you have deeper pockets :slight_smile: Seriously though, having something even remotely like this would be incredibly useful. It’s very SMS / SCCM like, which is where I originally came from.

8

(imported comment written by SystemAdmin)

Understanding concrete examples of how you would use these columns, or what you are trying to accomplish, would help us design an appropriate solution.

The file example sounds like it should be separate properties, each of which would then get their own column (name, date, version, etc.). So it wouldn’t require splitting apart columns. In this case, I could imagine each column would be helpful because you’re looking for differences in versions across machines, just like other properties that return only single results.

Other properties by their nature return multiple results (such as the example in the other forum, or the IP address example). If we automatically split those apart, we could end up with dozens (hundreds?) of columns. Worse, the orders of results is likely different, so identical results may be in different columns for different rows (though complicated matching could probably guess correctly).

For your experience with these types of properties, what are you trying to accomplish? Are you asking “which computers return this value”, or are you really asking “what are all the values that are returned across all computers?” Are you instead just interested in summaries across all machines: “what number/percentage of computers are reporting back each unique value?”

These different questions could/would be addressed in different ways in the interface, so it’s important to get a better understanding of what questions you’re trying to answer.

9

(imported comment written by MattBoyd)

Alright, here’s my shot at trying to clarify why this would be a nice feature to have. I’ll try to explain it as clearly as I can, but I apologize in advance if it makes no sense at all :confused:

To me, it seems that you should be able to make columns within properties so that it’s easier to retrieve data from that property in Web Reports. I can think of a few cases where I’ve found myself wishing for something like this, particularly when there are multiple pural values that need to be associated with each other…

As an example, say you want to return the IP Address and Mac address associated with each network adapter on the client. These properties are paired together, and really can’t go into two separate properties if you want to easily be able to tell what IP address goes with what Mac address. So now you have multiple attributes in the same property, separated by a delimiter:

(addresses of it, mac addresses of it) of adapters of network

Normally, this isn’t too difficult to deal with. However, when you go to write a Web Reports (or presentation) query to display the data, you could run into two potential problems. The first is aesthetic: Because you need to split each string “record” using your delimiter, the relevance becomes somewhat confusing and difficult to mentally parse:

("IP: " & preceding text of first “,” of it & " Mac: " & following text of first “,” of it) of (values of results(it, bes property “IP and MAC Address”)) of bes computers whose (exists results (it, bes property “IP and MAC Address”) whose (preceding text of first “,” of values of it starts with “172.28.127”) and name of it starts with “CB”)

To a common user, “preceding text of first “,” of it” may not mean a whole lot. I showed a query very similar to this to a colleague and he asked me if it was Klingon. It can get even more complicated when there are more than three attributes in the property, and you want to filter your results by values of those attributes. If there were columns within properties, we might be able to use something like this:

("IP: " &

column “IPAddress”

of it & " Mac: " &

column “MacAddress”

of it) of (

column values

of results(it, bes property “IP and MAC Address”)) of bes computers whose (exists results (it, bes property “IP and MAC Address”) whose

column “IP Address” of column values of it

starts with "172.28.127) and name of it starts with “CB”)

The other potential issue that you can run into is with delimiting itself. It’s easy to accidentally use a delimiter that’s too common. For example, BigFix queries that return multiple values will use a comma to separate their values by default. There’s been a few times where I’ve written relevance that returned multiple results, and one of them was a date/time value. These include commas in them, so they can interfere when I go to parse out the data in a Web Reports query.

10

(imported comment written by jessewk)

Hi boyd,

We actually have the solution you are looking for already. If you are returning results in a tuple, you can use the ‘tuple string’ inspector to parse out the specific columns. It will handle all of the escaping rules for you so you don’t have to worry about whether a value contains a comma.

Suppose your retrieved property was defined as:

(addresses of it, mac addresses of it) of adapters of network

In my deployment, I just have one computer and the result is this:

192.168.105.68, 00-0c-29-ce-ad-5a
0.0.0.0, 00-ff-10-80-5d-02

Then you could create a session query as follows:

(name of item 0 of it, tuple string items 0 of item 1 of it, tuple string items 1 of item 1 of it) of (computer of it, values of it) of results (bes property “ip_and_mac” , bes computers)

This result of the session query is:

WIN-LDTSNCUH9HK, 192.168.105.68, 00-0c-29-ce-ad-5a
WIN-LDTSNCUH9HK, 0.0.0.0, 00-ff-10-80-5d-02

11

(imported comment written by SystemAdmin)

jessewk, that looks like advanced klingon. And therein lies the problem. I think anyone and everyone that’s written even a small piece of code in an object oriented language can easily grasp objects with properties - FileXYZ.name, FileXYZ.ModifiedDate, etc. So from an ease of use point of view, I don’t like it! If I go into web reports I should be able to choose an object (retrieved property) and get it’s sub objects and have them displayed in different columns. Custom reporting is - shall we say it - very very hard and very very bad in terms of presentation. There are to many good reporting tools out there for someone to have to write code for something so basic.

Can you solve the problem below:

We have an analysis that returns a property that contains the location, size, create date and time of Outlook .pst files. So in order for us to get a web report that displays this as individual columns, I have to create a custom report with the code you provided?

I also think that from an ease of use point of view, how much easier the Relevance editor would be if you code type and all the sub objects after the . could show up as you were typing. No more fat fingering the language and an easy way to see all the objects.

abauer - I don’t see how having a single column with hundreds of values is any better than hundreds of columns. At least columns are lined up and visually easier to compare. Try comparing a multiple value column visually some time. And from a coding view, there is a lot less work to do since we don’t have to parse the multiple value column anymore.

To answer question "Are you asking “which computers return this value”, or are you really asking “what are all the values that are returned across all computers?” Are you instead just interested in summaries across all machines: “what number/percentage of computers are reporting back each unique value?” " - The answer is both. We’ve needed to perform both in the past.

boyd - I think we are in agreement - If you could just go through and click on all properties and their sub-properties in web reports - it would make it a lot easy to create a web reports - especially to the none coder.

12

(imported comment written by MattBoyd)

@jessewk - That’s much simpler than how I’ve been writing my WR relevance. I will definitely try using that in the future. Thanks!

@jspanitz - I definitely think that we agree that this feature could be useful for a variety of reasons, and that relevance syntax can become daunting at times. However, what you’re asking for in that specific form (Property.Attribute) seems to go against the standard syntax of relevance. It would probably be “Attribute of Property” or something similar. But I do some OO programming (and TSQL), so I can definitely relate to you with this request.

Slightly off topic - It was not my intention to start a debate about the usability of relevance language. It is incredibly powerful – is there any other query language for systems management that even comes close!? With that said, it can present quite a learning curve for the average sys admin, so it makes sense to advocate for finding different ways to make it easier to perform complex queries (without sacrificing performance).

13

(imported comment written by SystemAdmin)

boyd

Slightly off topic - It was not my intention to start a debate about the usability of relevance language. It is incredibly powerful – is there any other query language for systems management that even comes close!? With that said, it can present quite a learning curve for the average sys admin, so it makes sense to advocate for finding different ways to make it easier to perform complex queries (without sacrificing performance).

Agreed. We just wanted a way for multiple values to be automatically parsed without having to do this manually each and every time. There are quite a few things that require repetitive relevance in BigFix and it just seems natural to us to build in that functionality rather than manually create it each time.

John

14

(imported comment written by SystemAdmin)

I agree.