Remote processes and machine control of Windows NT based systems (2000/XP)

Download demo project - 90.4 Kb

Fig. 1 Client application running with various context menu(s)

Introduction

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 which 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 (refer 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 fig. 1
- Refresh the process list.
- Execute a process on the connected machine.
- Delete the machine from being monitored.
- Shutdown: Halt/reboot the machine or cancel the halt/reboot request.
Context menu on any process on a machine: Refer fig. 1
- End process
Timer Settings (or Settings->Timers): Refer fig. 4
- 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.
- 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 5 remote machines being monitored then there are 5 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 like triggering a new process, kill an existing process on the remote machine. If required, requests to reboot or shut down the remote machine can also be made.

Basic implementation scheme

Fig. 5 Client application with the server executable embedded in it's resources

The client application holds the server application (executable) in it’s resource section, like any other resource, viz., bitmaps, icons, menus etc. (refer fig. 5).

When the client asks to connect and monitor any remote machine, it has to supply it’s 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 the it’s resource section. The client application copies the server executable to the remote machine’s System32 directory. (CRemoteAdministrator:: CopyServiceExeToRemoteMachine() in the accompanying project)

Refer 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 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 user of the remote machine.

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.
- sending the list of processes to the client application (Thread function RemoteAdminProcessInfoThread())
- to process a request from the client to start a process on the remote machine (Thread function RemoteAdminExecuteProcessThread())
- to process a request from the client to end a process on the remote machine (Thread function RemoteAdminKillProcessThread())
- to process a request from the client to reboot or shutdown the remote machine (Thread function RemoteAdminSysShutdownThread())

Implementation details of the client application

The client is a standard SDI application based on MFC’s document/view architecture. 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 class which holds all data regarding the application. This class holds the only object of CRemoteAdministrator.

Implementation 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 4 threads (RemoteAdminProcessInfoThread(), RemoteAdminExecuteProcessThread(), RemoteAdminKillProcessThread(), 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. Similarly, 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.