Japanese version is here → Click
Hi, This series introduces a method for migrating PCs using an Azure-native tool called Azure Migrate. You can migrate physical machines and VMs on Hyper-V and VMware to the Azure environment. Especially in cases where there are many migration terminals, it is more convenient.
Also, VMware's VMs have two migration options: "agentless" and "agent-based". The former allows you to migrate more easily without installing an agent (application) on the VMware side's VM.
This is the first article about migrating a physical machine in an on-premises (home environment) to an Azure VM on IaaS using the Azure Migrate tool. Then I will write three other articles about the replication and migration steps.
So, we will eventually have four articles about Azure Migrate.
Azure Migration 1/4: Using Azure Migrate discovery and assessment function (this article)
Azure Migration 2/4: Deploying a Replication Appliance on a physical Windows server (Published)
Azure Migration 3/4: Replicating and migrating a physical PC to Azure VM
Azure Migration 4/4: Clean up about replication appliance-relevant apps and Azure Migrate Project Resources
OK, now let us get started.
■ What is Azure Migrate?
Azure Migrate is a migration tool provided by Microsoft Azure, and its functions are broadly divided into two categories: assessment and migration.
Assessment is a function that evaluates the feasibility of migrating the target machines to Azure, sizing the post-migration VMs, estimating costs, and evaluating dependencies between migration machines before migration.
Migration is a function that consistently performs tasks from detecting the target machines to deploying them to Azure VM. By the way, the results of the VM sizing generated by assessment can be used when deploying the VMs, so it is very convenient as it eliminates the need to manually set the VM's specs for each machine during migration. Of course, it is possible to execute migration without performing an assessment.
===========================
Azure Migrate Official Documentation
===========================
Now, let's get started right away!
Firstly, here are the prerequisites and recommended preparations before operating.
■ Prerequisites
This article is about migrating a physical machine(in my home environment)to Azure VM (IaaS)
Communication between the home environment and Azure is possible.
Only Azure Migrate will be used.
Communication for migration will be carried out through Azure PrivateEndpoint (APE).
Communication between Azure Migrate Appliance Server (AMA) and the target physical machine is possible.
All operations on the Azure side will be performed on the Azure Portal.
■ Network Architecture
The connection between the home environment and Azure is through an S2S VPN, and the Azure side is configured in a hub-spoke network topology.
Communication between the home environment and Azure is via an AFW (Azure Firewall). The Azure Migrate tool automatically creates the APE, Key vault, Storage Account, and Private DNS Zone used during migration and places them in the SpokeVNET. ※ Each VNET, Subnet, AFW, and VPN Gateway must be created and communication verified beforehand. (The creation procedure for each resource is omitted here.)
※ The red lines indicate the communication route.
■ Communication Image
The communication ports and communication data between the physical machine, Azure Migrate Appliance (AMA), and Azure Migrate Portal are as follows:
■ Recommended Preparations
1.Create a resource group for Migrate-related resources.
※ It's to delete related resources quickly after migration.
2.Make a naming rule.
※ It is to recognize migration-related resources easily.
From here, we will explain the procedure for assessing the target machines for whether they could be migrated to Azure properly. Processes will be broken down into steps.
【Step1】- Create an Azure Migrate Project
1. Open the main screen of Azure Migrate on the Azure portal and create a project.
↓
↓
2. Enter the necessary information, and click "Create."
- Select the resource group created in advance or create a new one here.
- Fill in the input fields under "Advanced."
-- Connect with Private Endpoint
Note: Azure Migrate supports both Public and Private Endpoints. However, most companies connect their on-premises environment and Azure using S2S VPN or ExpressRoute. Therefore, a connection via Private Endpoint without going through the Internet will be more helpful, and we will use it.
-- Regarding "disable public network access."
Note: This option appears when you connect via a Private Endpoint, and it is an option to turn off connections from the Internet. Azure Migrate supports third-party migration tools, which may need Internet access, so it might be better to select "No." However, since we are using only Azure Migrate this time and have already connected the two environments via S2S VPN, let's try "Yes." -- Select the VNET and Subnet that were created in advance.
The Azure Migrate home screen appears as follows after creation.
- Since it is possible to create multiple projects, you can switch between them by clicking on the project name and selecting from the drop-down menu.
- As you can see, the categories are broadly divided into two: "Assessment" (evaluation) and "Migration" (migration)
【Step2】- Installing Azure Migrate Appliance (AMA) for Detecting Physical Machines
===========================
Official Documentation for Azure Migrate Appliance
===========================
Installing AMA on an on-premises server is necessary to act as an intermediary to relay information between the target machines and Azure Migrate. We will install the AMA from now on.
1. Click on "Discover" in Azure Migrate's "Assessment Tool."
↓
-You can also upload CSV files besides deploying AMA.
-Select the type of server to install AMA on, but choose "Physical" as we are migrating physical machines.
<1. Generate a Project Key>
Generate a project key that needs to be entered when installing AMA to link it with the Azure Migrate project.
- Enter the AMA name.
- Click "Generate Key" (It takes some time to generate: about 10 minutes).
Confirm that the project key has been generated.
Note: Multiple AMAs can be created, but each requires a unique project key.
You can generate a new project key once you close the Discover screen and reopen it. On the other hand, you can check the generated project key by clicking "Manage existing appliances" next to "Generate Key."
<2. Download the AMA Script>
Download the AMA script.
↓
Since the size is about 500MB, it might be better to download it on the server where you will install AMA.
Note: All actions in Step2 and Step3 will be done on the server where AMA is installed.
<3. Install the Azure Migrate Appliance (AMA)>
Check here for the prerequisites and other details of the AMA server to install the AMA.
↓
Unzip the ZIP file and open the Readme file in the folder.
↓
Start Powershell in administrator mode and execute the command described in #4 of Readme.
The script to be executed is named "AzureMigrateInstaller.ps1", but you'll need to put the script's full path in Powershell to run it.
※If the folder path is not set in the environment variables, the path will not be found.
↓
If there has already been another AMA on the same server, the part in red below will appear, but pressing "Y" will automatically delete the previous AMA.
↓
Next, answer the questions in sequence.
- Since this is a migration of physical machines, select 3. Physical or other (AWS, GCP, Xen, etc.).
- Since this is neither the US government nor China, select 1. Azure Public.
- Since we connect via Private Endpoint, choose 2. Set up an appliance for a Migrate project created with private endpoint connectivity.
※In the case of connection via a Private Endpoint, it is a prerequisite that the AMA server is placed in a network environment where the Private Endpoint is reachable.
Confirm all the inputs, and if everything is fine, answer "Y" to the last question, and the installation will begin.
↓
↓
Installation complete (The message "You may use..." will appear at the end)
【Step3】- Registering DNS Information of Private Endpoint
When connecting AMA to Azure Migrate using a Private Endpoint, it's necessary to resolve the FQDN of the Private Endpoint. You can download this information on Azure Migrate. Place the downloaded DNS information in the DNS server or AMA server's hosts file.
Here's how to add it to the hosts file.
Note: If you do not register the DNS information correctly, an error will occur in Step 4, preventing a proper connection with the Private Endpoint. Be sure to register it.
1. Click on "Assessment tools" and then "Overview" (Summary) in Azure Migrate.
2. Click on "Properties" in the side menu.
3. Scroll down and click "Download DNS settings" to download.
4. Add the downloaded DNS information (txt) to the hosts file. The hosts file is located in "C:\Windows\System32\drivers\etc."
※Since the hosts file is read-only, copy it to another location first, update it, and then overwrite the original file.
↓
↓
5. Restart the AMA server.
【Step4】- Regist the AMA Server to the Azure Migrate.
1. After installing AMA, double-click the "Azure Migrate Appliance Configuration Manager" on the AMA server's desktop.
↓
The following screen will be displayed.
2. Scroll down a little and enter the project key.
(Do you still remember? (Laughs) The project key... It seems familiar... It was generated in Step 2)
↓
Once the project key is entered and "Verify" is clicked, the project key will be authenticated. A comment that says "Azure Migrate project key has been verified" will be displayed if the verification is successful.
3. Check the automatic update status of AMA.
Once the project key is verified, AMA's status check will be performed automatically. This time, the result was shown as unusable, but clicking on the blue text "Show appliance services" confirmed that all service versions are up to date. There are "Stopped" agents, but this is not a problem for the initial startup. After all subsequent registrations are completed, it will become "Running."
↓
4. Log in to Azure.
Click the login button, and log in to Azure, as shown below.
↓
If the following dialog is displayed, click "Copy code and log in" to proceed.
↓
For some reason, you will be asked to enter the code displayed earlier (though it doesn't seem to make much sense), but paste it and click "Next."
↓
Select or enter the account to log into Azure. The necessary roles for this account are described in the official document below.
===========================
===========================
We'll use an account with the "Subscription Owner" role this time.
↓
After logging in, you can close the tab if the following message is displayed.
↓
When you return to the appliance screen, a warning dialog about setting up DNS name resolution accurately will be displayed if you select a connection with Private Endpoint.
Note: If the correspondence of the name resolution of the Private Endpoint explained in Step 3 is not completed, the following message will be displayed. Click "Error details" to check the error content.
↓
Once the connection is completed, the following message will be displayed.
Note: If there are changes to the information registered up to Step 4, you need to click "Re-run prerequisites" below to update.
You have now registered the AMA server's information with Azure Migrate. From here, you'll follow the procedure to register the physical machines targeted for migration with Azure Migrate via the AMA server.
【Step5】- Regist the Physical Machine Credentials (Login information)
Next, we must register account information to log into the physical machine and connection information to the physical machine.
We need to navigate to the "2. Credentials and Detection Source Management" on the screen below.
1. Click the "Add Credentials" button.
2. Enter the physical machine credentials (login information) and click "Save."
Note: This process assumes the migration of Windows Server. If there are multiple target machines, you must register the credentials for each type of machine. A single registration will be enough if the same credentials are being used.
3. The registered information will be displayed as shown below.
【Step6】- Regist the Physical Machine Connection Information
We will register the connection information of the physical machine.
1. Click on "Add Detection Source."
2. Choose the method of addition, and input the connection information.
Note: The methods for addition are "Add a Single Item," "Add Multiple Items," or "CSV Import." If there are many target machines, filling in the required information in the specified CSV format and uploading it might be more accessible. In this case, as it's only one machine, select "Add a Single Item."
<Add a Single Item>
Choose the machine type and IP (or FQDN), select the credentials you previously registered, and click "Save" at the end.
NOTE: At this point, communication occurs between the AMA server and the physical machine, so don't forget to open port 5985.
If communication through the port is unavailable or the credentials are incorrect, or for any other reason, verification may fail, as shown below. In this case, click "Validation failed" to identify the reason for failure. Click "Reverify" to conduct the verification again.
Note: Details of two errors that occurred during actual work and the solutions are mentioned at the end of this article.
↓ If verification is completed without issues, it will be displayed below.
3. About the Web Apps or SQL Server in the physical machine
If the physical machine has Web Apps or SQL Server installed, these functions can be detected. However, if these features are absent, uncheck the option for "These features... this can be changed later." (In this case, these features are not on the physical machine, so turn OFF.)
【Step7】- Detect Physical Machines
The machine's credentials and detailed information (IP address and verification of login credentials) have been registered. Next, we will use this information to extract the information of the target machine and register it with Azure Migrate.
1. Click "Start Detection."
↓
If you use a Private Endpoint, the following message will be displayed.
↓
The number of target machines and the time required per machine are mentioned. Still, the required time may vary depending on factors such as the internet environment and the specifications of the physical machine. Most of the time, it takes several minutes.
↓
I waited about 5 minutes, and the detection was completed when the following message was displayed.
↓
The registration section's status has been set to "Discovery Initiated."
【Step8】- Verification of Physical Machine Registration Results
The work on the AMA server is done for now. Next, we move to Azure Migrate on the Azure Portal to check the information of the registered machines.
1. Access the Azure Migrate Portal.
Here is an overview of the entire home screen of the Azure Migrate Portal project.
↓
The "Detected Servers" and the Windows OS distribution in the assessment tool section are set to "1." Since there is only one evaluation appliance (AMA server), it is set to "1."
2. Check the detected physical machine.
Click on "1" under "Detected Servers" and check the information of the registered physical machine in the list of detected servers.
↓
As you can see, the status of some items is "Detecting" and "Verification in Progress," so please do not close the AMA and leave the AMA server and the physical machine powered on.
【Step9】- About "Business Case" and "Dependency Analysis"
<Business Case>
"Building a Business Case" is a convenient tool for managing and progressing migration projects of a specific scale. Still, it will be omitted this time as it is a review of the assessment procedure.
<Dependency Analysis>
In most migration cases, multiple target machines exist, and the dependencies between servers may need to be fully understood. This feature allows you to analyze the dependencies between registered target machines.
===========================
===========================
Note: This analysis is limited to the range that Azure Migrate can detect, so please cross-check with the dependency information that administrators, users, and other stakeholders have!
After registering the evaluation target machine for the first time, dependency analysis is performed automatically, so if you click "Add Servers" in "Dependency Analysis," the selection of target servers is inactive.
↓
Select the AMA server from the "Select Appliance" drop-down menu if there are multiple AMA servers. Also, depending on the number of chosen machines, dependency analysis may take time.
【Step10】 - Evaluation
"Evaluation" is not only for Azure VM, but it's also possible to evaluate the migration cases for Azure SQL, App Server, or AVS (Azure VMware Solution). Since migrating from on-premises to VM, we'll select "Azure VM."
1. Select the type of evaluation and the detection source.
As mentioned before, while you can evaluate for Azure VM, Azure SQL, App Server, or AVS (Azure VMware Solution), we'll select "Azure VM" here.
↓
For "Detection Source," you can select machines detected directly from the appliance or those imported directly. In this case, since we registered via the AMA server, we'll choose the former.
2. Set up the evaluation.
After migrating the target machine to Azure, this step involves setting configurations for evaluating things like VM specifications and costs. You can change the conditions for the same machine and assess it in different scenarios multiple times.
Click "Edit".
↓
Set the conditions.
↓
Let's explain some of the items here:
- Type of Storage
- Saving Options
===========================
===========================
- VM Size
===========================
===========================
Also, hovering over the "!" symbol next to each item name will display its description.
- Offer or License Program
If your Azure VM subscription is tied to an EA agreement, select "EA agreement." |
For subscriptions not tied to an EA agreement, choose "Pay-as-you-go" or "Pay-as-you-go Dev/Test." |
- Azure Hybrid Benefit
If applying a valid Windows Server license to an Azure VM, set this item to "Yes" (This can give significant discounts!). |
↓
For example, set as shown below and click "Save."
3. Perform the evaluation.
Click "Select Server to Evaluate."
↓
Enter the required information and click "Review and Create Evaluation."
↓
Click "Create Evaluation".
↓
A message, as shown below, will appear in "Notifications." It may take some time for the evaluation results to be ready.
↓
Click "Update to Latest Information" in Azure Migrate.
↓
Once the evaluation is complete, as shown below, the number in the "Evaluation" category will become "1". The total count of evaluation results will be displayed if multiple evaluations have been conducted.
4. Confirm the evaluation results.
Click on the total number in the "Evaluation" category or the number for Azure VM to go to the list of evaluation results. You can confirm that the evaluation you created earlier has been output.
The item on the far right, "Confidence Rating," is currently not applicable for evaluating physical servers, so it displays "Not Applicable." Details about the confidence rating and how to improve it are provided in the following official documentation:
===========================
===========================
↓
Click on the evaluation result to display the result.
↓
You can check the details of the evaluation result of Azure VM in the side menu "Azure Compatibility." There is also information on the VM's specifications, prerequisites for migration (conditional), recommended migration tools, and boot methods.
↓
You can also check the details of the monthly costs in the side menu "Cost Details." What you should be careful about is that the computing cost in the graph is the pure monthly cost without the Azure Hybrid Benefit. The red frame in the bottom right shows the monthly cost after applying for the Azure Hybrid Benefit.
↓
Evaluation results can be exported. Also, you can change the conditions in "Settings" and recalculate by clicking "Recalculate."
Summary
This article summarized registering and evaluating physical machines in the on-premises environment to Azure Migrate. How was it?
Although there are quite a few steps to set up initially, once you have set up an AMA server, a single AMA server can support migrating up to 1000 machines, so it might be easier than manually migrating 1000 servers.
Next time, I'd like to summarize the actual migration procedure.
Reference
Troubleshooting Errors That Occurred During Machine Authentication for Migration
■ Errors Related to WinRM (Windows Resource Management) Being Unreachable
WinRM is required for the authentication of the machine targeted for migration. The cause of this error can be broadly considered in the following three ways:
- The user selected as the credentials may not belong to the migration target machine's user group, "Remote Management Users," or that group may not even exist.
- WinRM may not be running at all.
- Communication with WinRM (port:5985) may be denied due to firewall or proxy server settings.
Now, let's explain the remedies for each cause.
1). Right-click the Windows icon on the migration target machine and click "Computer Management."
2). Go to "Local Users and Groups" → "Groups" in the side menu.
→ Check for the existence of "Remote Management Users." If not, create a new group.
3). Enter the group and check if the user selected as credentials belongs to the group. If not, add it.
WinRM can be set to either start or not start at machine boot. Some machines may be configured not to start WinRM at boot, so check the settings and turn on automatic startup at boot.
1). Press the Win key + R on the migration target machine and execute the "services.msc command."
2). Check the status of "Windows Remote Management" from the list of services. If it is not "Running," start it manually.
↓
Click "Start."
↓
Confirm that the service status is "Running."
If you use a firewall or proxy, you must allow communication on port 5985. Here, we explain the setting to open this port using Windows Defender. If using third-party products, please follow the procedures specific to that product.
1). Click the Win key on the migration target machine and search for "fire." Select "Check Firewall Status" from the results and check the "Connected" network (remember it 😆). In the example below, it's a "Public Network."
2). Click the Win key on the migration target machine and search for "security." Select "Enhanced Windows Defender Firewall" from the results.
3). In the "Inbound Rules" on the side menu, identify "Windows Remote Management (HTTP Inbound)." There will be two items with the same name; enable the one for the network you remembered in #1 (in this case, Public Network).
↓
↓
■ Error: "The WMI service returned an 'access denied' error."
This error is also mentioned in the MS official documentation for troubleshooting. Please refer to the document for details: