Migrating Server Environments to Azure – without using PowerShell

Here is an example of how to migrate a small 3 node SharePoint environment from VMware to Azure without using any Powershell.

1: Audit the existing environment

You'll need to know all the standard stuff really: server names, IP addresses, roles, resources, disk sizes and disk layouts. Write all this down for later.

In this example with have three simple machines:

• AD-01: An Active Directory server with a single 40GB drive running Windows 2008 R2, 2 GB RAM and a single processor. Internal IP Address: 172.16.0.144 (static)
• SQL-01: An SQL server with a single(!) 40GB drive running Windows 2008 R2, 4 GB RAM and dual processors. Internal IP Address: 172.16.0.145 (static)
• WEB-01: A SharePoint server with a single 40GB drive running Windows 2008 R2, 4 GB RAM and dual processors. Internal IP Address: 172.16.0.146 (static)

We'll use this information later to size the machines and configure our Azure virtual network

2: Prepare Azure

Depending on what you run in Azure already, you may need some or all of the following:

• A new virtual network, or a new subnet in an existing vnet, that will accommodate these machines.
• A storage account with a VHDs container.

For this example, we created a new storage account to separate these machines from our existing workloads, and a new virtual network, in which we provisioned the subnet 172.16.0.0/24. Having a dedicated vnet for a set of machines enables them all to talk to each other, plus you can add stuff like DNS servers (which we will in this case) and site-to-site connectivity for hybrid scenarios if needed.

3: Convert the VMware Disks to Hyper-V Disk Format

There's a variety of ways to do this. If you have a lot of machines to convert, and have access to the VMware hosts, you can point Microsoft's Virtual Machine Convertor tool 3.1 at your VMware farm and it will carry out the conversion for you, even moving them directly into Azure. In this case though, we've received VMWare backup files of the machines, so we need to do an "offline" conversion of the disks from the VMware format to Microsoft's VHD format (do not convert to VHDX). We use Starwind's V2V Convertor, http://www.starwindsoftware.com/converter, but there are loads of others out there. Just ensure you convert the disks to fixed-size VHD files.

4: Prepare Machines in Hyper-V

Create a new VM in Hyper-V and attach your freshly converted disk to it. We've found configuring it as a Gen1 machine with an IDE disk plays well with Azure. Once the machine has fired up, you'll need to make the following changes:

• Remove VMware tools/extensions, and update the Hyper-V extensions – reboot them a few times to make sure all the new devices are detected.
• Remove any static IP configuration and ensure the only network card in the system is set to DHCP.
• Ensure the remote desktop service and port are up and running.
• Shutdown the machines.

5: Upload the VHD to Azure storage

As we're avoiding using PowerShell, we use Cloudberry Explorer (http://www.cloudberrylab.com/free-microsoft-azure-explorer.aspx) to upload the disks as page blobs to our Azure storage account, VHDs container. In cloudberry explorer, you just use the "copy as page blob" button to accomplish this, to copy the files from local storage to Azure. To connect Cloudberry to your storage account, you just need your storage account name and access key (which you can get from the Azure management portal – save this for the next step too).

6: Resize the disks in Azure

In this case, the source disks were really small, so we wanted to increase their size. Most of the Microsoft documentation refers to resizing disks in Azure as being a Hyper-V operation – i.e. something we should have done in step 4 (or download them again, resize and reupload – not very efficient). So we found this solution from Maarten Balliauw (https://blog.maartenballiauw.be/post/2013/01/07/tales-from-the-trenches-resizing-a-windows-azure-virtual-disk-the-smooth-way.html) where he's manipulating the VHD file directly within Azure storage. This method seems to work very well, and takes less than a second. Very easy when the disk has yet to become a VM. Admittedly it's a command line programme, but's still not PowerShell! The four parameters needed are the new disk size (in GB), the URL of the blob (copy from the Azure interface or Cloudberry explorer)

7: Convert the Page Blob to a Disk

In order to attach the disk to a VM as an OS disk, you have to create a disk from a VHD in the "disks" section of Virtual Machine within the Azure management portal. Just click create and point it at the appropriate blob in the storage account, ensuring you check the box for "Contains Operating System". Don't worry about cache settings – these get updated when it gets attached to a virtual machine.

8: Create a Virtual Machine from the Disk

In the virtual machines section of the portal, create a new virtual machine from the gallery, and in the "my disks" section, you should find your newly created disks. In this case, we created the machines as "basic" tier, as there was no high-availability requirement, and renamed the first cloud service so it was more descriptive than the machine name. The second and third machines were then joined to the same cloud service, whilst all three machines were connected to the same vnet. We created extra endpoints for the SharePoint server. Completing this wizard provisions the virtual machine and starts it up so you can connect to it through RDP – takes about five minutes. If you have an Active Directory server, fire that up first.

9: Finishing Up

Depending on the services you're migrating, there's a number of finishing up steps you can do. As some of these require Powershell, these are up to you!

• Assign a "static" internal address to the Active Directory server and direct the vnet DNS setting to use it (you can generally get away with the long-term lease it gives the AD server when you fire it up, especially if you put your AD servers in their own subnet)
• Open up ports as endpoints to the public internet
• Create additional machines to create an availability group for the service you're placing in Azure.
• Expand the disks within the OS to use the new space.
• Move the page file to the temp disk (see below)

With our three machines, we just set the vnet's DNS server to be 172.16.0.4. They then functioned exactly as they did in VMware – with a bit more disk space (Azure also automatically gives each machine a "temp" drive that's useful for paging too)

10: Other Uses

• To create images instead of disks (so you can create multiple machines from the same image) you just need to sysprep your Hyper-V disk before you upload it, then in step 7, create an image instead of a disk, and in step 8, use "my images".
• You can also upload the data disks of a machine and attach them to any Azure machine using this same process. Just leave the box unchecked in step 7.