For a new chapter of my book on Veeam Availability Console, I created a second virtual datacenter and I needed to connect the two of them together with a vpn. I have many options, like using the embedded ipsec capabilities of the NSX Edge i have at both sites, as they both run vCloud Director, but I decided to use Veeam Powered Network, in order to use this opportunity to learn more about it. And the first thing I’ve learned was how to configure the appliance with a static IP address.
Lately I was updating a couple of my scripts, and when I re-used my script that automatically updates AWS records for Let's Encrypt DNS challenges, I realised that I never stored my AWS credentials anywhere, but I was just using those cached into my powershell environment. Time to have some proper credential management.
The beginning of each year, lately seems to be the time when I have to update my scripts that control the automatic management of SSL certificates. I started three years ago by learning first about Let's Encrypt certificates, and how they could have solved my needs for automatically renew (for free!) my SSL certificates. At the time I started to use ACMESharp: it seemed to be a great fit as it worked in powershell and had all the features I needed; but lately, it has lagged behind, and the move the ACME v2 was the final nail in its coffin.
For my tests, I use a couple of vCloud Director services thanks to some really generous service providers which are also Veeam customers. From time to time, I see they upgrade their installations but as an end user is not always straight-forward to find out which version of vCloud Director is in use. But there’s a way to find out even for end users.
Last week, I explained how to manually connect standalone computers to Veeam Availability Console. This time we will try to automate this process as much as possible.
Veeam Availability Console has been designed for multiple use cases, and one of them is to manage large fleets of computers. But what about those standalone machines we have lying around? It could be the last physical server we have in the datacenter, or a laptop of a consultant that is always travelling around. How can we deal with those? I involved my family’s computers to find out.
In a previous blog post I started to study Terraform, and how to connect it to vCloud Director. This time, I will build my entire lab using the same automation tool.
In my previous post, I talked about Veeam N2WS Backup and Recovery (known previously as CPM) and how to configure it to protect different AWS accounts. Now that the configuration is ready, it’s time to protect the virtual machines, and to export them into S3 so that we can have an offsite copy using Veeam Backup & Replication.