In this blog post, we’ll be:

• configuring a virtual network topology in Azure in the “hub and spoke model”
• deploying an example resource (a Key Vault) in our spoke network
  • restricting access to the Key Vault using a private endpoint connection so that it is only accessible inside the vnet
• configuring a DNS forwarder running Debian + Unbound in the hub network for resolving the private DNS name of the Key Vault
• configuring a Basic SKU Virtual Network Gateway
• configuring a Windows client to connect to the Basic VPN Gateway in a point-to-site configuration so it has access to the Key Vault through the private endpoint

Why?

A hub and spoke network with private endpoints for restricting access to various Azure PaaS resources is a fairly common architecture, but there are a few parts of it that lead to unnecessary costs: namely the PaaS private DNS resolver and the Virtual Network Gateway in its non-Basic SKUs, such as VpnGw1.

The primary purpose of this post is to document how I’ve achieved this architecture using the Virtual Network Gateway Basic SKU, which saves ~£80/month over the VpnGw1 SKU. It also saves the PaaS private DNS resolver costs by using a lightweight VM.

Create hub network

We’ll start by creating our “hub” network, called vnetHSTestConnectivity in my case.

We’ll be using the 172.16.0.0/24 range for this network.

» Read the rest of this post…

Despite the inexorable march towards running all workloads in the cloud, I see some specific advantages in maintaining some on-premises servers where this makes sense. Especially in a small scale environment like the one I am responsible for, this lets me do Interesting Things with my skill set and at small scale, only because I have full control over on-prem kit.

One of the options for backing up Hyper-V workloads I am looking at is Microsoft Azure Backup Server (MABS) v3. On a brand new deployment (Windows Server 2019), following Microsoft’s guide, I ran into issues with the MABS installer.

At the point of connecting to the Vault above, it would take a long time to “validate credentials” and then:

Invalid vault credentials provided. The file is either corrupt or does not have the latest credentials associated with recovery service. ID 34513

I found a way to work around this — we need to slipstream an updated version of the Microsoft Azure Recovery Service (MARS) Agent into the MABS installer before we run it.

Tidy Up First

If you have a messy server after some failed install attempts, roll back the VM if possible, or uninstall all MABS and MARS components with Add/Remove Programs.

Also, use the MMC certificates snap-in in Local Computer mode to remove any stale vault credential certificates.

To do, this launch mmc.

We will Add/Remove Snap-ins, and choose Certificates, Local Computer.

Remove any CB_ certificates from previous runs to avoid any possibility of confusion when the registration process runs again.

Take care to ensure you understand what you are doing before deleting certificates and keys. Do not delete anything you are not certain is unused and related to MABS. I cannot take responsibility for your loss if you follow this guide and have issues.

In the Azure Portal, go to your backup vault and check Backup Management Servers and Protected Servers, removing any registrations from previous failed installs, so we are installing into the vault with a clean state. Alternatively, create a new vault. I unfortunately ended up with my MABS server in Protected Servers and had to delete it. Ultimately it will be registered as a Backup Management Server, not a Protected Server.

The Workaround — Slipstream Updated MARS into MABS Installer

We are following Microsoft’s documentation on installing MABS, diverging only to slipstream in an updated MARS installer.

Download MABS from https://www.microsoft.com/en-us/download/details.aspx?id=57520

We will have the .exe and 7 .bin files. Run the .exe to extract the bin files. The install “media” in this case has now been extracted to C:\System_Center_Microsoft_Azure_Backup_Server_v3\System Center Microsoft Azure Backup Server v3.

Before we run the MABS setup wizard, we need to slipstream in the updated MARSAgentInstaller. Do not run the MARSAgentInstaller separately – we must have it invoked by the MABS wizard at the right time and in the correct context. If MARS is already installed when we try to install MABS, it will be unhappy and refuse.

Download the updated version of the MARSAgentInstaller https://download.microsoft.com/download/b/7/b/b7b5d2c9-d345-4d96-b48a-fe98a50f4c11/MARSAgentInstaller.exe

Copy and replace the version in C:\System_Center_Microsoft_Azure_Backup_Server_v3\System Center Microsoft Azure Backup Server v3\MARSAgent\MARSAgentInstaller.exe before running either setup program.

Now run C:\System_Center_Microsoft_Azure_Backup_Server_v3\System Center Microsoft Azure Backup Server v3\Setup.exe (the MABS installer, not the MARSAgent installer) and proceed as normal.

Provide the vault credentials we downloaded from the Azure portal to register the server as normal.

References

This references issue raised on TechNet forums. I cannot reply as the thread is locked.

https://social.technet.microsoft.com/Forums/en-US/bdcd9f72-ccbd-4b40-b984-5f3c09cf71f6/invalid-vault-credentials-provided