The short answer is Yes, but it is a little more complicated than just clicking a button.
I’ve had this conversation many times, so I wanted to share my thoughts on how this can be implemented via the MyCloudIT portal. This will not be a pure step-by-step process because each implementation will be a bit different, but I want to provide a high-level overview of the process and the few areas that will need some manual adjusting. Since this is a high-level overview, there are some steps that have been overlooked, and this process requires additional in-depth knowledge of Azure than the typical MyCloudIT customer is required to have to use the platform. We can assist in deploying a multi-region deployment if required. Email Support@mycloudit.com if you’d like to discuss the option or have our support team assist you. We are happy to help!
For those still interested…
If you can follow along with this document, in the end you will have two RDS deployments, one in East US and a second one in West US that are both connected to the same Windows Server Active Directory Domain and accessible from a single URL. This will provide the RDS capability across multiple Azure Regions.
Please note that each RDS deployment (East US and West US) will have their own User Profile Disks (UPDs). You can implement a Storage Spaces Direct cluster within Azure to replicate UPDs between the two Azure Regions, but that will generate more replication traffic and is beyond the scope of this document. Keep this in mind if you decide to attempt this on your own.
Let’s assume we will create our RDS deployment in both the East US Azure Region and the West US Azure Region.
We are going to start by deploying RDS in the East US Azure region. You can create a Standard or Domain Joined deployment in the East US Azure Region. If you are starting with an on-premises Active Directory infrastructure that you want to extend into Azure, you will need to follow this guide first to create the Windows Server Active Directory Domain Controller in Azure and connect it to your on-premises network.
Once your RDS deployment in East US is up and running, you will then come back to the MyCloudIT portal and deploy a Windows Server into the West US Azure Region. The interesting part here is that this new VM will follow a process similar to the one documented here. You will follow Steps 1 & 2 to create the new Windows Server in the West US Azure Region. After the Windows Server has been created and is running in the West US, go ahead and shut down the server so you can to change the IP scheme of the West US VNet. If you do not change the VNet IP address scheme in the West US VNet, it will conflict with the East US VNet (10.0.0.0/16).
Once you have changed the IP scheme for the West US VNet, for my example I changed the IP scheme to 10.1.0.0/16 for the West US VNet, and updated the DNS custom IP address to the new IP address of the Windows Server (which should be 10.1.0.4 in my example), you can proceed to Step 3 with one slight change. The Site-to-Site VPN connection will be a VNet-to-VNet connection from the West US VNet to the East US VNet, instead to an on-premises network. Here is a helpful article on connecting two VNet’s together. In the article I referenced, steps 1 & 2 have already been completed by our portal, you can proceed with Step 3. Create a gateway subnet. Step 4, should have also been completed by this time, so you can skip step 4 as well. Follow Step 5. Create a virtual network gateway. In Step 6. Create and configure TextVNet4 the virtual network has already been created in West US, but you will need to create a virtual network gateway for the VNet in West US. As you move to Step 7. Configure the TestVNet1 gateway connection, you will move back to the VNet created in East US and then connect it to the VNet in the West US. You can also complete Step 8. Configure the TestVNet4 gateway connection, and then on to Step 9. Verify your connections.
Once your two VNets are connected, you will be able to promote the Windows Server in the West US VNet to a Domain Controller within the Domain running in the East US Azure Region. At this point, you should now have Domain Controllers for your domain running in both the East US Azure Region and the West US Azure Region.
Now that you have the Domain Controller in the West US connected to the Domain in the East US, you can now deploy a Domain Joined RDS (or RemoteApp) solution in the West US Azure Region. Make sure to note that you will need to add a VM name prefix to the RDS VMs in the West US deployment to ensure you do not have duplicate computer names within the same Windows Server Active Directory. Our portal asks you if you’d like to add a VM name prefix, which is something we strongly encourage you to do. If you do not add a unique prefix to your RDS VMs, the deployment into the West US Azure Region will fail. Once you complete the provisioning wizard, the West US deployment will take about 90 minutes to complete.
Once you have your two RDS deployments running in both the East US and the West US, you can now leverage the Azure Traffic Manager to define a single URL that your users can connect to and it will route the users to the appropriate RDS deployment (East US or West US) based on the users’ location. This document discusses how to configure the Azure Traffic Manager to geographically load balance the traffic to your two RDS deployments.
At this point, you should now have a single URL that connects your users to a multi-Region RDS deployment that can connect to servers in either Azure Region. If you need full file resiliency, you could also deploy a Storage Spaces Direct Cluster to replicate your shared files between the two Azure regions if you choose, but that is beyond the scope of this document.
If you are interested in implementing any of the processes mentioned, please contact our support team and we would be happy to help you! You can get started by emailing Support @mycloudit.com and let us know what you would like to do.