ConfigMgr 2012 SP1 - Findings on Discovery Methods

As I was changing some discovery paths in Active Directory * Discovery, I noticed that the polling schedule was set to every 7 days, and that delta's were enabled for every 5 minutes.

This lead me to explore what it was discovering in these Deltas, and to check if I should increase the frequency of full discovery.

Enabling Delta Discoveries means that it checks every 5 minutes (by default) for changes or new objects.

Let's explore this...

New objects, well that's easy, but what is it that represents a change?
According to the logs created by the ad discovery agents, it appears that the search is looking for objects matching specific search criteria.

User Discovery

Here's an excerpt from the User Discovery Log adysrdis.log:

INFO: Previous highest committed USN = '48704'
INFO: New highest committed USN = '48706'
INFO: Search provider = 'LDAP'
INFO: Domain controller = ''
INFO: Succeed to cached binding for LDAP://TTDC01.tassietech.local/RootDSE
INFO: Include groups option will be ignored during incremental discovery.
INFO: search filter = '(&(uSNChanged>=48704)(|(objectCategory=group)(&(objectClass=user)(objectCategory=person))))'

So what is this uSNChanged attribute? It seems to be the key to the discovery of changed objects.
From the MSDN article, USN value assigned by the local directory for the latest change, including creation.
and Update Frequency - When the object is changed.

Pretty blunt isn't it! I thought so.

That means, ANY change to an object, increments the uSN which in turn, causes load on your ConfigMgr server as it has to parse that change, no matter how trivial.

A few things to note from the above log entries, the search has knowledge of where it left of last time it scanned.  It also has already queried AD for the latest uSN - this will be used as the starting point in the next query.

The search also says that it is going to ignore looking at groups during the incremental discovery.  This means that any group changes are not going to be discovered during this search.

In these cases, the user is still flagged as changed, but the group membership is not evaluated.

This made me think about group discovery deltas.

Group Discovery

Jumping into the Group Discovery log (adsgdis.log) I saw that it clearly states that is IS doing a recursive search during the delta.

Here's the relevant entries from adsgdis.log:

INFO: Previous highest committed USN = '48723'
INFO: New highest committed USN = '48729'
INFO: Search provider = 'LDAP'
INFO: Domain controller = 'TTDC01.tassietech.local'
INFO: Succeed to cached binding for LDAP://TTDC01.tassietech.local/RootDSE
INFO: search filter = '(&(uSNChanged>=48723)(&(objectCategory=group)))'
INFO: ads path = 'LDAP://TTDC01.tassietech.local/OU=GROUPS,DC=TASSIETECH,DC=LOCAL'
INFO: Bound to 'LDAP://TTDC01.TASSIETECH.LOCAL/OU=GROUPS,DC=TASSIETECH,DC=LOCAL'
INFO: successfully completed directory search
INFO: Start to recursively process into group objects
INFO: Finished recursively processing into group objects

So, even though the User Discovery agent isn't looking at groups - as long as group discovery is enabled, that will.

Unfortunately, my small development environment doesn't have the AD load to replicate a high change load in ConfigMgr.

I've had a thought about how I can replicate a busy AD using PowerShell.  If time permits one day, I'll knock it up and give it a test.

When we go start deploying to production, which is a VERY busy AD, we will soon see some load data.

I'll post soon on how the above works in conjunction with Collection Evaluations.