Remote Tools Session Process Flow

[Previous] [Next]

Now that we have examined how to configure and run a Remote Tools session on an SMS client, let's take some time to explore the process of initiating a Remote Tools session. An understanding of this process will enable you to analyze problem situations when you are attempting to remotely control a client computer.

When the SMS administrator starts a Remote Tools session, a specific sequence of events occurs. This flow of events will allow the communication between the SMS Administrator Console computer and the remote client computer. This section will guide you through the steps that take place in the SMS Administrator Console computer and on the primary site server when a Remote Tools session is initiated with a client computer. It will also give you a fair indication of the network traffic that is generated.

As you know, a Remote Tools session is initiated by selecting a client in the Collection folder in the SMS Administrator Console. So really the first step that occurs is that SMS determines whether the SMS administrator has permission to start a Remote Tools session through that collection. This permission is different from the Permitted Viewers list that can be configured as part of the Remote Tools settings; it involves object security set on the collection itself through SMS security. This type of security allows you to create customized SMS Administrator Consoles and delegate specific tasks, such as remote troubleshooting, to specific individuals without having to give them access to everything else. (This aspect of security is discussed in detail in Chapter 16.)

Now when the SMS administrator begins a Remote Tools session, Remote.exe makes a connection via the SMS Provider to the SMS site database using the resource ID of the client in question. The SMS Provider returns the IP and/or IPX address and NetBIOS name of the client. This information is passed to LDWMNT.dll, which attempts to connect to the client. LDWMNT.dll resolves the NetBIOS name through WINS or DNS, for example, and attempts a connection over each protocol (connection point).

NOTE

---

SMS 2.0 now establishes a TCP session with the client by default, instead of the User Datagram Protocol (UDP) sessions used by earlier versions of SMS. This guaranteed connection ensures that communications exist between the SMS Administrator Console and the client and should result in fewer lost session events.

In the meantime, the client agent is "listening," using the protocol to which Remote Tools was bound (by default, the primary protocol, or LANA 0). When a connection is attempted using this protocol, the client agent responds, and returns the Permitted Viewers list to Remote.exe. The list is evaluated to determine whether it includes the logged-on SMS administrator. If not, the logged-on SMS administrator is prompted for the name of a valid user. If the administrator is included, the client determines which remote tools are enabled, and Remote.exe displays the Remote Tools window to the SMS administrator with the appropriate tools enabled or disabled.

The SMS administrator initiates a remote tool such as Remote Chat or Remote Control. If user permission is required, the client displays a Remote Control Agent dialog box, as shown in Figure 10-17, asking the user for permission.

If user permission is granted, the appropriate tool is launched. If permission is denied, a message box similar to the one shown in Figure 10-24 is displayed on the SMS administrator's desktop.

Figure 10-24. Message box notifying the SMS administrator that user permission has been denied.

As you can see, a fair amount of network traffic is involved in establishing the Remote Tools session. In addition, the Remote Tools session itself can generate a rather significant amount of CPU usage on the client. For example, on a computer running Windows NT 4.0 with compression set to high and screen acceleration enabled, it is not uncommon to experience a CPU usage increase of between 90 and 100 percent. Setting compression to low can bring that down to the 50 to 65 percent range, but changing the compression setting may also generate additional network bandwidth usage.