Skip to content

dvanderslice/azureimmersionworkshop

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 

Repository files navigation

Catapult Systems Azure Immersion Workshop - Infrastructure Migration Microsoft Cloud Workshops

Line-of-business application migration
Hands-on lab step-by-step
November 2020

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of Microsoft of the site or the products contained therein.

© 2020 Microsoft Corporation. All rights reserved.

Microsoft and the trademarks listed at https://www.microsoft.com/en-us/legal/intellectualproperty/Trademarks/Usage/General.aspx are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Contents

Line-of-business application migration hands-on lab step-by-step

Abstract and learning objectives

In this hands-on lab, you will learn how to assess and migrate a multi-tier application from Hyper-V to Azure. You will learn how to use Azure Migrate as the hub for executing a migration, together with accompanying tools.

After this hands-on lab, you will know the role of Azure Migrate and related migration tools and how to use them to successfully migrate an on-premises multi-tier application to Azure.

Overview

During the automated provisioning of this lab environment, you will have a virtual machine provisioned that contains an on-premises infrastructure hosted in Hyper-V. This infrastructure is hosting a multi-tier application called 'SmartHotel', using Hyper-V VMs for each of the application tiers.

During the lab, you will migrate this entire application stack to Azure. This will include assessing the on-premises application using Azure Migrate; assessing the database migration using Microsoft Data Migration Assistant (DMA); migrating the database using the Azure Database Migration Service (DMS); and migrating the web and application tiers using Azure Migrate: Server Migration. This last step includes migration of both Windows and Linux VMs.

Solution architecture

The SmartHotel application comprises 4 VMs hosted in Hyper-V:

  • Database tier Hosted on the smarthotelSQL1 VM, which is running Windows Server 2016 and SQL Server 2017.

  • Application tier Hosted on the smarthotelweb2 VM, which is running Windows Server 2012R2.

  • Web tier Hosted on the smarthotelweb1 VM, which is running Windows Server 2012R2.

  • Web proxy Hosted on the UbuntuWAF VM, which is running Nginx on Ubuntu 18.04 LTS.

For simplicity, there is no redundancy in any of the tiers.

Note: For convenience, the Hyper-V host itself is deployed as an Azure VM. For the purposes of the lab, you should think of it as an on-premises machine.

A slide shows the on-premises SmartHotel application architecture. This comprises a SmartHotelHost server running Microsoft Hyper-V. This server hosts 4 VMs: UbuntuWAF, SmartHotelWeb1, SmartHotelWeb2, and SmartHotelSQL1. A series of arrows show how these VMs will be migrated to Azure. The first 3 VMs have an arrow labeled 'Azure Migrate: Server Migration' pointing to 3 similarly-labeled VMs in Azure. The last VM, SmartHotelSQL1, has an arrow labeled 'Azure Database Migration Service' pointing to an Azure SQL Database. A third arrow labeled 'Azure Migrate: Server Assessment' and 'Data Migration Assistant (DMA)' points from all 4 on-premises VMs to an Azure Migrate dashboard showing migration readiness.

Throughout this lab, you will use Azure Migrate as your primary tool for assessment and migration. In conjunction with Azure Migrate, you will also use a range of other tools, as detailed below.

To assess the Hyper-V environment, you will use Azure Migrate: Server Assessment. This includes deploying the Azure Migrate appliance on the Hyper-V host to gather information about the environment. For deeper analysis, the Microsoft Monitoring Agent and Dependency Agent will be installed on the VMs, enabling the Azure Migrate dependency visualization.

The SQL Server database will be assessed by installing the Microsoft Data Migration Assistant (DMA) on the Hyper-V host, and using it to gather information about the database. Schema migration and data migration will then be completed using the Azure Database Migration Service (DMS).

The application, web, and web proxy tiers will be migrated to Azure VMs using Azure Migrate: Server Migration. You will walk through the steps of building the Azure environment, replicating data to Azure, customizing VM settings, and performing a failover to migrate the application to Azure.

Note: After migration, the application could be modernized to use Azure Application Gateway instead of the Ubuntu Nginx VM, and to use Azure App Service to host both the web tier and application tiers. These optimizations are out of scope of this lab, which is focused only on a 'lift and shift' migration to Azure VMs.

Exercise 1: Discover and assess the on-premises environment

Duration: 60 minutes

In this exercise, you will use Azure Migrate: Server Assessment to assess the on-premises environment. This will include selecting Azure Migrate tools, deploying the Azure Migrate appliance into the on-premises environment, creating a migration assessment, and using the Azure Migrate dependency visualization.

All steps will be completed within your lab virtual machine. If you require assistance please raise your hand and the workshop facilitator will contact you and bring you to a breakout room as neccessary.

Task 1: Create the Azure Migrate project and add assessment and migration tools

In this task, you will create the Azure Migrate project and select the assessment and migration tools.

Note: In this lab, you will use the Microsoft-provided assessment and migration tools within Azure Migrate. A number of third-party tools are also integrated with Azure Migrate for both assessment and migration. You may wish to spend some time exploring these third-party options outside of this lab.

  1. Open your browser, navigate to https://portal.azure.com, and log in with your Azure subscription credentials. The credentials are on the desktop of your lab virtual machine. Follow the link in the automated email to access your lab. You do not need to access the portal.azure.com website from your local machine.

  2. Select All services in the portal's left navigation, then search for and select Azure Migrate to open the Azure Migrate Overview blade, shown below.

    Screenshot of the Azure Migrate overview blade.

  3. Select Assess and migrate servers, then Create project. Select your subscription and create a new resource group named AzureMigrateRG. Enter SmartHotelMigration as the Migrate project name, and choose a geography close to you to store the migration assessment data. Then select Create.

    Note: If you are running this lab in a shared subscription you will need to use a migrate project name that is unique in the subscription. Append characters to the end of migrate project name to make your project name unique. For example: SmartHotelMigration1234.

    Screenshot of the Azure Migrate 'Create project' blade, showing the Azure Migrate project name, resource group and geography.

  4. The Azure Migrate deployment will start. Once it has completed, you should see the Azure Migrate: Server Assessment and Azure Migrate: Server Migration panels for the current migration project, as shown below.

    Screenshot of the Azure Migrate 'Create project' blade, showing the Server Assessment and Server Migration panels.

Task summary

In this task you created an Azure Migrate project, using the default built-in tools for server assessment and server migration.

Task 2: Deploy the Azure Migrate appliance

In this task, you will deploy and configure the Azure Migrate appliance in the on-premises Hyper-V environment. This appliance communicates with the Hyper-V server to gather configuration and performance data about your on-premises VMs, and returns that data to your Azure Migrate project.

  1. Under Azure Migrate: Server Assessment, select Discover to open the Discover machines blade. Under Are your machines virtualized?, select Yes, with Hyper-V.

    Screenshot of the Azure Migrate 'Discover machines' blade, with Hyper-V selected.

  2. In 1: Generate Azure Migrate project key, provide SmartHotelAppl as name for the Azure Migrate appliance that you will set up for discovery of Hyper-V VMs. Select Generate key to start the creation of the required Azure resources.

    Screenshot of the Azure Migrate 'Discover machines' blade showing the 'Generate Azure Migrate project key' section.

    Note: If you are running this lab in a shared Azure Migrate project, you will need to provide an appliance name that is unique in the project. Append characters to the end of appliance name to make your appliance name unique. For example: SmartHotelAppl123.

  3. Wait for the key to be generated, then copy the Azure Migrate project key to your clipboard.

    Screenshot of the Azure Migrate 'Discover machines' blade showing the Azure Migrate project key.

  4. Read through the instructions on how to download, deploy and configure the Azure Migrate appliance. Close the 'Discover machines' blade (do not download the .VHD file or .ZIP file, the .VHD has already been downloaded for you).

  5. In a separate browser tab, navigate to the Azure portal. In the global search box, enter SmartHotelHost, then select the SmartHotelHost virtual machine.

    Screenshot of the Azure portal search box, searching for the SmartHotelHost virtual machine.

  6. Select Connect, select RDP, then download the RDP file and connect to the virtual machine using username demouser and password demo!pass123.

  7. In Server Manager, select Tools, then Hyper-V Manager (if Server Manager does not open automatically, open it by selecting Start, then Server Manager). In Hyper-V Manager, select SMARTHOTELHOST. You should now see a list of the four VMs that comprise the on-premises SmartHotel application.

    Screenshot of Hyper-V Manager on the SmartHotelHost, showing 4 VMs: smarthotelSQL1, smarthotelweb1, smarthotelweb2 and UbuntuWAF.

You will now deploy the Azure Migrate appliance virtual machine. Normally, you would first need to download the .ZIP file containing the appliance to your Hyper-V host, and unzip it. To save time, these steps have been completed for you.

  1. In Hyper-V Manager, under Actions, select Import Virtual Machine... to open the Import Virtual Machine wizard.

    Screenshot of Hyper-V Manager, with the 'Import Virtual Machine' action highlighted.

  2. At the first step, Before You Begin, select Next.

  3. At the Locate Folder step, select Browse and navigate to F:\VirtualMachines\AzureMigrateAppliance (the folder name may also include a version number), then choose Select Folder, then select Next.

Screenshot of the Hyper-V 'Import Virtual Machine' wizard with the F:\VirtualMachines\AzureMigrateAppliance folder selected.

  1. At the Select Virtual Machine step, the AzureMigrateAppliance VM should already be selected. Select Next.

  2. At the Choose Import Type step, keep the default setting Register the virtual machine in-place. Select Next.

  3. At the Connect Network step, you will see an error that the virtual switch previously used by the Azure Migrate appliance could not be found. From the Connection drop down, select the Azure Migrate Switch, then select Next.

    Screenshot of the Hyper-V 'Import Virtual Machine' wizard at the 'Connect Network' step. The 'Azure Migrate Switch' has been selected.

    Note: The Azure Migrate appliance needs access to the Internet to upload data to Azure. It also needs access to the Hyper-V host. However, it does not need direct access to the application VMs running on the Hyper-V host. To protect the application environment, the Azure Migrate Appliance should be deployed to a separate subnet within Hyper-V, rather than in the same subnet as your application.

    The Hyper-V environment has a NAT network using the IP address space 192.168.0.0/16. The internal NAT switch used by the SmartHotel application uses the subnet 192.168.0.0/24, and each VM in the application has been assigned a static IP address from this subnet.

    The Azure Migrate Appliance will be connected to a separate subnet 192.168.1.0/24, which has been set up for you. Using the 'Azure Migrate Switch' connects the appliance to this subnet. The appliance is assigned an IP address from this subnet using a DHCP service running on the SmartHotelHost.

  4. Review the summary page, then select Finish to create the Azure Migrate appliance VM.

  5. In Hyper-V Manager, select the AzureMigrateAppliance VM, then select Start on the left.

Screenshot of Hyper-V Manager showing the start button for the Azure Migrate appliance.

Task summary

In this task you deployed the Azure Migrate appliance in the on-premises Hyper-V environment.

Task 3: Configure the Azure Migrate appliance

In this task, you will configure the Azure Migrate appliance and use it to complete the discovery phase of the migration assessment.

  1. In Hyper-V Manager, select the AzureMigrateAppliance VM, then select Connect on the left.

    Screenshot of Hyper-V Manager showing the connect button for the Azure Migrate appliance.

  2. A new window will open showing the Azure Migrate appliance. Wait for the License terms screen to show, then select Accept.

    Screenshot of the Azure Migrate appliance showing the license terms.

  3. On the Customize settings screen, set the Administrator password to demo!pass123 (twice). Then select Finish.

    Note: When entering the password, the VM uses a US keyboard mapping. If you are using a non-US keyboard, some characters may be entered incorrectly. Select the 'eyeball' icon in the second password entry box to check the password has been entered correctly.

    Screenshot of the Azure Migrate appliance showing the set Administrator password prompt.

  4. At the Connect to AzureMigrateAppliance prompt, set the appliance screen size using the slider, then select Connect.

  5. Log in with the Administrator password demo!pass123 (the login screen may pick up your local keyboard mapping, use the 'eyeball' icon to check).

  6. Wait. After a minute or two, the browser will open showing the Azure Migrate appliance configuration wizard (it can also be launched from the desktop shortcut).

    On opening of the appliance configuration wizard, a pop-up with the license terms will appear. Accept the terms by selecting I agree.

    Screenshot of the Azure Migrate appliance terms of use.

  7. Under Set up prerequisites, the following two steps to verify Internet connectivity and time synchronization should pass automatically.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the first step 'Set up prerequisites' in progress. The internet connectivity, and time sync steps have been completed.

  8. Wait while the wizard installs the latest Azure Migrate updates. If prompted for credentials, enter user name Administrator and password demo!pass123. Once the Azure Migrate updates are completed, you may see a pop-up if the management app restart is required, and if so, select Refresh to restart the app.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the prompt to restart the management app after installing updates.

    Once restarted, the 'Set up prerequisites' steps of the Azure Migrate wizard will re-run automatically. Once the prerequisites are completed, you can proceed to the next panel, Register with Azure Migrate.

  9. At the next phase of the wizard, Register with Azure Migrate, paste the Azure Migrate project key copied from the Azure portal earlier. (If you do not have the key, go to Server Assessment > Discover > Manage existing appliances, select the appliance name you provided at the time of key generation and copy the corresponding key.)

    Screenshot of the Azure Migrate appliance configuration wizard, showing the registration with the Azure Migrate project.

  10. After you select Login, a new window will open asking for a code. This code is located below the Azure Migrate project key. Copy and paste this code in the login field. You will then be asked for your Azure portal credentials to complete the login process.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the registration with the login code for the Azure Migrate project.

    Screenshot of the Azure Migrate appliance login window, showing where to copy and paste the login code for the Azure Migrate project.

  11. Select Login. This will open an Azure login prompt in a new browser tab (if it doesn't appear, make sure the pop-up blocker in the browser is disabled). Log in using your Azure credentials. Once you have logged in, return to the Azure Migrate Appliance tab and the appliance registration will start automatically.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the registration with the Azure Migrate project as completed.

    Once the registration has completed, you can proceed to the next panel, Manage credentials and discovery sources.

  12. In Step 1: Provide Hyper-V host credentials, select Add credentials.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the 'Add credentials' button.

  13. Specify hostlogin as the friendly name for credentials, username demouser, and password demo!pass123 for the Hyper-V host/cluster that the appliance will use to discover VMs. Select Save.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the 'Add credentials' panel.

    Note: The Azure Migrate appliance may not have picked up your local keyboard mapping. Select the 'eyeball' in the password box to check the password was entered correctly.

    Note: Multiple credentials are supported for Hyper-V VMs discovery, via the 'Add more' button.

  14. In Step 2: Provide Hyper-V host/cluster details, select Add discovery source to specify the Hyper-V host/cluster IP address/FQDN and the friendly name for credentials to connect to the host/cluster.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the 'Add discovery source' button.

  15. Select Add single item, select hostlogin as the friendly name, and enter SmartHotelHost under 'IP Address / FQDN'.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the 'Add discovery source' panel.

    Note: You can either Add single item at a time or Add multiple items in one go. There is also an option to provide Hyper-V host/cluster details through Import CSV.

  16. Select Save. The appliance will validate the connection to the Hyper-V hosts/clusters added and show the Validation status in the table against each host/cluster.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the successful validation of the configured discovery source.

    Note: When adding discovery sources:

    • For successfully validated hosts/clusters, you can view more details by selecting their IP address/FQDN.
    • If validation fails for a host, review the error by selecting the Validation failed in the Status column of the table. Fix the issue and validate again.
    • To remove hosts or clusters, select Delete.
    • You can't remove a specific host from a cluster. You can only remove the entire cluster.
    • You can add a cluster, even if there are issues with specific hosts in the cluster.
  17. Select Start discovery to kick off VM discovery from the successfully validated hosts/clusters.

    Screenshot of the Azure Migrate appliance configuration wizard, showing the 'Start discovery' button.

  18. Wait for the Azure Migrate status to show Discovery has been successfully initiated. This will take several minutes. After the discovery has been successfully initiated, you can check the discovery status against each host/cluster in the table.

  19. Return to the Azure Migrate blade in the Azure portal. Select Servers, then select Refresh. Under Azure Migrate: Server Assessment you should see a count of the number of servers discovered so far. If discovery is still in progress, select Refresh periodically until 5 discovered servers are shown. This may take several minutes.

    Screenshot of the Azure Migrate portal blade. Under 'Azure Migrate: Server Assessment' the value for 'discovered servers' is '5'.

    Wait for the discovery process to complete before proceeding to the next Task.

Task summary

In this task you configured the Azure Migrate appliance in the on-premises Hyper-V environment and started the migration assessment discovery process.

Task 4: Create a migration assessment

In this task, you will use Azure Migrate to create a migration assessment for the SmartHotel application, using the data gathered during the discovery phase.

  1. Continuing from Task 3, select Assess under Azure Migrate: Server Assessment to start a new migration assessment.

    Screenshot of the Azure Migrate portal blade, with the '+Assess' button highlighted.

  2. On the Assess servers blade, enter SmartHotelAssessment as the assessment name.

    Screenshot of the Azure Migrate 'Assess servers' blade, showing the assessment name.

  3. Under Assessment properties, select View all.

    Screenshot of the Azure Migrate 'Assess servers' blade, with the 'view all' assessment properties link highlighted.

  4. The Assessment properties blade allows you to tailor many of the settings used when making a migration assessment report. Take a few moments to explore the wide range of assessment properties. Hover over the information icons to see more details on each setting. Choose any settings you like, then select Save. (You have to make a change for the Save button to be enabled; if you don't want to make any changes, just close the blade.)

    Screenshot of the Azure Migrate 'Assessment properties' blade, showing a wide range of migration assessment settings.

  5. Select Next to move to the Select machines to assess tab. Choose Create New and enter the group name SmartHotel VMs. Select the smarthotelweb1, smarthotelweb2 and UbuntuWAF VMs.

    Screenshot of the Azure Migrate 'Assess servers' page. A new server group containing servers smarthotelweb1, smarthotelweb2, and UbuntuWAF.

    Note: There is no need to include the smarthotelSQL1 or AzureMigrateAppliance VMs in the assessment, since they will not be migrated to Azure. (The SQL Server will be migrated to the SQL Database service and the Azure Migrate Appliance is only used for migration assessment.)

  6. Select Next, followed by Create assessment. On the Azure Migrate - Servers blade, select Refresh periodically until the number of assessments shown is 1. This may take several minutes.

    Screenshot from Azure Migrate showing the number of assessments as '1'.

  7. Select Assessments under Azure Migrate: Server Assessment to see a list of assessments. Then select the actual assessment.

    Screenshot showing a list of Azure Migrate assessments. There is only one assessment in the list. It has been highlighted.

  8. Take a moment to study the assessment overview.

    Screenshot showing an Azure Migrate assessment overview for the SmartHotel application.

  9. Select Edit properties. Note how you can now modify the assessment properties you chose earlier. Change a selection of settings, and Save your changes. After a few moments, the assessment report will update to reflect your changes.

  10. Select Azure readiness (either the chart or on the left navigation). Note that for the UbuntuWAF VM, a specific concern is listed regarding the readiness of the VM for migration.

    Screenshot showing the Azure Migrate assessment report on the VM readiness page, with the VM readiness for each VM highlighted.

  11. Select Unknown OS for UbuntuWAF. A new browser tab opens showing Azure Migrate documentation. Note on the page that the issue relates the OS not being specified in the host hypervisor, so you must confirm the OS type and version is supported.

    Screenshot of Azure documentation showing troubleshooting advice for the 'Unknown OS' issue. It states that the OS was listed as 'Other' in the host hypervisor.

  12. Return to the portal browser tab to see details of the issue. Note the recommendation to migrate the VM using Azure Migrate: Server Migration.

    Screenshot of Azure portal showing the migration recommendation for the UbuntuWAF VM.

  13. Take a few minutes to explore other aspects of the migration assessment.

Task summary

In this task you created and configured an Azure Migrate migration assessment.

Task 5: Configure dependency visualization

When migrating a workload to Azure, it is important to understand all workload dependencies. A broken dependency could mean that the application doesn't run properly in Azure, perhaps in hard-to-detect ways. Some dependencies, such as those between application tiers, are obvious. Other dependencies, such as DNS lookups, Kerberos ticket validation or certificate revocation checks, are not.

In this task, you will configure the Azure Migrate dependency visualization feature. This requires you to first create a Log Analytics workspace, and then to deploy agents on the to-be-migrated VMs.

  1. Return to the Azure Migrate blade in the Azure Portal, and select Servers. Under Azure Migrate: Server Assessment select Groups, then select the SmartHotel VMs group to see the group details. Note that each VM has their Dependencies status as Requires agent installation. Select Requires agent installation for the smarthotelweb1 VM.

    Screenshot showing the SmartHotel VMs group. Each VM has dependency status 'Requires agent installation'.

  2. On the Dependencies blade, select Configure OMS workspace.

    Screenshot of the Azure Migrate 'Dependencies' blade, with the 'Configure OMS Workspace' button highlighted.

  3. Create a new OMS workspace. Use AzureMigrateWS<unique number> as the workspace name, where <unique number> is a random number. Choose a workspace location close to your lab deployment, then select Configure.

    Screenshot of the Azure Migrate 'Configure OMS workspace' blade.

  4. Wait for the workspace to be deployed. Once it is deployed, navigate to it and select Agents management under Settings on the left. Make a note of the Workspace ID and Primary Key (for example by using Notepad).

    Screenshot of part of the Azure Migrate 'Dependencies' blade, showing the OMS workspace ID and key.

  5. Return to the Azure Migrate 'Dependencies' blade. Copy each of the 4 agent download URLs and paste them alongside the Workspace ID and key you noted in the previous step.

    Screenshot of the Azure Migrate 'Dependencies' blade with the 4 agent download links highlighted.

  6. Return to the RDP session with the SmartHotelHost. In Hyper-V Manager, select smarthotelweb1 and select Connect.

    Screenshot from Hyper-V manager highlighting the 'Connect' button for the smarthotelweb1 VM.

  7. Select Connect again when prompted and log in to the Administrator account using the password demo!pass123.

  8. Open Internet Explorer, and paste the link to the 64-bit Microsoft Monitoring Agent for Windows, which you noted earlier. When prompted, Run the installer.

    Note: You may need to disable Internet Explorer Enhanced Security Configuration on Server Manager under Local Server to complete the download.

    Screenshot showing the Internet Explorer prompt to run the installer for the Microsoft Monitoring Agent.

  9. Select through the installation wizard until you get to the Agent Setup Options page. From there, select Connect the agent to Azure Log Analytics (OMS) and select Next. Enter the Workspace ID and Workspace Key that you copied earlier, and select Azure Commercial from the Azure Cloud drop-down. Select through the remaining pages and install the agent.

    Screenshot of the Microsoft Monitoring Agent install wizard, showing the Log Analytics (OMS) workspace ID and key.

  10. Paste the link to the Dependency Agent Windows installer into the browser address bar. Run the installer and select through the install wizard to complete the installation.

    Screenshot showing the Internet Explorer prompt to run the installer for the Dependency Agent.

    Note: You do not need to configure the workspace ID and key when installing the Dependency Agent, since it uses the same settings as the Microsoft Monitoring Agent, which must be installed beforehand.

  11. Close the virtual machine connection window for the smarthotelweb1 VM. Connect to the smarthotelweb2 VM and repeat the installation process (steps 8-10) for both agents (the administrator password is the same as for smarthotelweb1).

You will now deploy the Linux versions of the Microsoft Monitoring Agent and Dependency Agent on the UbuntuWAF VM. To do so, you will first connect to the UbuntuWAF remotely using an SSH session.

  1. Return to the RDP session with the SmartHotelHost and open a command prompt using the desktop shortcut.

    Note: The SmartHotelHost runs Windows Server 2019 with the Windows Subsystem for Linux enabled. This allows the command prompt to be used as an SSH client. More info of supported Linux on Azure can be found here: https://Azure.com/Linux.

  2. Enter the following command to connect to the UbuntuWAF VM running in Hyper-V on the SmartHotelHost:

    ssh demouser@192.168.0.8
  3. Enter 'yes' when prompted whether to connect. Use the password demo!pass123.

    Screenshot showing the command prompt with an SSH session to UbuntuWAF.

  4. Enter the following command, followed by the password demo!pass123 when prompted:

    sudo -s

    This gives the terminal session elevated privileges.

  5. Enter the following command, substituting <Workspace ID> and <Workspace Key> with the values copied previously. Answer when prompted to restart services during package upgrades without asking.

    wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <Workspace ID> -s <Workspace Key>
  6. Enter the following command, substituting <Workspace ID> with the value copied earlier:

    /opt/microsoft/omsagent/bin/service_control restart <Workspace ID>
  7. Enter the following command. This downloads a script that will install the Dependency Agent.

    wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin
  8. Install the dependency agent by running the script download in the previous step.

    sh InstallDependencyAgent-Linux64.bin -s

    Screenshot showing that the Dependency Agent install on Linux was successful.

  9. The agent installation is now complete. Next, you need to generate some traffic on the SmartHotel application so the dependency visualization has some data to work with. Browse to the public IP address of the SmartHotelHost, and spend a few minutes refreshing the page and checking guests in and out.

Task summary

In this task you configured the Azure Migrate dependency visualization feature, by creating a Log Analytics workspace and deploying the Azure Monitoring Agent and Dependency Agent on both Windows and Linux on-premises machines.

Task 6: Explore dependency visualization

In this task, you will explore the dependency visualization feature of Azure Migrate. This feature uses data gathered by the dependency agent you installed in Task 5.

  1. Return to the Azure Portal and refresh the Azure Migrate SmartHotel VMs VM group blade. The 3 VMs on which the dependency agent was installed should now show their status as 'Installed'. (If not, refresh the page using the browser refresh button, not the refresh button in the blade. It may take up to 5 minutes after installation for the status to be updated.)

    Screenshot showing the dependency agent installed on each VM in the Azure Migrate VM group.

  2. Select View dependencies.

    Screenshot showing the view dependencies button in the Azure Migrate VM group blade.

  3. Take a few minutes to explore the dependencies view. Expand each server to show the processes running on that server. Select a process to see process information. See which connections each server makes.

    Screenshot showing the dependencies view in Azure Migrate.

Task summary

In this task you explored the Azure Migrate dependency visualization feature.

Exercise summary

In this exercise, you used Azure Migrate to assess the on-premises environment. This included selecting Azure Migrate tools, deploying the Azure Migrate appliance into the on-premises environment, creating a migration assessment, and using the Azure Migrate dependency visualization.

Exercise 2: Migrate the Application Database

Duration: 60 minutes

In this exercise you will migrate the application database from the on-premises Hyper-V virtual machine to a new database hosted in the Azure SQL Database service. You will use the Azure Database Migration Service to complete the migration, which uses the Microsoft Data Migration Assistant for the database assessment and schema migration phases.

Task 1: Register the Microsoft.DataMigration resource provider

Prior to using the Azure Database Migration Service, the resource provider Microsoft.DataMigration must be registered in the target subscription.

  1. Open the Azure Cloud Shell by navigating to https://shell.azure.com. Log in using your Azure subscription credentials if prompted to do so, select a PowerShell session, and accept any prompts.

  2. Run the following command to register the Microsoft.DataMigration resource provider:

    Register-AzResourceProvider -ProviderNamespace Microsoft.DataMigration

    Note: It may take several minutes for the resource provider to register. You can proceed to the next task without waiting for the registration to complete. You will not use the resource provider until task 3.

    You can check the status by running:

    Get-AzResourceProvider -ProviderNamespace Microsoft.DataMigration | Select-Object ProviderNamespace, RegistrationState, ResourceTypes

Task summary

In this task you registered the Microsoft.DataMigration resource provider with your subscription. This enables this subscription to use the Azure Database Migration Service.

Task 2: Create an Azure SQL Database

In this task you will create a new Azure SQL database to migrate the on-premises database to.

Note: This lab focuses on simplicity to teach the participant the technical tools required. In the , more consideration should go into the long-term plan prior to creating the first DB. For instance: Will this DB live in an Azure landing zone? Who will operate this environment post-migration? What policies are in place that the migration team should be aware of prior to migration? These landing zone and operating model related topics are covered in the Cloud Adoption Framework’s Ready methodology. You don’t need to deviate from the script, but be familiar with the four-step process in that methodology, so you can field those types of a questions if they come up in the lab.

  1. Open the Azure portal at https://portal.azure.com and log in using your subscription credentials if it's not still up.

  2. Expand the portal's left navigation by selecting Show portal menu in the top left then select + Create a resource, then select Databases, then select SQL Database.

    Azure portal screenshot showing the select path to create a SQL Database.

  3. The Create SQL Database blade opens, showing the Basics tab. Complete the form as follows:

    • Subscription: Select your subscription.

    • Resource group: (create new) SmartHotelDBRG

    • Database name: smarthoteldb

    • Server: Select Create new and fill in the New server blade as follows then select OK:

      • Server name: smarthoteldb[unique number]

      • Server admin login: demouser

      • Password: demo!pass123

      • Location: IMPORTANT: For most users, select the same region you used when you started your lab - this makes migration faster. If you are using an Azure Pass subscription, choose a different region to stay within the Total Regional vCPU limit.

    Note: You can verify the location by opening another browser tab, navigating to https://portal.azure.com and selecting Virtual Machines on the left navigation. Use the same region as the SmartHotelHost virtual machine.

    • Use SQL elastic pool: No

    • Compute + storage: Standard S0

    Note: To select the Standard S0 database tier, select Configure database, then Looking for basic, standard, premium?, select Standard and select Apply.

    Screenshot from the Azure portal showing the Create SQL Database blade.

    Screenshot from the Azure portal showing the New server blade (when creating a SQL database).

  4. Select Next: Networking > to move to the Networking tab. Confirm that No access is selected.

    Note: We will configure private endpoints to access our database later in the lab.

  5. Select Review + Create, then select Create to create the database. Wait for the deployment to complete.

Task summary

In this task you created an Azure SQL Database running on an Azure SQL Database Server.

Task 3: Create the Database Migration Service

In this task you will create an Azure Database Migration Service resource. This resource is managed by the Microsoft.DataMigration resource provider which you registered in task 1.

Note: The Azure Database Migrate Service (DMS) requires network access to your on-premises database to retrieve the data to transfer. To achieve this access, the DMS is deployed into an Azure VNet. You are then responsible for connecting that VNet securely to your database, for example by using a Site-to-Site VPN or ExpressRoute connection.

In this lab, the 'on-premises' environment is simulated by a Hyper-V host running in an Azure VM. This VM is deployed to the 'smarthotelvnet' VNet. The DMS will be deployed to a separate VNet called 'DMSVnet'. To simulate the on-premises connection, these two VNet have been peered.

  1. Return to the cloud shell browser tab you used in task 1 to register the Microsoft.DataMigration resource provider. Check that the registration has been completed by running the following command before proceeding further.

    Get-AzResourceProvider -ProviderNamespace Microsoft.DataMigration | Select-Object ProviderNamespace, RegistrationState, ResourceTypes
    

    Screenshot showing the resource provider 'registered' status.

  2. In the Azure portal, expand the portal's left navigation and select + Create a resource, search for migration, and then select Azure Database Migration Service from the drop-down list.

  3. On the Azure Database Migration Service blade, select Create.

    Screenshot showing the DMS 'create' button.

  4. In the Create Migration Service blade, on the Basics tab, enter the following values:

    • Subscription: Select your Azure subscription.

    • Resource group: AzureMigrateRG

    • Service Name: SmartHotelDBMigration

    • Location: Choose the same region as the SmartHotel host.

    • Service mode: Azure

    • Pricing tier: Standard: 1 vCore

    Screenshot showing the Create DMS 'Basics' tab.

  5. Select Next: Networking to move to the Networking tab, and select the DMSvnet/DMS virtual network and subnet in the SmartHotelHostRG resource group.

    Screenshot showing the Create DMS 'Networking' tab.

  6. Select Review + create, followed by Create.

Note: Creating a new migration service can take around 20 minutes. You can continue to the next task without waiting for the operation to complete. You will not use the Database Migration Service until task 5.

Task summary

In this task you created a new Azure Database Migration Service resource.

Task 4: Assess the on-premises database using Data Migration Assistant

In this task you will install and use Microsoft Data Migration Assistant (DMA) to assess the on-premises database. DMA is integrated with Azure Migrate providing a single hub for assessment and migration tools.

  1. Return to the Azure Migrate blade in the Azure portal. Select the Overview panel, then select Assess and migrate databases.

    Screenshot showing the Azure Migrate Overview blade in the Azure portal, with the 'Assess and migrate databases' button highlighted.

  2. Under Assessment tools, select the link to add a tool, then select Azure Migrate: Database Assessment, then select Next.

    Screenshot showing the 'Select assessment tool' step of the 'Add a tool' wizard in Azure Migrate, with the 'Azure Migrate: Database Assessment' tool selected.

  3. Under Migration tool, select the link to add a tool, then select Azure Migrate: Database Migration, then select Next.

    Screenshot showing the 'Select assessment tool' step of the 'Add a tool' wizard in Azure Migrate, with the 'Azure Migrate: Database Migration' tool selected.

  4. Once the tools are installed in Azure Migrate, the portal should show the Azure Migrate - Databases blade. Under Azure Migrate: Database Assessment select + Assess.

    Screenshot highlighting the '+Assess' link on the 'Azure Migrate - Databases' blade in the Azure portal.

  5. Select Download to open the Data Migration Assistant download page. Copy the page URL to the clipboard.

  6. Return to your remote desktop session with the SmartHotelHost VM. Open Chrome from the desktop and paste the Data Migration Assistant download URL into the address bar. Download and install the Data Migration Assistant, but do not launch it yet.

  7. From within SmartHotelHost, open Windows Explorer and navigate to the C:\Program Files\Microsoft Data Migration Assistant folder. Open the Dma.exe.config file using Notepad. Search for AzureMigrate and remove the <!-- and --> around the line setting the EnableAssessmentUploadToAzureMigrate key. Save the file and close Notepad when done.

Screenshot showing the Dma.exe.config setting enabling upload to Azure Migrate.

  1. From within SmartHotelHost launch Microsoft Data Migration Assistant using the desktop icon.

  2. In the Data Migration Assistant, select the + New icon. Fill in the project details as follows:

    • Project type: Assessment

    • Project name: SmartHotelAssessment

    • Assessment type: Database Engine

    • Source server type: SQL Server

    • Target server type: Azure SQL Database

  3. Select Create to create the project.

    Screenshot showing the new DMA project creation dialog.

  4. On the Options tab select Next.

  5. On the Select sources page, in the Connect to a server dialog box, provide the connection details to the SQL Server, and then select Connect.

    • Server name: 192.168.0.6

    • Authentication type: SQL Server Authentication

    • Username: sa

    • Password: demo!pass123

    • Encrypt connection: Checked

    • Trust server certificate: Checked

    Screenshot showing the DMA connect to a server dialog.

  6. In the Add sources dialog box, select SmartHotel.Registration, then select Add.

    Screenshot of the DMA showing the 'Add sources' dialog.

  7. Select Start Assessment to start the assessment.

    Screenshot of the DMA showing assessment in progress.

  8. Wait for the assessment to complete, and review the results. The results should show two unsupported features, Service Broker feature is not supported in Azure SQL Database and Azure SQL Database does not support EKM and Azure Key Vault integration. For this migration, you can ignore these issues.

    Note: For Azure SQL Database, the assessments identify feature parity issues and migration blocking issues.

    • The SQL Server feature parity category provides a comprehensive set of recommendations, alternative approaches available in Azure, and mitigating steps to help you plan the effort into your migration projects.
    • The Compatibility issues category identifies partially supported or unsupported features that reflect compatibility issues that might block migrating on-premises SQL Server database(s) to Azure SQL Database. Recommendations are also provided to help you address those issues.
  9. Select Upload to Azure Migrate to upload the database assessment to your Azure Migrate project (this button may take a few seconds to become enabled).

    Screenshot of the DMA showing the assessment results and the 'Update to Azure Migrate' button.

  10. Select Azure from the dropdown on the right then select Connect. Enter your subscription credentials when prompted. Select your Subscription and Azure Migrate Project using the dropdowns, then select Upload. Once the upload is complete, select OK to dismiss the notification.

    Screenshot of the DMA showing the assessment results upload panel.

  11. Minimize the remote desktop window and return to the Azure Migrate - Databases blade in the Azure portal. Refreshing the page should now show the assessed database.

    Screenshot of the 'Azure Migrate - Databases' blade in the Azure portal, showing 1 assessed database.

Task summary

In this task you used Data Migration Assistant to assess an on-premises database for readiness to migrate to Azure SQL, and uploaded the assessment results to your Azure Migrate project. The DMA is integrated with Azure Migrate providing a single hub for assessment and migration tools.

Task 5: Create a DMS migration project

In this task you will create a Migration Project within the Azure Database Migration Service (DMS). This project contains the connection details for both the source and target databases. In order to connect to the target database, you will also create a private endpoint allowing connectivity from the subnet used by the DMS.

In subsequent tasks, you will use this project to migrate both the database schema and the data itself from the on-premises SQL Server database to the Azure SQL Database.

We'll start by creating the private endpoint that allows the DMS to access the database server.

  1. In the Azure portal, navigate to the SmartHotelHostDBRG resource group, and then to the database server.

  2. Select Private endpoint connections under Security, then + Private endpoint.

  3. On the Basics tab that appears, enter the following configuration then select Next: Resource.

    • Resource group: SmartHotelDBRG

    • Name: SmartHotel-DB-for-DMS

    • Region: Select the same location as the DMSvnet (Should be the region closest to you).

    Screenshot showing the 'Create a private endpoint' blade, 'Basics' tab.

  4. On the Resource tab, entering the following configuration then select Next: Configuration.

    • Connection method: Connect to an Azure resource in my directory.

    • Subscription: Select your subscription.

    • Resource type: Microsoft.Sql/servers

    • Resource: Your SQL database server name.

    • Target sub-resource: sqlServer

    Screenshot showing the 'Create a private endpoint' blade, 'Resource' tab.

  5. On the Configuration tab enter the following configuration then select Review + create, then Create.

    • Virtual network: DMSvnet

    • Subnet: DMS (10.1.0.0/24)

    • Integrate with private DNS zone: Yes

    • Private DNS zones: (default) privatelink.database.windows.net

    Screenshot showing the 'Create a private endpoint' blade, 'Configuration' tab.

  6. Wait for the deployment to complete. Open the Private Endpoint blade, and note that the FQDN for the endpoint is listed as <your database>.database.windows.net, with an internal IP address 10.1.0.5.

    Screenshot showing the DNS entry for the SQL database server private endpoint

    Screenshot showing step 1 to find the DNS entry for the SQL database server private endpoint

    Screenshot showing step 2 to find the DNS entry for the SQL database server private endpoint

    Screenshot showing step 3 to find the DNS entry for the SQL database server private endpoint

    Note: Private DNS is used so that the database domain name, <your server>.database.windows.net resolves to the internal private endpoint IP address 10.1.0.5 when resolved from the DMSvnet, but resolves to the Internet-facing IP address of the database server when resolved from outside the DMSvnet. This means the same connection string (which contains the domain name) can be used in both cases.

  7. Return to the Database server blade. Under Security, select Firewalls and virtual networks. Set 'Deny public network access' to Yes, then Save your changes.

    Screenshot showing the link to add an existing virtual network to the SQL database network security settings.

  8. Check that the Database Migration Service resource you created in task 3 has completed provisioning. You can check the deployment status from the Deployments pane in the AzureMigrateRG resource group blade.

    Screenshot showing the AzureMigrateRG - Deployments blade in the Azure portal. The Microsoft.AzureDMS deployment shows status 'Successful'.

  9. Navigate to the Database Migration Service resource blade in the AzureMigrateRG resource group and select + New Migration Project.

    Screenshot showing the Database Migration Service blade in the Azure portal, with the 'New Migration Project' button highlighted.

  10. the New migration project blade, enter DBMigrate as the project name. Leave the source server type as SQL Server and target server type as Azure SQL Database. Select Choose type of activity and select Create project only. Select Save then select Create.

    Screenshot showing the Database Migration Service blade in the Azure portal, with the 'New Migration Project' button highlighted.

  11. The Migration Wizard opens, showing the Select source step. Complete the settings as follows, then select Next: Select databases.

    • Source SQL Server instance name: 10.0.0.4

    • Authentication type: SQL Authentication

    • User Name: sa

    • Password: demo!pass123

    • Encryption connection: Checked

    • Trust server certificate: Checked

    Screenshot showing the 'Select source' step of the DMS Migration Wizard.

    Note: The DMS service connects to the Hyper-V host, which has been pre-configured with a NAT rule to forward incoming SQL requests (TCP port 1433) to the SQL Server VM. In a real-world migration, the SQL Server VM would most likely have its own IP address on the internal network, via an external Hyper-V switch.

    The Hyper-V host is accessed via its private IP address (10.0.0.4). The DMS service accesses this IP address over the peering connection between the DMS VNet and the SmartHotelHost VNet. This simulates a VPN or ExpressRoute connection between a DMS VNet and an on-premises network.

  12. In the Select databases step, the Smarthotel.Registration database should already be selected. Select Next: Select target.

    Screenshot showing the 'Select databases' step of the DMS Migration Wizard.

  13. Complete the Select target step as follows, then select Next: Summary:

    • Target server name: Value from your database, {something}.database.windows.net.

    • Authentication type: SQL Authentication

    • User Name: demouser

    • Password: demo!pass123

    • Encrypt connection: Checked

    Screenshot showing the DMS migration target settings.

    Note: You can find the target server name in the Azure portal by browsing to your database.

    Screenshot showing the Azure SQL Database server name.

  14. At the Project summary step, review the settings and select Save project to create the migration project.

    Screenshot showing the DMS project summary.

Task summary

In this task you created a Migration Project within the Azure Database Migration Service. This project contains the connection details for both the source and target databases. A private endpoint was used to avoid exposing the database on a public IP address.

Task 6: Migrate the database schema

In this task you will use the Azure Database Migration Service to migrate the database schema to Azure SQL Database. This step is a prerequisite to migrating the data itself.

The schema migration will be carried out using a schema migration activity within the migration project created in task 5.

  1. Following task 5, the Azure portal should show a blade for the DBMigrate DMS project. Select + New Activity and select Schema only migration from the drop-down.

    Screenshot showing the 'New Activity' button within an Azure Database Migration Service project, with 'Schema only migration' selected from the drop-down.

  2. The Migration Wizard is shown. Most settings are already populated from the existing migration project. At the Select source step, re-enter the source database password demo!pass123, then select Next: Select target.

    Screenshot showing the 'Select source' step of the DMS Migration Wizard. The source database password is highlighted.

  3. At the Select target step, enter the password demo!pass123 and select Next: Select database and schema.

    Screenshot showing the 'Select target' step of the DMS Migration Wizard. The target database password is highlighted.

  4. At the Select database and schema step, check that the SmartHotel.Registration database is selected. Under Target Database select smarthoteldb and under Schema Source select Generate from source. Select Next: Summary.

    Screenshot showing the 'Select database and schema' step of the DMS Migration Wizard.

  5. At the Summary step, enter SchemaMigration as the Activity name. Select Start migration to start the schema migration process.

    Screenshot showing the 'Summary' step of the DMS Migration Wizard. The activity name, validation option, and 'Run migration' button are highlighted

  6. The schema migration will begin. Select the Refresh button and watch the migration progress, until it shows as Completed.

    Screenshot showing the SchemaMigration progress blade. The status is 'Completed'.

Task summary

In this task you used a schema migration activity in the Azure Database Migration Service to migrate the database schema from the on-premises SQL Server database to the Azure SQL database.

Task 7: Migrate the on-premises data

In this task you will use the Azure Database Migration Service to migrate the database data to Azure SQL Database.

The schema migration will be carried out using an offline data migration activity within the migration project created in task 5.

  1. Return to the Azure portal blade for your DBMigrate migration project in DMS. Select + New Activity and select Offline data migration from the drop-down.

    Screenshot showing the 'New Activity' button within an Azure Database Migration Service project, with 'Offline data migration' selected from the drop-down.

  2. The Migration Wizard is shown. Most settings are already populated from the existing migration project. At the Select source step, re-enter the source database password demo!pass123, then select Next: Select target.

    Screenshot showing the 'Select source' step of the DMS Migration Wizard. The source database password is highlighted.

  3. At the Select target step, enter the password demo!pass123 and select Next: Map to target databases.

    Screenshot showing the 'Select target' step of the DMS Migration Wizard. The target database password is highlighted.

  4. At the Map to target databases step, check the SmartHotel.Registration database. Under Target Database select smarthoteldb. Select Next: Configure migration settings.

    Screenshot showing the 'Map to target databases' step of the DMS Migration Wizard.

  5. The Configure migration settings step allows you to specify which tables should have their data migrated. Select the Bookings table (Make sure the MigrationHistory table is not checked) and select Next: Summary.

    Screenshot from DMS showing tables being selected for replication.

  6. At the Migration summary step, enter DataMigration as the Activity name. Select Start migration.

    Screenshot from DMS showing a summary of the migration settings.

  7. The data migration will begin. Select the Refresh button and watch the migration progress, until it shows as Completed.

    Screenshot from DMS showing the data migration in completed.

As a final step, we will remove the private endpoint that allows the DMS service access to the database, since this access is no longer required.

  1. In the Azure portal, navigate to the SmartHotelHostDBRG resource group, and then to the database server. Under Security, select Private endpoint connections.

  2. Select the SmartHotel-DB-for-DMS endpoint added earlier, and select Remove, followed by Yes.

    Screenshot from the SQL server showing the SmartHotel-DB-for-DMS private endpoint being removed.

Task summary

In this task you used an off-line data migration activity in the Azure Database Migration Service to migrate the database data from the on-premises SQL Server database to the Azure SQL database.

Exercise summary

In this exercise you migrated the application database from on-premises to Azure SQL Database. The Microsoft Data Migration Assistant was used for migration assessment, and the Azure Database Migration Service was used for schema migration and data migration.

Exercise 3: Migrate the application and web tiers using Azure Migrate: Server Migration

Duration: 90 minutes

In this exercise you will migrate the web tier and application tiers of the application from on-premises to Azure using Azure Migrate: Server Migration.

Having migrated the virtual machines, you will reconfigure the application tier to use the application database hosted in Azure SQL. This will enable you to verify that the migration application is working end-to-end.

Task 1: Create a Storage Account

In this task you will create a new Azure Storage Account that will be used by Azure Migrate: Server Migration for storage of your virtual machine data during migration.

Note: This lab focuses on the technical tools required for workload migration. In a real-world scenario, more consideration should go into the long-term plan prior to migrating assets. The landing zone required to host VMs should also include considerations for network traffic, access control, resource organization, and governance. For example, the CAF Migration Blueprint and CAF Foundation Blueprint can be used to deploy a pre-defined landing zone, and demonstrate the potential of an Infrastructure as Code (IaC) approach to infrastructure resource management. For more information, see Azure Landing Zones and Cloud Adoption Framework Azure Migration landing zone Blueprint sample.

  1. In the Azure portal's left navigation, select + Create a resource, then search for and select Storage account, followed by Create.

    Screenshot of the Azure portal showing the create storage account navigation.

  2. In the Create storage account blade, on the Basics tab, use the following values:

    • Subscription: Select your Azure subscription.

    • Resource group: AzureMigrateRG

    • Storage account name: migrationstorage[unique number]

    • Location: IMPORTANT: Select the same location as your Azure SQL Database (can be found in the Azure portal).

    • Account kind: Storage (general purpose v1) (do not use a v2 account).

    • Replication: Locally-redundant storage (LRS)

    Screenshot of the Azure portal showing the create storage account blade.

  3. Select Review + create, then select Create.

Task summary

In this task you created a new Azure Storage Account that will be used by Azure Migrate: Server Migration.

Task 2: Create a Virtual Network

In this task you will create a new virtual network that will be used by your migrated virtual machines when they are migrated to Azure. (Azure Migrate will only create the VMs, their network interfaces, and their disks; all other resources must be staged in advance.)

Note: Azure provides several options for deploying the right network configuration. After the lab, if you’d like to better understand your networking options, see the network decision guide, which builds on the Cloud Adoption Framework’s Azure landing zones.

You will also configure a private endpoint in this network to allow private, secure access to the SQL Database.

  1. In the Azure portal's left navigation, select + Create a resource, then select Networking, followed by Virtual network.

    Screenshot of the Azure portal showing the create virtual network navigation.

  2. In the Create virtual network blade, enter the following values:

    • Subscription: Select your Azure subscription.

    • Resource group: (create new) SmartHotelRG

    • Name: SmartHotelVNet

    • Region: IMPORTANT: Select the same location as your Azure SQL Database.

    Screenshot of the Azure portal showing the create virtual network blade 'Basics' tab.

  3. Select Next: IP Addresses >, and enter the following configuration. Then select Review + create, then Create.

    • IPv4 address space: 192.168.0.0/24

    • First subnet: Select Add subnet and enter the following then select Add

      • Subnet name: SmartHotel

      • Address range: 192.168.0.0/25

    • Second subnet: Select Add subnet and enter the following then select Add.

      • Subnet name: SmartHotelDB

      • Address range: 192.168.0.128/25

    Screenshot of the Azure portal showing the create virtual network blade 'IP Addresses' tab.

  4. Navigate to the SmartHotelHostDBRG resource group, and then to the database server. Under Security, select Private endpoint connections, then select + Private endpoint.

  5. On the Basics tab, enter the following configuration then select Next: Resource:

    • Resource group: SmartHotelDBRG

    • Name: SmartHotel-DB-Endpoint

    • Region: Select the same location as the SmartHotelVNet.

    Screenshot showing the 'Create a private endpoint' blade, 'Basics' tab.

  6. On the Resource tab, enter the following configuration then select Next: Configuration:

    • Connection method: Connect to an Azure resource in my directory.

    • Subscription: Select your subscription.

    • Resource type: Microsoft.Sql/servers

    • Resource: Your SQL database server.

    • Target sub-resource: sqlServer

    Screenshot showing the 'Create a private endpoint' blade, 'Resource' tab.

  7. On the Configuration tab, enter the following configuration then select Review + Create then Create:

    • Virtual network: SmartHotelVNet

    • Subnet: SmartHotelDB (192.168.0.128/25)

    • Integrate with private DNS zone: Yes

    • Private DNS zone: (default) privatelink.database.windows.net

    Screenshot showing the 'Create a private endpoint' blade, 'Configuration' tab.

  8. Wait for the deployment to complete. Open the Private Endpoint blade, and note that the FQDN for the endpoint is listed as <your database>.database.windows.net, with an internal IP address 192.168.0.132.

    Screenshot showing step 1 to find the DNS entry for the SQL database server private endpoint

    Screenshot showing step 2 to find the DNS entry for the SQL database server private endpoint

    Screenshot showing step 3 to find the DNS entry for the SQL database server private endpoint

    Note: Private DNS is used so that the database domain name, <your server>.database.windows.net resolves to the internal private endpoint IP address 192.168.0.132 when resolved from the SmartHotelVNet, but resolves to the Internet-facing IP address of the database server when resolved from outside the VNet. This means the same connection string (which contains the domain name) can be used in both cases.

    Note: If the private endpoint connection fails to allow the IP address or database domain name to connect to the database, it may be required to create a new firewall rule to allow the IP address ranges of the database and the private link.

Task summary

In this task you created a new virtual network that will be used by your virtual machines when they are migrated to Azure. You also created a private endpoint in this network, which will be used to access the SQL database.

Task 3: Register the Hyper-V Host with Azure Migrate: Server Migration

In this task, you will register your Hyper-V host with the Azure Migrate: Server Migration service. This service uses Azure Site Recovery as the underlying migration engine. As part of the registration process, you will deploy the Azure Site Recovery Provider on your Hyper-V host.

  1. Return to the Azure Migrate blade in the Azure Portal, and select Servers under Migration goals on the left. Under Migration Tools, select Discover.

    Note: You may need to add the migration tool yourself by following the link below the Migration Tools section, selecting Azure Migrate: Server Migration, then selecting Add tool(s).

    Screenshot of the Azure portal showing the 'Discover' button on the Azure Migrate Server Migration panel.

  2. In the Discover machines panel, under Are your machines virtualized, select Yes, with Hyper-V. Under Target region enter the same region as used for your Azure SQL Database which can be found in the Azure portal and check the confirmation checkbox. Select Create resources to begin the deployment of the Azure Site Recovery resource used by Azure Migrate: Server Migration for Hyper-V migrations.

    Screenshot of the Azure portal showing the 'Discover machines' panel from Azure Migrate.

    Once deployment is complete, the 'Discover machines' panel should be updated with additional instructions.

  3. Copy the Download link for the Hyper-V replication provider software installer to your clipboard.

    Screenshot of the Discover machines' panel from Azure Migrate, highlighting the download link for the Hyper-V replication provider software installer.

  4. Open the SmartHotelHost remote desktop window, launch Chrome from the desktop shortcut, and paste the link into a new browser tab to download the Azure Site Recovery provider installer.

  5. Return to the Discover machines page in your browser (outside the SmartHotelHost remote desktop session). Select the blue Download button and download the registration key file.

    Screenshot of the Discover machines' panel from Azure Migrate, highlighting the download link Hyper-V registration key file.

  6. Open the file location in Windows Explorer, and copy the file to your clipboard. Return to the SmartHotelHost remote desktop session and paste the file to the desktop.

  7. Still within the SmartHotelHost remote desktop session, open the AzureSiteRecoveryProvider.exe installer you downloaded a moment ago. On the Microsoft Update tab, select Off and select Next. Accept the default installation location and select Install.

    Screenshot of the ASR provider installer.

  8. When the installation has completed select Register. Browse to the location of the key file you downloaded. When the key is loaded select Next.

    Screenshot of the ASR provider registration settings.

  9. Select Connect directly to Azure Site Recovery without a proxy server and select Next. The registration of the Hyper-V host with Azure Site Recovery will begin.

  10. Wait for registration to complete (this may take several minutes). Then select Finish.

    Screenshot of the ASR provider showing successful registration.

  11. Minimize the SmartHotelHost remote desktop session and return to the Azure Migrate browser window. Refresh your browser, then re-open the Discover machines panel by selecting Discover under Azure Migrate: Server Migration and selecting Yes, with Hyper-V for Are your machines virtualized?.

  12. Select Finalize registration, which should now be enabled.

    Screenshot of the Discover machines' panel from Azure Migrate, highlighting the download link Hyper-V registration key file.

  13. Azure Migrate will now complete the registration with the Hyper-V host. Wait for the registration to complete. This may take several minutes.

    Screenshot of the 'Discover machines' panel from Azure Migrate, showing the 'Finalizing registration...' message.

  14. Once the registration is complete, close the Discover machines panel.

    Screenshot of the 'Discover machines' panel from Azure Migrate, showing the 'Registration finalized' message.

  15. The Azure Migrate: Server Migration panel should now show 5 discovered servers.

    Screenshot of the 'Azure Migrate - Servers' blade showing 6 discovered servers under 'Azure Migrate: Server Migration'.

Task summary

In this task you registered your Hyper-V host with the Azure Migrate Server Migration service.

Task 4: Enable Replication from Hyper-V to Azure Migrate

In this task, you will configure and enable the replication of your on-premises virtual machines from Hyper-V to the Azure Migrate Server Migration service.

  1. Under Azure Migrate: Server Migration, select Replicate. This opens the Replicate wizard.

    Screenshot highlighting the 'Replicate' button in the 'Azure Migrate: Server Migration' panel of the Azure Migrate - Servers blade.

  2. In the Source settings tab, under Are your machines virtualized?, select Yes, with Hyper-V from the drop-down. Then select Next.

    Screenshot of the 'Source settings' tab of the 'Replicate' wizard in Azure Migrate Server Migration. Hyper-V replication is selected.

  3. In the Virtual machines tab, under Import migration settings from an assessment, select Yes, apply migration settings from an Azure Migrate assessment. Select the SmartHotel VMs VM group and the SmartHotelAssessment migration assessment.

    Screenshot of the 'Virtual machines' tab of the 'Replicate' wizard in Azure Migrate Server Migration. The Azure Migrate assessment created earlier is selected.

  4. The Virtual machines tab should now show the virtual machines included in the assessment. Select the UbuntuWAF, smarthotelweb1, and smarthotelweb2 virtual machines, then select Next.

    Screenshot of the 'Virtual machines' tab of the 'Replicate' wizard in Azure Migrate Server Migration. The UbuntuWAF, smarthotelweb1, and smarthotelweb2 machines are selected.

  5. In the Target settings tab, select your subscription and the existing SmartHotelRG resource group. Under Replication storage account select the migrationstorage... storage account and under Virtual Network select SmartHotelVNet. Under Subnet select SmartHotel. Select Next.

    Screenshot of the 'Target settings' tab of the 'Replicate' wizard in Azure Migrate Server Migration. The resource group, storage account and virtual network created earlier in this exercise are selected.

    Note: For simplicity, in this lab you will not configure the migrated VMs for high availability, since each application tier is implemented using a single VM.

  6. In the Compute tab, select the Standard_F2s_v2 VM size for each virtual machine. Select the Windows operating system for the smarthotelweb virtual machines and the Linux operating system for the UbuntuWAF virtual machine. Select Next.

    Note: If you are using an Azure Pass subscription, your subscription may not have a quota allocated for FSv2 virtual machines. In this case, use DS2_v2 or D2s_v3 virtual machines instead.

    Screenshot of the 'Compute' tab of the 'Replicate' wizard in Azure Migrate Server Migration. Each VM is configured to use a Standard_F2s_v2 SKU, and has the OS Type specified.

  7. In the Disks tab, review the settings but do not make any changes. Select Next, then select Replicate to start the server replication.

  8. In the Azure Migrate - Servers blade, under Azure Migrate: Server Migration, select the Overview button.

    Screenshot of the 'Azure Migrate - Servers' blade with the 'Overview' button in the 'Azure Migrate: Server Migration' panel highlighted.

  9. Confirm that the 3 machines are replicating.

    Screenshot of the 'Azure Migrate: Server Migration' overview blade showing the replication state as 'Healthy' for 3 servers.

  10. Select Replicating Machines under Manage on the left. Select Refresh occasionally and wait until all three machines have a Protected status, which shows the initial replication is complete. This will take several minutes.

    Screenshot of the 'Azure Migrate: Server Migration - Replicating machines' blade showing the replication status as 'Protected' for all 3 servers.

Task summary

In this task you enabled replication from the Hyper-V host to Azure Migrate, and configured the replicated VM size in Azure.

Task 5: Configure static internal IP addresses for each VM

In this task you will modify the settings for each replicated VM to use a static private IP address that matches the on-premises IP addresses for that machine.

  1. Still using the Azure Migrate: Server Migration - Replicating machines blade, select the smarthotelweb1 virtual machine. This opens a detailed migration and replication blade for this machine. Take a moment to study this information.

    Screenshot from the 'Azure Migrate: Server Migration - Replicating machines' blade with the smarthotelweb1 machine highlighted.

  2. Select Compute and Network under General on the left, then select Edit.

    Screenshot of the smarthotelweb1 blade with the 'Compute and Network' and 'Edit' links highlighted.

  3. Confirm that the VM is configured to use the F2s_v2 VM size (or DS2_v2 or D2s_v3 if using an Azure Pass subscription) and that Use managed disks is set to Yes.

  4. Under Network Interfaces, select InternalNATSwitch to open the network interface settings.

    Screenshot showing the link to edit the network interface settings for a replicated VM.

  5. Change the Private IP address to 192.168.0.4.

    Screenshot showing a private IP address being configured for a replicated VM in ASR.

  6. Select OK to close the network interface settings blade, then Save the smarthotelweb1 settings.

  7. Repeat these steps to configure the private IP address for the other VMs.

    • For smarthotelweb2 use private IP address 192.168.0.5

    • For UbuntuWAF use private IP address 192.168.0.8

Task summary

In this task you modified the settings for each replicated VM to use a static private IP address that matches the on-premises IP addresses for that machine

Note: Azure Migrate makes a "best guess" at the VM settings, but you have full control over the settings of migrated items. In this case, setting a static private IP address ensures the virtual machines in Azure retain the same IPs they had on-premises, which avoids having to reconfigure the VMs during migration (for example, by editing web.config files).

Task 6: Server migration

In this task you will perform a migration of the UbuntuWAF, smarthotelweb1, and smarthotelweb2 machines to Azure.

Note: In a real-world scenario, you would perform a test migration before the final migration. To save time, you will skip the test migration in this lab. The test migration process is very similar to the final migration.

  1. Return to the Azure Migrate: Server Migration overview blade. Under Step 3: Migrate, select Migrate.

    Screenshot of the 'Azure Migrate: Server Migration' overview blade, with the 'Migrate' button highlighted.

  2. On the Migrate blade, select the 3 virtual machines then select Migrate to start the migration process.

    Screenshot of the 'Migrate' blade, with 3 machines selected and the 'Migrate' button highlighted.

    Note: You can optionally choose whether the on-premises virtual machines should be automatically shut down before migration to minimize data loss. Either setting will work for this lab.

  3. The migration process will start.

    Screenshot showing 3 VM migration notifications.

  4. To monitor progress, select Jobs under Manage on the left and review the status of the three Planned failover jobs.

    Screenshot showing the *Jobs link and a jobs list with 3 in-progress 'Planned failover' jobs.

  5. Wait until all three Planned failover jobs show a Status of Successful. You should not need to refresh your browser. This could take up to 15 minutes.

    Screenshot showing the *Jobs link and a jobs list with all 'Planned failover' jobs successful.

  6. Navigate to the SmartHotelRG resource group and check that the VM, network interface, and disk resources have been created for each of the virtual machines being migrated.

    Screenshot showing resources created by the test failover (VMs, disks, and network interfaces).

Task summary

In this task you used Azure Migrate to create Azure VMs using the settings you have configured, and the data replicated from the Hyper-V machines. This migrated your on-premises VMs to Azure.

Task 7: Enable Azure Bastion

We will need to access our newly-migrated virtual machines to make some configuration changes. However, the machines do not currently have public IP addresses. Rather than add public IP addresses, we will access them using Azure Bastion.

Azure Bastion requires a dedicated subnet within the same virtual network as the virtual machines. Unfortunately, our SmartHotelVNet does not have any free network space available. To address this, we will first extend the network space.

  1. Navigate to the SmartHotelVNet virtual network, then select Address space under Settings on the left. Add the address space 10.10.0.0/24, and Save.

  2. Select Subnets under Settings on the left, and add a new subnet named AzureBastionSubnet, with address space 10.10.0.0/27.

  3. Select + Create a resource in the portal's left navigation, then search for and select Bastion, then select Create.

  4. Fill in the Create a Bastion blade as follows:

    • Subscription: Your subscription

    • Resource group: (Create new) BastionRG

    • Name: SmartHotelBastion

    • Region: Same as SmartHotelVNet

    • Virtual Network: SmartHotelVNet

    • Subnet: AzureBastionSubnet

    • Public IP address: (Create new) Bastion-IP

    Screenshot showing the 'Create a Bastion' blade.

  5. Select Review + create, then Create.

  6. Wait for the Bastion to be deployed. This will take several minutes.

Task 8: Configure the database connection

The application tier machine smarthotelweb2 is configured to connect to the application database running on the smarthotelsql machine.

On the migrated VM smarthotelweb2, this configuration needs to be updated to use the Azure SQL Database instead.

Note: You do not need to update any configuration files on smarthotelweb1 or the UbuntuWAF VMs, since the migration has preserved the private IP addresses of all virtual machines they connect with.

  1. Navigate to the smarthotelweb2 VM overview blade, and select Connect. Select Bastion and connect to the machine with the username Administrator and the password demo!pass123. When prompted, Allow clipboard access.

    Note: You may have to wait a few minutes and refresh to have the option to enter the credentials.

    Screenshot showing the Azure Bastion connection blade.

  2. In the smarthotelweb2 remote desktop session, open Windows Explorer and navigate to the C:\inetpub\SmartHotel.Registration.Wcf folder. Double-select the Web.config file and open with Notepad.

  3. Update the DefaultConnection setting to connect to your Azure SQL Database.

    You can find the connection string for the Azure SQL Database in the Azure portal by browsing to the database, and selecting Show database connection strings.

    Screenshot showing the 'Show database connection strings' link for an Azure SQL Database.

    Copy the ADO.NET connection string, and paste into the web.config file on smarthotelweb2, replacing the existing connection string. Be careful not to overwrite the 'providerName' parameter which is specified after the connection string.

    Note: You may need to open the clipboard panel on the left-hand edge of the Bastion window, paste the connection string there, and then paste into the VM.

    Set the password in the connection string to demo!pass123.

    Screenshot showing the user ID and Password in the web.config database connection string.

  4. Save the web.config file and exit your Bastion remote desktop session.

Task summary

In this task, you updated the smarthotelweb2 configuration to connect to the Azure SQL Database.

Task 9: Configure the public IP address and test the SmartHotel application

In this task, you will associate a public IP address with the UbuntuWAF VM. This will allow you to verify that the SmartHotel application is running successfully in Azure.

  1. Navigate to the UbuntuWAF VM blade, select Networking under Settings on the left, then select the network interface (in bold text).

    Screenshot showing the path to the NIC of the UbuntuWAF VM.

  2. Select IP configuration under Settings on the left, then select the IP configuration listed.

    Screenshot showing the path to the ipConfig of the UbuntuWAF VM's NIC.

  3. Set the Public IP address to Associate, and create a new public IP address named UbuntuWAF-IP. Choose a Basic tier IP address with Dynamic assignment. Save your changes.

    Screenshot showing the public IP configured on the UbuntuWAF VM.

  4. Return to the UbuntuWAF VM overview blade and copy the Public IP address value.

    Screenshot showing the IP address for the UbuntuWAF VM.

  5. Open a new browser tab and paste the IP address into the address bar. Verify that the SmartHotel360 application is now available in Azure.

    Screenshot showing the SmartHotel application.

Task summary

In this task, you assigned a public IP address to the UbuntuWAF VM and verified that the SmartHotel application is now working in Azure.

Task 10: Post-migration steps

There are a number of post-migration steps that should be completed before the migrated services is ready for production use. These include:

  • Installing the Azure VM Agent

  • Cleaning up migration resources

  • Enabling backup and disaster recovery

  • Encrypting VM disks

  • Ensuring the network is properly secured

  • Ensuring proper subscription governance is in place, such as role-based access control and Azure Policy

  • Reviewing recommendations from Azure Advisor and Security Center

In this task you will install the Azure Virtual Machine Agent (VM Agent) on your migrated Azure VMs and clean up any migration resources. The remaining steps are common for any Azure application, not just migrations, and are therefore out of scope for this hands-on lab.

Note: The Microsoft Azure Virtual Machine Agent (VM Agent) is a secure, lightweight process that manages virtual machine (VM) interaction with the Azure Fabric Controller. The VM Agent has a primary role in enabling and executing Azure virtual machine extensions. VM Extensions enable post-deployment configuration of VM, such as installing and configuring software. VM extensions also enable recovery features such as resetting the administrative password of a VM. Without the Azure VM Agent, VM extensions cannot be used.

In this lab, you will install the VM agent on the Azure VMs after migration. Alternatively, you could instead install the agent on the VMs in Hyper-V before migration.

  1. In the Azure portal, locate the smarthotelweb1 VM and open a remote desktop session using Azure Bastion. Log in to the Administrator account using password demo!pass123 (use the 'eyeball' to check the password was entered correctly with your local keyboard mapping).

  2. Open a web browser and download the VM Agent from:

    https://go.microsoft.com/fwlink/?LinkID=394789

    Note: You may need to open the clipboard panel on the left-hand edge of the Bastion window, paste the URL, and then paste into the VM.

  3. After the installer has downloaded, run it. Select Next, Select I accept the terms in the License Agreement, and then Next again. Select Finish.

    Screenshot showing the Windows installer for the Azure VM Agent.

  4. Close the smarthotelweb1 window. Repeat the Azure VM agent installation process on smarthotelweb2.

You will now install the Linux version of the Azure VM Agent on the Ubuntu VM. All Linux distributions supports by Azure have integrated the Azure VM Agent into their software repositories, making installation easy in most cases.

  1. In the Azure portal, locate the UbuntuWAF VM and Connect to the VM using Azure Bastion, with the user name demouser and password demo!pass123. Since this is a Linux VM, Bastion will create an SSH session. You may need to enter the credentials again.

  2. In the SSH session, enter the following command:

    sudo apt-get install walinuxagent

    When prompted, enter the password demo!pass123. At the Do you want to continue? prompt, type Y and press Enter.

    Note: You may need to open the clipboard panel on the left-hand edge of the Bastion window, paste the command, and then paste into the VM.

    Screenshot showing the Azure VM Agent install experience on Ubuntu.

  3. Wait for the installer to finish, then close the terminal window and the Ubuntu VM window.

To demonstrate that the VM Agent is installed, we will now execute the 'Run command' feature from the Azure portal. For more information on the VM Agent, see Windows VM Agent and Linux VM Agent.

  1. Navigate to the smarthotelweb1 blade. Under Operations, select Run command, followed by IPConfig, followed by Run. After a few seconds, you should see the output of the IPConfig command.

    Screenshot showing the Run command feature.

  2. As a final step, you will now clean up the resources that were created to support the migration and are no longer needed. These include the Azure Migrate project, the Recovery Service Vault (Azure Site Recovery resource) used by Azure Migrate: Server Migration, and the Database Migration Service instance. Also included are various secondary resources such as the Log Analytics workspace used by the Dependency Visualization, the storage account used by Azure Migrate: Server Migration, and a Key Vault instance.

    Because all of these temporary resources have been deployed to a separate AzureMigrateRG resource group, deleting them is as simple as deleting the resource group. Simply navigate to the resource group blade in the Azure portal, select Delete resource group and complete the confirmation prompts.

Task summary

In this task you installed the Azure Virtual Machine Agent (VM Agent) on your migrated VMs. You also cleaned up the temporary resources created during the migration process.

Exercise summary

In this exercise you migrated the web tier and application tiers of the application from on-premises to Azure using Azure Migrate: Server Migration. Having migrated the virtual machines, you reconfigured the application tier to use the migrated application database hosted in Azure SQL Database, and verified that the migrated application is working end-to-end. You also installed the VM Agent on the migrated virtual machines, and cleaned up migration resources.

After the hands-on lab

Duration: 10 minutes

Task 1: Clean up resources

You should complete all of these steps after attending the Hands-on lab. Failure to delete the resources created during the lab will result in continued billing.

  1. Delete the SmartHotelHostRG resource group containing the SmartHotelHost.

  2. Delete the SmartHotelDBRG resource group containing the Azure SQL Database.

  3. Delete the BastionRG resource group containing the Azure Bastion.

  4. Delete the SmartHotelRG resource group containing the migrated VMs and related infrastructure resources.

  5. Delete the AzureMigrateRG resource group containing the Azure Migrate resources (if not done already at the end of Exercise 3).

You should follow all steps provided after attending the Hands-on lab.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published