Practice of migrate local Exchange testing labs to Azure

We need to migrate 5 local Exchange testing labs (15 VMs, 6 Domain Controllers) to Azure VM, and run Automation testing against those labs after migration complete. This blog elaborate the steps which I tried during the practice.

1. Prepare VM images and upload to Azure.

The local labs host on Hyper-V server. So we just use VHD file as our base images. Azure team provide a guideline to upload VHD and create VM: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-upload-vhd-windows-server/.

In the guideline the VM should be sysprepped before upload, but the VHDs we got are non-sysprepped because they are exported and uploaded to AWS S3 in advance.

For non-sysprepped VHDs, a necessary step for Azure is turning off Windows firewall on PowerShell and remote desktop port. Azure might failed to modify the firewall setting if your VHD is non-sysprepped, then you have no way to connect into your VM.

The VHDs need to be uploaded by Powershell Add-AzureVHD because Azure only support fixed disk type and the command will convert dynamic VHD in upload process. http://hindenes.com/trondsworking/2014/08/18/how-to-upload-vhd-files-to-azure/

2. Setup Virtual Network and create VM

The virtual network need to be setup at first, because we can’t modify VNet setting after VM is created.

As the VHD is non-sysprepped and we don’t want Azure to modify our OS settings, we need to create OS disk from VHD, then create VM from OS disk. In this way, we tell Azure just use OS in the disk rather than modify OS as Azure template. It is different with creating VM from image which will copy your VHD to a new one. So it would be better to backup your VHDs before you make major change on OS if you create VM from disk.

After the VM is created, Azure will try to install VM agent in your VM. The operation always fail in my experience, and I believe it is because Azure can’t get administration access in your OS. So you need to install VM agent manually once you could RDP to the VM.

https://msdn.microsoft.com/en-us/library/azure/dn832621.aspx

3. Resume Lab

DNS server should be the first VM resumed as other VMs depend on that. DNS server and Domain Controller will need static IP, a PowerShell command Set-AzureStaticVNetIP can be used.

Get-AzureVM ServiceName myvm -Name myvm | Set-AzureStaticVNetIP IPAddress ‘192.168.0.132’ | Update-AzureVM

Then you can set DNS server IP address in VNet configure so other VMs could use that DNS server for internal lookup.

Domain controllers should be resumed before Exchange servers. Here we need to discuss more about DNS server setting. I found a robust DNS setting on Azure is setup AD integrated DNS server on domain controller, then setup stub lookup zone on DNS server and point to domain controller. In this way, you don’t need to worry about time synchronization between DNS server and domain controller even you need to frequently shutdown and start up those servers.

For those Exchange servers, an important thing is reconnecting to domain controllers because the DC don’t know who is who after Exchange servers are recreated on Azure. We can reset computer account of the Exchange server on Active Directory Users and Computers, then quit and rejoin domain. Don’t attempt to quit and rejoin domain before reset computer account! That will make your Exchange server a new SID in Domain, it might break a lot of permission or relationship in lab.

It would be worth to rebuild trust if labs have trusts before, because I found some weird issue go away after I rebuild the trusts between domains.

Exchange is designed to start all the time, and have a lot services need to be running to keep Exchange work. But we need to stop and start those labs everyday for Automation Testing. For those services failed to start automatically because dependent service have not been started, we can put them into Automatic Start (Delay) status. Then those services have more chance to start automatically.

4. Azure limitation

Resume labs on Azure have some limitation.

Azure only support Server OS Windows 2008 and Windows 2012 series. So if your lab heavily need client OS or Windows 2003, Azure might not be your choice.

Azure Virtual Network don’t support broadcast. So you had better use FQDN in all your automation testing.

Azure Virtual Network can’t assign IP address per request, can only assign 1 IP address for 1 VM. So those features depends on new IP assignment like Exchange DAG can’t be deployed on Azure.

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s