MEM CM Technical Preview 2102 - Troubleshooting Collections with the View Relationships Tool

Introduction

The IT helpdesk worker gets a call complaining this or that application has not installed, even though the user has been informed the application has been deployed to the correct collection for the device.  The helpdesk worker knows that Configuration Manager is the agent, on the device, that is used to install the application. 

The helpdesk worker needs to do a few checks to determine why the application is not installed.

1) He or she may check the CM client is actually installed on the device.

2) He or she may check the CM service (named SMS Agent Host) is running on the device.

3) He or she may check the CM logs to ensure the machine policy process is taking place.

4) He or she may check that the Application Evaluation action has taken place.

4) He or she may check there are no firewall rules preventing the client communicating with the CM server components

5) He or she may check the CM cache is not full.

6) He or she may check that the application source files have been distributed to the correct distribution point server.

There may be some bespoke tools the helpdesk worker may use also to troubleshoot the failed application.  At some point however, having found no further issues - the helpdesk worker will need to ensure that the device is in the collection, to which the application has been deployed.

And then the penny drops - the device indeed is not in the collection.  And if this is the case - the device is never going to run the application.  Not until the issue is resolved, and the device name does appear in the collection - not until then will the application install on the device.

In this article I will step through the troubleshooting process - determining why a device is not in the collection it should be in.  I will use the new collection graphical feature introduced in SCCM 2010 to show how this new tool can indeed assist us with solving such an issue as this.

I will cover three necessary checks required in the collection membership examination process:

1) The collection membership rule is correct.

2) The device configuration meets the criteria defined by the collection membership rules.

3) The collection's dependencies and relationships to other collections is correct.

The Collection Membership Rule

I have a collection called Virtual Machines and I have a number of virtual machines in my MEM CM technical preview 2102 site.  My Hyper-V virtual machine, whose NetBIOS name is MDMClient1, should be in this collection - but it is not. I only have the one virtual machine in the collection, and this is in fact the MEM CM site server itself - server2b.

I  navigate to Assets and Compliance\Overview\Device Collections and highlight the Virtual Machines collection.  I right click on the collection and select Properties.

The Virtual Machines Properties windows appears with several tabs.  I will click on the Membership Rules tab.  Here we can see there is a rule called Virtual Machines.

I can then click on the Edit button (after highlighting the rule).

The next step is to click on Edit Query Statement.

If you are confident with using SQL or WQL expressions you will want to click on Show Query Language.  For this collection the WQL query is as shown below.

Highlighting the expression and a right click and a copy and paste reveals the total WQL query.  The important bit is the defining condition after the where statement:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Model = "Virtual Machine"

We see here that the collection is expecting a machine's model to have a value of  'Virtual Machine', if it is to be a member of the collection itself.

If you are not comfortable with WQL, rather than clicking on Show Query Language, you can click on the Criteria tab to determine the condition that is required, as shown below.

Now that we know the criteria for the collection membership we can then determine if the device configuration itself meets that criteria.

The device Configuration

In our example we do know that unless our device has a Model value of 'Virtual Machine', it will not appear in our collection.  How do we determine the exact model value for our machine?  There are a number of ways and I shall illustrate two of them.

Perhaps the easiest way is to click on Run, from the device itself, and then enter MSInfo32. The System Information tool appears and you can determine the WMI value for the Model in the right hand pane.

As can be seen, the value of Virtual Machine is listed and this is the correct value for our collection.  

Another way to retrieve the Model value is to use PowerShell, which seems to be the de rigueur way of doing things in the Windows world these days.

I do open up a windows command prompt with elevated privileges. I type in:

powershell.exe -executionpolicy bypass

After pressing Enter I have the PowerShell command interface ready to retrieve the model value.  I can retrieve this by typing in:

(Get-WmiObject -Class:Win32_ComputerSystem).Model

After pressing Enter I do have the Model value as shown.

Once more, using PowerShell, I have verified that the Model value is correct.  The next step is to check the collection relationships and dependencies. 

The Collection Relationships

Because we are using SCCM technical preview 2102 we do have the very useful Collection View Relationships tool.  This will help us to get to the solution to our problem - that is, the reason our virtual workstation is not appearing in our Virtual Machines collection. 

Firstly, using the CM console, we right click on the All Systems collection and select View Relationships

In my environment the tool presents two collection dependent pages.

Here is the graphical page one view.

And by clicking on the green arrow to the right I am taken to page 2.

The blue lines detail the limiting collection for each collection at a lower level from the All Systems collection.  We do know that unless a device is in the limiting collection for the bespoke collection we are analysing, the device itself cannot appear in our bespoke collection.

We can see from the graphical tool that the limiting collection, for our Virtual Machines collection, is the following collection: All Systems with CM client version 5.00.9045.1001.

And checking the criteria for this parent collection we confirm that indeed the Configuration Manager client needs to be on version 5.00.9045.1001.  This is the correct client version for the SCCM Technical Preview 2102 release.

Thus we can determine that we should check the CM client version on the client as a next step.  Unless the client version is correct, the device will not appear in the limiting collection and thus it will not appear in the bespoke collection itself - in this case the Virtual Machines collection.

On the client I do open the control panel and click on the Configuration Manager applet.

Here on the General tab I can see that indeed the Configuration Manager client version is correct.

We are still to get to the exact cause of our issue.  We know that the device should be in our bespoke collection but it is not.  So let us once more see if the View Relationships tool can provide us with another clue as to the reason for our dilemma.

The next thing I do is right click on my Virtual Machines collection and select View Relationships.  This gives me a graphical view of all the relationships for our bespoke collection.

We can see from this diagram that the immediate limiting collection, All Systems with CM client version 5.00.9045.1001, also has an Exclude relationship with the Developers Virtual Machines collection.  We know this is an exclude relationship from the Legend box that appears  to the upper right in the graphical tool. The grey dotted line is an exclude relationship.

Thus checking the properties off the Developers Virtual Machines collection I can see that my workstation device is actually added as a direct membership.

The penny drops:  because this is an Exclude limiting collection, and because my problematic device is in this exclude limiting collection - the problematic device is also filtered out of the bespoke Virtual Machines collection.  A possible solution therefore, is to remove the Direct Rule for my problematic device from the Developers Virtual Machines collection.

Having removed the direct rule and refreshing my bespoke Virtual Machines collection - my problematic device now appears in the Virtual Machines collection.

Conclusion

Hopefully I have shown in this article, how following a sensible set of checks and verifications, and by using the new Collections Relationships tool, we can eventually arrive at the cause of a failed application deployment.  In this case there was no failure as such, only a misunderstood relationship between a number of collections  - preventing our target collection from being populated with the device itself. 

I hope you have enjoyed reading this article and I wish you the same success in your own collection relationship analysis.

Colin