SMS 2003 AD System Discovery - tuning suggestions
A discussion thread on the MSSMS discussion list recently talked about ways to improve the performance of AD System Discovery in SMS 2003. Based on this discussion, I would make these recommendations:
1. Each time you see an entry in the ADSYSDIS.LOG file that says “Unable to resolve” for a machine, a three-second delay will be added to the discovery process. This is because Windows has tried to resolve the name via DNS and WINS with no luck, so it then tries a broadcast and waits three seconds for a reply. This delay can be eliminated if you tell Windows not to do the broadcast. To do this, modify the NBT node type of the SMS server from an H-node to a P-node. See http://support.microsoft.com/default.aspx?scid=kb;en-us;160177 for more information. This is the registry change (which requires a reboot to activate):
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters]
“NodeType”=dword:00000002
As an example, if you have an Active Directory with 10,000 computers and 10% cannot be resolved, this will add 50 minutes (1,000 x 3 / 60) to the total AD System Discovery cycle time. Want to know how much time is being added in your specific case? Look at the ADSYSDIS.LOG file and estimate the number of “Unresolved“ messages in each batch of 100 machines (where the log shows a count message every 100 computers). If it looks like you have 10 messages per every hundred machines, 10% are unresolvable. (Want an exact number? Count all the messages.) An alternative approach is to clean these “garbage” machines out of AD, but that’s usually a different team’s problem so the SMS admin is forced to work around this.
2. Notice the long delay after the last batch of machines is processed, where no additional messages are logged. On a larger environment (10,000+ machines) this delay can easily be an hours. What happens during this time? This is mostly a result of AD System Discovery expanding all groups that it found while processing machines; it then asks AD to expand the membership of those groups looking for any other machines (possibly from other domains in the same forest) that it might have missed. In most environments, it’s not going to find any. Before SMS 2003 SP1, there was no way to disable that checking. With SP1, there is a new checkbox. Select the LDAP path that you added on the “Active Directory System Discovery” property page and bring up the properties of that LDAP path. Uncheck the “Include groups” checkbox.
Your results may vary, but typically these two changes can cut 30-60% of the time required to perform an AD System Discovery cycle.
It is also important that your AD sites are defined properly so that the SMS server always talks to the closest domain controller (across the LAN, not across the WAN). If this isn't possible, you can modify the LDAP path to specify which DC to use, but given all the other dependencies on AD sites, it would be better to do it the “right” way. (Check the ADSYSDIS.LOG to see which domain controller was used.) As a corollary to this, you may want to avoid setting up primary sites at locations that don't have DCs unless you do not plan to run discovery (only needed if you are targeting advertisements based on AD groups or OUs).