Let’s set the record straight once and for all on what, exactly, “Drill down from parent collection” means. You may have noticed this check box when you double-click on collections in PDQ Inventory. (What are collections?)
The image above shows the filters for the Firefox (Old version) collection. Notice the numbers next to the collection names (on the left tree panel).
It’s important to remember that when the “Drill down…” option is unchecked the filters in the collection are evaluated against each computer in your PDQ Inventory database. Generally speaking, most of your collections will probably have this option unchecked. Refer to the image above. If the “Drill down…” option had been unchecked then the two filters would be evaluated against 104 computers (the number next to the All Computers collection).
Filters are only processed against computers that are in the Parent Collection. Obviously, this only has an effect when your collection is nested inside of another collection. Refer to the image above. Instead of evaluating the filters against 104 computers (All Computers) the filters are only evaluated against the computers that exist in the parent collection called Firefox Installed.
Let’s assume that you have 3,500 computers in your database. Of those 3,500 computers only 179 have Firefox installed. This means that any child collections would only evaluate the 179 computers which would result in a slight performance improvement.
Child collections do not re-use filters in the parent collection. The biggest misconception is that you don’t need to duplicate filters in child collections. Let’s take the collections above as an example. Here is the filter that exists in the parent collection Firefox Installed.
Now, let’s try an experiment where we screw up the child collection. I build a new child collection called Firefox (Old version) BAD FILTERS. Here is where the mistake comes in. I think that I don’t need to have a filter for Application Name starts with Mozilla Firefox.
Why should I duplicate it since I am drilling down from a collection which already contains that filter? So I simply use a filter that says Application Version lower than 42.0.
Remember, this is an example of what not to do.Notice that I have 63 computers in the bad collection when I should have 23. Why? Because the BAD FILTERS collection simply looks for computers in the parent collection that have ANY application that has a version lower than 42.0.
We never specified a corresponding application name to be used with the version filter.
Inasmuch as child collections don’t re-use filters in the parent collection, there are some times when you don’t need to duplicate filters. I need to use some database lingo here: One-to-one and one-to-many. When you are dealing with a one-to-one relationship you can probably get away without duplicating. When you are dealing with a one-to-many relationship you need to duplicate.
Examples: One computer can have only one architecture, either 32 or 64 bit. That is an example of one-to-one. However one computer can have many applications. That is an example of one-to-many.
Let’s say you have a collection called HQ Workstations.
It filters out all computers that are under the HQ-Workstations OU in Active Directory. Any sub-collection that drills down will only evaluate computers that are in HQ-Workstations. For this example, let’s say you copied your Adobe AIR collections from the Collection Library underneath the HQ-Workstations collection. Then when you check the Drill Down box for all of the sub collections, you can easily see HQ-Workstations that have (or don’t have) Adobe AIR.
Also, you may notice that there is a variable to determine Adobe AIR. You can read more about variables in our documentation. Here is another example of proper usage of Drill Down where I don’t have to duplicate filters because of a one-to-one relationship.
My top-level collection has one filter: Computer O/S equals 7. (Don’t confuse the O/S filter with OS Name. O/S Name is the full O/S name such as Windows 7 Professional whereas the O/S is the “short” name of the O/S such as 7.)My other child collections each contain one filter: O/S Architecture. This is a rare example of times you don’t need to duplicate filters.