List of security changes in Systems Management Server 2.0 Service Pack 5 (816290)

MORE INFORMATION

Site-to-Site Communication Changes

SMS 2.0 SP5 site servers can sign all data sent between sites using private and public encryption key pairs. Data signing is not enforced by default after upgrading to SMS 2.0 SP5 sites; it must be enabled. Data signing makes sure that potentially malicious data from unauthorized sites is rejected. SMS does not encrypt site-to-site communications except under the following conditions:

• For packages that have encrypt values.
• When SMS account names and passwords are encrypted.

The sending site signs the data it sends by using its private key and inserts the signature in the instruction file for the data being sent. The receiving site then verifies the signature by using the sending site's public key. If the signature cannot be verified, the data is rejected.

Note SMS 2.0 SP4-and-earlier sites do not sign their data. SMS 2.0 SP4-and-earlier site servers cannot communicate with SMS 2.0 SP5 site servers when data signing is enabled.

You can change the requirements used by SMS 2.0 SP5 sites to communicate with other SMS 2.0 SP5 sites by using signed data. This is configured in the Site Properties dialog box on the Site Connection tab for each SMS 2.0 SP5 site server. If no SMS 2.0 sites report to another SMS 2.0 SP5 site, you can configure that site to prevent communication from SMS 2.0SP4 and earlier sites.

If you do not use the site-to-site key encryption communication requirements, monitor your hierarchy in the SMS Administrator console for rogue-site attachments. You can use the Preinst.exe tool to remove any rogue sites from your site database. In large hierarchies, enable unsigned data at only a small number of sites at a time to make the detection of rogue sites easier.

The keys are generated at each site during setup. The value of the private key is known only by the operating system. The keys change when the SMS Service account is changed for the site. The site automatically transfers the new public key to its parent site and all its direct child sites by using the old keys to securely transfer the new public key. The transfer occurs automatically under the following conditions:

• When you attach an SMS 2.0 SP5 child site to an SMS 2.0 SP5 parent site.
• When you upgrade an SMS 2.0 SP4 or earlier child site reporting to an SMS 2.0 SP5 parent site.
• When you install a new SMS 2.0 SP5 secondary site from an SMS 2.0 SP5 parent site or CD-ROM.
• When you make a change to the SMS Service account.

SMS 2.0 SP5 sites must have the public keys for all sites that they communicate with. Because of fan-out software distribution, this includes not only the immediate parent of each site, but also all of the higher-level parent sites, including the central site. It also includes all lower-level child sites, with either a direct or indirect connection. Every site requires all the public keys to be able to verify signatures for all sites they may receive data from, and to be able to send all public keys to parent sites.

Sites can exchange keys by:

• Receiving the keys from other sites when forwarding signed site-to-site communication to a receiving site.
• Manually transferring the keys when you execute the Preinst.exe tool with the appropriate switches and then transferring the generated files to other sites. There are several new command line options provided in Preinst.exe:
  • /KEYFORPARENT - Use this parameter to dump the site's public key into the file <SITECODE>.CT4 at the root of the SMS drive. Copy this file to the HMAN.BOX\inbox folder (not hman.box\pubkey) on the parent site.
  • /KEYFORCHILD - Use this parameter to dump the site's public key into the file <SITECODE>.CT5. Copy this file to the HMAN.BOX\inbox folder on the child site.
  • /CHILDKEYS - Use this parameter to dump the public keys of the current site and all child sites into the file <SITECODE>.CT6. Copy this file to the HMAN.BOX\inbox folder on the parent site.
  • /PARENTKEYS - Use this parameter to dump the public keys of the current site and all parent sites into the file <SITECODE>.CT7. Copy this file to the HMAN.BOX\inbox folder on the child site.
  • /UPDATEPERMS - Use this parameter to update permissions on the site-server inboxes

Windows Networking Logon Client Installation Changes

In SMS 2.0 Service Pack 4 (SP4) and earlier, you must give the SMS Service account or the SMS Site System Connection account domain administrator rights when you enable Windows Networking Logon Client Installation to create SMS logon points. Logon Server Manager (LSM) connects to the Admin$ share of a domain controller to create the logon point directory structure. Administrative permissions are required to connect to the Admin$ share of a computer. With these permissions, you must maintain additional high-level accounts that might present security risks. However, once logon points are created, low-level domain user permissions are sufficient to successfully access the logon point for inventory and for package-status reporting.

With SMS 2.0 Service Pack 5 (SP5), you may enable a security mode where Windows Networking Logon Client Installation no longer requires domain administrator permissions to maintain logon points. If this security mode is enabled, LSM will make the connection to the IPC$ share of domain controllers to maintain the SMSLogon directory structure. This share should let a successful connection occur under the context of a domain user logon.

To enable this security mode, follow these steps:

Note Administrator level credentials are required to perform these steps.

1. Install SMS 2.0 SP5.
2. Locate and click the following registry subkey:

   HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\domain\Security Mode Enabled

   Set the Security Mode Enabled value to 1 on the site server.
3. Create the SMSLogon folder and share on each domain controller. Set the share comment to "SMS NT logon service".
4. Set the following NTFS file system permissions on the SMSlogon folders:
   
   

   Account	F	M	RX	L	R	W	S
   SMS Service or Site System Connection account	X
   Users			X	X	X

   
   
   Note To simplify management of the NTFS permissions, create a domain group, grant permissions to this group, and then add SMS Service accounts or SMS Site System Connection accounts to this group.
   
   Note If the Security Mode Enabled flag is set to zero (not enabled), LSM will connect to the Admin$ share of the domain controllers, and the original LSM functionality will be available.

Limitations of introduced changes with security mode enabled

• You must have domain administration permissions to install Windows Networking Logon Discovery and other SMS site systems on a domain controller. This security mode applies only to Windows Networking Logon Client Installation.
• After you disable Windows Logon Installation, LSM does not automatically remove the SMSLOGON share.
• If you manually add a new logon point, and no SMS client exists on the domain controller, SMS tries to install a client and cannot. This scenario occurs because of the lack of rights. You must install the SMS client manually.
• You must manually add SMS logon scripts to the Net Logon share on the primary domain controller (PDC) or on the PDC emulator.
• You must manually edit user logon scripts.
  
  A supported hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Only apply it to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next SMS service pack that contains this hotfix.
  
  To resolve this problem immediately, contact Microsoft Product Support Services to obtain the hotfix. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, visit the following Microsoft Web site:

  http://support.microsoft.com/contactus/?ws=support

  Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

  816292 Windows Logon Installation requires domain administrator permissions to create logon points

Sample Scenarios

• Scenario 1: The administrator installs a NEW SMS 2.0 SP5 site server and enables Windows Networking Logon Client Installation in a single domain. Neither the SMS Service account nor the SMS Site System Connection account inherits domain administrative rights.
  • On the site server, the administrator sets theSecurity Mode Enabledvalueto 1 under the following registry subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\Domain_Name\Security Mode Enabled

  • The domain administrator then creates the SMSLOGON share with the "SMS NT logon service" comment on all domain controllers. The administrator grants Full Control permissions on the SMSLOGON folder to the SMS Service account and grants Read, List, and Execute rights for Everyone. For shared logon points, the domain admin creates a domain global group, adds each of the SMS site's SMS Service accounts or Site System Connection accounts to the group, and grants rights on the SMSLOGON folder to the group.
  • The administrator then enables Windows Networking Logon Client Installation in the SMS Administrator console. An SMS Site System Connection account has not been specified.
  • LSM first connects to the PDC emulator and enumerates all domain controllers in the domain.
  • Next, LSM checks for the existence of the SMSLOGON share with the correct comment on each domain controller in the domain. If the SMSLOGON share with the correct comment is found, LSM creates the Windows Networking Logon Client Installation directory structure and copies the appropriate files from the site server. A status message will be generated if LSM cannot find the share or if the comment is set incorrectly.
  • The administrator must copy the following files into the Netlogon share on any domain controller (In a Microsoft Windows NT 4.0 domain, these files must be copied to the Netlogon share of the PDC):
    • Smsls.bat
    • SlwNt16.exe
    • SlwNT32.exe
    • SlwNt32a.exe
    • Smsboot1.exe
    • SNboot.exe
    Because of the nature of directory service, these files are replicated to all domain controllers.
  • Finally, the administrator modifies the user logon scripts to execute Smsls.bat.
• Scenario 2: The administrator upgrades an existing SMS 2.0 site to SMS 2.0 SP5 with Windows Networking Logon Client Installation already enabled. During this process the SMS Service accounts rights are limited to domain user rights. The process of enabling Windows Networking Logon Client Installation will be much the same as described in the first sample scenario, with the exception that Windows Networking Logon Client Installation is already enabled and therefore the SMS logon points already exist.
  • The domain administrator must grant the following permissions on the SMSlogon folder to the SMS Service account or Site System Connection account:

    Folder	F	M	RX	L	R	W	S
    \SMSLOGON	X
    \SMSLOGON\SITESCFG	X

    To simplify management of the NTFS permissions, a domain group should be created, permissions granted to this group and the SMS Service account or SMS Site System Connection accounts added to this group.
  • On the site server, the administrator sets the Security Mode Enabled value to 1 under the following registry subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\Domain_Name\Security Mode Enabled

  • The administrator can now revoke the domain administrator rights from the SMS Service account.
• Scenario 3: After running SMS 2.0 SP5 setup with a domain user SMS Service account, the administrator now decides to enable Windows Logon Discovery. Therefore, the SMS Service account is manually added to the domain admins group.
  • The administrator adds the SMS Service account to the Domain Administrators group.
  • On the site server, the administrator sets the Security Mode Enabled value to 0 under the following registry subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\Domain_Name\Security Mode Enabled

    LSM will continue to maintain the SMS logon points.
  • Windows Logon Discovery is enabled by the administrator and the Logon Discovery Service is installed on all domain controllers.
  Note The difference between this scenario and the first and second sample scenarios is that LSM, by using a Domain Administrator account, will be able to remove SMS logon points when Windows Logon Discovery and Installation are disabled.
• Scenario 4: The administrator enables Windows Logon Discovery and Installation while a domain user account is specified for the SMS Service account and the "Security Mode Enabled" key is set in the registry.
  • On the site server, the administrator sets the Security Mode Enabled value to 1 under the following registry subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\Domain_Name\Security Mode Enabled

  • The administrator then creates the SMSLOGON share with the comment "SMS NT logon service" on all domain controllers.
  • Next the administrator enables Windows Logon Discovery and Windows Networking Logon Client Installation in the SMS Administrator console. An SMS Site System Connection account has not been specified.
  • LSM first connects to the PDC emulator and enumerates all domain controllers in the domain.
  • LSM checks for the existence of the SMSLOGON share with the correct comment on each domain controller in the domain. If the SMSLOGON share with the correct comment is found, LSM creates the Windows Networking Logon Client Installation directory structure and copies the appropriate files from the site server. A status message is generated if LSM can't find the share or the comment is set incorrectly.
  • LSM tries to install the Logon Discovery Agent (LDA). LSM first connects to the PDC emulator and tries to access the ADMIN$ share. Because of incorrect rights, LSM does not successfully access the ADMIN$ share and the following status message is generated: %11SMS NT Logon Server Manager failed to complete all of the configuration tasks on domain controller "%1" for domain "%2". These tasks include:%n%n1. Assigning the SMS logon point role to the site system "\\%1".%n2. Modifying the user logon scripts, if instructed to do so by the configuration of the Windows Networking Logon Discovery and Client Installation methods.%n3. Creating and updating the "SMSLOGON" share and the directories and files associated with it.%n4. Installing the SMS_NT_LOGON_DISCOVERY_AGENT service.%0
  • The administrator copies the following files to the Netlogon share on any domain controller in the domain. In a Windows NT 4.0 domain these files must be copied to the Netlogon share of the PDC.
    1. Smsls.bat
    2. SlwNt16.exe
    3. SlwNT32.exe
    4. SlwNt32a.exe
    5. Smsboot1.exe
    6. SNboot.exe
    Because of the nature of directory service, these files are replicated to all domain controllers.
  • As a last step, the administrator must modify the user logon scripts to execute SMSLS.BAT.
• Scenario 5: The administrator enables Windows Networking Logon Client Installation for multiple domains using different LSM options on a per domain basis. An administrator can manage multiple domains in an SMS site. When there are two domains, A and B, do the following.
  • In both domains, configure the SMS 2.0 SP5 site server services to run under a domain user account.
  • Specify two SMS Site System Connection accounts in the SMS Administrator console. SMS Site System Connection account A is member of the domain administrators group in site A. It has no rights in domain B. SMS Site System Connection account B has domain user rights in both domains A and B.
  • For domain A, the Security Mode Enabled flag in the registry is not set. Therefore, LSM manages SMS logon points just as it did in previous service packs.
  • For domain B, follow the steps in scenario 2, and the SMS logon points will be managed under the context of Site System Connection account B.
• Scenario 6: The SMS Administrator creates SMSLOGON shares on only half of the existing domain controllers, while the "Security Mode Enabled" flag is set and the SMS Service account is a domain user account.
  • On the site server, the administrator sets the Security Mode Enabled value to 1 under the following registry subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\Domain_Name\Security Mode Enabled

  • The administrator then creates the SMSLOGON share with the comment "SMS NT logon service" on half of the existing domain controllers. An SMSLOGON share was created on the PDC emulator.
  • The administrator enables Windows Networking Logon Client Installation in the SMS Administrator console. An SMS Site System Connection account has not been specified.
  • LSM first connects to the PDC emulator and enumerates all domain controllers in the domain.
  • LSM checks for the existence of the SMSLOGON share with the correct comment on each domain controller in the domain. If the SMSLOGON share with the correct comment is found, LSM creates the Windows Networking Logon Client Installation directory structure and copies the appropriate files from the site server. The following status message is generated if LSM cannot find the share or the comment is set incorrectly: // MessageId: SRVMSG_NTLGMNGR_WARNING_INSTALLSERVER
    //
    // MessageText:
    //
    // %11SMS NT Logon Server Manager failed to complete all of the configuration tasks on domain controller "%1" for domain "%2". These tasks include:%n%n1. Assigning the SMS Logon Point role to the site system "\\%1".%n2. Modifying the user logon scripts, if instructed to do so by the configuration of the Windows Networking Logon Discovery and Client Installation methods.%n3. Creating and updating the "SMSLOGON" share and the directories and files associated with it.%n4. Installing the SMS_NT_LOGON_DISCOVERY_AGENT service.%0
    //
    #define SRVMSG_NTLGMNGR_WARNING_INSTALLSERVER ((DWORD)0x8000058AL) LSM stops generating these status messages after 100 times and is tracked in the following registry key: Hkey_Local_Machine\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\<domain>\STATUS MESSAGE COUNT. This value must be set on a per-domain basis under the LSM registry key and can reach a maximum decimal value of 100. Optionally, the administrator has the choice to suppress or limit the number of these status messages. SMS 2.0 SP5 will allow the administrator to set the following registry key on a per-domain basis: Hkey_Local_Machine\Software\Microsoft\SMS\Components\SMS_NT_LOGON_SERVER_MANAGER\Domains\<domain>\Disable Status Messages
    • Example 1: The administrator creates the SMSLOGON share on five out of ten domain controllers. As LSM tries to access the SMSLOGON shares on all domain controllers, the value for STATUS MESSAGE COUNT will increases by 1 for each unsuccessful attempt to update an SMS logon point. Each of these messages is available in the SMS Administrator console. After the value reaches 100 no more status messages are reported.
    • Example 2: The administrator creates the SMSLOGON share on five out of ten domain controllers and chooses to suppress the LSM status messages. To suppress the status messages, the registry value Status Message Count is set to 100. No status message will be created.
    • Example 3: The administrator creates the SMSLOGON share on five out of ten domain controllers and resets the status message count. As LSM tries to access the SMSLOGON shares on all domain controllers, the value for STATUS MESSAGE COUNT will increase by 1 for each unsuccessful attempt to update an SMS logon point. Each of these messages is available in the SMS Administrator console. After the value reaches 100, the administrator manually resets the value to 0. LSM continues to generate status messages.
    • Example 4: The administrator creates the SMSLOGON share on five out of ten domain controllers, but prefers to have the first five warning messages reported. To receive only the first five status messages reported, the administrator sets the value Status Message Count to 95. LSM increases this value by 1 for each unsuccessful attempt. After the value reaches 100, no status message will be created.
  • The administrator copies the Smsman.exe file into the Netlogon share on any domain controller. In a Windows NT 4.0 domain this file must be copied to the Netlogon share of the PDC. Because of the nature of directory service, these files are replicated to all domain controllers. Smsman.exe can locate an SMS logon point even if Smsman.exe is run from a domain controller that does not have an SMS logon share with its supporting directory structure.
  • As a last step, the administrator must modify the user logon scripts to execute Smsman.exe.
• Scenario 7: The administrator decides to disable Windows Networking Logon Client Installation while using an SMS Service account limited to domain user rights.
  • As a first step, the administrator removes SMSLS.BAT from the user logon scripts.
  • The administrator must remove the following files from the Netlogon share on any domain controller. In an Windows NT 4.0 domain these files must be removed from the Netlogon share of the PDC:
    1. Smsls.bat
    2. SlwNt16.exe
    3. SlwNT32.exe
    4. SlwNt32a.exe
    5. Smsboot1.exe
    6. SNboot.exe
    Because of the nature of directory service, these files will be removed from all domain controllers.
  • The administrator disables Windows Networking Logon Client Installation in the SMS Administrator console. LSM deletes the complete directory structure under the SMSLOGON folder.
  • Note When there are shared logon points, only the <site code> directory under the SITES directory, the <site code>_CFG.LCF file from the SITESCFG directory and the site code of the following files are removed:
    1. CopyLog.tcf
    2. SMSMAN.tcf
    3. WIN16.tcf
    4. WIN95.tcf
    5. WINNT.tcf
    6. MasterCFG.MCF
  • As a last step, the domain administrator manually removes all SMSLOGON shares from all domain controllers.
• Scenario 8: The administrator decides to upgrade an SMS 2.0 SP5 site server with Windows Networking Logon Client Installation enabled and an SMS Service account with domain user rights to SMS 2003.
  For the upgrade from SMS 2.0 to SMS 2003, you must disable Windows Networking Logon Client Installation. Therefore, this scenario will be the same as sample scenario 7, followed by the upgrade to SMS 2003.

Windows Server 2003 Support Improvements

SMS 2.0 SP5 provides support for the Microsoft Windows Server 2003 operating system.

The table below lists the features of SMS 2.0 SP5 that are available to Windows Server 2003 SMS clients.

Feature	Level of Support	Description
Client Installation	Supported	None
Hardware Inventory	Supported	None
Software Inventory	Supported	None
Network Monitor	Supported	None
Software Distribution	Supported	None
Remote Tools	Supported	None
Software Metering	Partially supported	SMS cannot perform software metering of 16-bit applications on SMS clients running Windows Server 2003.

Changes introduced with SP5:

• If the SMS 2.0 Provider is not installed on the SMS site server, and if the computer that the Provider is installed on is running Microsoft Windows Server 2003, no data will appear for any nodes in the SMS Administrator console. For example, no collections will appear when you click the Collections node. This occurs because the SMS Provider is not handling the fully qualified domain name that the Windows Management Instrumentation (WMI) returns in Windows Server 2003. This problem is resolved in SMS 2.0 SP5.
• In SMS 2.0 SP4 and earlier, Microsoft Windows Server 2003 is not listed as an available operating system on the Requirements tab in the Program Properties dialog box. In SMS 2.0 SP5, Windows Server 2003 is added as a supported operating system. Selecting All x86 Windows Server 2003 Clients will limit the program to run on Windows Server 2003 systems.
• After you upgrade from Windows 2000 Server to Windows Server 2003, all installed components of the SMS 2.0 client enter a "repair pending" state. The root cause of this problem is that the HKEY_LOCAL_MACHINE\Software\Microsoft\NAL\Client key loses its permissions, and therefore CCIM32 cannot access the Provider information in the registry. In SMS 2.0 SP5 CCIM32 will re-evaluate and reset the registry permissions recursively.
• In Windows Server 2003, domain user and user group names with more than 64 characters are supported. Before SP5, SMS Data Discovery Manager (DDM) failed to process DDRs returned from Windows NT User Discovery and Windows NT User Group Discovery that contain names longer than 64 characters. In SMS 2.0 SP5, DDM no longer uses a hard coded limit of 64 characters. DDM now calculates the width of domain user and user group names.
• In SMS 2.0 SP4 and earlier the SMS User Wizard does not list users of the local domain in the Browse window if the local domain is running in Windows Server 2003 native mode. This issue is corrected with SMS 2.0 SP5. The drop-down list will now populate with the users and groups of the Windows Server 2003 local domain.
• SMS 2.0 SP5 enables the installation of the SMS Software Metering client agent on Windows Server 2003 computers. In SMS 2.0 SP4 and earlier versions, Windows Server 2003 computers are recognized as Terminal Servers, and this prevents the installation of the SMS Software Metering client agent. The SMS Software Metering client agent cannot run on computers running Windows NT 4.0 Server or Windows 2000 Server with Terminal Services enabled. The following scenarios are permitted:
  • The SMS Software Metering client agent installs on computers running Windows NT 4.0 Server or Windows 2000 Server with Terminal Services disabled.
  • The SMS Software Metering client agent does not install on systems running Windows NT 4.0 Server and Windows 2000 Server with Terminal Services enabled.
  • The SMS Software Metering client agent installs on computers running Windows Server 2003.

Slow Link Detection

In SMS 2.0 SP4 and earlier, the SMS client's slow link detection for distribution points was not reliable for software distribution. SP5 implements the following solution:

A new internal SMS function, TestConnectionSpeed2, has been implemented that copies a file over a link and tries to calculate its speed. This will be the primary detection method when the test file is present, otherwise current client behavior is maintained. This method will require a registry modification and restart of the SMS Executive service. When the SMS Distribution Manager updates a package it will either remove the test file or put the test file on the Distribution Point (DP) depending on the current registry setting.

List of Changes to Slow Link Detection:

• The network link speed test file, Netspeed.dat, is copied to the <install drive>\SMS\bin\<platform> directory on the SMS site server during installation of SP5.
• The Netspeed.dat file's standard uncompressed size is 3,400 bytes. This file size permits the SMS client to more accurately detect the available bandwidth on slow links with a network capacity up to 512 kilobits per second (Kbps). On faster links this file size may produce volatile results. The implementation of this file is not dependant on any specific file size. File sizes from 1 byte up to 4 GB are supported. An administrator can replace Netspeed.dat with a larger or smaller file to "tune" the link speed test to the environment. Generally, results will be more stable when the file size is increased.
• 
  For example, if you are primarily concerned about WAN users on 512-Kbps links, you may want to increase the size of the test file to 50 KB. However if you have clients connected through very slow links the current size or smaller of Netspeed.dat may be sufficient.
• The results of the new test method should never exceed the maximum link speed of the connection but may be inconsistent because of temporary network conditions or other segment traffic and the like. The Smsapm32.log file will state the size of the test file, its transfer time, and the link speed calculation.
• The current Slow Network Threshold Speed setting found in the Site Control file and under the following registry key:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Sites\System\XXX\Client Components\Software Distribution

  is also used in the new procedure. Its default value remains at 40000 bps.
• When you upgrade to SMS 2.0 SP5, the following registry keys are created on the site server under

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_DISTRIBUTION_MANAGER

  :
  • Slow Link Support Enabled=dword:00000000
  • Slow Link Test File Enabled=dword:00000000
• To enable automated support for the new slow link test, set both Slow Link Support Enabled and Slow Link Test File Enabled to 1. This directs Distribution Manager to copy the Netspeed.dat file from the drive\SMS\bin\platform directory to the root SMS package share or directory on the distribution point. The SMS package share or directory can be \\server\smspkgX$, \\server\customshare or \\server\volume\smspkg, depending on the network operating system. To force SMS Distribution Manager to delete the Netspeed.dat file from the distribution point, set the Slow Link Test File Enabled registry key to 0 on the SMS site server. With this setting, SMS Distribution Manager will update the Netspeed.dat file, should it change.
• To disable automated slow link support, set the Slow Link Support Enabled registry key to 0. If automated support was previously enabled this will not delete any existing Netspeed.dat files. This setting permits the administrator to manually copy and maintain the file on distribution points.
• SMS Distribution Manager performs its slow link support tasks whenever a distribution point is updated. During this slow link support task SMS Distribution Manager will update the Netspeed.dat file.
• The Available Programs Manager (APM) application searches for the Netspeed.dat file on the distribution point beginning with the program's package directory. APM then continues to search the parent folders until either the share or volume is reached. This permits the administrator the flexibility to specify how the link test should be performed.
  For example, by copying the Netspeed.dat file to the share, the link test will be performed the same for all packages on that distribution point. If the Netspeed.dat file is only copied to the package directory (and this can be done by manually placing Netspeed.dat in the package's source directory), the link test can be controlled on a per-package basis. This permits the administrator to specify which packages should or should not be downloaded over a slow link. It is also possible to use a combination of the two where some package directories will have the file and their own link test control where other package directories will rely upon the test control specified for all packages. This level of control can also be used with automated support enabled as the Netspeed.dat file is only maintained at the distribution point level.