PDQ Inventory offers a number of different filtering options for its dynamic collections and reports to help you easily identify specific computers. These filters include both Value Filters and Group Filters. Value Filters allow you to specify a scanned attribute of your computers and the value or values of that attribute you want your collection or report to consider. Group Filters allow you to combine Value Filters and define how your collection or report will think about them.
Value Filters
Value Filters are split up into four sections that determine what computer attribute the filter is comparing, a value to compare that attribute to, and rules for what type of comparison is being made. These sections are represented by the “Filter”, “Column”, “Comparison”, and “Value” columns in the Filtering Window when creating a dynamic collection or a report. Here you can see these columns along with an incomplete set of filters as shown when creating a new dynamic collection:
Depending on the comparison type that is set, there may also be a second “Value” column available. For example, the “Version Between” comparison has a second value available to set an upper and lower bound for your comparison.
Group Filters
In addition to the value filters, each collection or report will also have at least one group filter. In the example above, this is the “All” group filter. There are four different group filter options available:
All: This group filter will be considered true if a machine matches all of the value filters in the group.
Any: This group filter will be considered true if a machine matches at least one of the value filters in the group.
Not All: This group filter will be considered true if a machine matches some or none, but not every value filter in the group.
Not any: This group filter will be considered true only if a machine matches none of the value filters in the group.
Filtering Basics
When adding one or two simple filters to a collection or report, these filters can usually be read similarly to a natural language sentence structure. For example, this set of filters will find all computers which have an application whose name contains “Google Chrome”
This works similarly when filtering for a specific version of an application. The following set of filters will find all computers which have version 88.0.4324.190 of Google Chrome. Since both of those filters are located under the same “All” group, they will be evaluated together. Any computers which have an application containing the name “Google Chrome” but at a version other than 88.0.4234.190 will not show up in the results, nor will any computers which have an application whose name does not contain “Google Chrome” at version 88.0.4324.190.
Combining Filters
Now that you're getting comfortable with filters, you may want to start creating some more complicated collections. For example, let's say you're standardizing browsers in your organization want to find all the computers in your environment that have both Google Chrome and Mozilla Firefox installed. If you try that with filters like the ones we've shown so far, you may wonder why your collection isn't showing any results.
Because of the logic necessary to allow PDQ Inventory to combine some filters together, such as combining the "Application | Name" and "Application | Version" filters together to search for a specific version of a specific application, all Value Filters within a single Group Filter are evaluated together. If you have two "Application | Name" filters in one group filter, PDQ Inventory will be looking for one application entry which meets both of those conditions at once. In most cases, this means it won't find anything at all. Instead, you'll want to be sure that the two applications you're searching for are in separate group filters so that PDQ Inventory knows to evaluate them separately:
Negating Filter Conditions
While filters like the ones above which search for computers that do meet a set of criteria are usually relatively simple, filtering for computers which do not meet those criteria can be a little more confusing at first. The best way to set up these filters will depend on whether each computer has a one-to-one or a one-to-many relationship with the values being filtered. For example, one computer will only have one OS and one hostname, so these are one-to-one relationships. One computer will most likely have multiple applications installed and might have more than one display connected, so these are considered one-to-many relationships.
With a one-to-one relationship, filtering for machines that don’t meet certain criteria is fairly straightforward. Most comparisons in filtering contain an inverse - the “Equals” comparison can be inverted by using the “Does Not Equal”, the “Contains” comparison can be inverted by using “Does Not Contain”, and so on. Here is an example of a collection to find all machines whose hostname does not begin with “LT” by using one of these filters:
Filtering for machines that don’t meet particular criteria for a one-to-many relationship is a bit different. Instead of changing the comparison, you will need to change the group filter from “All” to either “Not All” or “Not Any” while leaving the comparison value the same as it would be in a collection searching for computers which do meet that criteria. This is because each filter in PDQ Inventory is evaluated against all values for a given computer. Filtering for computers with an application name that does not contain “Google Chrome” for example will show all computers that have any application other than Google Chrome installed instead of all computers without Google Chrome.
Filtering with Variables
In some cases, you may want to update a particular value in multiple collections at once. For example, if you have multiple collections that filter computers based on the most recent version of an application you will want to update that application version. You can do this by using custom variables. To manage your custom variables, go to Options > Variables from the main PDQ Inventory console. Once you specify a name and a value for a variable, you will be able to reference that variable in your filters. Then the next time that value changes and you want to update your collections, you can edit the value of the variable and every collection using the variable will be updated as well. Here you can see an example of a variable and how to properly reference it in a collection.
As with all things, be sure to test your filters and verify the results. It can be helpful to know of a small handful of machines that do meet the criteria for whatever collection you’re creating as well as a small handful of machines that do not meet the criteria so that you can quickly validate the results.
