Upload a Windows 2003 Hyper-V VHD to Azure (Part 2 of 2)

In part one of this two part blog post, I created a Hyper-V VHD disk from a Windows 2003 VMWare VM. Now I want to upload the VHD disk to Azure and create a VM there. I will run the Domino server on the VM and test connecting to it with a web browser and a Notes client.

Note: I provide an abundance of details with screenshots.

Log in to Azure

If you don’t already have PowerShell version 1.4 or above installed, read How to install and configure Azure PowerShell.

  1. Open Azure PowerShell and sign in to your Azure account. A pop-up window opens for you to enter your Azure account credentials.


  1. Get the subscription names for your available subscriptions.

Get-AzureRmSubscription | Sort-Object subscriptionName | Select-Object SubscriptionName

  1. Set the correct subscription using the subscription ID. Replace<subscriptionName> with the ID of the correct subscription.
Select-AzureRmSubscription -SubscriptionName Pay-As-You-Go


Get the storage account

You need a storage account in Azure to store the uploaded VM image. You can either use an existing storage account or create a new one.

To show the available storage accounts, type:


If you need to create a storage account, follow these two steps:

1. You need the name of the resource group where the storage account should be created. To find out all the resource groups that are in your subscription, type:


To create a resource group named vmResourceGroup in the Central US region, type:

New-AzureRmResourceGroup -Name vmResourceGroup -Location “Central US” -Tag @{Name = ‘Created By’;Value = ‘Randy’}


2. Create a storage account named vmrhrstorageaccount in this resource group by using the New-AzureRmStorageAccount cmdlet:

New-AzureRmStorageAccount -ResourceGroupName vmResourceGroup -Name vmrhrstorageaccount -Location “Central US” -SkuName “Standard_LRS” -Kind “Storage”

Valid values for -SkuName are:

  1. Standard_LRS– Locally redundant storage.
  2. Standard_ZRS– Zone redundant storage.
  3. Standard_GRS– Geo redundant storage.
  4. Standard_RAGRS– Read access geo redundant storage.
  5. Premium_LRS – Premium locally redundant storage


Upload the VHD to your storage account

I know of three ways to upload the VHD to a storage account. I will briefly review how to use each one. I think PowerShell will always work; but Cloudberry has a Pause feature that I really like.

  1. PowerShell
  2. Storage Explorer
  3. Cloudberry Explorer


Use the Add-AzureRmVhd cmdlet to upload the image to a container in your storage account. I am uploading the file windows2003.vhd from “F:\Users\Randy\Documents\Virtual Machines\Domino R8.5 Azure\” to a storage account named vmrhrstorageaccount in the vmResourceGroup resource group. The file will be placed into the container named vmcontainer and the new file name will be vmWindows2003VHD.vhd.

The first time I ran this code, I specified 4 uploader threads to see if that would improve upload performance.

–NumberOfUploaderThreads 4

My understanding is that I need a bigger pipeline for uploading as the number of uploader threads is increased. So setting it to 32 with my current pipeline would be of no benefit. This time I am just going to use a single thread.

$rgName = “vmResourceGroup”$urlOfUploadedImageVhd = “https://vmrhrstorageaccount.blob.core.windows.net/vmcontainer/vmWindows2003VHD.vhd”Add-AzureRmVhd -ResourceGroupName $rgName -Destination $urlOfUploadedImageVhd -LocalFilePath “F:\Users\Randy\Documents\Virtual Machines\Domino R8.5 Azure\Windows2003.vhd”





21 hours later …


If successful, you get this response:


Storage Explorer

I will assume that you already have Azure Storage Explorer installed. Click on Upload.


I select the VHD file that I want to upload.


Initializing Upload took several minutes without any updates.


The upload begins! Only 1407 hours …


A few minutes later there is no change in how much is uploaded.


I cancel the upload.


Perhaps Storage Explorer is not the right tool for what I need here.

Cloudberry Explorer

I download CloudBerry Explorer for Azure Blob Storage from http://www.cloudberrylab.com.

I install and run the software. I choose the Freeware edition.


I configure a connection to my vmrhrstorageaccount on Azure.


I select my Windows2003.vhd file and click on Copy as a Page Blob. Page blob is mainly used for VHD’s. The Copy process begins.

Note the Pause button is what excites me! I want to be able to pause the upload at times. For example, I use my Internet connection for all voice calls.


The Blob file is being updated …


The upload is 100% completed. It took about 24 hours to complete … just a few hours longer than the initial estimate.


Check Azure Storage

I open my Azure site to the storage account that I created:


I open the Blobs. I can see the vmcontainer that I created.


I click on vmcontainer. I can see the vhd file that I uploaded.


Create a Managed Disk from the VHD

I am creating a managed disk. A managed disk manages the storage accounts used for the VM disks for you. You specify the type (Premium or Standard) and size of disk you need, and Azure creates and manages the disk for you. You don’t have to worry about placing the disks across multiple storage accounts in order to ensure you stay within the scalability limits for the storage accounts — Azure handles that for you.

I am referencing another resource for creating the VM. I like to use PowerShell.


I run the PowerShell code to create a new resource group and a new OS disk from the uploaded VHD.

Note: I had problems with New-AzureRmDiskConfig. So I went to this webpage and followed the instructions.


I closed and restarted PowerShell. Then went through the login process again.


Then I continued with the PowerShell commands below.

$location = “Central US”

$destinationResourceGroup = “myWindows2003ResourceGroup”

New-AzureRmResourceGroup -Location $location -Name $destinationResourceGroup

$sourceUri = “https://vmrhrstorageaccount.blob.core.windows.net/vmcontainer/Windows2003.vhd

$osDiskName = “myWindows2003Disk”

$diskconfig = New-AzureRmDiskConfig -Location “Central US” -AccountType StandardLRS  -CreateOption Import -SourceUri $sourceUri

$osDisk = New-AzureRmDisk -DiskName $osDiskName -Disk $diskconfig -ResourceGroupName $destinationResourceGroup

The new resource group is created


The operating system disk is also created! I can see it in the new resource group that I created.

The disk is listed in the new resource group.


I can click on the disk to view the properties.


Create the new VM

First I need to create the subNet and vNet of the virtual network.

Below is the PowerShell I used to create the subnet and vNet.

$subnetName = ‘win2003SubNet’

$singleSubnet = New-AzureRmVirtualNetworkSubnetConfig `

   -Name $subnetName `


$location = “Central US”

$destinationResourceGroup = “myWindows2003ResourceGroup”

$vnetName = “win2003VnetName”

$vnet = New-AzureRmVirtualNetwork `

   -Name $vnetName -ResourceGroupName $destinationResourceGroup `

   -Location $location `

   -AddressPrefix `

   -Subnet $singleSubnet

I receive a warning:

WARNING: The output object type of this cmdlet will be modified in a future release.

Now I must be able to log in to my VM using RDP. I need to have a security rule that allows RDP access on port 3389. Because the VHD for the new VM was created from an existing specialized VM, I can use an account from the source virtual machine for RDP.

The Lotus Notes Domino web server uses port 80 to distribute and receive http requests.

The Lotus Notes Client uses port 1352 by default to communicate with the Lotus Notes Server.

Lotus Notes servers use port 1352 by default to replicate with each other.

Thus, I also want to allow access on port 80 and 1352.

$nsgName = “myWindows2003NSG”

$rdpRule = New-AzureRmNetworkSecurityRuleConfig -Name “myRDPRule” -Description “Allow RDP” `

    -Access Allow -Protocol “Tcp” -Direction Inbound -Priority 110 `

    -SourceAddressPrefix Internet -SourcePortRange * `

    -DestinationAddressPrefix * -DestinationPortRange 3389

$httprule = New-AzureRmNetworkSecurityRuleConfig -Name “myHTTPRule” -Description “Allow HTTP” `

    -Access “Allow” -Protocol “Tcp” -Direction “Inbound” -Priority “100” `

    -SourceAddressPrefix “Internet” -SourcePortRange * `

    -DestinationAddressPrefix * -DestinationPortRange 80

$notesrule = New-AzureRmNetworkSecurityRuleConfig -Name “myIBMNotesRule” -Description “Allow IBM Notes” `

    -Access “Allow” -Protocol “Tcp” -Direction “Inbound” -Priority “120” `

    -SourceAddressPrefix “Internet” -SourcePortRange * `

    -DestinationAddressPrefix * -DestinationPortRange 1352

$nsg = New-AzureRmNetworkSecurityGroup `

   -ResourceGroupName $destinationResourceGroup `

   -Location $location `

   -Name $nsgName -SecurityRules $rdpRule, $httprule, $notesrule

I receive the same warning:

WARNING: The output object type of this cmdlet will be modified in a future release.

I review the virtual network that I created.


I click on the win2003VnetName virtual network and then on Subnets.


I see one warning in Address space. I just have to be careful not to run my SharePoint server at the same time! But I will probably change the Vnet settings soon.


Next I open my new network security group. I can see that my inbound security rules were successfully created.


The RDP rule has a warning.


Create a public IP address and NIC

To enable communication with the virtual machine in the virtual network, I need a public IP address and a network interface.

$destinationResourceGroup = “myWindows2003ResourceGroup”

$ipName = “myWindows2003IP”

$pip = New-AzureRmPublicIpAddress `

   -Name $ipName -ResourceGroupName $destinationResourceGroup `

   -Location $location `

   -AllocationMethod Dynamic

$nicName = “myWindows2003NicName”

$nic = New-AzureRmNetworkInterface -Name $nicName `

   -ResourceGroupName $destinationResourceGroup `

   -Location $location -SubnetId $vnet.Subnets[0].Id `

   -PublicIpAddressId $pip.Id `

   -NetworkSecurityGroupId $nsg.Id

I open the new NIC that I created in Azure. Everything looks like it set correctly.


The IP address for the Public IP address is not set yet.


Next I select the VM type, VM name, disk size, and the NIC.

My VMWare VM has a 40GB disk drive, dual core processor, and 3032MB of memory. I need something similar on Azure. I can see the list of available VMs at the URL here:


The Basic_A1 series has 1 CPU, 1.75GB of memory, 40GB disk drive, and 1 NICs. It is one less CPU and half the memory that I currently have on my VMWare VM.

The Basic_A2 series has 2 CPU, 3.5GB of memory, 60GB disk drive, and 1 NICs. A Basic is an economical option for development workloads, test servers, build servers, code repositories, low-traffic websites and web applications, micro services, early product experiments, and small databases.

I want to try the Basic_A2 series; but I will exceed my quota limit of 10 cores by 1 core.

I create a Support Request to increase my quota to 20. https://portal.azure.com/#create/Microsoft.Support

My Support Request is approved within two minutes!!! Awesome!

I will proceed with Basic_A2 series.

$vmName = “myWindows2003VM”

$vmConfig = New-AzureRmVMConfig -VMName $vmName -VMSize “Basic_A2”

$vm = Add-AzureRmVMNetworkInterface -VM $vmConfig -Id $nic.Id

$vm = Set-AzureRmVMOSDisk -VM $vm -ManagedDiskId $osDisk.Id -StorageAccountType StandardLRS `

    -DiskSizeInGB 40 -CreateOption Attach -Windows

New-AzureRmVM -ResourceGroupName $destinationResourceGroup -Location $location -VM $vm

I check Azure for my new Windows 2003 VM. It is running!


I click on the VM to view the Overview details.


I click on Connect to view the VM. I click Open to continue.


I click Connect to continue.

Note: Ignore the IP address in the screenshot below. It should match the public IP address.


I click Yes to continue.


The first time I tried this, I got a warning message. Basically, I believe that it failed because I did not have a network adapted on the VM that I uploaded.


But this time it looks like it is working! I have a connection and can log into the server.



I successfully login.


Auto-Shutdown of Azure VM

As a precaution, I set my VM to auto-shutdown at 5:00PM Central Time. This setting is made in Azure. I try to do this as soon as possible to avoid any unnecessary expenses while I am testing.


Update Windows Firewall to Open Port 1352

I had to update the Windows Firewall on the Windows 2003 VM to open port 1352 for the Notes client. I open the Local Area Connection. Then I open Windows Firewall and click on the Exceptions tab. Then click on Add Port.


I add the details for port 1352 as seen below. I do not make any changes to the default scope. I click OK to accept the changes.


I click OK to close the Windows Firewall dialog.

Update Hosts, LMHosts.sam, and Server Connection

I updated the IP address in the hosts and lmhosts.sam files to point to the local IP address. You may need to do the same if you use these files for host resolution.

I also updated the connection record in the local address book in the Lotus Notes client to use the new local IP address.


Start the Domino Server

I start up the Domino 8.5.3 Server successfully.


Test Connection via Web Browser

I came back a day later to test connecting to the Domino web server on Azure. I start the VM and the Domino server.

I have to run “load http” on my Domino server to start the web services. You may not have to do so.

Then I open a web browser on my computer and open up the URL

The IP address is the new public IP address. It will change every time I start the Azure VM.

Test.nsf is a Lotus Notes database on my Domino server. The test database opens in a web browser. Success!


Test Connection via Lotus Notes Client

Next I will test connecting from my Lotus Notes client. I update the connection document to point connections to the Domino server to the public IP address:


I updated the IP address in the hosts and lmhosts.sam files to point to the public IP address.

Then I attempt to open a Notes database on the Domino server. Success!


I select my Test.nsf database and open it. Success again!


Next Steps

To make this a permanent solution, I need to configure a permanent IP address for the public IP address in the resource group and a permanent IP address for the Windows 2003 Server in the virtual network / subnet. Then I won’t need to update the IP address references everywhere each time I restart the Azure VM.

I should update the Domino Server record to point to the updated IP address or DNS name.

I should also validate the licensing of the Windows 2003 server. It is warning me that I need to validate the licensing again since the hardware changed significantly.

I could try a lift-and-shift migration using Azure Site Recovery. I think that would be a good approach for a large scale migration of VMs.


Thus, I was able to successfully migrate a Windows 2003 VMWare VM to an Azure VM. I was also able to connect to the Domino server running on the VM via a web browser and the Notes client.

Additional Resources

The link below provides documentation on how to create and upload a Windows virtual hard disk (VHD) to be used in creating an Azure VM. You can upload a VHD from either a generalized VM or a specialized VM.


For a complete walk-through of how to prepare, upload and create a new VM using managed disks, see Create a new VM from a generalized VHD uploaded to Azure using Managed Disks or Upload a specialized VHD to create a VM in Azure.+

For more details about disks and VHDs in Azure, see About disks and VHDs for virtual machines.



One thought on “Upload a Windows 2003 Hyper-V VHD to Azure (Part 2 of 2)

  1. Pingback: Preparing a Windows 2003 Server VMWare VM for Import to Azure VM (Part 1 of 2) | Randy's Technology Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s