Remote Processes and Machine Control of Windows NT-Based Systems (2000/XP)

Environment: VC++ 6.0, 7.0, 7.1; Windows 2000/XP, Platform SDK, MFC


  • Tested on Windows 2000/XP

  • Windows NT 4 and its previous versions not supported

  • Should work on Windows 2003 Server without any trouble, but not yet tested

  • Will compile with VC++ 6.0 only when used with the latest Platform SDK; else, there may be a compilation error of not having the latest shellapi.h

Fig. 1 Client application running. Various context menu(s) shown.


There are times, as a Windows network administrator, you would like to control certain aspects of machines sitting remotely, without having to install and trigger an application on the remote machine that will communicate with the administrator’s machine.

How to Use the Client Application for Control

  • Ctrl + A (or File -> Add machine): Add a machine whose control is required and processes to be monitored (see Fig. 2).

    Fig. 2 Adding a machine

    In case of an error, an information balloon will be shown in the system tray, as shown in Fig. 3.

    Fig. 3 Information balloon

  • Context menu(s) on for a connected machine: Refer to Fig. 1
    1. Refresh the process list.
    2. Execute a process on the connected machine.
    3. Delete the machine from being monitored.
    4. Shutdown: Halt/reboot the machine or cancel the halt/reboot request.

  • Context menu on any process on a machine Refer to Fig. 1
    1. End process

  • Timer Settings (or Settings -> Timers): See Fig. 4
    1. Process refresh: Wait for “x” seconds before querying all connected machines for their processes list. This is apart from what time will be taken to query the processes on remote machines.
    2. Shut down delay: Wait for “x” seconds before executing a shutdown or reboot command on the remote machine.

    Fig. 4 Timer refresh rate

  • File -> Save /Save As

    Save the connected machine(s) information to the requested directory. All machine monitoring can again be loaded while using the File -> Open command, without adding all machines individually.

Security Note: Currently, the administrator passwords are just serialized to a file without encryption. Hence, one can see the passwords by just opening the file in a normal text editor.

The How of Controlling Machines Remotely

  • There is one client application that displays all the processes of the requested remote machines with a pre-determined refresh rate.

  • There is one server application (one per remote machine), which has to be triggered on the remote machine automatically (without any user intervention), when a request for monitoring and control is made to it. This server application will send periodic processes updates to the client. For example, if there are five remote machines being monitored, there are five remote server applications, which keep sending periodic process updates and one client application from where all remote machines are being monitored.

  • The client can also request certain other tasks to the server application, such as triggering a new process or killing an existing process on the remote machine. If required, requests to reboot or shut down the remote machine also can be made.

Basic Implementation Scheme

Fig. 5 Client application with the server executable embedded in its resources

The client application holds the server application (executable) in its resource section, like any other resource, such as bitmaps, icons, menus, and so forth (refer Fig. 5).

  • When the client asks to connect and monitor any remote machine, it has to supply its IP address and Administrator logon’s password.

  • The client application makes an attempt to connect to the ADMIN and IPC resources using the Windows API WNetAddConnection2(). (CRemoteAdministrator::EstablishAllConnections() in the accompanying project).

  • After connecting to the remote machine through the ADMIN and IPC connections, the client application loads the server executable from its resource section. The client application copies the server executable to the remote machine’s System32 directory. (CRemoteAdministrator:: CopyServiceExeToRemoteMachine() in the accompanying project)

See Fig. 6 for the remote copying scheme:

Fig. 6 Server executable copying scheme

The client application gets the HANDLE to the Service Manager of the remote machine, as an IPC connection that has been established above. The client application then starts the server executable copied in the remote machine’s System32 directory as a Service. This all is independent, done automatically, and is unknown to the remote machine’s user.

  • Once the server application gets triggered as a Service, it starts sending the list of processes to the client application through Named Pipes.

  • Each server application has a minimum of four threads that service a single client:
    1. Sending the list of processes to the client applicaton (Thread function RemoteAdminProcessInfoThread())
    2. To process a request from the client to start a process on the remote machine (Thread function RemoteAdminExecuteProcessThread())
    3. To process a request from the client to end a process on the remote machine (Thread function RemoteAdminKillProcessThread())
    4. To process a request from the client to reboot or shutdown the remote machine (Thread function RemoteAdminSysShutdownThread())

Implemenation Details of the Client Application

The client is a standard SDI application based on MFC’s document/view architechture. The important classes in the client application are:

  • CMachineInfo: This class holds the HANDLES to four named pipes with which a remote machine connection has been established for requesting different tasks (remote process read, start, kill, and machine shutdown/reboot). This class also holds a list of current processes on the remote machine. It also contains strings for password, IP, and logon type (which has to be Administrator only). CMachineInfo is derived from MFC’s Cobject so that it can be serialized.
  • CRemoteAdministrator: This class handles all the network communication based on named pipes with different remote machines. This class holds a list of CMachineInfo objects. This CMachineInfo list can be serialized to a file and loaded later.
  • CRemoteAdminDoc: This is the MFC’s CDocument derived that which holds all data regarding the application. This class holds the only object of CRemoteAdministrator.

Implemenation Details of the SERVER Application

  • Once the server application has been started as a service on the remote machine, the client application makes a connection to the server through four named pipes. These four HANDLES of named pipes service the client requests through four threads (RemoteAdminProcessInfoThread(), RemoteAdminExecuteProcessThread(), RemoteAdminKillProcessThread(), and RemoteAdminSysShutdownThread()).
  • There is another thread that is constantly updating the processes list (UpdateProcessInfoList()).
  • When there is a new named pipe connection, the counter lServicePipeInstanceCount is incremented. Similalry, when a named pipe is disconnected, it is decremented. When there are no named pipes (lServicePipeInstanceCount == 0), the server application is stopped and deleted from the remote machine.



Download demo project – 504 Kb

Download executable – 671 Kb

More by Author

Must Read