Using Enhanced System Discovery 2007 R2 For Speedy Software Distribution

I’ve been working with a customer on a way to improve their software distribution to computers through Configuration Manager.  Currently, with ConfigMgr, if you use query based collections on group membership for software distribution, then distribution can be slow.  For example:

1. Configure AD System Group Discovery to run at midnight.
2. Create an AD Group ‘G_SWD_Microsoft_Project’.
3. Create a collection based on this group, with the query (my domain is SCCMDEV)
   1. select SMS_R_SYSTEM.* from SMS_R_System where SMS_R_System.SystemGroupName = "SCCMDEV\\G_SWD_Microsoft_Project"
4. Set the collection schedule to daily at 03:00am
5. Advertise software to this collection.

Time	Action	Result
any time	Computer added to the group	Helpdesk expect software to be delivered
00:00	AD System Group Discovery runs	System Resources ‘System Group Name’ array populated with group membership
03:00	Collection Update runs	Computer is now a member of the collection
any time after	Computer runs a policy retrieval and evaluation cycle	Software is delivered.

From this we can see that software will typically be delivered overnight.  We can speed this up by increasing the discovery and collection update schedules, but this will add load to the server, and still may not be as fast as we require.  Enhanced System Center Discovery has some features to help with this.

Note that I am not affiliated with the manufacturer of Enhanced System Discovery , System Center Tools, nor am I recommending this product. This is simply the findings of some research, published here so that it may help others make an informed decision regarding this product.

ESD 2007 R2 can improve this by offering the following features

1. Delta Discovery.   Only resources which have changed since the last discovery are discovered.
2. Collection Updating.   If the membership of a group a collection is built from changes, ESD kicks the collection to update the membership.

This means that we can run the discovery method at a much tighter schedule, for example every 5 minutes.  We can then have the following software distribution setup.

Note: All quoted timescales in this article should be checked in your environment before implementing to ensure that it scales well

1. Configure AD System Group Discovery to run at midnight.
2. Create an AD Group ‘G_SWD_Microsoft_Project’.
3. Create a collection based on this group, with the query (my domain is SCCMDEV)
   1. select SMS_R_SYSTEM.* from SMS_R_System where SMS_R_System.ESDmemberof like "%\\G_SWD_Microsoft_Project"
4. Advertise software to this collection.

Time	Action	Result
any time	Computer added to the group	Helpdesk expect software to be delivered
within 5 minutes	Enhanced AD Group Discovery runs	System Resources ‘System Group Name’ array populated with group membership
within a few minutes	Collection Update runs	Computer is now a member of the collection
within an hour	Computer runs a policy retrieval and evaluation cycle	Software is delivered.

So we can see that the policy should be received very quickly, within a maximum time of the software distribution policy refresh cycle plus around 10 minutes.

Notes on setting up Enhanced System Discovery

This is a summary of the basic steps I went through to configure ESD in my environment.

1. Download and install:

1. Download from https://www.systemcentertools.com/esd2007.html
2. Email Steve Bobosky (sbobosky@systemcentertools.com) to get a demo key for your test domain.
3. Installed MSI on site server, but this can be any system.

2. Run “Enhanced System Discovery.exe & Configure

1. Make a note of the message
2. We only have one domain, so we leave just the ‘default’ subkey.

3. Check working correctly

1. Ran again and checked the log (in the default ConfigMgr log location) to see that all is OK
2. Saw that it was creating DDRs. Checked that DDRs were processed by checking properties of a resource in the admin console. All is good!

4. Create AD Groups

1. Create global (or universal?) security groups for SW Distribution, e.g.
   • G_SWD_Microsoft_Visio
   • G_SWD_Microsoft_Project

5. Create collection for Software Distribution

Microsoft Visio:
select SMS_R_SYSTEM.*
from SMS_R_System
where SMS_R_System.ESDmemberof LIKE "%\\G_SWD_Microsoft_Visio"

Microsoft Project:
select SMS_R_SYSTEM.*
from SMS_R_System
where SMS_R_System.ESDmemberof LIKE"%\\G_SWD_Microsoft_Project"

IMPORTANT: Groups will have the format <DOMAIN>\<GROUPNAME>, so use LIKE “%\Groupname” to work for all domains. The ‘\\’ is WQL notation for ‘\’

IMPORTANT: Do not use SystemGroupName which is return by AD System Group Discovery, use ESDmemberof instead

6. Follow documentation under ‘Configuring Delta Group Discovery’. Namely

1. Ensure HKLM\Software\System Center Tools\Enhanced System Discovery 2007\Default\DeltaDiscovery is set to ‘Yes’.
   • This was set by default
2. Configure the ‘SQL DB’ registry value to be the database of your primary site. SMS_WGB for example.
   • This was set by default
3. Configure the ‘SQL Server’ registry value to be the server that hosts the SMS database.
   • This was set to the SCCM Server by default. We have a remote SQL database, so changed this to SCCM-SQL
4. Configure the account ESD is running as to have read privileges to the v_RA_System_ESDMemberOF SQL view. Access to this specific view is required, but can also be granted by making the ESD account a member of the SMS Reporting Users group.
   • Using administrator for test
5. Add one of more rule to the GroupMonitorRules multi string value in the registry.
   • Added G_SWD
6. Configure TimeAdjust with the time zone information
   • Configured with –60 minutes
   • See below for more information

The GroupMonitorRules format should match the GroupNameFormat:

GroupNameFormat	GroupMonitorRules examples
Short	Application_Office_2007_Pro Application_*
Long	cn=Application_Office_2007_Pro,cn=Software Distribution Groups,dc=woodgrove,dc=com. cn=Application*,cn=Software Distribution

This should be enough to get ESD 2007 R2 working, with Delta discovery and kicking collection updates off.

How does ESD perform delta discovery?

ESD checks the whenChanged attribute of an object in AD on a Domain Controller.  This is set to the current UTC time either when a change is made to the object on the local domain controller, or when a change is replicated from a remote DC.  It will always contain the time in UTC format of when the DC we are querying sees a change in an object.  ESD queries AD for a list of computer and group objects which have the whenChanged timestamp greater than the last time that ESD ran.

An important observation is that an object must change in order for it to be discovered, and with computer accounts they must also have a resolvable IP (by default).  If no changes are made manually to the record, the system will be discovered with the following:

• A machine will change its password (by default) every 30 days (Ref4).
• LastLogon will change every 14 days, but is not replicated (Ref1, Ref2, Ref3).

The in built AD System Discovery will discovery machines with a resolvable IP address. If scavenging is set to 7 days, machines will be discovered for 7 days after they are taken off the network. This means there can be a discrepancy of 21 days (7 + 14) between the two discovery methods, i.e. if a machine is removed from the network today then ESD may have a record two weeks old for it, and AD Sys Disc will continue discovering it for another week. This should be taken into consideration when:

• Setting thresholds for system maintenance tasks
• Troubleshooting non clients.

What does TimeAdjust do?

The current build of ESD 2007 R2 (1.0.3512.23279) and below has an issue with the way it compares the time for delta discovery.  It appears that:

• whenChanged attribute from AD is return in universal time format.  this is GMT.
• LastRun timestamp in the regsitry is the system time.

This means we need to add an offset to ensure that the times match.  Currently, in the UK in British Summer Time, this is –60 minutes.

Note: Steve is working on this issue, and it should be resolved in the next release, due early 2010. In the mean time, the above workaround worked perfectly.

How does ESD discovery group membership changes?

When a computer is added to or removed from a group, the whenChanged timestamp is adjusted.  ESD queries for all AD groups which have changed since the last time it ran, then filters this by GroupMonitorRules.   It then appears to now build select statements to query AD for the systems it is interested in.  These are:

1. Systems changed since last runtime
2. All Systems in the groups that have been modified
3. All Systems in the collections built on groups which have been modified.  This is obtained fro mv_RA_System_ESDMemberOF.

This ensures that both systems added to and removed from groups are included, so the collection memberships are correct.  A fragment from the log shows:

Building Select Statement number 1. Select statement = SELECT cn, operatingsystem, whenchanged, adspath, useraccountcontrol, description, primarygroupid, memberof, ManagedBy FROM 'LDAP://DC=SCCMDEV,DC=local' WHERE objectcategory = 'computer' and (whenchanged > '20090929113400.0Z' or cn = 'SCCM-CONFIGMGR' or cn = 'DEPLOYEDSERVER3')

Conclusion

From my testing, this looks to be a veyr good solution for my customer.  I’ll blog more if I find any more groundbreaking information.

Enhanced System Discovery can do a lot more than I have talked about here.  Check out the features at Enhanced System Discovery

This post was contributed by Ian Dearing, a Dedicated Supportability Engineer with Microsoft Premier Field Engineering, UK.

Comments

• Anonymous
  June 10, 2010
  Ian - thanks very much for this blog. I have recently updated the latest build so timezone information is accounted for automatically without needing to use timeadjust. Now timeadjust can be used strictly for performance tweaking.