Azure Datacenter in Sweden

Microsoft announced last year that they are going to launch two new Azure datacenter regions in Sweden in 2021.

The main region will be placed in Sandviken (Sweden Central), where the region will offer outside Azure, Microsoft 365 and Dynamic 365. The main Azure region also will feature availability zones and a guess is that it will be one of the larger regions in Europe.

A secondary Azure region will be featured in Staffanstorp in south of Sweden. This region will be a small region and will be serving for data residency primary as a secondary region to Sweden Central. Similiar to what Norway West region is to Norway East region. The Swedish south central will not feature Availability zones (at least to start out with).

One of the big things with the Swedish datacenters are their will be one sustainable datacenter. Gearing towards Microsoft goal of being carbon negative by 2030, hopefully Microsoft will reach that milestone.

Looking forward to Microsoft releasing the GA date of the Azure Sweden datacenters.

Convert Azure Firewall to Firewall Manager – part 2

In our previous part, the Firewall policy was created. In this part we will take the policy, do a few minor changes and convert the Firewall we got our framework from.

To start of, the Firewall Policy in itself will not do “anything” until it is applied to Azure Firewall resource (or Secured hub, that is Azure Firewall inside Virtual WAN). The Azure Firewall Policy created can be applied to new Firewall or converting existing firewalls. For this particular case, converting existing Azure Firewall is the target.

Before converting, if we already have another Firewall Policy we want to have as a parent to our current policy, we can proceed to add that to the Azure Firewall policy before. Either we can do this Portal, or handle it via code. Open up the ARM template in VS code and under  “Microsoft.Network/firewallPolicies” resource, under properties, add the following line. Example code

{
    "$schema": "https://schema.management.azure.com/
schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
"parameters":{
..
   "basepolicy": {
            "type": "string",
            "defaultValue": "resourceid"
        }
...
},
"variables:{},
"resources":[
      ..
      "basePolicy": {
                    "id": "[parameters('basepolicy')]"
                }
        ...
        ]
        }
    ]
}

Go live

Converting an existing Azure Firewall to Firewall Manager is none-disruptive operation. How this fit in your change regim, may differ since Azure Firewall more often then not is a central component in your deployment and because of that requires a change window. However from a technical standpoint, there is no traffic lost in the network tests I done during the convert.

To convert a current Azure Firewall can either be done thru the Portal and follow the guide

If you already have Azure Firewall handled via code, it is three things we need to do (ARM template as example).

  1. Remove all current Azure Firewall rules in the ARM template
  2. Remove threatIntelMode setting
  3. Add the Firewall Policy (the one we converted) resourceID reference

"firewallPolicy": {             
     "id": "resourceIDofFirewallPolicy"         
}

Now, the configuration is ready for deployment. If there is an already pipeline, use that. In this example case, we deploy via Powershell

New-AzResourceGroupDeployment -Name "1" -ResourceGroupName´ "firewall-rg" -Mode Incremental -TemplateFile´
.\firewall.json -TemplateParameterFile´
.\firewall.parameters.json -Verbose

The convert usually takes the same amount of time as an regular Azure Firewall rule update. One thing noted is that if you have IP groups as reference, it usually take a bit more time.

After deployment is complete, we can see the difference in two parts in the Azure Portal. On the Firewall object itself we see a difference that we have fewer options on Settings

The settings are now moved to the Firewall Manager, where we can see it under “Hub virtual networks”

Deploy Azure Bastion centrally in Hub & Spoke

Azure Bastion Host is used for remote access of virtual machines without need exposing thoose virtual machines with public IPs. When launched Azure Bastion Host came with a serious drawback, as it did not support VNET peering, hence, we needed to deploy per Virtual Network, making the solution expensive as you needed one per spoke.

Luckily, Azure Bastion Host now has support for VNET peering. Hence the requirement to have one Azure Bastion host per virtual network is not required anymore to get it to work. The next logical placement of the Azure Bastion Host is now to put it more centrally, to keep one Azure Bastion host per region deployment, thus saving cost. A common place can be the connection hub vnet, since it is a well connected with the spokes. If that is the case, you do not want to give more access then needed, since there is other important resources in that subscription. All needed permissions for the Azure Bastion Host can be read at the FAQ for BastionHost for VNET Peering.

Implementation
First part is to establish a role defination as there is no role for Bastion Host as for this date. Hence we need to create a custom role defination. Here is deployment template for BastionReader.
Important to note, in case you do not have access to the root management group, you will need to modify it to a scope where you have the permissions to add Role definitions.

Second part is to deploy the actual Azure Bastion host resource and allocate an group to that role defination. Template for that can be found here.

The input parameters are

  • Basename, prefix for the resources
  • VirtualnetworkID, this is the ID to the virtual network with the AzureBastionSubnet
  • Role defination ID, the ID of the Bastion Reader
  • AAD group, the object ID of the group that will have access to the Bastion resource

After the template is deployed, we are now ready to use the Azure Bastion Host. When using it, make sure that subscription filter is not filtering out the subscription where you are Azure Bastion Host is located, since it utilize this for lookup.

Conclussion
From an architectual this is not an optimal solution, since you do not want to give permissions in the your hub subscription to “everyone” if not needed. Hopefully there is some clever solutions from Microsoft coming to change this.

Convert Azure Firewall to Firewall Manager – part 1

Firewall Manager and Firewall policies has been the new kid on the block for some time now (General avaialable in June) and with the new Azure Firewall Premium Firewall only being supported with Firewall Policy (link), it is logical to start migrating existing Azure Firewall to utilize Firewall Policy to be able to consume all new services.

The first part is to get the existing ruleset setup in your existing firewall to a new Azure Firewall policy. Microsoft have published a article with an script for it here . There were a few missing things such as IP groups support and some assumption, so a slightly modified script can be found here at my git repo link .

The script will do the following

  • Create an Firewall policy with specified name (and resource group if not already created)
  • Poll all info from the specified Firewall
  • Set threat detection setting into the Firewall policy
  • Loop thru Application Rule set, Network Rule set and NAT rule set from the source and apply that to the Azure Firewall policy created

To run the script, open up either Cloudshell or your local Powershell prompt and select the subscription where Azure Firewall is located. Fill in your current firewall resource group and firewall name and then the names of the Firewall Policy and resource group.

.\Export-RulesToFirewallPolicy.ps1 -FirewallResourceGroup "firewall-rg" -FirewallName "firewall" -FirewallPolicyResourceGroup "firewallpolicy-rg" -FirewallPolicyName "firewallpolicy" -FirewallPolicyLocation westeurope

Now the firewall policy are ready to either be used in to convert existing firewall or a new Azure Firewall.

Enable Hybrid benefit on all already deployed Windows VMs in your subscription

Hybrid benefit in Azure means that you are purchasing the Windows license elsewhere, instead of “pay-as-you-go” with the VM consumption. The reason to do this is either your organization already owns licenses or purchased licensese to save cost (there is a brake even when it makes sense to buy the license outside of Azure).

To retrofit this to existing subscription, it is quite straight forward with Powershell. It is just a metadata for the virtual machine, so there is no down time required (reference https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing#convert-an-existing-vm-using-azure-hybrid-benefit-for-windows-server) .

The following Powershell code takes your current logged in Azure subscription context, get all Windows machines that does not have Hybrid benefit enabled and loops thru them, enabling Hybrid benefit.

[Cmdletbinding()]
Param
(
)


$nonehbvm = Get-AzVM -Status | where{$_.StorageProfile.OsDisk.OsType -eq "Windows" -and (!($_.LicenseType))} | Select-Object Name,ResourceGroupName,Licensetype
foreach($i in $nonehbvm)
{
    $vm = Get-AzVM -ResourceGroup $($i.ResourceGroupName) -Name $($i.Name) 
    Write-Verbose "Setting hybrid benefit on VM $($i.Name) "
    $vm.LicenseType = "Windows_Server"
    Update-AzVM -ResourceGroupName $($i.ResourceGroupName) -VM $vm
} 

How routes are distributed to Spoke Virtual networks with a secured hub

Microsoft has a interesting addon for the Virtual WAN offering in preview, Azure Firewall (Manager) in the Azure Virtual WAN. This means that we can filter traffic traversing our Virtual WAN Hub instead of sending it to a NVA or Azure Firewall in another Virtual Network for example.

There is a lot of intresting stuff regarding this, but one that is not that well documented (yet, still preview). Is how routing is working and how the routes are distributed to the different spokes. It differs a bit from the “old” Hub-and-Spoke model, where you had to maintain Route table for each spoke to point to your NVA in the hub. Virtual WAN however solves this differently and at first glance, a more elegant way.

If you press the hyper link on “Learn more” on the configuration page you end up on Azure Firewall manager documentation page, that for the moment lacks the section.

So how does it work? For the default route, choose Send via Azure Firewall, for traffic between VNET, you need to specify the address range for each spoke you add.

When you press save, a deployment is launched and what happens is the Virtual Hub routing tabel get updates. However the Route section on virtual hub in portal is still empty.

However, if you deploy a virtual machine in one of the networks and inspect the route table of the machine you will see the following

Default route is the system learned routes (Virtual Network or VNET peering for example). The interesting are the Virtual Network Gateway, the Virtual Hub injects the routes in the “Gateway” route table to distribute the routes to the different spokes and hence we do not need to maintain a route table on each spoke, compared to the old Hub and spoke model.

Notice, the Firewall manager is still in preview, so this can be changed when the service goes GA.

Avoid Source NAT for none RFC1918 ranges in Azure Firewall

In certain scenarios, some companies are using public IPs for internal purposes. This more common in education or larger old enterprises as they got assigned a sizeable public IP range. This creates some unique challanges for Azure Firewall in combination with ExpressRoute or VPN.
By default, Azure firewall will source NAT communication with IP adresses not defined in the RFC 1918 space (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16).

If the none RFC1918 space is coming from ExpressRoute or VPN, it will source NAT to one of the Azure Firewall interfaces. For example if you got 192.168.0.0/26 defined as your AzureFirewallSubnet, it can be 192.168.0.6 for example. This is choosen “random”, since AzureFirewall consist of at least 2 instances behind the scene. Hence, if a virtual machine (Virtual Machine Windows) in Azure with the source IP of 172.0.0.10, sitting “behind” the firewall, communicating with an on-premise virtual machine (Virtual Machine Linux) with the IP of 30.30.30.10, the target machine, will see one of the Azure Firewall IPs as source IP, for example 192.168.0.5.

For certain applications, this can brake functionality and therefor not a desired behaviour. Lucikly Microsoft released a new feature, where we can defined our own ranges, that should be excluded from source NAT. From Azure Portal, navigate to the Firewall and press Private IP range.

Here, already defined is IANA Private ranges (RFC1918), here we can add our 30.30.30.0/16 range, to make it excluded from Source NAT. After change is applied. Virtual Machine Linux will see 172.16.0.10 of Virtual Machine Windows as the source IP, instead of the Azure Firewall Internal IP.

Via ARM template
If you want to add this via ARM templates instead, add the following snippet under the properties configuration

"additionalProperties": {
                    "Network.SNAT.PrivateRanges": "IANAPrivateRanges , 30.30.30.0/24"
                },

Setup Docker on Windows 10

Firing up containers locally is always useful, whatever it is for learning, developing or just being curious.

First off, verify that you have virtualization enabled on your computer, it should return true

(Get-WmiObject Win32_Processor).VirtualizationFirmwareEnabled
True

Then enable Containers and Hyper-V, make sure to run Powershell as admin

Start-Process Powershell -verb Runas
Enable-WindowsOptionalFeature -Online -FeatureName "Microsoft-Hyper-V" -All
Enable-WindowsOptionalFeature -Online -FeatureName "Containers"

Install Docker module and binaries, confirm.

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker-desktop  -ProviderName Chocolatey

and then finally, restart your computer

Restart-Computer -Force

Now you have docker installed on your system. To switch between Linux or Windows containers, choose on the Docker tray icon

Enjoy!

SQL Backup with Azure Recovery Services

Microsoft announced a bit back that they now include SQL Backup of SQL Server installed on Azure VMs. https://azure.microsoft.com/en-us/blog/azure-backup-for-sql-server-on-azure-vm-public-preview/. This enables us to gather most (if not yet all) backup services in one tool.

Setup
First of, you will need a Recovery service vault in the same subscription as your SQL Server resides. When recovery service is in place, choose backup and there is an option “SQL Server in Azure VM”

This will prompt to run a discovery, to search for Azure virtual machines with SQL Server on it. After it finds it, it will install a small windows service AzureBackupWindowsWorkload that utilize a user (NT Service\AzureWLBackupPluginSvc) for the backup. This process takes in my experience a few minutes. If your VM was not provisioned thru Azure SQL Server image, the SQLIaaSExtension will need to be installed and add NT Service\AzureWLBackupPluginSvc as Sysadmin user on the SQL Server instance.

After discovery is completed, there will be a list with SQL Server Instances and what databases resides on the particular instance. From here, either check the top to get all database, or choose what databases that are going to be backed up.

Next step is configure the backup policy. There is a default created that will do a full/diff backup each day, and logbackup each hour. Or create a policy that match your company RPO needs. (During preview the default policy cannot be changed)

After configuration, recommended is to intial a backup, this will run an initial full backup of the databases. The progress can be tracked in Recovery service under backup jobs

Restore
A backup is only as good as its ability to be restored. Restores are intiated from Recovery service. Simply choose the database that are going to be recovered and choose Restore DB

Restores option are to overwrite current database or to restore on Alternate Location (on same SQL Server with different name or other registrered SQL Servers). Makes it handy to restore one offs when you want to test something on a database or do restore tests

If the database is in full recovery model, the possibility to restore in a specific time and date will be presented, or from latest full/diff backup. This experience is similiar what is presented in SQL Management Studio. Easy and to the point.

Lastly, a few moreoption to set in NO Recovery and the physical name and location of the .mdf and .ldf files are given. After that, review and press Restore. The restore job can be tracked under Backup jobs in Recovery services.

Summary
This functionality adds a bit in the puzzle to make the backup and recovery service more complete. The easiness of configuration and restore makes it available for a broad audience.