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 and agent automatic installation

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.
If you are subscribed to this blog via RSS, you may have noticed that May and June have been two empty months in terms of writing, and tobe honest the entire 2019 has not been so prolific as usual. This is because I worked, and I’m still working, on some large projects that took a big chunk of my time. I’m still writing these days, but the outcome is coming out in big pieces instead of weekly posts. The first one is this, about Veeam Availability Console.
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.
One of the main focus of this year for me as a cloud architect at Veeam, is to learn as much as possible about public cloud technologies, and how our software solutions can interact with them. I started a few weeks ago to deep dive into our solutions for Amazon Web Services, using N2WS Backup & Recovery. One of the things I’ve learned is how to create a dedicated account to protect other accounts.
Lately, I took the decision to do not have anymore a physical lab, even if it was already hosted and managed at a service provider, but to completely nest it inside a vCloud Director tenancy. But while I was planning the rebuild operation, I also decided it was time to make its creation process as automated as possible, and while doing so, I learned a bit about how to use Terraform.
A couple of weeks ago I presented to a customer Veeam's integration with AWS services, specifically the Direct Restore to EC2 feature. He was really interested, but he also immediately thought about possible large scenarios of this feature. This solution is not a Disaster Recovery technology, since a machine is not replicated into EC2, ready to be powered on, but it's rather a backup that is uploaded and then imported into EC2. But still, massive migrations or the creation of dev/test environments from a production copy were really nice use cases.