Fig. 1 Client application running with various context menu(s)
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
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 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
- 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
Basic implementation scheme
Fig. 5 Client application with the server executable embedded in it's
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
CRemoteAdministrator::EstablishAllConnections() in the
- 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. (
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
- sending the list of processes to the client application (Thread function
- to process a request from the client to start a process on the remote
machine (Thread function
- to process a request from the client to end a process on the remote machine
- to process a request from the client to reboot or shutdown the remote
machine (Thread function
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
CMachineInfo is derived from MFC’s
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
derived class which holds all data regarding the application. This class holds
the only object of
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 (
- There is another thread that is constantly updating the processes list
- 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.
Inspired by the tools at Sysinternals. Thanks to Zoltan Csizmadia for sharing his code).