ConfigMgr2012: The case of unexplained - Mismatch in a User collection members count in Primary and CAS
Here is an interesting issue I worked with Umair Khan on a support case. This will help in analyzing collection evaluation in a hierarchy for user collections and system collections.
Issue:
=====
Only a single custom user collection (rest others work fine) doesn’t replicate it members up in the hierarchy to CAS. We see 10 members in that collection in primary site and nothing in CAS. We have a CAS and multple primaries and all these 10 members we are talking belong to a single primary.
More details on how the collection is defined. It’s an Application collection meant for uninstallation applications. So it detects the application is installed for a machine by a user by the SMS_G_System_AppClientState class. The query used is as described in
//
select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain from SMS_R_User inner join SMS_G_System_AppClientState on SMS_R_USER.UniqueUserName = SMS_G_System_AppClientState.UserName where SMS_G_System_AppClientState.AppName = "APPLICATIONNAME" and SMS_G_System_AppClientState.ComplianceState = 1
//
Assessment:
=========
Now the basic things that initially comes to mind when the data is there on the child but not there on the CAS is replication. Yes, DRS! But we have verified the change tracking number and changes for the replication group Collection_Membership being the latest on CAS and links are ACTIVE.
VLOGS doesn’t show any exceptions in processing any record and all looks good. So why the mismatch?? Or What’s happening here?
Dissection:
========
Here basically will defy and frustrate you unless the evaluation logic is known. I will first explain the concept then we will come back to the issue again.
Suppose we have a hierarchy:
Difference between evaluation in a User collection and Device collection:
So collections ([Collections] ) are global data, no matter you create them at any site they will replicate to all other sites. [CollectionMembers] as client data are site data. So if I create a collection membership rule for a device collection as all Windows 7 machines on CAS, what happens?
- Note that there is no CollEval at CAS, and the rule flows down to each primary as global data. The collection membership is locally calculated for each site individually and independently. And once done each sites updates its [CollectionMembers] and send the membership to CAS.
- Now CAS then holds the data in the [CollectionMembers] from all the sites.
So suppose if there were total 7000 Win7 machines in the hierarchy. What we will see on CAS is Member Count = 7000 and Members Visible on site = 7000. Taking the example of hierarchy above supposedly assuming if each primary has 3500 Win7 clients then on both the Primary sites collection view will show Member Count = 7000 and Members Visible on site = 3500.
Yes, the primary knows the total count as it is again a global data stored in [CollectionMemberCounts]
I hope majority of us know the part above. Let’s bring in the tricky part. Is it the same for a user collection in a hierarchy? You guessed it right NO!
Now the reason for that NO is we don’t have the need for each site to independently send the data to CAS as USERS are considered as global data. So what do we do?
[Thanks to Jonathan Shi for this vital piece of Info that actually helped in cracking the case]
Everything thing is same except the part I already mentioned. We just select a single site to send the membership changes to the CAS on behalf of all other primaries. So that special primary is the first primary site that you created in the hierarchy.
So if the previous admin left the job, how do we find the first primary site?
//
select * from sites where ReplicatesReservedRanges = 1
//
Yes, the above will give you the first primary site. Coming back to the assumed hierarchy, if I have a user collection and I added a user resource in PR2 then:
PR2 on collection evaluation will update its CollectionMembers. So the Member Count on PR2 will be still the old value but ‘Members Visible on Site’ will increase by 1 as mentioned earlier CollectionMemberCounts is global data and CAS still does not know of this addition.
PR1 on collection evaluation will update its CollectionMembers and *send the changes to the CAS*. The Member Count on PR1 will be still the old value but ‘Members Visible on Site’ will increase by 1 as mentioned earlier CollectionMemberCounts is global data and CAS still does not know of this addition.
CAS will see now a member’s addition via DRS message received and update its members and update the total member count for that collection.
This will replicate back to the Primary site and then member count will be updated on them.
So as of now I think in logical means be it User or Device collection the Members visible on site cannot be greater than total Member Count. We are done with the concept part now! J
Coming back to the issue, why are CollectionMembers not replicating up to CAS on this scenario.
Note that we use SMS_G_System_AppClientState class in the collection query. This actually corresponds to fn_ListAppClientState() function in SQL. If you see its definition:
//
SELECT
appname.DisplayName AS AppName,
ci.CI_ID as AppCI,
ci.ModelId as AppModelID,
ci.ModelName as AppModelName,
sd.Name0 as MachineName,
us.FullName as UserName,
ccs.ComplianceState as ComplianceState,
ccs.CIVersion as Revision,
sd.ItemKey as ResourceID
FROM CI_CurrentComplianceStatus ccs
INNER JOIN vSMS_ConfigurationItems ci ON ci.ModelId = ccs.ModelID AND ci.IsLatest=1 AND ci.CIType_ID = 10
INNER JOIN System_DISC sd ON sd.ItemKey = ccs.ItemKey
INNER JOIN Users us ON us.UserID = ccs.UserID
LEFT JOIN fn_LocalizedCIProperties(@LocaleID) AS appname ON ci.CI_ID = appname.CI_ID
//
So this function is basically telling you the compliance state for an application installed on a machine by a user.
So here is the catch, CI_CurrentComplianceStatus is a site data table and though user is global info, machine is site data. We will replicate the whole site data up in the CAS.
Also, take an example of the hierarchy here, if suppose a user installed an app in PR2 then:
PR2 collection membership will update and it will update the CollectionMembers locally.
PR1 on its evaluation of this collection *will not find any changes* as the CI_CurrentComplianceStatus table is site data specific. And hence PR2 data will stay at PR2 and then move to CAS but not known to PR1.
Now, Since PR1 is the first site it will not replicate the CollectionMembers as it did not know of the changes of insertion in the PR2 CollectionMembers as collection was based on CI_CurrentComplianceStatus which is site data specific.
CAS will not know of any members being added and will also not update its CollectionMembers and increase the CollectionMemberCounts.
Yes, that’s the issue :)
To summarize how it looks when we have the issue. SQL queries:
On PR2: [Members visible on site > Member count]
Console
SQL
On PR1:
Console
SQL
On CAS:
Console
SQL
Conclusion: Don’t use a site data dependent criterion in a User based collection. Not that I can find any documentation on this and this is going by design! :)
Senthilkumar Pandurangan & Umair Khan
Support Escalation Engineers | Microsoft System Center Configuration Manager.
Disclaimer: This posting is provided "AS IS" with no warranties and confers no rights
Comments
- Anonymous
June 08, 2015
Hi Folks,
I am back with yet an Unexplained chain :) This one helps to understand the difference between - Anonymous
June 14, 2015
Nice one ! (Though Little confusing), So whom should we say the Culprit behind the real cause?? Site Data or the Delay on DRS..! - Anonymous
June 15, 2015
There is no delay issue here. The point is "If a site data criteria is used in User collection then we will hit the issue" - Anonymous
June 17, 2015
Can you think of any other way to create a user-based collection that only pulls in members with a device-based attribute (such as computer name, OU, etc.)?- Anonymous
July 13, 2016
I'm running into this issue with trying to create a collection of users based on topconsoleuser from a device collection. I have a CAS and three primaries. Only the membership from our first primary site shows on our CAS for the user collection. The one positive is that the members that do not show up are still populated at the CAS where the policy is applied, so they're receiving the application we're trying to distribute, but we just can't properly report on them.
- Anonymous
- Anonymous
January 04, 2017
Great work Umair and Zendil !! Little tricky to understand internals for the first time but Wonderful piece of info..