When Veeam released Veeam FastSCP for Microsoft Azure a couple of months ago, we still deployed our VMs (virtual machines) in the classic ASM (Azure Service Management) model. Microsoft recently released a new model called ARM (Azure Resource Manager). I’m not going into depth about the differences between the two models, but I did want to point out that a VM deployed in the ASM model is deployed differently in the ARM model.
Microsoft views the ARM model as the future to deploy new compute resources. Unfortunately, because of the differences in deployment, Veeam FastSCP for Microsoft Azure doesn’t work anymore out-of-the-box. For this reason, you’ll need to make some changes inside the VM to get it working again.
Here is the procedure to take advantage of Veeam FastSCP for Microsoft Azure with Microsoft ARM-deployed VMs.
Create firewall rules
In the classic model, firewall rules were called endpoints, and they needed to be created per VM. In the ARM model, you can create a security group that you can use to create firewall rules for all VMs in that resource group.
In my example, I have a resource group called Veeam-VMBP and I created a network security group with the exact same name. Here, you’ll want to add an inbound rule to make sure that your traffic is from the computer where you are running FastSCP to the VM on port 5986 (default HTTPS Windows Remote Management).
As an example, see the below rule that I created:
Install or create a (self-signed) certificate and enable PowerShell remoting
In the classic model, when you deploy a VM, PowerShell remoting is configured for you. In the new model it is not, so you will need to do it yourself.
NOTE: This process will vary, depending on whether you use a publicly signed o self-signed certificate. Since most cases are with a self-signed certificate, I will discuss this variation. When you want to use a publicly signed certificate, the process is much easier because you only need Set-WSManQuickConfig –UseSSL to get things working.
Below you will see the PowerShell one-liners I used to configure my deployed Windows Server 2012 R2:
$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "FastSCP-Server"Export-Certificate -Cert $Cert -FilePath C:\temp\certEnable-PSRemoting -SkipNetworkProfileCheck –ForceNew-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint –ForceNew-NetFirewallRule -DisplayName "Windows Remote Management (HTTPS-In)" -Name "Windows Remote Management (HTTPS-In)" -Profile Any -LocalPort 5986 -Protocol TCP
Some explanation:
- The first line creates a self-signed certificate with the DNS name of my server (in this case, FastSCP-Server). It then stores it in the certificate store.
NOTE: Add the certificate details to a variable called $Cert to use it further.
- The second line exports the certificate to a location (in this case C:\temp\). If you have an error on this line, note that the directory has to exist upfront, it will not be created.
- Third line will enable PowerShell remoting. I used the
-Forceto skip the user prompts and-SkipNetworkProfileCheckto ensure that PowerShell doesn’t complain when your network connection type is public (which it probably will be) - The fourth line creates the HTTPS listener, which won’t be created automatically, only the HTTP listener and connects the certificate to it
- Finally, the fifth line creates a new Windows Firewall rule that opens Windows Remote Management over HTTPS
And Poof! You can once again use Veeam FastSCP for Microsoft Azure.
Connecting to the server
Below you can see that I can connect to my server again and I have access to the data on my VM.
Conclusion
Veeam FastSCP for Microsoft Azure works out-of-the-box when used with a Microsoft Azure VM deployed in the classic model. However, when you deploy a VM in the Azure Resource Manager model, things are a bit different and Remote PowerShell is not configured anymore. To be able to take advantage of Veeam’s solution, you will first need to take a few quick steps to manually enable it.
