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.
Recently I’ve been asked by a colleague if Veeam Backup & Replication supports VMware NSX. The answer to me was pretty clear, since Veeam works at the vSphere layer and what is sees are “just” portgroups, regardless if they are simple, distributed, or NSX virtual wires. Nonetheless, I decided to do a quick test to prove it.
In the previous posts of this series, we completed the configuration of Veeam Availability Console, and onboarded our first customer. The customer logged into his own account and configured the different services. Now in this fourth part, we are going to connect a remote Veeam Backup server in order to monitor it.
I’ve seen often Veeam users to configure their repositories using administrative permissions. This is a really bad practice as the most precious part of a Veeam environment, the backup files, are then exposed to security risks, in case anyone can obtain those credentials. And with the raise of cryptolockers and ransomware this behavior has become even more dangerous. For Linux repositories, users can configure their servers to use common users.
In my previous article about Let’s Encrypt certificates Use Let’s Encrypt free certificates in Windows for Veeam Cloud Connect I explained the basics of Let’s Encrypt technology, and how to use its certificates on a Windows machine using ACMEsharp libraries with Powershell. I found out that the previous script had a problem with renewals, so I went on to fix it.