In order to set up remote management you need to decide which topology you want to use. You can have slaves connect to the master console or the master connects to the slave, or combination of both methods.
From the main menu, open Security and Remote Settings:
In the screen that opens next you must set a password:
Once you set up a password (at the very least) you can click OK and then go back and Enable Remote Management:
In order to allow slaves to connect to the master server, you need to open the Security and Remote Settings screen and check “Allow incoming remote management connections” on the master computer. You also have to specify a TCP port number. In our example above it’s 7700.
The SSL option should be checked if any remote management link will go through an intelligent firewall system or the internet or other public networks. Otherwise, firewalls might misinterpret the traffic as malicious and abruptly break the connection. The standard Windows Firewall, however, will work fine without the SSL option and requires no further configuration.
Once you have enabled remote management by clicking on the option in the main menu (after having set up a password as described above), the main screen will split vertically. You will see a server tree on the left with the local host being already added below. Then right-click on top entry “Server List” and select “Add Server”:
On the screen that follows you can enter the slave’s details:
Here you need to specify if the slave will connect to this master server (inbound), or whether the master is supposed to connect to the slave (outbound).
For the inbound scenario where the slave connects to the master, you must provide the local network name and the remote control password. The password you enter here is the one you defined in the slave’s “Security and Remote Management “configuration screen. Hence, the master can only control the slave if the master knows the slave’s password as well as its network name; this is how trust is being established.
When you add the server in the master screen by right-clicking on “Add Server”, enter the network name and password exactly as it appears in the Security and Remote Management Settings of the slave.
Click Add Server:
And on the master side you enter:
Based on the slave’s settings shown below (note the screen displays the network name “win2019”):
Also note, the slave has a password defined and the option “Connect to remote master consoles” checked. In our example, this slave connects to two masters. One master is at mastersaddress.com:7700 and the other is a local master at 10.0.0.3:7700. The port number is 7700 and appears after the semicolon.
In the master’s Add Server screen we need to enter the network name “Win2019” so that the incoming connection can be matched to the password of that particular slave, which also has to be entered in the same screen. Only then the two can talk together.
In this example, we set up the same slave to be receiving
the master’s connection instead. From the master’s perspective it’s an outbound
connection. For the slave it’s therefore an inbound connection. Hence,
we need to “allow incoming management connections” and we choose port 7700 as
All we need to do at the slave side is to set the password and allow incoming remote management connections.
On the master we need to configure the slave and tell the master to connect to the slave, which is an outbound connection:
Note that here we must provide the local network name for identification purposes, the remote management password entered in the previous screen on Win2019, and the address or IP address of Win2019 and port number, which in our example are 10.0.0.99 and 7700, respectively. These settings tell the master where the slave is, what the password is (to establish trust), and that we want the master to connect the slave (outbound); hence, we have to provide the address of the slave (10.0.0.99 or network name on LAN) and the port number.
Once the remote server is added, you can see all tasks of all servers listed one underneath the other by selecting the top entry “Server List”. By right-clicking on a particular server, you see additional actions available for each server:
“New Task” creates a new task on the selected server.
“Update Task List” requests an up-to-date task list from the server. The master already periodically makes such requests automatically; however, with this function you can force it to occur immediately.
“Remote Server” removes the server entry from the tree.
“Logs” allows you to load on of the remote server’s main service logs.
“Edit FTP Server Settings” opens the FTP settings at the remote server site.
“Install Software Update” opens the Software Installation Screen where you can remotely update the software of all or selected connected servers.
“Server Information” displays additional server details of the connected server.
In order to start a restore process, you need to log on to the server where the restore process is supposed to run. Note, however, that in LAN environments you can use UNC paths as targets, with document based backups; i.e. you can run the restore process on any server via UNC and pull backup files from another server, and also write the restored data over UNC to any other server. While all kinds of backup tasks can be restored from UNC, restoring to UNC paths may only be done for documents and offline virtual disks. Note that VMs cannot be integrated automatically into Hyper-V Manager over the network. For VMs to be added back into the Hyper-V Manager, you need to run the restore locally on the server that is to receive the restored VM.
You can manage backups on remote servers from the master server as if you are connected locally. Folder, file, and physical disk selection is passed through as if it were local.
The time in the log view is displayed in the local time zone of the viewer. If your remote servers are in a different time zone, the time shown in the time column is adjusted automatically.
Note that the refresh of remote server backup progress will be slower than that of the local server. Also there may be a delay when you request certain operations, due to the packet roundtrip time to and from the destination. It may take a few seconds before the remote server reacts to a particular command, depending on link conditions and distance.