ConfigMgr : Machine added to a ConfigMgr group is not captured during the Delta Discovery Process (ConfigMgr 2007)

usa_new_york_manhattan_rockefeller_center_binoculars_112290_602x339

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

 

source : (my own post) https://blogs.technet.microsoft.com/configurationmgr/2012/03/27/machine-added-to-a-configmgr-group-is-not-captured-during-the-delta-discovery-process/

Advertisements


Categories: Uncategorized

Tags: , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: