Introducing the Azure SQL Database DTU Calculator

The following is the first in a series of posts about the Azure SQL Database DTU Calculator.  This post describes the need for the calculator and the process of creating it.

As part of my job at Microsoft, I get the opportunity to work closely with companies across the US.  My particular area of focus is Azure so I spend most of my days talking about a company’s business model, architecture, IT costs, and other technical issues to help them identify areas where Azure can help as well as provide them with a roadmap for migration.  During one such meeting about 6 months ago, I was talking to a company about Azure SQL Database as a potential option for migrating their RackSpace SQL Server to Azure.  If you’re familiar with Azure SQL Database, then you’re probably familiar with the term database throughput units (DTUs).  If not, a DTU is something the Azure SQL team created to describe the relative capacity of a performance level across a blended measure of CPU, memory, reads, and writes.  The article, Azure SQL Database Service Tiers and Performance Levels, contains a more thorough explanation.  Anyway, during that discussion one of the company’s architects asked, “how do I know how many DTUs my database needs.” 

Seems like a reasonable question and at the time I didn’t have a great answer.  I’d read the guidance, Azure SQL Database introduces new near real-time performance metrics, so I was familiar with the process of starting with feature capability, picking the lowest performance level, migrating the database, and then adjusting based on utilization.  However, I could see the concern this caused for the engineers.  Migrating a database from location A to location B isn’t a trivial task and doing so with any level of ambiguity isn’t something any engineer would recommend.  It was at that time I reached out to a friend on the Azure SQL Database team for help.  The conversation went something like this (names have been changed to protect the innocent):


Hey John.  Quick question… Do you have anything to do with or know anything about SQL Database DTUs?


You bet.


Cool.  In your opinion, would it be possible to write a DTU Calculator which a developer could run against their on-premise database to see which tier of SQL Database they would map to?


We’ve discussed doing such a thing, and I think it’s a good idea, just haven’t had the time to do it yet.  Feel free to send me email, and I’ll get the right conversation going.

A calculator is born…

One of my main objectives when developing the calculator was to keep it simple – something engineers at any level of expertise could easily use.  With that in mind, I spent the last several months working with the Azure SQL team to understand all the complexities of converting SQL Server performance to database throughput units and developing a website to wrap those complexities in a simple, intuitive interface which can analyze your production database workload and accurately calculate the service tier and performance level needed in Azure SQL Database – all before migration.  I’m happy to announce the Azure SQL Database DTU Calculator does just that!  The calculator is available to use but I’d love to hear your feedback and results.  As I mentioned earlier, this post is just an introduction.  Look for my next post to go into more detail about using the calculator and interpreting the results.


Windows 8 FlipView with WebView

Over the last several months, I’ve been working with a client on a Windows 8 app.  The app is basically a book but rather than embedding the pages of the book in the app, the client wants to load the pages dynamically when the app starts and cache them for a period of time.  Since each page of the book has a corresponding html page, the client decided to load the pages into a WebView control.  A good choice since the WebView control can easily render the html content but it also gives the developer a lot of flexibility to inject scripts and manipulate the DOM – which he did but it’s out of the scope of this blog.

Rather than loading all the pages into a single WebView control, the client wanted the user to be able to swipe left and right to change pages.  The FlipView control was the first choice since it supports the swiping behavior but neither of us were sure we could wrap a WebView control with a FlipView control.  After searching the inter-webs for a while, I found a lot of contradictory information.  Some forums say it’s possible but don’t provide good examples while other claim it’s not possible.  I’m here to confirm that it is possible and here’s how:

Step 1:

Open Visual Studio and create a Windows Store app using the language of your choice.  For my project, I chose XAML/C# and the blank app template.

I’m pretty sure Html5/JS will work but I haven’t confirmed.  Sorry.

Step 2:

For simplicity of this blog, I’m not going to load the html pages dynamically from a web backend.  I’ll just add the pages to a folder in the app and load them from there.  I added a folder called, Content.  Under that folder I added 5 pages.  A title page and 4 content pages.

Step 3:

Open the MainPage.xaml file and add the following XAML inside your Grid.

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <FlipView x:Name="HtmlFlipView" 
                  HorizontalAlignment="Center" Background="White">

Step 4:

protected override async void OnNavigatedTo(NavigationEventArgs e)

    if (HtmlFlipView == null || HtmlFlipView.Items == null) return;

    for (int i = 0; i < 5; i++)
        var htmlWebView = new WebView();
        string htmlPage = await WrapHtmlPageAsync(string.Format("mobydickpage{0}.html", i));


private async Task<string> ReadLocalFileAsync(string path)
    StorageFile file = await StorageFile.GetFileFromApplicationUriAsync(new Uri(path));
    return await FileIO.ReadTextAsync(file);

private async Task<string> WrapHtmlPageAsync(string htmlPage)
    const string customStyle =
"body {font-size: 18px;}";

    // Internal content and scripts
    string content = await ReadLocalFileAsync(string.Format("ms-appx:///content/{0}", htmlPage));

    return string.Format("<!DOCTYPE html><html><head><meta charset='UTF-8'><title>Moby Dick</title>" +
        "<style type='text/css'>{0}</style>" +
        "</head>" +
        "<body>" +
        "{1}" +
        "</body>" +
        "</html>", customStyle, content);

That’s it!  When the app loads the MainPage view, the OnNavigatedTo event runs.  I added code to iterate for each page; creating a new WebView control and loading the corresponding html page.

There are probably a million better solutions out there but this one demonstrates the point.  It’s entirely possible to create a WebView control inside a FlipView control to achieve a swipe effect between pages.

Extended Validation (EV) and the Windows Store

Update – 11/21/2016

There’s currently an issue with the Windows Dev Center registration page which causes the a properly signed XML file to fail on upload. I am working with the Microsoft team responsible for Windows Dev Center to get the issue resolved and will provide an update as soon as it’s fixed.

For now the MSFT team has asked that you work directly with MSFT Dev Center Support.  You can contact them at, Microsoft Support, and selecting either the “Chat now” or “Submit an incident” button.

The good, the bad, and the ugly.

Even if you’re an experienced Windows 8 developer with a plethora of apps in the store, chances are you haven’t heard of the extended validation option for your account.  And rightly so.  The use case is very specific.  It’s only available if you’re registered as a Company as opposed to an individual developer and only applicable to apps that need access to the documentsLibrary capability.  In fact, at the time of this post, I think I was one of the first to complete the process end-to-end.  It wasn’t a pleasant experience.  Definitely not something I would want when evangelizing Windows Store awesomeness.  I’m hoping this post can help others get through the good, the bad, and the ugly (not necessarily in that order) of the extended validation process.

Extended Validation:  What and why?

According to the Windows Store,

…apps that declare the documentsLibrary capability can only be submitted from developer accounts which can demonstrate they have acquired an Extended Validation (EV) code signing certificate from a certificate authority (CA).

I suppose an EV process makes sense when you read what the documentsLibrary capability does.  Effectively, it provides the app programmatic access to the user’s Documents, filtered by file types declared in the manifest.  The keyword being, “programmatic,” which is different than the standard UI file picker in that no user interface is involved.  This capability is somewhat outside the scope of the WinRT app sandbox which only lets the user decide which files it wants the app to interact with.  With the documentsLibrary capability, the app can interact with any file in the Documents folder as long as the file type is declared in the app’s manifest.

Extended Validation:  How?

Most apps don’t need programmatic access to the user’s Documents folder, but let’s suppose for sake of this blog your app does.  There are several steps to follow:

First, download the signable .xml file.  The link to download the file can be found by logging into your Windows Store account and clicking the “Account” link.  You’ll find the EV section just after the Publisher ID.


Second, purchase a code-signing certificate from Symantec or Digicert.  Both certificate authorities provide EV code-signing certificates which will work.  My personal experience is with Digicert but I expect Symantec would work the same.  Effectively, you purchase the certificate, fill out a form, and submit the form to your respective certificate authority.  The CA will then send a thumb drive to your company’s address with some instructions on how to use the drive to install the certificate.  Digicert has an image that describes this process:

So far the process seems pretty easy, right?  Download the .xml file, purchase the certificate, insert the thumb drive, and run the .exe on the thumb drive to sign the file.  If only it was that easy.  If you look on Symantec’s EV page under “Key Features”, take notice of the supported file types,

Digitally sign 32-bit and 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi, .xpi, and .xap files) and kernel-mode software

Okay but where’s .xml?

The Bad

I don’t want to go into a ton of details but traditional code-signing engines don’t sign .xml file types.  They are typically used to sign installers or libraries like the file types above.  In fact, if you tried to sign the .xml file with a typical code-signing tool, you’d get an error…  Not cool.

I spent several hours going back and forth with the Windows Store team and Digicert explaining the problem.  Digicert’s support was completely baffled as to why I would want to sign an .xml file so they weren’t much help.  Microsoft support was better but it required my traversing the org tree to find the team responsible for the EV section of the Store.  Not as easy as you’d think with 90,000+ employees.

The Ugly

Working with Microsoft’s EV team was awesome.  I was able to chat directly with a developer – finally someone with answers – and he was able to write a console program which signs .xml files.  I ran the program, configured the parameters and what do you know?  It worked!  Hurray!  I can now publish my app to the store.

NOTE:  the code signing certificate produced by the CA must be generated using SHA2, not SHA1 and the certificate must exist in the user’s certificate store before running the .exe.

The Good…?

Even though developing a custom C# project to sign .xml files isn’t an ideal solution it’s better than nothing so I’m calling this one “good.”  I’m also calling it good because I’ve received permission from Microsoft and the team who developed the project to host it on CodePlex.  You’re welcome.  Feel free to download the entire project or just the .exe to sign .xml files for as part of your extended validation status.  The tool is available at,

Hope it helps,


Hello World!

It’s finally here!  My official blog.  It’s been on my list of todos for a long, long time and now I finally have some incentive (Micro$oft) to actively write.

I recently changed roles at Microsoft so now I’m a Technical Evangelist for Developer and Platform Evangelism (DPE) in US-West.  Best job ever!  I spend my time working with companies across the region to help them develop apps for Azure, Windows 8, and Windows Phone, which also happen to be my three favorite platforms.  It’s been a fantastic experience so far and I’m happy I made the change.  I’m hoping to use this blog as a means of sharing my experience as a Microsoft Technical Evangelist.

In addition to working at MSFT.  I also spend time developing my own applications.  I’ve got a couple of Win8/WP apps in the store, a very robust Treasury Workstation running on Azure, a Win Form app, and several web sites I’ve built along the way.  Check them out!