How to migrate Azure Managed Disk to different subscription and region – Part II

On the previous post I describe what need to do to move Azure Managed Disks between subscriptions and after that between regions (see link HERE). Although I didn’t explore the steps mention to move between regions.

Here are the step-by-steps of each stage, mention on the previous post, of how to move the Azure Managed Disk between Azure Regions:

1. Stop the virtual machine from migrating

1. Navigate to the Azure portal (https://portal.azure.com)
2. Click Virtual Machines on the left-hand menu, then select the virtual machine to be migrated
3. Click Stop

2. Enable the Export function to generate a single URL containing the VHD of the managed disk to migrate

1. On the selected virtual machine, click on Disks

2. Select the managed disk that you want to migrate

3. Click Export

4. Click on the Generate URL button

5. Copy this unique URL pointing to the target VHD file to the Notepad or any other clipboard.

3. Create a storage disk in the target region of the new subscription

1. So now, we need to create a storage account in the target region on the target subscription

2. Create a Container (folder) containing the VHD file to use and retrieve the connection information to that storage account:

2.1. On the Azure portal, select All Services.
2.2. Scroll to storage, and then select storage accounts
2.3. On the Storage Accounts window, click Add
2.4. Select the subscription in which you want to create the storage account, as well as the target resource group
2.5. Enter the name for your storage account
2.6. Select the location of your storage account (target region)
2.7. Leave all other fields to their default value
2.8. Click Verify + Create to review your storage account settings and create the account.

3. After the storage account is created, click Blob on the container

4. On the Name field, type VHDs

5. Click the OK button to confirm. This folder will contain the VHD file copied to the new region.

6. Click VHDs and then select Properties

7. Copy the URL to the Notepad (example: https://tempmanagedisk.blob.core.windows.net/vhds)

8. Click access keys and copy the Key1 key to the Notepad.

4. Use the AzCopy command from an Azure virtual machine (this option will decrease the copying time) to copy the data (VHD file) from the managed disk to a storage account created in the target region of the new subscription

AzCopy is a command-line utility designed to copy data from/to an Azure Blob, to a file or to a Table using simple commands with optimum performance. You can copy data between a file system and a storage account, or between storage accounts.

To start, you need to download and then install the latest version of the AzCopy utility from the following link aka.ms/downloadazcopy on a Windows virtual machine hosted in Azure. This was the way that I found to speed up the process of transferring the data between managed disks.

So, let start with the steps to copy the data:

1. Run a command prompt from the Azure virtual machine

2. Select the C:\Program Files (x86) \microsoft SDKs\Azure\AzCopy Directory (the utility does not modify the path).

3. Type the command to copy the data from the source managed disk to the target storage account previously created in a target subscription:
        azcopy /source:”<URL_FROM_VHD>” /dest:”<URL_VHD_DESTINATION>” /destkey:”<KEY1>”

5. From the VHD in the storage account, create a managed disk

After the copy is completed, we need to create a managed disk from the VHD copied.

1. Click All services

2. Select disks and Add

3. Enter the name of the managed disk to be created from the VHD file copied to the Storage account

4. Select the target subscription, the target resource group, and especially the target region

5. From the source Type drop-down menu, select Storage Blob, and then click the Browse button

6. Select the target storage account

7. Select the VHDs container

8. Select the copied VHD file and then validate by clicking the Select button

9. Finally enter the size in GiB and then click the Create button.

6. From the previously managed disk created, recreate a virtual machine

Now that the managed disk is on a different region and subscription, the final step is to create a virtual machine from the managed disk.

1. On the Azure Portal, navigate to Disks

2. Click on the managed disk that was created

3. Create a virtual machine

4. Follow the steps to create the virtual machine.

With these 6 steps, we copied a managed disk from an Azure virtual machine from region A to region B of another subscription, and then recreated the virtual machine.

Finally, be aware that it is possible to enable migration of managed disks between 2 subscriptions from the Azure portal GUI, but this method does not allow you to change the region of the virtual machine (thus the managed disk) and is only valid if the source virtual machine is not backed up.

To enable this feature, run the following 2 commands from a PowerShell Azure window and the source subscription:

Register-AzureRmProviderFeature -FeatureName ManagedResourcesMove -ProviderNamespace Microsoft.Compute

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute

Cheers,Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

Unresponsive Azure VM

Another day I was at one of my costumers, and a system engineer come to me asking me if I could help him troubleshoot an issue with an unresponsive Azure VM. I love this moments, specially when I can always learn new ways that users are using Azure.

OK, lets move to the issue. Here is the list of issues that he reports to me:

  • No RDP into VM
  • VM not “pingable” from the network (either on prem or on Azure)
  • Remote PowerShell not available

Usually when this kind of issues happen, I always recommend to redeploy (see picture below).

But what does the redeploy on an Azure VM does to fix the issue. Sometimes the VM running on the host/node on Azure, get “stuck” on a state that makes the VM seems inaccessible from the network, although from the monitoring the VM is still running. By redeploy the Azure VM, you are redeploying the VM on another host/node in the same Azure datacenter.

What this mean? Means that Azure will shutdown automatically your VM, move it to another host/node available with the capacity to run and then power it back. All of this process will retain the configuration, the resources associated and the disks.

How to redeploy an Azure VM

You have to option, either through the Azure Portal or through PowerShell

Azure Portal

  • On Azure Portal, navigate to the VM. Down on the left under Support + troubleshooting area, you will find the Redeploy.

  • When you select Redeploy, it will appear a page explaining what will happen. Then click Redeploy
  • After that you will see the status the VM changing to Updating. When the status change to Running the redeploy is finish and now you can access the VM.

PowerShell

If you want to use the Azure Cloud Shell or the PowerShell on your machine the command is the same.

Set-AzureRmVM -Redeploy -ResourceGroupName “<RESOURCE_GROUP>” -Name “<VM_Name>”

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Serial Console access on Azure Virtual Machine

Finally come the day that Microsoft was able to announce this feature. Accessing the serial console on an Azure VM is a huge step forward. But why is so important? It’s huge! Sometimes when our friend Mr Murphy comes and makes everything goes south, you are in a certain way limited on the diagnostic tools that you have, to troubleshoot the cause of that machine is not booting. Have access to the boot of the server (Linux or Windows) is crucial at this time. Serial Console access will end those day of redeploy a VM using the same disk, when this option is viable, off course. You can see the announcement here.

But let’s dive into the Accessing the Serial Console. On each VM that you have running on Azure, under the SUPPORT + TROUBLESHOOTING, you will find the Serial console (preview).

When you click on that, automatically start to connect to the Serial Console of that VM.

After a few seconds, finishes the connection. And show me this screen. But I can’t do anything.

If you scroll up, then some light at the end of the tunnel. OK, I need to enable the SAC (Special Administrative Console) on the server.

To access the Serial Console on the server you need the enable it. To enable, just follow the steps below:

  1. Connect to your VM through RDP (in this case a Windows VM)
  2. Open the cmd with elevated (administrative privileges)
  3. From the cmd prompt run the following commands
    bcdedit /ems {current} on
    bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
  4. Reboot the VM

And then, you have access to the serial console of your server.

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Load Balanced and Availability Set with multiple VMs

When it comes to best practices to how to setup multiple virtual machines using a load balanced and availability set, the information out there is either outdated or hard to find.

What is the scenario? Imagine that you need to set a few VMs that need to be shared the configuration and some files between them. How you could do it?

After a few searches on the web, I come across with the IIS and Azure Files blog post. Although this post is dated of October 2015, and as you know, Azure is changing in a very fast pace. My first though was, is this still applicable? After a few tests on my test environment, I found that it’s! Surprisingly! So, if you follow all the steps in the post you may configured your environment.

In my case, there was a specific requirement that this approach wasn’t applicable. My workloads required low latency. So, I went again searching how I could achieve this. And then I found the solution on GitHub! Microsoft publish a template that the only thing you need is fill the blanks. THANK YOU!

This is the template that I’m referring too, 201-vmss-win-iis-app-ssl.

Solution overview and deployed resources

This template will create the following Azure resources

  1. A VNet with two subnets. The VNet and the subnet IP prefixes are defined in the variables section i.e. appVnetPrefix, appVnetSubnet1Prefix & appVnetSubnet2Prefix respectively. Set these two accordingly.
  2. A NSG to allow http, https and rdp access to the VMSS. The NSG is assigned to the subnets.
  3. Two NICs, two Public IPs and two VMSSs with Windows Server 2012 R2
    3.1) The first VMSS is used for hosting the WebSite and the 2nd VMSS is used for hosting the Services (WebAPI/WCF etc.) 3.2) The VMSSs are load balanced with Azure load balancers. The load balancers are configured to allow RDP access by port ranges 3.3) The VMSSs are configured to auto scale based on CPU usage. The scaled out instances are automatically configured with Windows features, application deployment packages, SSL Certificates, the necessary IIS sites and SSL bindings
  4. The 1st VMSS is deployed with a pfx certificate installed in the specified certificate store. The source of the certificate is stored in an Azure Key Vault
  5. The DSC script configures various windows features like IIS/Web Role, IIS Management service and tools, .Net Framework 4.5, Custom login, request monitoring, http tracking, windows auth, application initialization etc.
  6. DSC downloads Web Deploy 3.6 & URL Rewrite 2.0 and installs the modules
  7. DSC downloads an application deployment package from an Azure Storage account and installs it in the default website
  8. DSC finds the certificate from the local store and create a 443 binding
  9. DSC creates the necessary rules, so any incoming http traffic gets automatically redirected to the corresponding https end points

The following resources are deployed as part of the solution

A VNet with two subnet

The VNet and the subnet IP prefixes are defined in the variables section i.e. appVnetPrefix, appVnetSubnet1Prefix & appVnetSubnet2Prefix respectively. Set these two accordingly.

  • NSG to define the security rules – It defines the rules for http, https and rdp acces to the VMSS. The NSG is assigned to the subnets
  • Two NICs, two Public IPs and two VMSSs with Windows Server 2012 R2
  • Two Azure load balancers one each for the VMSSs
  • A Storage accounts for the VMSS as well as for the artifacts

Prerequisites

  1. You should have a custom domain ready and point the custom domain to the FQDN of the first public IP/Public IP for the Web Load balancer
  2. SSL certificate: You should have a valid SSL certificate purchased from a CA or be self signed
  3. Create an Azure KeyVault and upload the certificate to the KeyVault. Currently, Azure KeyVault supports certificates in pfx format. If the certificates are not in pfx format then import those to a windows cert store on a local machine and then export those to a pfx format with embeded private key and root certificate.

 

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

 

Move VM between VNETs in Azure

This week I come into this scenario, I would like to move a virtual machine in azure between different VNETs. You might have different reasons to do it, but what is the best way to do it?

First you have to understand the scenario, is between VNETs on the same region, or between regions? Same subscription or different subscriptions? And at last same tenant or between different tenants?

The way that I look into to this is simple. I know that you have different ways to approach these scenarios, but I want to try to create a solution that no matter what you could use it.

Let’s work on the possibilities. What we know:

  • When you create a VM in Azure, you create several resources (compute, network and storage)
  • When you delete the VM in Azure, you only delete de compute (assuming that you click on the delete button and you didn’t delete the resource group). That means the VHD and the network adapter (and all their dependencies) will remain intact.

So we could use this “orphan” resources (objects) to create a new VM on the VNET that we want. Genius! 😊

In this case we could use the script that I publish to create the VM with the existing disk (see here). That is one option.

Although, if you are on the path of using ARM Template with JSON, you might want to double check if your JSON template reflects that as well (see here).

This is another way to solve your issue of moving a VM between VNETS.

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga