Published: Aug 03, 2020
Large parts of the northern hemisphere take the month of July off. Schools are closed, the weather is good (unless you are in Ireland, where I am located), and its nice to just sit back and relax. In the Microsoft calendar, July marked the end of FY20 and the start of a whole new semester for Azure (and Windows) development. Lots of things that were already rolled out were made generally available, new visions were shared, and lots of new things to learn were dropped onto the heads of those of us trying to keep up with Azure.
I have been looking forward to the next big release from Azure networking since I first learned about it last year. Azure Virtual WAN has started the rollout of a whole “new version” of their on-premises and Azure connectivity solution.
If you work with Azure networking in anything but the smallest deployments, you should be using a hub & spoke architecture – this mimics the pattern of a network core and virtual/access networks in a classic data center or computer room. The hub network can be quite complex, with a virtual network, subnets to manage routing in, virtual network gateway(s), a firewall (cluster), and peering connections to maintain, not to mention the additional routing configurations required in the hub for each spoke and also in each spoke subnet – and it’s only more complex if you use a third-party router and/or firewall appliance.
Azure Virtual WAN takes that hub and turns it into an appliance-like experience. The offering has been generally available for a while and has gradually improved its features and customer scenarios. Originally, Virtual WAN was a service to create one or more hubs for an SD-WAN solution. Today, it’s also a connectivity solution between branches (even in different continents), Azure virtual networks, and users connecting to the WAN/Azure via VPN.
The month of July kicked off with some quietly launched news: Azure Firewall Manager is now generally available (I promised last month that there was more Azure Firewall news coming). Azure Firewall Manager introduces a tiered system to configure Azure Firewall using inheritance based policies. For example, global security managers can control all firewalls with a central parent policy, and regional security managers can configure their local firewall with a child policy that inherits from the central parent. Firewall Policy is available for the traditional virtual network SKU of Azure Firewall, but also for the now generally available SKU that is optionally deployed into Azure Virtual WAN Virtual Hub, AKA the Secured Virtual Hub, which can be created using ARM templates or using the Azure Firewall Manager (note the Azure Firewall has a maximum throughput of 30 Gbps which lower than the 50 Gbps throughput of the Virtual Hub router).
A couple of announcements were shared at the Microsoft Inspire conference for Microsoft partners:
The new partners include VMware and Cisco Meraki, the latter, which is commonly deployed around the world and is a significant step forward. I know that the Azure Virtual WAN team is rapidly working on expanding the list of supported devices for automated routing configuration in an SD-WAN.
The new capabilities are not fully deployed yet; Custom Routing is a new way to do routing (only available in Virtual WAN) to reduce the number of configurations required in a secured hub & spoke architecture. This feature is slated to be deployed to all Azure regions by the end of the week starting August 3rd – the controls are greyed out in the Azure Portal if you do not have access to the new features yet.
A big piece of news is that the Azure Virtual WAN team is working to integrate 3rd party virtual appliances into the Virtual Hub. If this works out how I think it could, it will integrate these appliances into Azure networking in ways that the legacy hub & spoke could not – routes had to be propagated using manually-configured User-Defined Routing and scale-out/in was manual and slow. Today, this is in preview only with just a single appliance from Barracuda.
It appears that the “Windows” part of WVD is affecting the release schedule of updates, just as with updates for Windows 10 – sorry; I could not resist that. Yes, the Spring Update for WVD is not new – lots of news sites and blogs told it was available months ago … but it wasn’t really available. The Spring Update was in preview and was available in just a few regions. Prospective customers tried to use the new features in their desired Azure region to find that they weren’t there yet. But today they are: New Windows Virtual Desktop capabilities now generally available. The new improvements are:
In addition to all this, the Remote Desktop client for Android now supports Windows Virtual Desktop connections.
Here are other Azure IaaS headlines from the past month:
Most of my last 18 months on the job have been focused on deploying Azure resources and securing them. What happened inside the virtual machine or the app has had nothing to do with me; that was handled by the customer or whoever looked after their day-to-day IT. And that changed with a project that I have been working on recently.
The customer is in “evacuation mode” and is rapidly departing their old managed service provider. They have a short deadline to deploy a green-field IT landing zone, including all the stuff that you take for granted, such as domain controllers, PKI, and so on. My team has to build that stuff, so suddenly we were doing work inside the Azure resources, something that we don’t normally think about.
That eventually led me to think that I needed to manage Windows Server across many virtual machines – even “SaaS-first, platform-second” strategies require virtual machines in the real world! To manage those machines we decided to use Windows Admin Center (WAC), the free tooling from Microsoft that integrates deeply with Microsoft partners and is constantly improving. In July, Windows Admin Center version 2007 was made generally available. To be honest, I don’t use any of the Azure integrations, so I cannot comment on them – we manage everything as code through Azure DevOps. But I found it necessary to have a central view of the Windows deployments that we did not have elsewhere. This combined with Azure Monitor’s VM Insights gives us lots of tooling, at very little cost.
Windows Server is not dead – and I don’t think it will be for a very long time.