Over the last few years I had to move my blog through different hosting providers, and when in March my last hosting, EpicWin Hosting, closed business with only one month of notice I decided that I had enough of small hosting providers run by people I know, so I decided to finally make the big step and move to Azure.

Unfortunately this happened during a moment in which my life is going through some big changes, and I didn’t have time and brain-power to put all my efforts into the migration, so you might have noticed that my blog was down between end of March (when the hosting closed) till last week.

The down was due to a strange problem with database access permissions on my SQL Server on Azure. Well… strange for me that used Azure for the first time, maybe it’s how SQL Server on Azure it’s supposed to work.

Another issue I had was with the mapping of domains to web sites, keeping both example.com and www.example.com pointing to same web site.

The SQL Server user permissions problem

The migration from the on-premise database to azure SQL Server went very smoothly: I installed the SQL Database Migration Wizard on my VM, setup firewall rules on Windows Azure, ran the wizard and all tables and data were moved to the newly created DB on Azure. For a step by step procedure, I recommend reading Migrating a SQL Server database to SQL Azure by Tim Heuer: it’s from last year, and many steps are not necessary any more, but it’s a good overview of the process.

The problem started when I tried accessing my blog: I was getting an user access error from the database, despite having configured the connection string correctly, and being able to access the database both via the online DB manager, and from my local Management Studio.

After some attempts, emails with some Azure MVPs, and lots of frustration I quitted the challenge and let the blog down for a few weeks. I went back to try and solve the problem last week, and finally solved the problem.

I had put in the connection string the username of the administrator account of the my server on Azure, which I though would have had access to all the DBs in the server, like the sa user does on a normal SQL Server. Unfortunately that was not the case: I had to create another server login, and a new user inside my database and grant him dbo rights. More information on SQL Azure user management can be found on MSDN: Managing Databases and Logins in Windows Azure SQL Database.

After that, the blog started running without any issue: no change in Subtext code or SPs. If it hadn’t been for that silly problem with the DB user, migration from on-premise to Azure WebSites would have been completed in less than 2hrs.

Mapping custom domains to windows azure web sites

Mapping a custom domain to an Azure website is pretty easy: just create a CNAME that points to mysite.azurewebsites.net and everything works fine.

www.example.com 21600 IN CNAME mysite.azurewebsites.net

But if you also want to configure the non-www things become more complicate, because you cannot just create a CNAME, but need to create an A record for your domain, and the azure management site wants to verify that you are the owner of the domain before letting you configure the custom domain name. Here is the procedure for setting up an A record:

• first you need to create the CNAME that is used for verification, which has be to awverify followed by the domain you want to configure as A record. In the case of the non-www domain, it has to be:
  awverify.example.com 21600 IN CNAME awverify.mysite.azurewebsites.net
• After the DNS has propagated (you can check with http://www.digwebinterface.com/) you can go on and create the A record:
  example.com 19473 IN A your.azure.IP.address
• Then of course add the domain inside the custom domain section of your azure web site.

Before wrapping up, two notes that might confuse you at first:

• your website has to be running as shared or reserved (free mode doesn't allow domain names, at least not during beta)
• If you were used to the *.example.com notation to configure any hostname to point to the same IP address, remember that this won't work on as the azure portal checks for the specific CNAMEs

More information on how to manage custom domains on Azure web sites can be found again on the Azure documentation portal: Configuring a custom domain name for a Windows Azure web site.

Traffic and SEO problem after 2 months of down time

Unfortunately, the almost 2 months of down time, apart from the non blogging, also meant that my site disappeared from Google search results.

Here is the traffic profile of my blog, before and after the period of unavailability.

From more than 1500 pages a day, it went down to 200-300 pages a day, all coming from referrals on stackoverflow or forums, but with very little search results from Google. Let’s see how long it takes to go back to previous figures.

Performance and logging

Now I have to monitor the performance of the web site on Azure, and try to understand where all those peaks in CPU time and HTTP Errors come from.

Migrating to Azure Web Sites is easy

Despite the small issue with user access, I have to say that the migration to Azure Web Sites was kind of easy: it’s just like running on a normal hosting. Also no problem with the Lucene indexes, which are usually the most critical part of a Subtext installation on shared hosting environments.

A small request to all my readers: if you have more experience than me with Azure, could you please comment with some tips on how to monitor performance and errors on Azure better? Same if you have some tips on how to get back to being indexed by Google.