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.



Preparing a Windows 2003 Server VMWare VM for Import to Azure VM (Part 1 of 2)


I have a read a few blog posts on uploading old VMs to Azure. Some of the blog posts make it look like it is a very simple process. However, the comments to the posts often describe a failure and request additional details. I’m going to post the details about my experience. I will also provide some explanation on where I ran into some problems and explain what I do to resolve them.

This is part one of a two part blog posting. Part one ends with the conversion of a Windows 2003 VMWare VM to a Hyper-V VHD disk. Part two provides the details to upload the VHD disk to Azure and create a VM there. Then I 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.

My Current VMWare VM

I have an old Windows 2003 Server running in a VMWare Workstation VM. I used to run a SharePoint 2010 Server on it; but now I use it to run a Domino R8.5 Server. I suspect that a lot of organizations have Domino Servers running on Windows 2003 Servers. The preparation steps would be slightly different if they upgraded their Windows 2003 Server to Windows 2008 or 2012. The differences would be with the configuration of remote access on the server.

I want to upload the Windows 2003 Server to an Azure VM. It has a 40GB disk drive with 7GB of free disk space. It is running a 32-bit version of Windows 2003 Server with Service Pack 2 installed. I know that Azure provides best effort support only for running Windows 2003 servers – both 32-bit and 64-bit.

Below you can see a screenshot of the System Properties of my Windows 2003 Server.


I know that I can upload both generalized and specialized VHDs to Azure. Each type requires that you prepare the VM before starting. I want to create a specialized VM.

Generalized VHD – a generalized VHD has had all of your personal account information removed using Sysprep. If you intend to use the VHD as an image to create new VMs from, you should:

Specialized VHD – a specialized VHD maintains the user accounts, applications and other state data from your original VM. If you intend to use the VHD as-is to create a new VM, ensure the following steps are completed.

  • Prepare a Windows VHD to upload to Azure.
  • Do not generalize the VM using Sysprep.
  • Remove any guest virtualization tools and agents that are installed on the VM (i.e. VMware tools).
  • Ensure the VM is configured to pull its IP address and DNS settings via DHCP. This ensures that the server obtains an IP address within the VNet when it starts up.

Create a Clone

I make sure that my Windows 2003 Server VM is shut down. Then I create a clone of my Windows 2003 Server VM.

The Welcome Screen appears. I click Next to continue.


The Clone Source screen appears. I accept the current settings and click Next to continue.


The Clone Type screen appears. I select Create a full clone and click Next to continue.


The Clone Name screen appears. I update the name and click Finish to continue.


The cloning process begins.


The final screen appears and I click Close.


Preparing the VM

I power on the cloned VM.


I often get this error displayed; but it never seems to be a problem. I click OK to continue.


I check the VMWare VM Network Configuration.


I changed the setting to obtain an IP address automatically. This is the right configuration; but it won’t really matter since I lose the network adapter when I convert to a Hyper-V disk drive.

I clicked OK.


Windows Management Core Package

I want to check that I have installed the Windows Management Core Package installed on my Windows 2003 Server.

I run PowerShell. I happen to have it on my desktop.


I double-click on the icon and PowerShell starts. It looks like I have v1.0 installed.


The package I want to download contains PowerShell 2.0.

I can download the package from here: http://www.microsoft.com/en-us/download/details.aspx?id=4045

I click on Download.


I have to click on click here to download manually.


But that still does not download the file.

I know that the URL to the file is https://download.microsoft.com/download/1/1/7/117FB25C-BB2D-41E1-B01E-0FEB0BC72C30/WindowsServer2003-KB968930-x86-ENG.exe

I return to my PowerShell window.

I copy and paste the following commands:

$url = “http://download.microsoft.com/download/1/1/7/117FB25C-BB2D-41E1-B01E-0FEB0BC72C30/WindowsServer2003-KB968930-x86-ENG.exe&#8221;

$path = “C:\download\WindowsServer2003-KB968930-x86-ENG.exe”

# param([string]$url, [string]$path)

if(!(Split-Path -parent $path) -or !(Test-Path -pathType Container (Split-Path -parent $path))) {

      $path = Join-Path $pwd (Split-Path -leaf $path)


“Downloading [$url]`nSaving at [$path]”

$client = new-object System.Net.WebClient

$client.DownloadFile($url, $path)

#$client.DownloadData($url, $path)


Note that I removed the “s” in https://.

I confirmed that I have a download folder on the C: drive.


I hit Enter. The file downloads.


I run the file in C:\download.


Good news! I already have the Core installed!

Run Windows Update

I also checked Windows Update in Internet Explorer to see if I was missing an update.


I have not updated this server in almost 10 years. It is taking a long time to check!

I expect this to be the situation for most companies, too.


But I know that a process is running. I checked Windows Task Manager.


The process completes almost an hour later.


I will install the first updates.


I click on Review and install updates.


Then I click on Install Updates.


The installation completes and I click on Restart Now.


The Windows 2003 Server restarts.

I check Windows Update again. This time I will install all high-priority updates. There are 169 updates to apply. I expect this to take an hour or more.


Note: Update 17 required me to install Internet Explorer 8. I had to click on some dialog boxes.

I restart the VM after the installation completes.

Set Windows configurations for Azure

On the virtual machine you plan to upload to Azure, run all the following commands from the command prompt window with administrative privileges. In this case, I run as Administrator.



Change to the C:\windows\system32 directory.

Remove any static persistent route on the routing table:

To view the route table, run route print from the command prompt window.

Check the Persistence Routes sections. If there is a persistent route, use route delete to remove it. The VM has none because I changed the IP settings to obtain an IP address automatically.


Remove the WinHTTP proxy:

netsh winhttp reset proxy


Set the disk SAN policy to Onlineall.


 san policy=onlineall



Set Coordinated Universal Time (UTC) time for Windows and the startup type of the Windows Time (w32time) service to Automatically:

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1

Enter Yes and hit Enter

sc config w32time start= auto


Set services startup to Windows default values

Make sure that each of the following Windows services is set to the Windows default values. To reset the startup settings, run the following commands:

sc config bfe start= auto

sc config dcomlaunch start= auto

sc config dhcp start= auto

sc config dnscache start= auto

sc config IKEEXT start= auto

sc config iphlpsvc start= auto

sc config PolicyAgent start= demand

sc config LSM start= auto

sc config netlogon start= demand

sc config netman start= demand

sc config NcaSvc start= demand

sc config netprofm start= demand

sc config NlaSvc start= auto

sc config nsi start= auto

sc config RpcSs start= auto

sc config RpcEptMapper start= auto

sc config termService start= demand

sc config MpsSvc start= auto

sc config WinHttpAutoProxySvc start= demand

sc config LanmanWorkstation start= auto

sc config RemoteRegistry start= auto

I saw multiple messages stating that the specified service does not exist; but I continued with the process.



Update Remote Desktop registry settings

If there are any self-signed certificates tied to the Remote Desktop Protocol (RDP) listener, remove them:

REG DELETE “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SSLCertificateSHA1Hash”

This registry key did not exist on my VM.


For more information about configuring certificates for RDP listener, see Listener Certificate Configurations in Windows Server

Configure the KeepAlive values for RDP service:

REG ADD “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services” /v KeepAliveEnable /t REG_DWORD  /d 1 /fREG ADD “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services” /v KeepAliveInterval /t REG_DWORD  /d 1 /fREG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp” /v KeepAliveTimeout /t REG_DWORD /d 1 /f


Configure the authentication mode for the RDP service:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v UserAuthentication /t REG_DWORD  /d 1 /fREG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v SecurityLayer /t REG_DWORD  /d 1 /fREG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v fAllowSecProtocolNegotiation /t REG_DWORD  /d 1 /f


Enable RDP service by adding the following subkeys to the registry:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD  /d 0 /f


Configure Windows Firewall rules

The steps for later versions of Windows server are very different because of a new and improved version of Windows Firewall. It is relatively easy on a Windows 2003 Server.

First, I confirmed that Windows Firewall was on.


I made sure that the Remote Desktop setting in Windows Firewall on my Windows 2003 server is set to TCP 3389 with Scope set to “Any”.



Run PowerShell as an administrator.

Run the following command in PowerShell to allow WinRM through the firewall and enable PowerShell Remote service.

Enable-PSRemoting –force


Verify VM is healthy, secure, and accessible with RDP

I do not have a way to confirm that the Windows Management Instrumentation (WMI) repository is consistent. That is, there is no command that I can run on Windows 2003 Server. If the repository is corrupted, see the blog post WMI: Repository Corruption, or Not?

I cannot run the bcdedit commands to set the Boot Configuration Data (BCD). I am listing them below so that you know what they are.

bcdedit /set {bootmgr} integrityservices enable

bcdedit /set {default} device partition=C:

bcdedit /set {default} integrityservices enable

bcdedit /set {default} recoveryenabled Off

bcdedit /set {default} osdevice partition=C:

bcdedit /set {default} bootstatuspolicy IgnoreAllFailures

Remove any extra Transport Driver Interface filters, such as software that analyzes TCP packets.

To make sure the disk is healthy and consistent, run the CHKDSK /f command in the command prompt window. Type “Y” to schedule the check and restart the VM.



Uninstall any other third-party software and driver related to physical components or any other virtualization technology.

I uninstall the VMWare Tools. I restart the VM as required.

Note: This is likely where I lose my network adapter since it is a VMWare network adapter.


I click Cancel when the Found New Hardware Wizard appears.


Regardless, a new device was installed. I click Yes to restart my VM again.


Make sure that a third-party application is not using Port 3389. This port is used for the RDP service in Azure. You can run netstat -anob in the command prompt window to see the ports that are used by the applications.

It looks like TermService (svchost.exe) is using Port 3389. This is the Remote Desktop Service.


If the Windows VHD that you want to upload is a domain controller, follow these extra steps to prepare the disk.

Reboot the VM to make sure that Windows is still healthy and can be reached by using the RDP connection.

I check that my Administrator account has the right to logon onto the server via Remote Desktop.


I will add my Administrator account.


I click Add User or Group. I enter Administrator and click on Check Names.


I click OK to continue. The Administrator name appears in the list.


I click OK to continue.


I am certain that I have no network connection in the VM now. Later I will use Hyper-V Integration Services to enable network connectivity.

Shut down the VM!


Convert the VMWare VMDK to Hyper-V VHD

Microsoft offers a VMWare VM conversion kit: http://www.microsoft.com/en-us/download/details.aspx?id=42497

I tried this kit; but afterwards I was unable to connect to the VM on Azure using RDP. I think it is because I lost the VMWare VM network adapter. Maybe the conversion kit works; but I need to run the converted VHD file in Hyper-V and add a network adapter. That is what I am doing next; but using a different tool for the conversion from VMWare to VHD.

Convert the VMWare VMDK to Virtual PC VM

I still do not have a network adapter in the VMWare VM. I will add one later.

I downloaded and install StarWind V2V Converter 8.0.167. StarWind Software V2V Image Converter is a virtual machine conversion utility. The package can convert many existing virtual machine formats to others.

I convert the VMWare Workstation VM disk to a Virtual PC pre-allocated image. The series of screenshots that follow show the steps that I followed.






I have successfully converted my VMWare VM to a MS Virtual PC VM.

Enable Hyper-V

My current setup does not have Hyper-V configured. However, I do have Windows 10 Pro installed with Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz processors. So I am able configure Hyper-V.


I have to configure my Windows 10 computer to support Hyper-V and Virtual PC. I followed the steps in the following blog posts:



More information on Hyper-V running on Windows 10:



Hyper-V Manager

For more information on Hyper-V running on Windows 10:


I run Hyper-V Manager.

First, I create a virtual switch connected to the External network. See the steps documented in Part Three in the URL above.

Second, I create a new VM.




Assign 3032MB of memory (or however much you need to allocate). It may change when you select your Azure VM series.



I chose the virtual switch for my network configuration that I created as a first step.



New VM appears in Hyper-V Manager


Start the VM


It is running, but needs a network connection.


Installing a Network Adapter

Map the CD drive to vmguest-HyperV.iso. If you do not have the file, you have to find it somewhere on the Internet.

Click OK to upgrade the HAL.


Installation starts


Click Yes to restart


Installation continues after reboot and logging in


Click Yes to restart


After restart, additional settings are applied.


Finally, I have a Local Area Connection again! The Microsoft Hyper-V Network Adapter is installed.



Shut down the VM!

That concludes this blog post. Part two of this two part blog posting will continue with uploading the VHD to Azure.