Building a Web Server VM that lives in Windows Azure….

I have had some issues uploading my web server to Windows Azure as a part of my series on Migrating my home network to Azure. So I decided to fill the gap with a post on building a web server in Windows Azure until I get the upload issues resolved.

Scenario – I have a web server that is running as a VM on my home network. I need this webserver to live in Azure instead. Since this server only servers content to the public and is not used for an Intranet purposes, I do not need it to be domain joined for any additional security or control. I just need it to respond to web browsers that make requests.

Step 1 – Provision Windows Server

Step 2 – Install necessary roles and features

Step 3 – Patch the VM

Step 4 – Source Web Server - Package up my Web Sites

Step 5 – Copy Package to Destination Server

Step 6 - Destination Web Server – Extract Web Sites to INETPUB

Step 8 – Configure Web sites in IIS

Step 9 – Identify Azure VM IP Address and Update DNS

Step 1 – Provision Windows Server

The first step is to build the base Windows Server. I am doing this through the Windows Azure Management portal at https://manage.windowsazure.com

I don’t need a lot of storage or processing power for my particular web server. I don’t host a lot of content locally and what I do is static. The bulk of my sites are very small, place holders, or redirects to other sites. So I am going to use the smallest possible instance to keep my costs as low as possible. I am, also using Windows 2012 Server as the base (the web server I am migrating as a part of my series is a Windows 2008 R2 Server which is also due for an upgrade)

It takes about 5-8 minutes for a VM of this size to be ready to go in Windows Azure.

Step 2 – Install necessary roles and features

Now that the server is up and running, I have connected to it as an RDP session. From here I am going to add the necessary roles and features to operate as a web server.

First thing is to change Windows Updates – By default, all new Windows machines are configured to automatically check for and install updates every day at 3:00am. While this is generally satisfactory and even recommended for client machines, servers may be running critical workloads and need a more granular and controlled maintenance Windows. In reality, the default would be just fine for my purposes, but I still think it is a best practice to change Windows Server from Automatically updating to only checking and letting the Admins determine when to install.

Now I am going to add the Web Server Role though the Server Configuration Wizard

I only need the Web Server Role which also ensures that I have the proper management tools installed.

There are a few other Web Server specific items I am adding to the Web Server Role Services to support my scenario

HTTP Redirection – Because I do redirect other sites

FTP Server – To make it easier to move Web Content to/from this server from a remote location

All other items are default items. I do not need to add or remove anything for my scenario

 

For the remainder of the wizard I use the defaults and then start the install of the Web Server Roles features. It only takes a minute or two for this to complete.

Step 3 – Patch the VM

You know this works, check for updates, install, reboot. Lather, Rinse, Repeat as needed until fully patched.

Step 4 – Package Up My Web Sites

As I have noted, all of my web sites consist of static content or redirects. They don’t actuall host any web based applications. So I don’t have to worry about ASP.NET compatibility or other issues that standard LOB web-based applications will have to deal with. I can simply ZIP up all of the content directories, copy them to the destination servers and then unzip. The only thing left remaining would be to recreate the web sites in IIS.

However, if you do have applications or you have to migrate larger websites with more complicated configurations, you can leverage the Web Deploy Kit 3.5 to migrate and duplicate web site data.

I zipped up all of my web sites on the highest comporession level to give me the smallest ZIP file possible. I ended up with ~35 Megs of data to copy yo my destination server.

Step 5 – Copy Package to Destination Server

There are several ways we can copy the data to the new server. I installed FTP services on the new server, but I have not configured and DNS resolution, nor have I tested networking yet to see if it is reachable. Since network testing will be the final phase of this, I will skip uploading to the Azure Based IIS server’s FTP. I also have an FTP server running already on my local IIS server where I can drop the file in an FTP site, then connect from my Azure based Web server to download. Or, I can simply copy/paste from the RDP sessions I have open to each machine for administration to copy the file that way. This final option si wjhat I did since I have a relatively small amount of data I have to copy.

Step 6 - Destination Web Server – Extract ZIP files for Web Sites

Simple enough. I extracted all of my web sites to the INETPUB folder.

…and now we just have to…

Step 8 – Configure Web sites in IIS

For each site I recreated the web sites manually, adjusted the BINDINGS. and browsed each site internally to make sure they work. All of them worked flawlessly the very first time so I am all done with moving the web sites over.  However, I still have the original web server up and running right now to make sure all stays online.

Step 9 – Identify Azure VM IP Address and Update DNS

The only thing we have left to do is identify the IP address of my VM that is running in Azure and then update my DNS to point browsers to the new web server. This again is a simple option for me because I use Host Headers for my web servers and all of them have always been published via a single IP address.

Azure VM’s are unique in that that they have two IPv4 addresses that we have to be aware of. There is an “Internal IP Address” that is assigned to the virtual network adapter on the VM itself. This can easily be retrieved using IPCONFIG at a CMD line in the VM itself.  There is also a Public Virtual IP Address (VIP) that is assigned to every Azure VM to allow it to speak to the outside world. This address as well as the Internal IP are visible in the Azure Management Console. Just select your VM, then go to it’s Dashboard and you will see both addresses listed on the right hand side -

The Public Virtual IP Address (VIP) is what we have to provide to DNS as it is the only one accessible from the outside world. Azure maps the VIP to the Internal address automatically for us.

now that I have the VIP address, I just have to update DNS, test, and then wait for DNS servers to refresh zone information to ensure they accessible. This can take 24-48 hours (but is usually faster in my experience).  I have updated my DNS and tested and things are working. So now I just have to test again in 24 hours to finalize and I am done!

Cheers!