DOCUMENT:Q173120 31-JUL-2001 [sms] TITLE :SMS: Windows NT Remote Control May Fail in Routed Environment PRODUCT :Microsoft Systems Management Server PROD/VER:winnt:1.2 OPER/SYS: KEYWORDS:kbtshoot smsremtshoot kbRemoteProg ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Systems Management Server version 1.2 ------------------------------------------------------------------------------- IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe. SYMPTOMS ======== When using Systems Management Server to remote control a Windows NT client computer in a routed environment, the remote control session may fail if the router(s) drop too many of the packets. Therefore, the stability of a remote control session is directly related to the stability and performance of the network environment in which it is being used. MORE INFORMATION ================ Systems Management Server remote control uses IP Sockets as the default transport method for Windows NT client computers. More specifically, the remote control session relies on a stream of UDP frames (packets) between the client and administrator console. Because UDP frames are not guaranteed delivery (which is inherent to the TCP/IP protocol suite), a busy router may drop UDP frames in favor of higher priority traffic such as TCP frames. You can use Network Monitor to see ICMP frames from the router indicating that the router is too busy to process the packet (for example, ICMP Source Quench messages or ICMP Redirect messages and so forth). If the router is a black hole router, (no notification that it is dropping packets) you will not see any ICMP messages returned. If too many frames in a remote control session are lost, the session will terminate without warning. WORKAROUND ========== Use a NetBIOS session for remote control rather than using IP sockets to work around this problem. Even though it is much more reliable, it may prove to be slower in some environments. To test a remote control session over a NetBIOS session or Lana such as NetBT, (NetBIOS encapsulated in TCP/IP) perform the following steps: I. View the Lana numbers defined on the client computer running Windows NT. 1. Click Start, point to Settings, and then click Control Panel. 2. Double-click the Network icon. 3. On the Services tab, select NetBIOS Interface, and then click Properties. From the list of defined Lana numbers, you may see something like "NetBT -> El90x -> El90x1" defined for Lana 0. This can be interpreted as NetBIOS encapsulated in TCP/IP over the Ethernet adapter. This is normally the most desirable choice for a remote control session. As long as a name resolution method (such as WINS) is being used in the network environment, this is a reliable choice. NetBT = NetBIOS encapsulated in TCP/IP NwlnkNB = NetBIOS encapsulated in IPX NBF = NetBIOS encapsulated in NetBEUI For systems that use a dial-up connection as well, you may see other Lana numbers similar to "NetBT -> NdisWan4". WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. II. Configure the Remote Control agent to listen on a specific Lana number. 1. Start Registry Editor (Regedt32.exe) and find the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client Services \Remote Control\Parameters 2. Change the "CommandLine" value from "-IP" (IP Sockets) to "-L0" (Lana 0). To permanently override the site-wide setting, set the "Override Site CommandLine" value under the Remote Control key to a value of "1" as well. This ensures that the CommandLine value is not overwritten if the Systems Management Server client components are ever upgraded. If NetBT proves to be a reliable and functional alternative to IP sockets in your environment, the site-wide setting for Windows NT Server Remote Control can be changed via the Systems Management Server Administrator utility. To change the setting, start the Administrator utility and use the following steps: 1. In the Site Properties window, click Clients, and then select Proposed Properties. 2. Click Options. 3. Click the "NetBIOS Lana Number" option button and enter the Lana number you want. This will most often be a zero. 4. Click OK until you have closed the Site Properties window. After the site property changes have taken effect, each Systems Management Server client running Windows NT will need to run Upgrade.bat from the SMS_SHR share of a Systems Management Server logon server to be configured to use the new remote control setting. STATUS ====== Microsoft has confirmed this to be a problem in Systems Management Server version 1.2. This problem was corrected in the latest Microsoft Systems Management Server 1.2 U.S. Service Pack. For information on obtaining the service pack, query on the following word in the Microsoft Knowledge Base (without the spaces): S E R V P A C K Additional query words: prodsms ====================================================================== Keywords : kbtshoot smsremtshoot kbRemoteProg Technology : kbSMSSearch kbSMS120 Version : winnt:1.2 Issue type : kbbug ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2001.