In this blog post I’d like to focus on various services and solutions regarding WVD as well as ‘plain’ RDS, on-premises, within Azure, and a combination of the two. In short, we’ll look at: On-prem and Azure RDS -> Disaster Recovery & Migrating On-prem RDS to Azure RDS -> Migrate Azure RDS to WVD
Given it’s (WVD) architecture there’s nothing stopping Microsoft from letting on-premises hosts connect as well. In fact, WVD is what used to be RDMI. RDMI, as it was originally positioned, did allow hosts/VM’s to be on-premises, it’s something Microsoft explained and advertised even in various presentations, video’s and such. Just like the ‘reverse connect/proxy’ approach, which was introduced with RDMI as well.
Anyway, this got me thinking, there’s a ton of stuff that Microsoft Azure offers to extend what you have on-premises, why not throw a little WVD in the mix as well and see where we end up. It’s not WVD on-premises, like most are asking for, no, but I might be able to provide you with a few pointers worth having a look at. I’ve also included some non/less technical services/options for you to consider.
First things first
Being able to extend what you run on-premises into Azure requires a connection of some sort, like a Site to Site VPN using an Azure VPN gateway, for example. The use of an ExpressRoute is also optional, though far more expensive and often a bit of an overkill. This is one way to connect what you already have on-prem, to your WVD/Azure Cloud tenant. By the way, if you’re interested in reading more on some of the difference between ExpressRoute, Point to Site, and Site to Site VPN options, go here.
Once you have the connection/networking taken care of there are multiple Azure services / solutions that become of interest.
Who are you?
In other words, identity. As most of you probably know by now Azure AD is needed for WVD to work. It’s used for user authentication purposes, while your WVD machines need to be domain-joined to a Windows Server Active Directory (by means of a standard or hybrid domain join). For this you can use Azure Active Directory Services, build an Active Directory based on IaaS, or use an existing on-premises Windows Server Active Directory.
Either way, your Azure AD will need to be kept in sync with your (on-premises) ‘other’ Active Directory of choice. WVD VM’s cannot be directly Azure AD joined. If it’s the on-premises route you choose, you can use Azure AD Connect for synching purposes. This set up is not specific to WVD, by the way. Once you have this in place it also allows you to take full advantage of other Azure services and solutions. Let’s explore a few, shall we.
One step at a time
Let’s take a step by step approach and see how we can leverage various Azure services, apply them to RDS, WVD, and perhaps combine them with some of our on-premises resources as well.
Burst to Azure
First up is the option to burst workloads to Azure, when you run out of on-premises resources, for example. Or perhaps you’d like to setup some sort of DR model, active/active, or active/passive Given that connectivity and identity are both already taken care of we can jump right over to the good stuff.
Note that this is meant for traditional RDS type workloads, not WVD. Having said that, the Windows 10 Enterprise for Virtual Desktops Preview image (introduced with the WVD service) is available from the Azure market place and can be used outside of the WVD control panel (without the WVD agent installed, so it won’t register), if used with Citrix. It has also been mentioned (by Microsoft) that, in time other CSP’s will be able to do the same. Maybe this will change going forward, being able to leverage the multi-session Win10 image, I mean, and just from a CSP perspective. Even though Win10 MU won’t be available on-premises, this could be a nice step in between for some.
Auto scaling…
Within Azure, Dynamic Scaling can be used to scale out the number of machines when needed, but also to shut machines down (scale down) when no longer used, to save on costs. When working with RDS though, there are some things to keep in mind.
Dynamic/Auto scaling isn’t optimized to work with RDS type workloads. For example, while it’s not a problem to increase or decrease the number of machine at any given time, either manually or automatically based on various metrics, new machines won’t be added the RDS host session collection, or removed for that matter. This will have to be done manually. Also, when scaling down you’ll have to consider ‘draining’ your session hosts from active user sessions before shutting them down.
Domain Name System
One more thing to consider is DNS. DNS can be configured on a vNet (will apply to all VM’s in that vNet) or network interface level (individual per VM). Another option would be to create a new VM in Azure, domain join it and turn it into an additional Domain Controller with DNS. When RDS sessions are established there is a ton of traffic and information going back and forth between your DC’s and RDS hosts, this way you’ll have one near your RDS machines right up there in Azure.
Disaster Recovery Model
Azure Site Recovery can be used for disaster recovery as well as migration purposes. According to Microsoft “Migration uses the same steps as disaster recovery with one exception. In a migration, failing machines over from your on-premises site is the final step. Unlike disaster recovery, you can’t fail back to on-premises in a migration scenario.” Which makes sense.
Next to DR and migration, ASR together with a solution like Azure Traffic Manager can also be leveraged to combine on-premises RDS with RDS on Azure (IaaS). Note that because WVD has brokering, load balancing, etc. all built in ‘as a service’ this type of set up only applies to plain RDS. ATM offers a range of options to choose from when it comes to directing users to one of the configured sites, as shown below. I’ve listed some documentation options for your you to check out below.
I’m not going to go over all the steps needed to set up ASR, for DR or machine migration, I just wanted to point out that it can used for other things besides recovery. ASR can also be used for safe guarding your WVD environment. Migration works for on-premises physical machines as well as VMware and Hyper-V type VM’s, and from Azure to Azure (different Regions). In fact, @pmarquesc (on Twitter) recently wrote an excellent post on this particular topic, have a look here. Go here for Microsoft’s own documentation on Azure Site Recovery.
You’ll start by setting up your Azure target environment -> a replication policy -> initiate replication -> a test migration -> followed by the final migration. Make sure to keep an eye on some of the post-migration steps as well.
Migrate IaaS RDS to WVD
Now that we know how we can extend, and/or migrate our on-premises RDS deployment into Azure, as a next step, let’s have a look at how we can migrate IaaS Azure RDS machines into WVD. On a high level here’s what you’ll do: register to WVD -> create a tenant -> create a hostpool -> Install WVD agent onto your Azure RDS machine (s) -> the agent will register itself with the WVD control panel / service – job done.
Never mind if it’s WVD or RDS you are interested in, both solutions offer various ARM templates and PowerShell CMDlets helping you in setting up and configuring your tenant, collections, host and app groups, and even to publish desktops and applications when desired.
Other Azure services that might be of interest
Just a few pointers that work for RDS on Azure, and will probably apply to WVD as well. If not today, they might in the (near) future.
- Auto Scaling Groups / Virtual Machine Scale Sets. I already highlighted these earlier.
- Start and Stop VM’s are available from the Azure market place. The Start/Stop VMs during off-hours solution starts and stops your Azure Virtual Machines on a schedule or by utilization – Azure Automation is behind this.
- Auto-shutdown is available on a per VM basis, when desired. You’ll have a couple of options to choose from when it comes to when a machine needs to be shut down. While not many use this feature in production environments (there’s no auto power on option available, for example), with WVD, especially now that it’s still in preview and most are busy exploring the service, it’s one you might want to consider.
- At his time you don’t have any choice when it comes to Regions, at least not regarding WVD (you do for RDS, of course). However, when the WVD goes live, keeping latency in mind, you might want to have a look at the different regions, price-wise I mean. Not all services and resources are priced equally.
- Now that we are on the subject of multiple regions, this applies to RDS as well as WVD in the future, consider using multiple for HA, DR, and fail over purposes.
Well, that’s it for now. There’s more to share, but this post already turned out a bit lengthy so I’ll leave at this. Hopefully this post has been somewhat helpful to some.
