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.113556.1.4.804:=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.113556.1.4.804 = 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).
Reference article:
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/