How we Moved our SharePoint Hosting to Azure VM and got into the Cloud

In the early days of the Web a server was typically a desktop PC with a network card sitting under somebody's desk, or maybe on a little trolley. Once, one evening in 1998, I noticed I couldn't get to our website. The next morning when I got to the office I went to the server expecting it to need a reboot maybe. The trolley was empty and the window had been forced open.

More recently our web server has been in a 'hosting facility' which over the years has meant increasing physical security and redundant power and internet connections. But you are still somewhat at the mercy of your hosting provider, and ours recently let us down badly, particularly with respect to the email hosting service they were providing. We went with a local supplier, who was originally in the same building, but over time the business changed hands and changed direction. But we stuck with them and, to be fair, they provided a good service for many years.

Then one day we stopped getting emails. It turned out that somebody at the hosting company had upgraded their email server and our accounts had not made it across to the new system. Simple enough to resolve you might think; but for some reason this seemed to be beyond the technical abilities of the support staff. We spent over two weeks trying to get them to reinstate the email service and explaining to them the seriousness of the consequences. We ended up having to wrack our brains to think of anybody who might have had reason to email us and making an embarrassing call to ask them to send again to an alternative address. After another week, a terse conversation with their service manager and a half-hearted apology, we persuaded them to give us control of the domain. As soon as the domain transfer was complete we set up an Office 365 account and configured the necessary DNS records to route the email. The whole process took a couple of hours before the emails started coming through again. We never recovered the emails sent to us during the three week outage, but problems so far after six months with Office 365? Zero. Touch wood.

The service provider also hosted our web server in their hosting centre. Our strategy had been to run our own server on inexpensive desktop hardware that we then upgraded. Every few years we would build a new server using the current versions of software, whatever it happened to be, give it a soak test for a few weeks, and then install it in the hosting centre. Since 2007 this has been Windows Server, SQL Server and SharePoint Foundation.

Then at the beginning of April we got a message telling us that our hosting provider was moving to a new hosting centre at the end of the month and that due to their, ahem, focus on larger accounts they would not be able to accommodate less than half rack inbound entry commitments (or some such jargon). Oh well; at least we had a few days to find alternative arrangements. Thanks for that. As we went through the hosting options we realised we wanted to stay on our SharePoint platform, we weren't ready to migrate the sites, we just wanted things to keep running the way they were. Our server is running a number of web sites which are based on SharePoint Foundation 2010 with a significant amount of custom code. It was not something that could easily be replaced by a cheap web hosting service.

Then we learned that the Azure VM offering had become available. This is not Software as a Service (SaaS), or even Platform as a Service (PaaS). It is what Microsoft calls Infrastructure as a Service (IaaS). So it was time for an experiment - could we simply transfer our existing server to a VM hosted in Azure?

Setting up

First you need an Azure account. You can get a free trial or if you are already an MSDN subscriber you will probably find that an Azure account is included with a limited amount of hosting already paid for. You also need a Microsoft (formerly live.com) account which you will use to access the service.

When you create a new virtual machine on Azure you can either upload your own sysprep'ed VM or pick from a number of stock VMs. There are is a choice of over a dozen ready-made VMs including Windows Server OS (and various Linux distributions).  It is a big advantage to use one of these because unless you have an excellent Internet connection it will take a while to upload a VM image which is likely to be of the order of tens of gigabytes. Because the existing server was running on Windows Server 2008 R2 we chose this from the menu of guest OS options. One thing to be aware of is that, as with on-premises installations, older operating system versions may not be supported indefinitely. If you are using SharePoint Server 2013 you have the added convenience of being able to select this from the many available VMs without the need to install the software, although you will need to install SQL Server or preferably create another VM to host SQL Server.

You get to choose from a number of pre-set 'sizes' of VM. These are a bit like tee-shirt sizes and offer an increasing number of CPU cores and memory starting with a single core and just under 2 GB up to a huge 8 cores and 56 GB of memory. Because our existing physical machine had 2 cores and 4 GB of memory we chose the roughly equivalent 'Medium' size. You can always change this later if your needs increase. It is worth mentioning that our server is below the recommended size for SharePoint Foundation 2010. Even so, we are able to support a significant amount of traffic on one or two of these sites (i.e. of the order of 10,000 unique visits per day) because we have custom code that has been optimized to support the particular workload. Don't take that as a recommendation - stick to the sizing guidelines on TechNet.

Getting it all up and running.

It took only a few minutes to have a base machine up and running with Windows Server. We then used a remote desktop connection to the new server and at this point it was much the same procedure as when we had created a physical server. We downloaded the various components - SQL Server Express and SharePoint Foundation 2010 and their prerequisites - directly from our subscription so the various images never went through our Internet connection and in all likelihood never left Microsoft's server infrastructure. Then we had to upload our SharePoint content databases and our custom SharePoint solution packages. On this occasion we did all this manually, but if you had to do it repeatedly you could create a set of PowerShell scripts to automate the process.

Once we had everything up and running we needed to configure an 'endpoint'. This allows you to expose the http service on port 80 for example (the remote desktop endpoint is provided for you automatically). This process is somewhat similar to configuring firewall rules, and no doubt this is in part what is happening within the Azure network. Finally we could change our DNS settings for our various websites and switch them over to the IP address allocated to our virtual machine. As long as we don't decommission the VM we are assured that it will keep this IP address. This is true even if we change the VM configuration, for example increasing the machine size, or as the Azure infrastructure relocates the VM to different physical hardware for whatever reason.

A convenient dashboard allows you to monitor the server without needing to establish a remote desktop session. So far the performance metrics suggest that the VM easily outperforms our three year old physical hardware it has replaced, which is probably to be expected.

The Cloud has Arrived

I used to be somewhat sceptical about cloud computing. For several years now Microsoft have been 'all in the cloud' but from our perspective the cloud still seemed a long way away. It took a while for some of Microsoft's cloud offerings to take shape and settle down. Of course it is a cloud so it is nebulous and ever-changing. But for all the shifting and billowing the service it exposes is becoming pretty solid and reliable. You have to judge not only which technology to bet on, but when. Many people have backed a technology which was ultimately successful but at the wrong time - too early when it wasn't ready, or too late and getting left behind. It feels as though the time is now right.

With IaaS we are still responsible for maintaining and patching our server. But it gives us the right level of flexibility, and at a cost that will probably work out less than our original provider. And we now have the added advantage that we don't need to worry about hardware maintenance any more, and if the need arises we can quickly scale up to a larger server or farm with a few clicks.

So does it all work? Well, if you are reading this, our cloud-hosted server is working, and the cloud has arrived. Touch wood.