Veeam Availability Console is completely web-based. For this reason, it’s extremely easy to consume it, and the idea behind the product is that the console can be used directly by users. To do so, the Console itself has to be published over Internet, following a few but important steps.
Split Server and Web UI
The first important step to guarantee a proper and secure deployment is to properly split the two main components. The Deployment Guide describes this as the “Distributed Installation Scenario” and consists on installing VAC Server and VAC Web UI into two different servers. Thanks to this choice, you can install the proper VAC server into the management network, close to the VBR server that is used by Veeam Cloud Connect, and protected behind different firewall and other tools, while the Web UI, effectively the web server, can be placed in a DMZ network together with other web services like the VCC Failover Portal or the Cloud Gateways. The linked page has all the information in terms of ports that needs to be open between the two servers.
If you already installed VAC in a single machine as I did, the process to split them is fairly easy.
First, you deploy the new dedicated webserver, this needs to be a Windows OS machine with these requirements. In my case, this machine is vacweb.cloudconnect.local. The machine is placed in the DMZ and the needed port (TCP/UDP 1989) is opened between VAC and VACWEB, so that the final design is similar to this one:
On the Web server, I executed again the the VAC installation, but in this step:
I only selected to install the Web UI. Since I didn’t choose to install the Portal Server, because it’s already running on another machine, in the following step I’ve been asked to specify where this server is in the network:
Once the installation is completed, I can now access VAC from two different website servers, the original VAC server itself and the new dedicated webserver. This is a possible option to create a load-balanced deployments, where you can have multiple webservers available. In my case however, I completed the setup by editing the installation in the VAC server and uninstalling the Web server component. To uninstall the WebUI, mount the installation iso, go into the “WebUI” folder, and right click on VAC.WebUI.x64.msi and select Uninstall. Don’t worry this will only uninstall the Web server.
UPDATE 14.05.2020: if you uninstall the WebUI component, you also need to remove the CWM components, otherwise updates of the console will fail. To remove them, run in powershell first:
Get-WmiObject -Class Win32_Product -Filter “Name like ‘%Veeam%'”
to find them, and then:
(Get-WmiObject -Class Win32_Product -Filter “Name=’name of the component‘”).Uninstall()
to uninstall them.
Get-WmiObject -Class Win32_Product -Filter “Name like ‘%Veeam%'”
to find them, and then:
(Get-WmiObject -Class Win32_Product -Filter “Name=’name of the component‘”).Uninstall()
to uninstall them.
Finally, Web server security can be improved by installing a certified SSL certificate. The WebUI is installed as a IIS website, so this is the place to configure security and certificates:
Who can access VAC
Because the server is now exposed over Internet, anyone can at least reach the login screen and try to enter. For this reason it’s extremely important to protect its access. By default, the first user that has full access to VAC and can start the configuration process is the Local Administrator of the Windows machine where the VAC Service is installed.
Surely, setting a really strong password for this user is extremely important, but we can do even better: VAC can be managed by any local administrator of the Windows server running VAC itself, or any local administrator on the Veeam Cloud Connect server. This behavior is listed in the Configuration -> Portal Users page:
Now, let’s use an example: in my Service Provider, we are four admins that need to administer VAC. I can choose to create 4 new administrative users in the VAC server and at the same time to completely disable the access to “Veeam Backup Administrators” in the screen above:
This is even more important if any of the two servers, or both, are joined to a Windows Active Directory, since ANY domain administrator can access the VAC portal. So, in my VAC server I created my own user, and I completely disabled the local administrator:
and removed the domain administrators from the local administrators:
My new dedicated user is now the only one (together with the service account running VAC server) to be able to access the Web UI:
