Category Archives: Windows Azure

Downgrading the SendGrid Add-On for Windows Azure

One of the (many) awesome aspects of Windows Azure and the Azure Portal is the support for Add-Ons. This feature allows 3rd-parties to closely integrate their services into Azure and offer their products via the Azure Portal Store. The Add-Ons feature also allows you to manage much of those services right within the Azure Management Portal.

Azure and SendGrid

I’ve been using the SendGrid service off-and-on for the past year, having set it up initially via the Windows Azure Add-Ons Store. SendGrid is an awesome service for sending emails from a variety of platforms. It offers great prices and rich analytics, and can be used from the Node.js JavaScript environment found throughout the Windows Azure services.

And, thanks to the integration I mentioned above, it’s very easy to scale your SendGrid service from the free option up to the plans with higher allowances and richer analytics.

The Big But

Pee-Wee Big But

Now that’s all great, but

While it’s as simple as a few clicks in the Azure Management Portal to upgrade your SendGrid plan…

If you have created your SendGrid plan via the Windows Azure Add-On Store, there is literally no way to downgrade the plan.

After searching both the Add-Ons area in the Azure Portal as well as the SendGrid management portal I got in touch with both SendGrid and Azure support. They were very helpful but, after several days they confirmed that this capability is simply not possible for the accounts created via the Azure Add-On Store.

So what can you do? The solution is both simple and obvious, if tedious: You can actually add multiple SendGrid plans to your Azure account via the Azure Add-On Store. Simply add a new SendGrid plan at the lower rate. Then migrate over the SendGrid credentials you are using in your applications and services.

Tedious? Yes. But it works if you need to downgrade before this ability is officially supported.

Painless File Backups to Azure Storage

Windows Azure

In my previous post I discussed steps and utilities for backing up Azure SQL Databases in order to guard against data loss due to user- or program-error. Since then I’ve started investigating options for backing up files – specifically those in Azure Virtual Machines – to the same Azure Storage service used previously.

Just like before I was delighted to find an existing app that makes this super easy. The AzCopy utility makes it possible to copy files to and from Azure Storage and local storage, or from Azure Storage to Azure Storage, with a nice set of arguments.

For instance, the following command will copy all of the files in a local folder, recursively, over to Azure Storage. It will overwrite existing files, and it will skip any files that already exist unless the source file is newer. Perfect.

AzCopy.exe C:HereBeImportantThings http://yourstoragename.blob.core.windows.net/yourstoragecontainer /destKey:YourSuperLongAzureStorageKey /S /V /Y /XO

The Azure storage account name and access key can be accessed in the Storage section of the portal, by clicking the Manage Access Keys button at the bottom of the Windows Azure Portal.

Azure Storage Information

This command took under a minute to backup 3,000 files to Azure Storage from an Azure Virtual Machine. From there I can keep running the command and it will only copy new files over to Azure Storage, overwriting any existing file.

As in my previous post, my little utility AzureStorageCleanup is a nice companion to this process. I have updated the source on Github to include a -recursive argument, which will remove files within the virtual hierarchy found in blob storage (created by the recursive option in AzCopy).

AzureStorageCleanup.exe -storagename yourstoragename -storagekey YourSuperLongAzureStorageKey -container yourstoragecontainer -mindaysold 60 -recursive

By scheduling AzureStorageCleanup to run with the -recursive option, you can remove old files to keep storage use in-check.

Painless Azure SQL Database Backups

Windows Azure

While the SQL Database service from Windows Azure provides resiliency and redundancy, there is no built in backup feature to guard against data loss due to user- or program-error. The advised way to handle this is to take a three-step approach:

  1. Make a copy of the SQL Database
  2. Backup the database copy to Azure Storage
  3. Maintain & remove any outdated backups on blob storage

The process in Windows Azure that backs up a SQL Database to blob storage is not transactionally consistent, which is why the initial database copy is required.

Richard Astbury has provided an excellent tool, SQLDatabaseBackup, that takes care of the first two steps with little fuss:

SQLDatabaseBackup.exe -datacenter eastus -server hghtd75jf9 -database MyDatabase -user DbUser -pwd DbPassword -storagename mybackups -storagekey YourSuperLongAzureStorageKey -cleanup

The data center and server name can be obtained from the SQL Databases section of the Windows Azure Portal.

SQL Database Information

The Azure storage account name and access key can be accessed in the Storage section of the portal, by clicking the Manage Access Keys button at the bottom of the portal.

Azure Storage Information

Finally, by specifying the -cleanup argument, the utility will delete the SQL Database copy it creates after the backup is successfully created.

And while the pricing for Azure blob storage is very affordable, you may want to automate the process of deleting old backups. I’ve created a very simple utility that does just that. AzureStorageCleanup uses command line arguments that mirror the SQLDatabaseBackup project (as it is meant to compliment its use):

AzureStorageCleanup.exe -storagename mybackups -storagekey YourSuperLongAzureStoragekey -container sqlbackup -mindaysold 60

The above command will remove files equal-to-or-older-than sixty days from the container “sqlbackup” – the default container used by SQLDatabaseBackup. The details of each file deleted are printed to the console.

By scheduling these two utilities on an available machine you’ll have painless, affordable backups for any of your Windows Azure SQL Databases.

Hosting XAF ASP.NET Projects using Azure Web Sites

Azure Web Sites is a new offering from Microsoft under their Windows Azure cloud platform. It’s a scalable solution that allows you to host ASP.NET, PHP, and node.js projects. If your needs are basic, your sites – up to 10 of them – can be hosted for free*. If you need something like a custom domain, you’ll pay a bit more – currently about $8/mo. If you’d like a reserved instance, rather than shared, that will kick it up to around $70/mo. But you can run several of your web sites on that one reserved instance.
*bandwidth and database sold separately see site for details

The awesome thing is that you can start with the free setup, get up to 10 web sites going and, if your needs grow, scale your web sites up by simple dragging sliders in a web portal. It’s all very simple and straightforward and seems to work well.


One of the first things I tried with the free Azure Web Sites preview was hosting an eXpressApp Framework ASP.NET solution and database. While there are a few gotchas that came with publishing my XAF project to Azure Web Sites, most were the sort of issues you’d work through publishing an XAF ASP.NET project to any new server. However, there are some Azure-specific steps needed to work through some of these, which I’ll cover towards the end.

To get started, head to the Windows Azure homepage and sign up for Azure Web Sites. Afterwards, visit the Azure management portal. Note that after signing up for Azure Web Sites you’ll be treated to a nice new HTML5 UI for the Azure management portal (unfortunately the database management portal is still Silverlight).

Once you are in the management portal, click WEB SITES on the left, then click the NEW button at the bottom-left of the portal. Select the CREATE WITH DATABASE option (no I’m not yelling, the site is covered in caps).


You’ll need to give both your web site and database a name, and assign a login name and password for your database.


After the process completes, you’ll be left at the DASHBOARD screen for your new web site. On the right, under quick glance, click Download publish profile. This is the file you’ll use in Visual Studio to publish your XAF ASP.NET project. Next, click View connection strings and note the ADO.NET connection string for your Azure database instance.


As a final step in the Azure portal, scroll down the DASHBOARD page and click the link to your database under linked resources. Click the MANAGE button at the bottom of the portal. This should prompt you to add your current IP address to the firewall rules so that you can access the SQL database. Click YES.


This is necessary if you want to debug your application locally with the database hosted on Azure. Afterwards you can click NO to manage the database (we just needed the firewall rule added).

Next, if you haven’t already, you’ll want to download and install the Windows Azure SDK.

Now we can jump into Visual Studio and start the process of setting up the XAF ASP.NET project for hosting in Azure. First, double-click the WebApplication.cs file in the Web project. Select the Sql Connection and then edit its ConnectionString property, using the ADO.NET connection string from above. Make sure you use your real password as that will not be shown in the portal.


With the new connection string in place, and with the firewall rule added from the steps above, you should now be able to click Start to debug your XAF ASP.NET project, and successfully run against the new Azure database. This step will also create the destination database schema within the database hosted on Azure.

With these changes in place, right-click the Web project and click Publish. Click the Import button on the first screen and import the publishing profile you saved from the Azure portal.


Click Next through the wizard. On the final page you can click Start Preview to preview what will be published. Finally, click Publish.

Aaaand YSOD! Here’s where a bit of troubleshooting comes in. Some of this will be similar to publishing an ASP.NET XAF project to any host. Start by disabling Custom Errors in your web.config and Publish again.

Now you should see that the problem is that the DevExpress ExpressApp assemblies are not on the server.


Multi-select the DevExpress assemblies referenced by your Web project using CTRL or SHIFT. In the Properties Window, set Copy Local to True.


Go ahead and Publish again. Now, all of the DevExpress assemblies referenced by your project will be uploaded to Azure.

Aaaand YSOD! Even after setting all of the assemblies explicitly referenced by the ASP.NET project to Copy Local, there are missing ExpressApp assemblies.


Some assemblies – for instance DevExpress.ExpressApp.Security and DevExpress.ExpressApp.Objects – are not explicitly referenced by any of the XAF projects (mentioned to DevExpress here). While this may be addressed by DevExpress in a future update, in the meantime you’ll need to explicitly add any references with the Add Reference dialog, set Copy Local to true, Publish, and repeat on YSOD.

At this point, the ASP.NET XAF app should run properly hosted in Azure Web Sites.


But, there’s one last “gotcha” I want to cover, as trouble-shooting this is specific to Azure Web Sites. If you encounter the generic XAF ASP.NET error, you’ll need access to the XAF log to troubleshoot.


This may happen, for instance, if you make use of the HTML property editor in your ASP.NET solution and have not published all of the required assemblies.

To access the XAF log, go back to the Azure management portal. Click on the link under FTP HOSTNAME, which is in the quick glance column of the DASHBOARD.


You’ll be prompted for a username and password. You can get these by editing the PublishSettings file¬†(downloaded above) in Notepad. Look for the userName and userPWD values after the FTP publishMode.

Once you’ve logged in, you’ll have full FTP access to both your sites and any logs. Navigate to site, then wwwroot. You should see an eXpressAppFramework.log file.


View the file’s contents, and search for “error occurred”. This will help you find XAF errors that occur that don’t cause a YSOD. This can and will happen for missing assembly references, such as DevExpress.SpellChecker.Core, if you use the HTML property editors.

With connection strings in place and all of the proper assemblies referenced and published, XAF ASP.NET projects run quite well in Azure Web Sites.


I’ve been using Azure Web Sites for a couple of months to host both my personal website and the website for Hip Shot and have been very pleased overall. And, if you don’t need a custom domain or a reserved instance, your web site hosting is free – bandwidth and database storage aside.