Configure Azure Site Recovery Zone to Zone Replication

In this post we will be going through setting up and configuring Azure Site Recovery (ASR) using zone to zone replication.

The zone to zone replication feature of Azure Site Recovery allows the replicate data and resources within the same region but across different zones. This is particularly useful for high availability of applications and services in the event of a zone outage.

Zone to Zone Replication in Azure ASR offers several advantages. It provides low recovery point objectives (RPOs) and recovery time objectives (RTOs) by continuously replicating changes. This ensures minimal data loss and enables quick failover in case of a disruption.

To configure zone to zone replication, the VM’s that is going to be replicated needs to be in an availability zone if not you wont be able to select it.

For existing VM’ the only way to move to an availability zone is through a CLI to copy and re deploy the VM.

To start using ASR we need to create a new recovery services vault.

To create a new ASR go to Recovery Services vaults blade in the Azure portal and click on create.

Select the subscription that the vault will be deployed, resource group, give the vault a name and set the region.

Add tags if in use and then review and create.

The deployment of the vault can take a few minutes complete.

Select the vault, go to replicated items and select Azure virtual machines.

Select the region, resource group and select the availability zone that the VM was deployed too.

Select the VM to be replicated, if the VM doesn’t show check to make sure it was deployed to an availability zone.

Next either create a new target resource group or use an existing one and select failover network.

Select availability options to specify the target zone.

Select the default or create a replication policy. I set to update extension to allow ASR to manage (this will create an Azure Automation Account).

Review setting to confirm everything is correct and enable.

If we check the site recovery jobs we should see the replication be create.

We can also see the status of the replication under replicated items.

It will take a little while for the synchronization to complete. Once completed there will be a warning, this is just alerting that the failover hasn’t been tested.

Last step will be to test failover.

If we click on the three dots beside the replicated item we then have the option to failover or test failover.

select the recover point and virtual network (for a test failover this can’t be the same as the production VNET.)

To check the status of the failover job, go to Monitoring > Site Recovery Jobs and select the failover job.

Once the job completed there should be a VM running with -test at the end of the name in the recovery resource group.

The VM will have a different IP address than the production VM, once where finished testing the last step is to clean up the failover test.

Go back to the replicated items and select cleanup test failover.

We can add in a note if we want, tick testing complete and then click ok to remove the test VM.

The cleanup job will run this will take a few minutes to complete and the test VM should now be gone.

Configure Azure Backup Email Reporting

In this post we will be going through the process of setting up Azure Backup Email Reporting.

First step is to configure the Azure Backup Reporting, for this you will need to have already configured at least one Azure Recovery service vaults and have backup running.

I have gone through this process in a previous post so wont be going over here. see previous post for steps involved.

Azure VM Backup using Azure Recovery Service Vault

Once we have the backup vault and backup configured we need to configure an Log Analytics workspace to send diagnostic data to so the reports can generate data.

To create a Log Analytics Workspace go to the Azure Admin portal > Log Analytics workspaces.

Click create

Select the resource group the workspace will be created in, give it a name and select the region.

Add tags if required and create.

Now that we have the log workspace we can configure the backup vault to send diagnostic data.

Go to Backup center > Vault

Select the vault that will have diagnostic enabled and go to Diagnostic settings.

Give the diagnostics a name, select the Azure backup category’s and send to log workspace. Select the log workspace to send to.

Click save it can take a few hours before data starts to show in the workspace.

To check that the backup report are showing data,

Go to Backup center > Backup reports and select the workspace from the drop down list.

Click on summary tab to view the summary report.

Once we have reports working we can now configure the email reporting.

To configure email reporting,

Go to Backup center > Backup reports > Email Report

Give the task a name (this will be the name of the logic app), set the subscription, resource group and region.

We will also need to set email frequency, destination email address and email subject.

There is a bug in the naming of the task it suppose to allow hyphens but the UI gives an error if you use them. The work around to this is to create without the hyphens and then once the logic app is deployed clone with the correct naming.

Once the logic app is created if we want to use hyphens, go to Clone and use hyphens for the name of the cloned logic app.

Then remove the logic app without the hyphens.

Next we need to approve both the API’s

On the Office365 API authorize the account that is authorize will be used to send the mail so if there is no mailbox associated against the account you will receive an error like the below.

“Office 365 Outlook” connector Error:- REST API is not yet supported for this mailbox. This error can occur for sandbox (test) accounts or for accounts that are on a dedicated (on-premise) mail server

To use a Shared Mailbox the Logic app will need modified the send a mail v2 action and add in a from address and use an account that has send as permission set on the mailbox.

https://learn.microsoft.com/en-us/connectors/office365/#send-an-email-from-a-shared-mailbox-(v2)

Once both API have been authorized we can run the trigger to test the job.

The backup report should then send.

To modify the time that the mail is sent at, we will need to set the time in the logic app. Open the logic app designer and add a new parameter under Recurrence.

Set the value to the start time required.

The summary mail should now send daily at 9AM.

How to check VM SKU and VM Series Sizes Different Methods

When deploying VMs in Azure using template we need to be able to check the VM SKU and sizes to be able to update templates to deploy different OS version and VMs sizes.

There are a few different methods that can be used.

There is the Microsoft document, below is the link to the virtual machine size docs.

https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-general

We can select the type in this case we will use general purpose.

Select the size, I selected ddv5-ddsv5-series. There will be table listing the VM sizes.

We also check the the VM size from the Azure portal by creating a new VM and changing the VM sizes.

Last method is to use either PowerShell or Azure CLI to query the require details on Windows Image SKU and VM sizes.

First we need to install the Azure AZ PowerShell module.

Run the below command to install the AZ module

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Once the module is installed run

Connect-AzAccount

We can use the Get-AzVMImagePulisher to get the publisher name in this case I was looking for Microsoft Windows.

Get-AzVMImagePublisher -Location northeurope | Where-Object {$_.PublisherName -like 'MicrosofWindows*'}

To check all available Windows Server images we can run.

Get-AzVMImageSku -Location northeurope -PublisherName MicrosoftWindowsServer -Offer Windowsserver

We can use where-object filter to by server OS version.

Get-AzVMImageSku -Location northeurope -PublisherName MicrosoftWindowsServer -Offer Windowsserver | Where-Object {$_.Skus -like '2022*'}

To get the VM series size use the below command to check size in the specific region.

Get-AzVMSize -Location northeurope

To filter by a specific cores or name we will use where-object again.

Get-AzVMSize -Location northeurope | Where-Object {$_.Numberofcores -eq '4' -and $_.Name -like 'Standard_D*'}

Now once we have the SKU and Image size we can update our template file with the required VM size and image references.

Using Parameter File With Bicep Templates

In the previous post we went through the process of deploying an Bicep template using parameter that where called directly from PowerShell.

Deploy Azure Resource Using Bicep template and PowerShell

This is ok when deploying resources that require only a few values to be set, but this can become difficult to manage when there are a lot of parameter like when deploying virtual machines or web apps.

A parameter file for Bicep is a json file that has the specific parameter names and values set.

I used this Microsoft document as a reference to create the parameter file.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameter-files

Below is the Bicep file we created in the last post.

A parameter file for the storage Bicep template would look like the below.

Once we have the parameter file, we are ready to test the deployment. To test without actually deploying the resource add the whatif parameter.

New-AzResourceGroupDeployment -ResourceGroupName ResourceGroupName -TemplateFile .\BicepTemplate.bicep -TemplateParameterFile .\BicepParamter.json -WhatIf

Next we will create a template to deploy a virtual machine and it network interface. To create base template in visual studio code type

res-nic to populate the network interface:

Use res-vm-windows to populate the virtual machine.

I will be creating parameters for each part that requires customization and anything that doesn’t I will leave with the hardcode values like. The @descirpiton is a Parameter decorators that allow use to add a description of what the parameter is used for.

I create two variables for the vnetId and subnetref that are used for the network interface

Below is what the updated virtual machine resource template looks like.

Once we have the Bicep template file ready the next step is to configure the parameter file. I copied the default template file code from the above Microsoft document and added in each of the required parameters.

To get the virtual network ID that will be used in the parameters file go to the virtual network and click on properties > Resource ID.

Once we have that we can fill out the reset of the parameter values.

After the template file has been configured, we can test the deployment same way as the storage account and use the whatif to confirm there are no errors.

As I have not set the admin password in the template or parameter file the deployment will prompt for the admin password to be set on the VM.

If the test deployment comes back without any issues we can check the results from the whaif deployment to confirm all the are correct.

Since the template and parameter files have returned no error we are ready to run and deploy the new VM resource.

If we check the resource group the new VM, OSDisk and network interface should be created.

Now that we have all the template and parameter file working we can just create a new parameter file for each VM resource. We can now create fully customized VM’s pretty quickly instead of having to deploy using the Azure market place and manually select the options we want to set.

Deploy Azure Resource Using Bicep template and PowerShell

In a previous post we went through deploying resource using ARM templates. I have been recently working on creating some new templates to be used for additional deployment and decided to use Bicep templates instead as it seem to an easier and more straight forward way of writing template files to deploy resources in Azure.

Bicep uses a simpler syntax than creating templates using JSON, the syntax is declarative and specifies which resources and resource properties you want to deploy.

Below is a comparison of a JSON and Bicep template file to create a storage account.

We can see that the bicep file is an easier format to read and create.

To get started with Bicep we will first be installing the Bicep extension to Visual Studio Code so we can edit and modify Bicep templates.

The extension adds intellisense which makes it easier than looking up the full syntax for each resource.

To create a new template click on new file in VS code and select bicep as the language.

To create a template using intellisense either start typing the res-resource type or the resource type itself.

Click on the resource to pre populate the template.

The values can be hard code in the template file but this would require manual change each time the template is run.

We can add parameters to the template to make it more reusable. There are a few different types of parameters that can be used.

Below is a brief description of each type.

Parameter	Description
string	Single line value
array	Allow multiple values
int	Integer value
bool	Required true or false
objects	Allows property types

Microsoft have a more in depth document on the different data types.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/data-types

The below is an example of a template with parameters set.

Once we have the template we need to install Azure PowerShell if not already installed and to install the Bicep tools, below is the document to install.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/install#install-manually

To connect to Azure PowerShell use

Connect-AzAccount

Once connected we can use the New-AzResourceGroupDeployment to deploy the template and specify the parameters values. To test the deployment for errors without running an actual deployment we can use the -whatif parameter.

New-AzResourceGroupDeployment -ResourceGroupName ResourceGroup -TemplateFile pathtotempaltefile\BicepStorageTest.bicep -location regsion -storagename storageaccountname -storagetype Standard_LRS -WhatIf

Run the command and it should return any error if there is an issue or green if there is no issue.

Once the template comes back with no issues we can remove the -whatif and the storage account will be created.

To confirm the storage account has been created use the Get-AzStorageAccount

Using parameters in the Bicep template is fine when there are only a few that need to be called but for more complex deployment it will be better to use a parameters file and pre fill each value.

In the next post we will go through the process of using a template to create a VM and its network interface and will call a parameters files instead of call the parameters in PowerShell directly.

Azure VM Snapshot Backup: UserErrorRequestDisallowedByPolicy

During a recent project I have been deploying new VM to Azure, when trying to configure the Azure VM backup I was getting a failure at taking snapshot.

The error that showed in the reason was UserErrorRequestDisallowedByPolicy.

This was being caused by a policy that one of the Azure Admins had setup to require tags be configure on resource groups. When a initial backup is run it creates a resource group to save the restore point collection to and it is this resource group that is getting blocked by the Azure tag policy.

To view the policy details we can go to Policy > assignments

Click on the policy to view the parameter’s.

There are two option to work around this issue, either changing the policy from a Deny effect to a Modify effect, or create the resource group manually.

I will be creating a manual resource group as I am not that familiar with creating custom policy yet and this was the quicker workaround.

Below is the link to the Microsoft document on creating a manual resource group for restore collection point.

https://docs.microsoft.com/en-us/azure/backup/backup-during-vm-creation#azure-backup-resource-group-for-virtual-machines

Here are the steps that I did to get around this, by manually creating the resource group that will be used for the backup.

This needs to be RG name with 1 as this starting number in my case I used TheSleepyAdmin_Backup_RG1.

In the backup policy we specify the new resource group. Go to Azure Backup center > Backup policies.

Put in the name of the resource group we create manually without the number. In my case this was TheSleepyAdmin_Backup_RG

Wait for the policy update to complete.

Now try the backup again and it should complete.

If we check the resource group we can see that the restore point collection has been created.

Any addtional backup should now also be successfully, if the resource group becomes full it will try to create a new RG so there maybe a need to create another RG in the future. I will be having a look at creating or updating the tag policy to apply a modify instead of a deny but that will be in a different post as this seems like it would be a better longer term solution.

Enable Accelerated Networking on existing Azure VM’s

In this post we will go over the different methods to enabled accelerated networking in an existing Azure VM.

Accelerated networking improves performance as it allows the network interfaces of Azure VM to bypass the host.

Screen shot from Microsoft documentation

Below are some of the benefits of using accelerated network.

Lower Latency / Higher packets per second

Reduced jitter,

Decreased CPU utilization

Accelerated networking is only supported on VM that have 2 or more CPU’s. If the VM’s are in a availability set all VM’s in the set need to be powered off before updating.

There are three way’s to enabled accelerated networking on existing VMs use either AZ PowerShell Module or the AZ CLI and directly in the Azure portal.

To enable in the Azure portal go to Virtual machines > Networking and select the required network interface.

To enable first Power off the VM,

Select the network interface and click on the name. This will bring you to the network interface configuration page.

Click on enable accelerated networking

You will have to confirm you have validate that your operating system is supported.

Once completed the network interface should now show have accelerated networking enabled.

Enabling in the console is fine for one or two interfaces but if there are a few to update doing PowerShell or AZ CLI will be a quicker method.

To update using the AZ PowerShell Module, first we need to install the module.

To install run the below command

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Once installed use the below to connect, you will be prompted to put in Azure account details.

Connect-AzAccount

Once connected, we can check if the network interfaces have accelerated networking using the below command.

Get-AzNetworkInterface -ResourceGroupName RGName | Select-Object Name,EnableAcceleratedNetworking

To enabled accelerated networking the VM needs to be stopped and deallocated so either power off from the Azure console or use stop-azvm

Stop-AzVM  -Name VMName -ResourceGroupName RGName

To enable we need to get the network adapter information into a variable and then set the enabledacceleratednetworking property to true.

$networkacc = Get-AzNetworkInterface -ResourceGroupName RGName-Name nicname
$networkacc.EnableAcceleratedNetworking = $true
$networkacc | Set-AzNetworkInterface

Once the command completes, we can run the command to check the network interfaces again and one should now have enabledaccleratednetworking set to true.

If there were multiple network interfaces in the resource group to enable, we could get the list and loop through each, but each VM would need to be supported or they would error out.

$networkaccs = Get-AzNetworkInterface -ResourceGroupName RGName
foreach ($networkacc in $networkaccs){

$networkacc.EnableAcceleratedNetworking = $true
$networkacc | Set-AzNetworkInterface

}

Last step is to power back on the VM either from the Azure portal or using AZ PowerShell.

Start-AzVM  -Name VMName -ResourceGroupName RGName

That is the process for setting using AZ Powershell.

To set using the Azure CLI, first we need to install the go to the below and download the MSI installer.

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?tabs=azure-cli

Once installed launch PowerShell.

to logon either use az login for an interactive logon process

or use with username and password parameter. (This method will not work with MFA so we will be using the interactive method.)

az login -u <username> -p <password>

When running the az login command you will be brought to the standard login.microsoft.com page.

Once signed in, we can query the resource group for network interfaces to see what has acceleratednetworking enabled

az network nic list --resource-group RGName --query [].[name,enableAcceleratedNetworking] --output table

To update the interfaces the VM needs to be powered off either in the Azure console or using AZ Cli

To use AZ Cli

az vm deallocate --resource-group RGName --name VMName

az network nic update --name NicName --resource-group RGName --accelerated-networking true

Once the command completes run the list command again to confirm that acceleratednetworking is set to true.

last step is to start the VM using either Azure port or Az Cli

az vm start --resource-group RGName --name VMName

The network interfaces should now have accelerated networking enabled.

Deploying Infrastructure in Azure Using ARM Templates

I have recently been looking at using Azure Resource Manager templates (ARM) to deploy and redeploy resources in Azure. I haven’t really done a lot with ARM templates so I though it might be helpful to do a few test runs and try figure out how to deploy resource in Azure using ARM templates.

In this post we will be going to through creating a ARM template from an existing resource group and what we need to do to redeploy to a new resources group.

ARM Templates are JSON files that define the infrastructure and configuration that will be deploy.

https://azure.microsoft.com/en-gb/services/arm-templates/

First we are going to export the template from Azure resource group that we want to redeploy to another resource group.

Logon to the Azure portal and go to resource groups.

Select the resource group that we want to export the template from.

Go to Automation and select export template.

This will bring up the ARM template for the resource group. We can then download the template to modify, I will be using visual studio code with the Azure Resource Manager (ARM) Tools extension added to edit the template.

Once the zip file is download and extracted there will be two JSON files, parameters’ and template.

When we look at the template file itself there will be a set of parameters. There are default values for each parameters which are the names of each resource in the resource group. I remove the default values.

The parameters are what is used to define the name of the resources that are created.

When I first started to look at the ARM templates they did seem very confusing but if you break them up in to each part instead of looking at it as a whole it made a lot easier for me to understand how the template worked.

If we take the below as a example this part of the JSON defines the virtual network and subnet to be created. It sets the location, subnet prefixes and one subnet for 10.0.0.0/24.

If there are IP address assigned or the subnet need to be changed this can be updated in the JSON file.

Once the JSON file has been modified we can then use this to deploy to Azure. The two way we will be going through in this post is using Azure portal Deploy from a custom template and second we will be going through adding the parameters to the parameters JSON and deploy using PowerShell.

First we will go through the portal deployment.

Logon to the Azure portal and go to deploy from a custom template.

We could search for template using the quick start template if we don’t have a existing template

but we will be using build your own template so we will be selecting build your own template.

This image has an empty alt attribute; its file name is image-10.png

Once the blade opens click load file and select the JSON template file this will then load the template.

Click save this should then a view like the below that we can manually in put the details we want to use for the deployment.

Click next and the arm template will be validated.

Click create to start the deployment.

When I deployed the template I had some issues with the VM creation.

This was caused by a few different issue. The first was the managed disk which returned the below error.

“Parameter ‘osDisk.managedDisk.id’ is not allowed.”

I found this article on Github https://github.com/Azure/azure-quickstart-templates/issues/3290 that explained the fix was to change the manageddisk from

to the below storage account type

The second issue was to do with requireGuestProvisionSignal property. I found the below forum post that said to remove the line.

https://docs.microsoft.com/en-us/answers/questions/332816/the-property-39requireguestprovisionsignal39-is-no.html

I removed this from the JSON.

The last issue was due to the admin password not being set. To fix this I added a new parameter at the start of the template

and set it under below under os profile

Once this was done I went back to deploy a custom template and readd the details which should now have the addtional admin password field.

The deployment now completed without issue.

The resources now be deployed to the resource group.

The second method we will be going through to deploy the ARM template is to use PowerShell.

We will be using the New-AzResourceGroupDeployment command to deploy the template.

We first will be modifying the parameters file to set the names that will be used.

For the adminpassword I will be adding the password to the parameter’s file but in production this should not be done and instead use something like Azure key vault to store the password.

First we need to install the Azure module

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Next we run

Connect-AzAccount

Next we run the New-AzResourceGroupDeployment I used the verbose parameter to get more details on the deployment. We will be calling the template and parameter JSON files.

New-AzResourceGroupDeployment -ResourceGroupName "resource group"  -TemplateFile "path to template json" -TemplateParameterFile "path to parameters json"

Below is the command running and provisioning the resources in the template.

Once the deployment completes all the resources will show under the resource group.

We can also use the ARM template to redeploy a resource that has been removed.

If we run the New-AzResourceGroupDeployment again after a resource has been deleted the deployment picks up that the missing resources and redeploys.

This was my first attempt at doing ARM and it not as complicated as I first thought I will probable do a few more post in the future after I have some more time working with ARM templates.

Configure Azure Site Recovery for VMware

Azure site recovery (ASR) is a DR / Migration tool from Microsoft and can be used to configure DR between data centers or Azure.

In this post we will be going through setting up ASR to replicate a VM from VMware to Azure.

There are some limitations for ASR these are listed the below link

https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix

The main limits for VMware are guest disk need to be less than 4TB and vCenter needs to be at least 5.5.

I have a previous post on how to configured a recovery service vault so I wont be going over that again but if you need to configure here is the previous post.

https://thesleepyadmins.com/2018/11/23/azure-vm-backup-using-azure-recovery-service-vault/

Logon to Azure

Go to Recovery Services vaults

ASR1 Go to the already configure vault, select Site Recovery and click on prepare infrastructure ASR2 Once the wizard has started select the require goals ASR3 I am not running the planning tools as this is a test but it is recommended to run before starting a deployment to verify the required bandwidth. ASR4 Next we will download the OVA appliance that will be imported to VMware ASR5 Once the OVA has been downloaded and imported to VMware on boot up the server will require you to read / accept a licence agreement and provide an administrator password.

Give the server a name (this will show up in as the configuration server in Azure after the setup as been completed) ASR6 Next step is to sign in to Azure tenant that the server will connect to for replication ASR8 Next we will go through the configuration steps first step is to set the interface that will be used to connect to on-prem devices & connection back to Azure there can be two different NIC’s assigned if required. ASR9 Next is to configure the Recovery vault that will be used, select the subscription, the recovery vault RG and recovery service vault that has been configured. ASR10 Install the MySQL software ASR11 Next a validation test will run. (I am getting a warring for memory and CPU as I didn’t have enough memory / CPU and had to edit the VM to run on less resource but it will still complete) ASR12 Next is to connect to the vCenter server that is running the VM’s that are to be replicated to Azure. ASR13 Last step will configure the configuration server in Azure. ASR15 Once this has been completed we can go back to the Azure portal and we should now see the configuration server show under prepare infrastructure setup ASR16

Select the subscription and deployment model to be used for failover I am using Resource Manager ASR17 Next create a replication policy to apply to the ASR configuration server. ASR18 ASR19 Once the configuration is done we can now protect and replicate our on-prem VM’s , go back to site recovery and select step 1: Replicate Application ASR20 Select source, source location (Configuration server on-prem)Machine type (Physical / virtual), vCenter (If virtual) and the process server ASR21 Select the subscription, RG that the VM will replicate too and the deployment model ASR22 Next select the server that will be replicated the VM must be powered on and be running VMware tools be available for replication other wise they will be grey-out ASR23 Select the required disk type, storage account ASR24 last step is to assign the policy required (Multiple policy can be created base on the recovery time requirements and retention times) ASR25

Last step is to enabled replication

ASR26

Once enabled check the site recovery jobs to see the progress ASR27 Once replication has completed we can create a recovery plan, go to recovery Plans (Site Recovery and select Recovery plan ASR28 Give the plan a name, select source, target , deployment type and select the VM’s that will be added to the recovery. ASR29 ASR31

Azure Migrate Services Setup

With more companies looking to move workloads from on-prem to cloud providers, it can be difficult to work out the cost for current workloads.

In Azure we can utilize Azure Migrate Services.

At the time of this post VMware is only supported, this will be extended to Hyper-v in future releases. VMware VMs must be managed by vCenter Server version 5.5, 6.0, 6.5 or 6.7.

In this post we will be going through the process off assessing the on-prem VMware environment and view the assessment report.

The environment we will be assessing is VMware vCenter 6.7 and ESXi 6.7 and a VM running Windows Server 2016.

The architecture of the Azure Migrate Service is shown in the following diagram

AZMIG

Below is the process

Create a project: In Azure, create an Azure Migrate project
Discover the machines: Download collector VM as an OVA and import to vCenter
Collect the information: The collector collects VM metadata using VMware PowerCLI cmdlets. Discovery is agentless and doesn’t install anything on VMware hosts or VMs. The collected metadata includes VM information (cores, memory, disks, disk sizes, and network adapters). It also collects performance data for VMs
Assess the project: The metadata is pushed to the Azure Migrate project. You can view it in the Azure portal.

Logon to Azure

Go to All services search for migration project AZMIG_1

Select Create migration project

AZMIG_2

Give the project a Name, subscription, Resource group & Geography

AZMIG_3

Select Discover & Assess AZMIG_4

Select Discover and Assess. then Discover machines AZMIG_5 download OVA. The system requirement for the OVA are:

CPU: 8 vCPU’s; Memory: 16GB; HardDrive: 80GB AZMIG_6

Next step is to import the OVA to VMware

Go to vCenter

AZMIG_7

Browse to the OVA file location and select AZMIG_8 Select the Name and location of the OVA AZMIG_9 Select the destination cluster AZMIG_10 Click Next AZMIG_11 Select destination data store and specify either thick or thin provisioned disk AZMIG_12 Select the port group tha the VM will use AZMIG_13 Review and confirm settings AZMIG_14

Once the OVA is imported, power on the VM

Read and accept the license terms and give the collector an admin password.

Log into the VM and run the connector utility on the desktop.

AZMIG_15

Got through the prerequisites checks AZMIG_16

Next step is to connect to the vCenter. Put in the vCenter IP or hostname, Username / Password and once connect select the cluster or host that is currently running the VM’s that need to be assessed for migration.

AZMIG_17

Next step is to connect back to Azure using the migration project credentials that were generated when creating the project AZMIG_19 AZMIG_18

Click continue and the last screen will start the discovery this can take a while to complete (60 minutes or so) AZMIG_20

Once the discovery has completed, we then need to Create assessment AZMIG_21

Create a new group and select the VM that will be assessed AZMIG_22

Once this has completed go to Overview and click on the assessment AZMIG_23

Once in the assessment you can see the readiness of your VM and the Monthly estimated cost for running the workloads and AZMIG_24

Click on the VM to view specific details and performance stats AZMIG_25

We can now see what the cost will be for migrating workloads to Azure and this can be presented to give a better understanding of the cost savings that can be achieved with cloud migrations.