Hi folks, my name is Sanman Parvalkar and I’d like to share information with you regarding Group Memberships and the Delta Discovery process in System Center Configuration Manager 2007.
When adding machines to a Security group you usually want them to appear in the collection quickly although there can be a delay while waiting on full discovery. If increasing the Full Discovery Polling schedule is not an option, we wondered if there might be another way to speed up this process by getting the machine's updated memberof information captured via the Delta Discovery process.
To test this we added machine A to Security Group - Computers-TEST. We also created a collection based on the security group Computers-TEST:
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 where SMS_R_System.SystemGroupName = "SMS\\Computer-TEST"
We then enabled delta discovery [default 5 minutes] on the following:
Active Directory System Discovery Active Directory System Group Discovery Active Directory Security Group Discovery
Unfortunately when the delta discovery process ran there was no DDR created for the machine A. We checked the LDAP search filters that were applied [for the LDAP path specified in the discovery method] and found the following in the Active Directory Security Group Discovery log:
search filter = '(&(uSNChanged>=149673)(&(objectCategory=group)(groupType:1.2.840.1135126.96.36.1994:=2147483648)))' In the above LDAP filter - it is checking for any Security Group with a uSNChanged value greater than or equal to 149672 information available here > 1.2.840.1135188.8.131.524 = LDAP_MATCHING_RULE_BIT_OR
A match is found if any bits from the attribute match the value. This rule is equivalent to a bitwise OR operator (http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475(v=vs.85).aspx).
2147483648 = ADS_GROUP_TYPE_SECURITY_ENABLED (http://msdn.microsoft.com/en-us/library/windows/desktop/ms677935(v=vs.85).aspx)
We checked the Active Directory System Discovery log and found this: search filter = '(&(uSNChanged>=149673)(&(objectClass=user)(objectCategory=computer)))'
The same was found in the Active Directory System Group Discovery log:
search filter = '(&(uSNChanged>=149673)(&(objectClass=user)(objectCategory=computer)))'
In the above two LDAP filters, it is checking for a Class-User and Category-Computer with respective higher than or equal to uSNChanged values.
NOTE The default logging does not indicate what Active Directory Attributes are to be viewed. These are listed on the Active Directory System Discovery > Properties > Active Directory Attribute tab.
We then manually ran the LDAP search filters via LDP and found that when adding a computer to a security group, the security groups uSNChanged value increases and the computers uSNChanged value remains the same.
The 'member' attribute changes on the security group which triggers the uSNChanged bump. The USN value for the machine does not increase as it is a "back link" attribute that is not populated like normal attributes (source : http://technet.microsoft.com/en-us/library/cc961761.aspx).
So the uSNChanged value of the machine has to increase for System Group Discovery Process to create a DDR for that machine, and only then will the attribute be fetched. Delta Discovery does not capture this occurrence of change in the machine due to this "back link" factor, hence the full discovery process is required for the machine to appear.
A workaround would be to change a field like the 'Description' field which then bumps up the uSNChanged value. This gets captured via the System Group Discovery Process and a DDR is created.
Here’s how to run the LDAP filters manually. The example below shows a list of computers with an uSNChanged value above 149673:
launch 'ldp.exe' > connection > connect 'leave the name field blank' - default port 389 connection > bind > default is 'bind as currently logged on user' > ok Browse > Search > Base DN : DC=contoso,DC=com Filter : search filter = '(&(uSNChanged>=149673)(&(objectClass=user)(objectCategory=computer)))' Scope - select 'Subtree' Attributes - add uSNChanged - so it would look like objectclass;name;description;canonicalName;usnchanged now Hit – Run
The output will look something like this:
ldap_search_s(ld, "DC=contoso,DC=com", 2, "(&(uSNChanged>=149673)(&(objectClass=user)(objectCategory=computer)))", attrList, 0, &msg) Getting 1 entries: Dn: CN=Machine-A,OU=Computers,DC=contoso,DC=com canonicalName: contos.com/computers/machine-A; description: its time for change !; name: Computer-A; objectClass (2): top; person; organizationlPerson; user; computer; uSNChanged: 149689;
The above ldap output indicates that 1 entry returned the computer "Machine-A" whose uSNChanged value was 149689 (higher than the search filter).
How to poll for object attribute changes in Active Directory on Windows 2000 and Windows Server 2003: http://support.microsoft.com/kb/891995
Sanman Parvalkar | System Center Support Engineer
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/ ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ Operations Manager Team blog: http://blogs.technet.com/momteam/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/