Michael Niehaus at myITForum.com

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).

Have you moved off of Windows 2000 yet?

For those of you still running Windows 2000 (any version), you may want to read the following support reminder - mainstream support will not be available for much longer.  For more information, see http://support.microsoft.com/lifecycle.

Windows 2000 Moves to Extended Support Phase July 1, 2005

Consistent with the Microsoft Support Lifecycle policy, on June 30th, 2005 Windows 2000 will transition from its Mainstream Support to its Extended Support phase.

Mainstream Support will end on June 30th, 2005 for the following  Windows 2000 products:

·        Windows 2000 Advanced Server

·        Windows 2000 Data Center Server

·        Windows 2000 Professional

·        Windows 2000 Server

SMS advanced client - not all return codes are treated the same

A recent e-mail thread on the MSSMS mailing list talked about why the SMS 2003 advanced client seems to behave differently sometimes, retrying advertisements where the program previously failed with certain return codes, i.e. return code 4.  This is directly related to the policy settings retrieved from the management point, documented on MSDN via http://msdn.microsoft.com/library/default.asp?url=/library/en-us/smssdk03/hh/sms/smsref30_0121.asp and stored in WMI.  You can find these values in WMI by looking at the CCM_SoftwareDistributionClientConfig instance located in the root\ccm\policy\machine\actualconfig namespace.

In this CCM_SoftwareDistributionClientConfig instance, there are three settings related to the automatic retry capability built into the advanced client:

• ExecutionFailureRetryErrorCodes - a list of return codes that should result in a retry.
• ExecutionFailureRetryCount - the maximum number of retries.
• ExecutionFailureRetryInterval - the number of seconds between retries.

By default, the list of retryable return codes is:

4,5,8,13,14,39,51,53,54,55,59,64,65,67,70,71,85,86,87,112,128,170,267,999,1003,1203,1219,1220,1222,1231,1232,1238,1265,1311,1323,1326,1330,1618,1622,2250

The default retry count is 1008; the default retry interval is 600 seconds (10 minutes).  So what does that mean?  Well, if the program run by the advertisement sets a return code in the list above, SMS will automatically try to run the advertisement again 10 minutes later; it will keep trying for many hours.  So, it would be best to avoid generating any of these return codes if you don't want this retry to occur, especially if this return code is consistently returned: each execution generates status messages, network traffic, etc., best avoided if not needed or desired.

The CCM_SoftwareDistributionClientConfig instance also contains a list of return codes that indicate the need for a reboot.  This property, RebootReturnCodes, contains these values by default:

1604,1641,3010,3011

So if a program returns any of these return codes, the advertisement will be considered successful, with the SMS client realizing that a restart is needed.

A third property on this class, LogoffReturnCodes, would enable SMS to automatically log off the current user based on the return code from the advertisement, but this property is not populated by default.

The lists of values in these properties, as reported in policy retrieved from the SMS management point, are obtained from the SMS site control file, although there is no supported way to modify these lists for all clients.  Contact Microsoft Support if you have any questions about this.