Architectural Design and Considerations Guide for Initial Workloads Migration

Introduction

This document is primarily a mentor's guide that is intended to assist technical implementation consultants with the steps to begin onboarding an end customer or organization to Microsoft Azure. Leveraging the "Setting the Scene – Successful Migration Scenarios" documents, along with the structured checklist provided in the "Master Engagement Plan/Checklist" document, this guide is the typical process a consultant would go through to drive successful initial workload migrations.

This guide includes links to existing Microsoft technical step-by-step implementation resources and associated training materials that will help an implementation consultant of varying Azure experience and expertise to navigate the process of workload migrations to Azure. This document should be used as a reference guide to become familiar with Azure and the various possible migration options for workloads from onpremise to Azure.

Creating the Virtual Network and Site-to-Site VPN for the Azure Virtual Machines

One of the first steps an organization does in integrating an on-premise datacenter to Microsoft Azure is to stretch the on-premise datacenter network to Azure. This connectivity is accomplished through a Site to Site VPN, which provides a security boundary so that the servers and workloads running in Azure are integrated with the stretched network of the on-premise datacenter. The network in Azure appears as part of the on-premise network, allowing servers/VMs in Azure to be joined to the onpremise Active Directory and also allow servers/VMs in Azure to be patched, monitored and managed as if they were within the on-premise datacenter.

A virtual network is required for the Azure Virtual Machines running in the cloud to cross a VPN gateway and connect back to the on-premises network. If a Virtual Machine in Azure is not part of a virtual network, or if the virtual network does not have a gateway, the Azure Virtual Machine will still work but it will not be able to connect back to the on-premises network directly.

Starting with Step 1 of the Microsoft online documentation that shows how to "Create a VNet with a Site-to-Site connection using the Azure Portal," this guide walks through the creation of an Azure network and a gateway as well as the creation of the VPN tunnel.

Important notes:

  • In step 1 of the guide linked above, you'll be defining the virtual network's address space. Make sure this doesn't overlap with any of your on-premises address space. For performance, choose an Azure region that reasonably corresponds to your on-premises datacenter.
  • In step 3, you'll be specifying DNS servers. You can specify the IP addresses of machines across the VPN in the on-premises network, if that is the desired configuration. These can be updated later if a Domain Controller or other DNS server is placed in the Azure Virtual Network after it is created.
  • In step 5, you'll create the VPN gateway. This takes some time (about 1 hour) and depends on what type of device is on the other end (on-premise) of the connection. Check this list for a list of compatible and supported VPN devices. If you don't have any of those appliances available, the same can be done with Remote Routing and Access Services running on a Windows Server 2012 or higher machine with a public IP address.
  • In step 6, you'll configure the network on Azure so the gateway knows what traffic to route. You'll need the public IP address of the VPN endpoint you plan to use in the on-premises network, as well as the address spaces that will be routed to on-premises through the Site-to-Site VPN.

Migrating the First Workload

With the Azure Virtual Network created and a site-to-site link established with the onpremises network, the first workload can now be migrated to Azure. For this example, a standalone IIS Web Server will be migrated. Once the Virtual Machine is created in Azure, creating the web server is identical to an on-premises server.

Important notes:

  • In this the Create the Windows virtual machine section of the "Create your first Windows virtual machine in the Azure portal" guide, use a size A1 Virtual Machine for this example.
  • If the Virtual Machine is to be public facing, it will need a Public IP and Network Security Group to allow port 80/443 through on the Public IP. Otherwise a Public IP can be omitted. The document and steps for Network Security Groups and allowing access can be found here, starting at the Open port 80 section. Follow these steps after the creation of the Virtual Machine in the "Create your first Windows virtual machine in the Azure portal" guide.

Following the guide, create a Windows Server 2016 Virtual Machine. This document walks through the creation of a Virtual Machine on the Azure Resource Manager as well as the networking of the Virtual Machine.

  • There are also some valuable training videos and guides on Microsoft Virtual Academy if you need a training refresher and visual step-by-step walkthrough on the creation of Virtual Machines in Azure. Those videos can be found at here and here.
  • If you would like to do the Virtual Machine creation through PowerShell, a guide titled "Create a Windows Virtual Machine using Resource Manager and PowerShell" can be found here. You can refer to it to see the PowerShell syntax for the Resource Manager operations.

Once the virtual machine is created and online, it is accessible for remote access through the steps outlined in the creation document. A DNS entry should be made for the Virtual Machine in your internal DNS server to allow connectivity for testing purposes.

At this point, Windows Server roles and applications can be installed on the newly created virtual machine, such as installing Microsoft IIS through Server Manager (stepby-step documentation is available here if needed). With IIS installed and running, HTML code can be pushed to the server either over the Site-to-Site VPN from the onpremises network using a simple \\servername\sharename SMB connection or copying through the remote desktop session.

Once the web application and code has been installed on the server, the Virtual Machine can be tested to ensure functionality:

  • Navigate to the webpage from 'localhost' (Azure Virtual Machine) to make sure all the code was successfully copied and is functioning.
  • Navigate to the webpage from across the Site-to-Site VPN from an on-premises machine by using the hostname you put into the DNS server above to ensure traffic is traversing the VPN correctly.
  • (If web server is public) Navigate to the webpage from the public IP address. You can collect the public IP address from the Essentials blade of your Virtual Machine when you click on it. See here for more information.

At this point, with a successful validation, the DNS name for the on-premises Web server (www, web, etc.) can be failed over to point to the Azure Virtual Machine to complete the migration and begin to have the Azure Virtual Machine serve requests rather than the on-premises server.

Confirming Basic Functionality in Microsoft Azure

Now that there is a virtual network, a site-to-site VPN, and the first workload running in Azure, other functions can be explored.

  • Accessing the Virtual Machine: You can access the Virtual Machine directly through the Azure interface using the Remote Desktop method as documented here, or you can Remote Desktop to it from a machine in your on-premises network by IP or hostname if you have allowed for that in your Virtual Machine's firewall settings.
  • Patching the Virtual Machine: Azure Virtual Machines need to be patched the same as on-premises systems. These Virtual Machines will be able to work with your standard patching process (e.g. WSUS, SCCM, standalone patching through Windows Update, etc.).
  • Monitoring the Virtual Machine: Azure Virtual Machines are monitored and managed just as the on-premises machines. Agents can be installed (e.g. SCOM, Splunk, Solarwinds) and report into your existing management servers.

Azure native options should also be explored as well. Options such as the Operations Management Suite (OMS) which can also be integrated with System Center Operations Manager (SCOM). These tools can handle log collection, monitoring, and system updates all within Azure itself.

Migrating the Second Workload (Example: Simple Single Server Web/SQL Configuration)

Now that the first workload is working and some basic Azure functions have been covered, the second workload can be migrated. This example will be similar to the first workload, with the exception of this server being an IIS Server and with an integrated SQL Server backend on the same Virtual Machine. Follow the instructions in the first workload as far as building the Virtual Machine. This machine will need to be larger than the first workload because of the SQL Server, so this machine should be an A3 Azure instance or higher.

Important notes:

  • Under the Create the Windows Virtual Machine section in the aforementioned guide, use a size A3 Virtual Machine for this example.

Following the previously mentioned guide here, create a Windows Server 2016 Virtual Machine on the virtual network previously created. Connect to the Virtual Machine, install Microsoft SQL Server, and install the Microsoft IIS role as done in the first workload (documented here). Backup the existing SQL database through SQL Server Management Studio. Copy the HTML code from the on-premises machine (documented here) to the Azure Virtual Machine over the network. Restore the database in SQL Server running on Azure and install the HTML code into IIS.

Once the database is mounted and the HTML code is installed, the Virtual Machine should be tested to ensure functionality:

  • Navigate to the webpage from 'localhost' (Azure Virtual Machine) to make sure all the code was successfully copied and is functioning.
  • Navigate to the webpage from across the Site-to-Site VPN from an on-premises machine by using the hostname you put into DNS server above to ensure traffic is traversing the VPN correctly.
  • (If web server is public) Navigate to the webpage from the public IP address. You can collect the public IP address from the Essentials blade of your Virtual Machine when you click on it. See here for more information.

Migrating the Second Workload (Example: Two Server Web & SQL Server Configuration)

Another common scenario for a second workload that could be targeted for the migration to Azure would be a two-server configuration that comprises of a Web server and a separate SQL server as part of the configuration. In this example, an IIS server with a SQL backend will be migrated, but SQL Server will be on a separate Virtual Machine. Overall, this configuration is not much more complicated than the first and second workloads we migrated. The only addition is needing to validate the network connectivity between the two machines.

Important notes:

  • Under the Create the Windows Virtual Machine section in the aforementioned guide, use size A2 Virtual Machines for this example. In the Virtual Machine creation guide, there is an option to build a Virtual Machine that already has SQL 2016 Enterprise installed. This can be chosen instead of Windows Server 2016 to save a step if your application already supports SQL 2016. However, for demonstrating Azure it is likely better to preserve parity with the on-premises application, as well as for testing purposes.
  • There is another way to migrate workloads to Azure that will be introduced in this workload. Both methods are viable, but the second method is more scalable to complex workloads and will allow for failover without needing to build a second set of servers.

Migration Method 1:

Following the previously mentioned guide here, create two Windows Server 2016 Virtual Machines on the Virtual Network previously created. On the Virtual Machine created for SQL, install the relevant SQL Server version to the app being migrated. Backup the database from the on-premises SQL Server and restore it onto this Azure SQL Server Virtual Machine. On the Virtual Machine created for IIS, install IIS (documented here) and copy the HTML code from the on-premises workload being migrated. With everything now copied to the Azure Virtual Machines, test the workload functionality by accessing the Web server in the same ways the first and second workload were tested.

Migration Method 2

This migration method copies the Virtual Machines from on-premise to Azure using Azure Site Recovery (ASR). Virtual Machines are then failed over to Azure using the Test Failover feature to start the Virtual Machines in Azure and validate their functionality. There will be more setup involved here as either Hyper-V or VMware environments will need to be prepared to copy the Virtual Machine to Azure.

ASR setup and configuration guides, along with guides for different virtualized environments, are part of the content framework all program partners have access to. Please refer to those documents for more information on setting up ASR in different environments. Additionally, the following docs have instructions depending on the environment you are coming from:

  • Hyper-V without System Center VMM
  • Hyper-V with System Center VMM VMware VMs

Follow the guide that suits your environment to replicate the Virtual Machines to Azure. This example below assumes a Hyper-V environment with VMM, so please refer to that guide when reviewing the following steps.

  • Follow the guide up to Step 7: Test your deployment.
  • The Test Failover will not shutdown on-premises Virtual Machines.
    • If you are connecting Virtual Machines via the Site-to-Site network, it is recommended shutting down the on-premises Virtual Machines to avoid conflicts on the network. Do this at a time when it is acceptable, like during a maintenance window for testing of the application.
    • If the Virtual Machines are connecting to an isolated virtual network, the on-premises counterparts do not need to be shutdown. However, it is likely that the app that is being tested will need access to authentication and other Domain Controller services. Thus, some extra configuration will be needed in ASR to bring a Domain Controller into the test mix, and the failed over DC will also need some light configuration to update the DNS entries of the newly failed over workload.
  • Test the workload by accessing the web server and testing web site functionality in the same way as the first and second workloads.
  • At the end of the test (5c of Step 7), the test Virtual Machines will be cleaned up and the on-premises Virtual Machines can be restarted. Unlike a Planned Failover, no changes you made during your test will be written back to on-premises.
  • If the test was successful, move forward with a Planned Failover to bring the workload live into Azure. The on-premises counterparts will replicate with the active Azure instance to stay up to date.

Extending Microsoft Active Directory to the Azure Network

In a potential initial migration scenario where the servers are standalone systems, there may not have been a need to add a Microsoft Active Directory domain controller in Azure if there's no AD authentication needed. However, as migrated workloads get more complex, the servers may need to be joined to Active Directory and/or having a domain controller in Azure may be required.

To add a domain controller in Microsoft Azure, it is simply a matter of creating a Windows Server Virtual Machine (matching the appropriate version of Window Server on-premise Active Directory domain controllers in the organization), and promoting the server to becoming a domain controller. The process of creating a domain controller in Azure is as follows:

  • Follow the steps for the First or Second Workloads earlier in this guide to build a Virtual Machine to be a Domain Controller in Azure. Since this is a small test deployment, an A2 sized Virtual Machine should be sufficient.
  • Follow the guide here (Install AD DS on Azure VMs and Reconfigure DNS Server for the virtual network steps) to promote a Virtual Machine to a Domain Controller in Azure.
    • Reserving a static IP address for the Domain Controller is recommended. This can be done with the following cmdlet. Update it with your Virtual Machine name (in place of "AzureDC1" in this example) and your IP address (in place of 10.0.0.4 in this example) in the virtual network:
    • Get-AzureVM -ServiceName AzureDC1 -Name AzureDC1 | SetAzureStaticVNetIP -IPAddress 10.0.0.4 | Update-AzureVM

Summary

It is at this point that the customer will have one or two workloads and likely an Active Directory Domain Controller (potentially 3-5 total Virtual Machines) running in Microsoft Azure. The customer should integrate these Azure Virtual Machines into their normal server and application administration & management process that includes patching, monitoring, and ongoing maintenance.

The links in this guide have not only shared deployment guidance, but also Microsoft Azure training resources that are helpful for customers who are new to Azure and are just getting up to speed on familiarizing themselves with the ongoing maintenance and management of Azure workloads.

With these initial workloads running in Azure, the next step is to quickly identify the next 12-15 servers that will be migrated to Azure, and continue on in advancing the migration of Virtual Machines to Azure via tools and automation.