Windows Azure Training Kit (June 2012) Now Available

by on June 21, 2012

The Windows Azure Training Kit June 2012 Update is now available. The June 2012 update includes 42 step-by-step hands-on labs and 20 presentations covering the new Windows Azure features.  Some of the highlights of this update include:

  • 12 new hands-on labs for Windows Azure Virtual Machines
  • 11 new hands-on labs for Windows Azure Web Sites
  • 2 new hands-on labs that demonstrate Windows Azure with Windows 8 Metro-style applications
  • New hands-on labs for Node.js and PHP using Mac OS X
  • Updated content for the latest Windows Azure SDKs, tools, and new Windows Azure Management Portal
  • New and updated presentations designed to support individual sessions to a full 3 day training workshops

Download Now

You can download the training kit here:

Just like past releases, the full training kit package (213MB) is a self-extracting exe that will unpack all of the hands-on labs and presentations to your local machine. You can then browse through the hands-on labs as HTML or the PowerPoint presentations locally. Alternatively, you can download the Training Kit Web Installer (2.4MB) and selectively choose individual hands-on labs or presentations. 


For those of you who have used the Windows Azure Training Kit in the past, you will notice several changes we’ve made in the full package: 

  • We have simplified the layout and structure of hands-on labs so that all content is on a single page. While this means we sacrificed a table of contents, it does mean that you can easily print and search through a hands-on lab when browsing the HTML. 
  • The HTML version of the hands-on labs no longer include JavaScript. Consequently, you will not receive any browser warnings when looking through an HOL that has been installed locally.
  • The setup scripts for the HOLs have been updated to use the new dependency checker that checks to ensure you have the necessary prerequisites and automates any setup steps. The new dependency checker also uses Web PI for the dependency checks.

The Web Installer experience has also been updated. Based on feedback we have changed the behavior of the Web Installer so that no content is selected by default. Users can now select the content they want to install. 

Content on GitHub

We are also now making the training kit content available on GitHub at or through the GitHub pages here. All of the hands-on labs included in the kit are written in a simple Markdown format, so they can be viewed on and easily changed directly through GitHub. This will also enable several of field evangelists and community insiders to contribute, improve, or localize the content. Finally, if you encounter any issues with the content, you can simply click on a link in the hands-on lab and log the issues in GitHub.


Why can’t I connect to my SQL Azure database?

by on May 15, 2012

We’ve been running our Azure Hands On Experience labs throughout the US Central Region for the last month or so and the SQL Azure exercises require the user to connect a newly created SQL Azure database from their development workstation.

Inevitably, at least one machine is configured with one or more settings that prevent a connection from succeeding, either from SQL Server Management Studio or Visual Studio’s Data Connections tree in Server Explorer (my preferred method btw).

Here are the troubleshooting tips we’ve been using in the labs:

1. Double check your software versions.

If you’re using SQL Server Management Studio, it needs to be SQL Server Management Studio 2008 R2 (the free express or full edition). If you go to the Help | About menu, the dialog will say R2 in the logo product logo.


If you want to connect from directly inside Visual Studio 2010, make sure you have Visual Studio 2010 Service Pack SP1 installed as well. If you go to the Help | About menu item in Visual Studio 2010, the popup dialog will say SP1 immediately after the product version number. Also, make sure you have the latest Windows Azure SDK installed. It will set up the hooks for azure database connectivity from within Visual Studio 2010.


2. Double check your SQL Server Native Client Configuration

If you’re getting an error that mentions named pipes it means the SQL client networking protocol settings on your development machine are set to connect to servers using the named pipes protocol by default. This won’t work with SQL Azure because named pipes is a network protocol optimized for local LAN traffic. All connections to SQL Azure are done using TCP/IP so you need TCP/IP enabled.

To do this, run SQL Server Configuration Manager go to your start menu and select All Programs | SQL Server 2008 R2 | Configuration Tools | SQL Server Configuration Manager.


You need to make sure the TCP/IP protocol is enabled under the SQL Native Client 10.0 Configuration tree item.  (On 64 bit machines you might have both 32 bit and 64 bit tree branches – be sure to enable TCP/IP in both). It’s generally a good ide to set TCP/IP as a higher priority protocol over named pipes as TCP/IP is the most common network protocol for SQL severs these days. This msdn article has more details about the configuration options.

3. Check your client side firewall rules.

SQL Servers communicate over TCP/IP through port 1433. The Windows Firewall software that shipped with XP SP2, Vista and Windows 7 is pretty good about about asking you when a new port is about to be used and letting you choose if you want it opened. If you're using another client side firewall solution, be sure to enable port 1433 for outbound connections. If your firewall software is set on an application by application basis, set up a rule for SQL Server Management Studio or Visual Studio appropriately.

4. Check the SQL Azure server firewall rules

When you create your SQL Azure database, you were asked to set up firewall rules to allow outside connections to the server. When you add a rule the dialog box lets you to set a range of IP addresses. It also shows your current IP address. In most cases your current IP address is chosen from a bank of addresses on the network you’re connected to.

To check these settings, log into your windows azure account, navigate to the databases area, and choose the database you’re trying to connect to from the tree on the left side of the screen. You should see the dropdown option to view and edit the Firewall Rules for your database server. Add or edit a rule to enable access for the development machine you’re trying to connect with.


As a minimum, you should add your current IP address as it is shown at the bottom. The hands on labs recommend adding a large enough address range so that if you have to reboot and end up acquiring a slightly different address you’ll still be able to connect with having to add another rule. You cans that I did this here.

Note: The address shown for Your current IP address is the public address that the server sees your internet traffic coming from. In the big chain of firewalls between you and your SQL Azure database, this is the address as it will be recognized from the network you currently reside in. It may or may not match the actual IP address your individual machine says it’s using. That’s OK. What it’s seeing is the most public internet facing firewall that you’re going through to get to the database. That’s all the server needs to know to allow you in.

5. Check your corporate firewall rules

If you still can’t connect and all of the above items check out and you’re currently connected to corporate network, chances are your corporate IT folks have another firewall in place to keep the baddies out and to keep you from accidentally letting them in.

If you’ve got an alternative method to connect to the internet such as a wireless hotspot or a guest network, try connecting to it and see if your attempt to reach your SQL Azure server succeeds. If so, then you know there’s a corporate firewall blocking you.

You’ll have to check with your network admins to see if they allow outbound TCP/IP connections on port 1433. Chances are you’ll have to do some paperwork to get that set up.


These are the troubleshooting steps we’ve found fruitful during labs. If you’re still stuck beyond this point, get a colleague to try connecting to your server from their machine. If they succeed, then you know there’s a configuration difference. It’s just a matter of finding the difference.

Multi Tenant Metering in Windows Azure

by on April 30, 2012

Our global ISV team just announced the public availability of the Cloud Ninja Multi-Tenant Metering Block (CNMB). The CNMB code sample enables SaaS ISVs to meter tenant-level consumption of various Windows Azure resources such as bandwidth, storage, SQL Azure, and compute. 

The first Cloud Ninja sample included some metering capabilities along with many other SaaS concepts such as monitoring, scaling, provisioning, etc. Given the demand for multi-tenant metering, there was a need for a stand-alone metering sub-system isolated from a main SaaS application that was easy to deploy, based on standards, and extensible. The outcome of that effort is the CNMB. Here are some screen shots:


clip_image001      clip_image002



It provides tenant-level meters, application level aggregates, a rich query model based on OData, an extensibility to implement custom meters. All the data can be queried using the OData API, which enables interesting mash-ups in PowerPivot and integration with external systems like billing.

The CNMB includes an HTML5 portal to visualize tenant and app level usage. You can try the live demo here and download full source code from CodePlex. The live demo is currently metering our Cloud Ninja application. When you try the demo, check out links on home page to app-level, tenant-level usage, PowerPivot dashboard, and OData feed.

It comes with out-of-box meter providers for bandwidth, storage, SQL Azure, and compute. In the future we will add providers for Tomcat and CDN. It is easy to write custom providers if you want to meter application specific resources. 

Key features of the CNMB

  1. Easy to Use: The CNMB works with existing multi-tenant SaaS application in a non-intrusive manner.  It needs simple configuration to point to SaaS application’s storage account and SQL Azure database and simple regular expressions to associate tenants with resource consumption. 
  2. Economical:  The CNMB can be deployed in a single web role, which hosts UI, Web Services, and metering workers.  Data schema is optimized so that 1GB SQL Azure database can hold an entire year’s worth data for thousands of tenants.
  3. Standards Based: All data in and out is via authenticated OData API.  OData allows rich query model on top of meter data.  We support both JSON and Atom payloads.  This enables 3rd party apps like PowerPivot and external systems like billing to consume meter data through industry standard API.
  4. Extensible: The CNMB has multiple levels of extension points from writing your own tenant resolver, defining customer meters, and developing customer meter providers.

If you are building a multi-tenant SaaS application, please check out the code sample and to provide feedback or feature requests using CodePlex’s discussion feature. 

For MSDN subscribers, Microsoft Partners or BizSpark members this is also a great opportunity to take advantage of the free Windows Azure Benefits and try this out on Azure servers of your very own.