Select the deployment model you want to use. I’m going for Azure Resource Manager (and so should you be doing ;-)):

On the next screen, click Configure Account, and enter your credentials for Azure (an account for this purpose!). If you’re going to restore Linux servers, you need to check that box and configure a helper appliance:

On the last page, the subcriptions this account has access to will be listed:

Here you’ll enter a name for the proxy – this will also be the VM name in Azure:

Next Veeam will need credentials for the VMs local administrator. Add a new credential object, with a username and password – no domain name!

Select the deployment model – Azure Resource Manager like when I added the Azure Account:

Now select your subscription – when you do that, Veeam will query for the available locations. Then select the location of your proxy:

Next you need to select a size for the VM, and a storage account. The size of the VM depends on the amount of data you’re going to push through it. I have personally pushed 6 MB/s through an A2_v2 VM.

Now select a resource group for your proxy. You can create a new or use an existing one. You also have to give the VM a public DNS name – this one is important, since that’s what Veeam is using to connect to the VM.

Next select the network and subnet the proxy should be connected to:

And the proxy deployment will start, so now you just sit back and wait for a couple of minutes:

And done:

If you go to Azure, you can find the proxy VM there:

Looking at disks, you can see there’s only 1 for operating system:

And the network interface , where we can see a public IP was added:

If we check the public IP configuration, we can see it uses a dynamic configuration, meaning no extra cost for a reserved IP:

Lastly, one thing I would have prefered to be a bit different, the Network Security Group:

As you can see, 2 ports are open:

• 3389 for RDP
• 6181 for Veeam connectivity

The configuration means these ports are open for everyone. No restrictions! This is a really bad designin my opinion. But there’s hope, you just have to think about the deployment before doing it. I would recommend one of the following:

• Locking down the NSG for your Azure Proxy VM, to restrict access from other than your own IPs
• Create a subnet specifically for Azure Proxy VMs, and lock it down with NSG
• Create a seperate network for Azure Proxy VMs – this will seperate them from everything else

I would prefer the 2nd option. That way I don’t have to maintain an extra network, but I can still restrict which IPs it can reach internally, and which public IPs can connect to it.

Again, select deployment model – Azure Resource Manager:

Select the subscription, location and choose the Azure Proxy VM you just created:

Now you can choose which size the VM should have in Azure, and which Storage Account to use:

On the next screen, select which Resource Group to restore the VM into:

And you can rename the VM object if you want to:

Then select network and subnet:

And in case you want, type a reason:

Go through the configuration and make sure it’s like you want it:

Now you just have to wait 🙂

As you can see, the job powers on the VM in Azure.

After the restore is done, the VM will be available in Azure. You should go and make a few changes to it though! Just like the Proxy VM, it will have a public IP and a Network Security Group attached to the network interface. Once again, the NSG allows RDP from any IP address!

A few notes…

This is an awesome feature, and it’s extremely easy to configure and use. It does have a few shortcomings though:

• Proxy VM wizard should allow you to lock down the NSG
• An option to use VPN connection for Proxy traffic would be nice, instead of connecting to a public IP
• Likewise the restore wizard should ask if you want a public IP, and allow you to choose an existing NSG or edit the rules
• A “nice-to-have” feature would be Availability Set support, in case I want to migrate multiple servers