Since the initial release of the Azure Management Libraries (WAML) as Portable Class Libraries (PCL, or pickles as I like to call them) we’ve had tons of questions from community members like Patriek asking how Windows Phone applications can be written that make use of the cloud management functionality WAML offers. At first glance it would seem that WAML is “unsupported on Windows Phone,” but the reality is that WAML is fully supported via it being a PCL, but some external factors made it seem just shy of impossible to be able to glue our PCL framework to each of the targeted client platforms. In the case of Phone, there are two blockers:

  1. Since the X509Certificate2class is unsupported on Windows Phone developers can’t make use of the certificate-based method of authenticating against the Azure REST API
  2. Since there’s no ADAL implementation that targets Phone there’s no way to use ADAL’s slick functionality to get my authentication token. The assumption here is that some creative coding is going to have to be done to go deeper into the OAuth stack. Sounds nasty.

Well, that’s never stopped any motivated coder before, right? Armed with some code from Patriek, a problem statement, and a pretty informative blog post written by none other than Vittorio on how he had some fun tying Phone to REST Services using AAD, I set out to start at ground zero to get some code working on my phone that would enable me to see what’s happening in my Azure subscription, across all my sites, services, and data stores. I set out to create a new type of phone app that will give me complete control over everything I’ve got published to my Azure cloud subscription. This post will walk through the code I worked up to get a baseline Windows Phone mobile cloud management app running.

Creating and Configuring the Phone App

First, a little background is required here. As Vittorio’s post makes very clear, the OAuth dance the WP8 code is going to be doing is pretty interesting, challenging, and results with a great set of functionality and an even greater starting point if this app gives you some ideas on what you could make it do next. In fact, if you’re into that whole social coding thing, the code in this post has a GitHub repository right here. The code in the repository contains the project I created in this screen shot in more detail.


The first step is to pull down the NuGet pacakges I’ll need to write this application. In this particular case I’m kind of thinking of writing a Windows Phone app that I’ll use to management my Azure Web Sites, Cloud Services, SQL Databases, Storage Accounts, and everything in between. So I’ll right-click my Phone project and select the correct packages in next step.


I’ll go ahead and pull down the entire WAML NuGet set, so I can manage and view all of my asset types throughout the my Azure platform subscription. By selecting the Microsoft.Azure.Management.Libraries package, all of the SDK Common and WAML platform NuGets will all be pulled down for this application to use.


The Common SDK, shown below in the project’s references window, provides the baseline HTTP, Parsing, and Tracing functionality that all the higher-order WAML components need to function. Next to that is the newest member of the Common SDK tools, the Common Windows Phone reference, which is new in the latest release of the Common SDK package. This new addition provides the high-level functionality for taking token credentials from within the Windows Phone client and being able to attach those credentials to the SDK client code so that calls made to the Azure REST API from a phone are authenticated properly.


If you read my last blog post on using WAAD and WAML together to authenticate WAML-based client applications, there are a few important steps in that post about working through the process of adding an application that can authenticate on behalf of your WAAD tenant. Take a look at that post here to get the values for the App Resources dialog in the screen shot below. In a sense, you’ll be setting application settings here that you can get from the Azure portal. You’ll need to create an application, then get that app’s client id, and your subscription and active directory tenant id or domain name, and place those values into the code’s resources file, as shown below.


The Login View

The first view shows a built-in web browser control. This web browser will be used to direct the user to the login page. From there, the browser’s behavior and events will be intercepted. The authentication data the form contains will then be used to manually authenticate the application directly to AAD.

Reminder – As Vittorio’s post pointed out, you might not want to use this exact code in your production app. This is a prototype to demonstrate putting it all together in the lack of important resources. Something better will come along soon. For now the OAuth dance is sort of up to me.

Note the web browser control has already been event-bound to a method named webBrowser_Navigating, so each time the browser tries to make a request this method handler will run first, and allow my code to intercept the response coming back to the browser.


Once the login page loads up, I’ll presume a login is in order, so I’ll go ahead and navigate to the login page, passing in a few of my own configuration parameters to make sure I’m hitting my own AAD tenant.


Vittorio deep-dives on the workflow of this code a lot better than I’ll try to do here. The basic idea is that the browser flow is being intercepted. Once the code realizes that AAD has authenticated me it hands back a URL beginning with the string I set for the redirectUrl property of this application in the portal. When my code sees my redirectUrl come through, I just run the GetToken() method to perform the authentication. It posts some data over the wire again, and this time, the response activity is handled by the RetrieveTokenEndpointResponse() event handler.


Once this handler wakes up to process the HTTP response I’ve received from the AAD authentication workflow (that we did via the OAuth dance), my access token is pulled out of the response. The subscription id value is then persisted via one of my App’s properties, and the next view in the application is shown.


When the user first opens the app, the obvious first step is visible. We need to show the user the AAD login site, and allow the user to manually enter in their email address and password. In this window. I could use a Microsoft (Live/Hotmail/etc.) account or an organizational account. The latter, so long as they’ve been marked as Azure subscription co-admins, would be able to log in and make changes, too.


Once the user logs in they’ll be shown a list of their subscriptions, so let’s take a look at how the code in the subscriptions view is constructed.

Selecting a Subscription

The subscription selection view just shows a list of subscriptions to the user in a long scrolling list. This list is data-bound to the results of a REST API call made via the SubscriptionClient class, which goes out and gets the list of subscriptions a user can view.

Note – even though I can see my full list of subscriptions, I’ve only installed the Application into one AAD tenant in one of my subscriptions. If I click any of the other subscriptions, things won’t work so well. A subscription and a tenant are tied together. Unless your application gets special permission (it does happen from time to time, I hear) your application can only access Azure assets in the same subscription. If you wanted to work across subscription you’d have a little more work to do.

The XAML code below shows how the list of subscriptions will be data-bound to the view. I may eventually go into this code and add some view/hide logic that would show only those subscriptions I could impact using the application settings I’ve got running in this app. Point is, I can see all of the subscriptions I can manage and conceptually manage them with some additional coding.


The code below is what executes to log a user in with their stored access token and subscription id, when the TokenCloudCredentials class is used to wrap their credentials up as a single construction parameter to most of the management client. Since I was able to get a token from the OAuth dance with AAD, and since I know which subscription ID I want to affect, I’ve got everything I need to start working against the rest of the service management REST API endpoints.


When the subscriptions page loads, it gives me the chance to select the subscription I want to manage. Note:I just need to be cautiousand only click the subscription that matches the subscription where my AAD tenant is set up. In my case, I’ve got the application installed into my AAD tenant that lives in the subscription named Azure MSDN – Visual Studio Ultimate. If I were to select any of my other subscriptions I’d get an exception.

To have true parity across all subscriptions you’d need to have an application setup in each of your directories and some additional configuration, oryou’d have to allow other tenants set up multi-tenancy with your AAD tenant.


Once the subscription list is data-bound the user can select a subscription to work with. Selection of a subscription item in the list fires the following code.


It persists the subscription id of the subscription the user selected, and then navigates the user to the AssetListViewpage, which will show more details on what’s in a user’s Azure subscription.

Viewing Cloud Assets via Mobile Phone

To provide a simple method of being able to scroll through various asset types rather than emulate the Azure portal, I made use of the LongListSelector and Pivot controls. In each Pivot I display the type of Azure asset being represented by that face of the pivot control. Web Sites, slide, Storage, slide, SQL, slide, Cloud Services… and so on. The idea for the phone prototype was to show how WAML could be used to load ViewModel classes that would then be shown in a series of views to make it easy to get right to a particular asset in your Azure architecture to see details about it in a native Phone interface.


Since the assets list page is primarily just a logically-grouped series of lists for each of the types of assets one can own in their Azure stack, the ViewModel class’s main purpose is to expose everything that will be needed on the view. It exposes Observable Collections of each type of Azure asset the app can display.


What would be better as controller functionality, the code in the codebehind of the view ends up doing most of the data-acquisition from the Azure REST APIs via WAML calls. In the code sample below the GetWebSites method is highlighted, but the others – GetSqlDatabases, GetStorageAccounts, and GetHostedServices – all do the same sorts of things. Each method creates instances of appropriate management client classes, retrieves asset lists, and data-binds the lists so that the assets are all visible in the Windows Phone client.


The web sites pivot is shown below. I’m thinking of adding a deeper screen here, one that would show site statistics over the last Ndays, maybe add an appSetting and connectionString editor page, or something else. Have any ideas?


Here’s a list of my cloud services – 2 empty PaaS instances and 1 newly set-up VM instance.



Though the OAuth dance has a few drawbacks and the code is a little less elegant than when I could make use of ADAL in my previous example, it works. Once I have the token information I need from the browser, I can run with that information by creating an instance of a TokenCloudCredential, passing in the token I received from the OAuth dance to get to authenticate WAML and therefore, make calls out to the Azure Service Management API to automate my asset management. Since WAML is a PCL package, and as a result of the introduction of support for the Windows Phone platform into the SDK Common NuGet package, the community can now freely experiment with solutions combining Windows Phone and the Management Libraries.

Happy Coding!

Integration with Azure Active Directory was one of the main features we wanted to get into the 1.0 release of the Azure Management Libraries. Since Visual Studio and even the PowerShell Cmdlets (which use WAML, in fact) already have support for AAD, it was really important to all of us on the team that we have a method of providing authentication directly via AAD from within C# code using WAML. This makes for a synonymous login experience across all three of these (and more) areas. Most importantly, it makes it easy for Azure users to be able to manage all their subscription assets when they only need to login using their username/password portal credentials rather than go through the process of creating and uploading management certificates. This blog post will answer some of the questions and requests we’ve had from the community on how to tie AAD and WAML together, to create AAD-authenticated applications code that can be used to manage your Azure account assets.

This won’t be a deep-dive into how AAD works, but more a short examination on how it and WAML can be used together.

I worked quite a bit with the AAD team, especially Vittorio Bertocci, on this post. Our teams have a regular meeting so we’re on the same page, but the guys on their team spent some additional cycles with us spelunking, coming up with features, and so on. As we talked about ideas, the AAD team gave me some great resources, like this post which walks through the process of setting up a client app so that it can be authenticated using AAD. Vittorio’s site has a series of great examples on how to go deeper with AAD. I won’t go too deep into the inner-working of AAD in this post, so keep check out those great resources if you want more information. Thanks to the AAD team for all your help and patience and supporting our team!

Create a client app for managing Azure assets

The code for this sample application won’t be too complicated. I’m actually going to retrofit a small command line app I wrote the other day when asked by a peer in another team who wanted to export the list of Virtual Machine images in the gallery. The code for this itty-bitty application’s beginnings is below, which makes use of the Compute Management Management Library.


With this code already working using my Management Certificate, and with it being a relatively simple app, it seemed like a great case for demonstrating how easy it is to switch out the CertificateCloudCredentials for the TokenCloudCredentials class once the AAD infrastructure is set up and ready. Speaking of that, this would be a good time to walk through the process using the Azure portal to set up an AAD application in my AAD directory that I can develop that will use the Management Libraries to manage my subscription.

Setting up an AAD application using the portal

To authenticate using AAD I first need to create an application in my Azure subscription’s existing Active Directory tenant. To do this I go to my AAD tenant page in the portal and click the Applications tab at the top.


I currently have no applications authenticating against my directory so I’ll click the Add button at the bottom of the portal.


Selecting the second option in this list presents me with a huge list of existing applications with which AAD can integrate. Since I’m interested in authenticating an application I’m writing, I’ll click the first option. 


The application I’m writing is a small console application, not a web app. Hence I’ll select the second option – Native Client Application - in the Add Application dialog, shown below. If I’d wanted to put an ASP.NET Web API up in the cloud that would use AAD on the back end for authentication, I’d select the top option, Web Application and/or Web API. The API my client app will need to access is the actual Azure Service Management API, which AAD has a special provision for in the portal that will be examined in a moment.


Next, I’ll need to provide a redirect URI. Even though the application I’m writing is a native app, I still need to provide this URI to give AAD more details on the specific application that will be authenticating.


Once these settings are made, I can see the application’s client id in the portal, along with the information I provided during the application’s creation process. The MSDN code site article I mentioned above, written by the AAD team, walks through more details of how the client application authentication workflow functions and offers more details, so definitely check out that sample if you need more information on these settings. For now, what’s important to remember from this window are the client idtext box and the redirect URI created below. Those two strings make up 2 of the 3 strings I’ll need to authenticate a WAML application with AAD.


The final piece of information is the AAD tenant id, which can be found by clicking the View Endpoints button in the portal when on the page for the directory I wish to use to authenticate users.


The URI provided in each of the text boxes in the resultant dialog contain a GUID. This GUID is the tenant id, so it’ll need to be copied out for use in my code.


Changing the WAML code to perform AAD authentication

Back in Visual Studio I’m ready to change the code to make use of AAD authentication. The first step is to reference the required NuGet package, the Active Directory Authentication Library (ADAL). This will enable my project the ability of prompting the user with a login dialog, into which they can enter their Microsoft account username and password. It will also add all sorts of goodness from the AAD folks that you can make use of in your client applications.


In the code I’ll add a method called GetAuthorizationHeader that will take my tenant id as a parameter. I’ll presume the calling code might want to make use of the common tenant, but will give callers the ability to pass in their own tenant GUID identifying their custom Active Directory tenant. Take note that within this method I’m making use of the application’s settings, the redirect URL and the client id property from the portal. As well. I’m passing the base URI of the Azure REST API as the value for the resourceparameter to the AuthenticationContext.AcquireToken method. Vittorio has a great blog post introducing ADAL and what you can do with it, so if you’re looking to dive deeper on this topic head on over to and check it out. In a more practical implementation I should probably be setting those values up as appSetting variables, but for this demonstration code sheer pasting in the values is sufficient.


The final step in the code is to comment out the old authentication mechanism, where I was using the X509Certificate2 class to authenticate using a management certificate. In place of this code, which creates an instance of a new CertificateCloudCredentials class, I’ll make a call to the new GetAuthorizationHeader method to get my token, then use that token as a parameter to an instance of the TokenCloudCredentials class.


Authorizing access to the Azure Service Management API to my client application

At this point the code almostworks. However, when I run it I get an error that pretty clearly indicates what’s wrong in the exception message. Clearly, this application hasn’t been granted access to the service management API.


A recently-added (okay, a personally recently-discovered) feature within the portal allows me to specify which applications I’m going to allow access to this client application. Since I’ve not yet created any APIs that also use AAD as an authentication mechanism I’ll only see the two default items in this drop-down menu (the Graph Explorer and the Service Management API). By selecting the option Azure Service Management API, I effectively grant my client application access to any of the REST API URLs available under Once I save this setting, the code should run and give me back the list of Virtual Machine images from the gallery.


When I run the code this time, it works as expected. I’m prompted for my credentials, thanks to some of the functionality provided in the ADAL package.


Once I log in using my subscription’s credentials, WAML can authenticate and pull down the list of virtual machines.


From here, I could use the rest of the functionality available in WAML to do whatever I need. Now that I’m able to authenticate using AAD, I won’t need to create, upload, configure, and track my management certificates. Rather, my applications can just make use of Active Directory to log in and manage my subscription’s assets.

I hope you find this to be an exciting new option available in the Azure Management Libraries. I’ve been looking forward to showing this feature off, as I think it shows two awesome areas of the client developer experience – AAD via ADAL and the REST API via WAML – being used together to create some amazing client-side magic against the Azure cloud. Thanks again to the AAD folks for lending a hand from time to time with some of the details and fine tuning!

I received an email from Hanselman this week, a forward of an email he received after posting his [much-appreciated and far too kind] blog post on WAML. The email was from a community member experiencing a behavior when trying to use WAML to create web sites (or manage their existing sites) from code running on the server side from another Azure Web Site. I can imagine lots of user stories when a Web Site could be used with WAML:

  • I’m a software-as-a-service application business owner. I want to give users a form that, once filled out and submitted, will take user input and create a new web site and copy my application’s code into their web site
  • My web application needs to create a storage account when it first starts up
  • My web application needs to create a SQL Database when it first starts up

Automation isn’t limited to the desktop. With WAML you can pick and choose which areas you need to offer and install the appropriate NuGets and get up and running quickly. There are a few caveats, however, mostly deliberate design decisions based on the basic ideas of cryptography and data integrity. I spent a few hours this week talking to my good friends in the Web Sites team, along with my own awesome team in Azure Developer Experience, to work through some certificate-loading problems I was seeing in Web Sites. The ability to use a management certificate is pretty important when programming against WAML (yes, AAD support is coming soon in WAML). I’ve seen a few different forums mention similar issues. Given WAML makes use of certs, and sometimes using certs on the server side in the Web Site can be a little tricky, I thought a walk-through was in order.

How Meta. A Web Site that Makes Web Sites.

I’ve created a Visual Studio 2013 solution, with an ASP.NET project in the solution, that I’ll be using for this blog post. The code for this site is on GitHub, so go grab that first. The code in the single MVC controller shows you a list of the sites you have in your subscription. It also gives you the ability to create a new site. The results of this look like the code below.


Here’s a snapshot of the code I’m using in an MVC controller to talk to the Azure REST API using WAML.

There are a few areas that you’ll need to configure, but I’ve made all three of them appSettings so it should be relatively easy to do. The picture below shows all of these variables. Once you edit these and work through the certificate-related setup steps below, you’ll have your very own web site-spawning web site. You probably already have the first of these variables but if you don’t, what are you waiting for?


Once your Azure subscription ID is pasted in you’ll need to do a little magic with certificates. Before we get to all the crypto-magic, here’s the method that the controller calls that prepare WAML for usage by setting up an X509Certificate.


I’d been using a base 64 encoded string representation of the certificate, but that wouldn’t work on top of Web Sites. Web Sites needs a real physical certificate file.Which makes sense – you want for access to your subscription to be a difficult thing to fake, so this configuration you have to go through once to secure the communication? It’s worth it. The code below then takes that credential and runs some calls to the WebSiteManagementClient object, which is a client class in the Web Sites Management Package.


This next part is all about cryptography, certificates, and moving things around properly. It’s not too complicated or deep into the topics, just a few steps you should know just in case you need to do this again.

Don’t worry. If it were complicated, you wouldn’t be reading about it here.

Creating a Self-Signed Cert and Using the PFX and CER Files Properly with Web Sites

I’ll run through these steps pretty quickly, with pictures. There are many other great resources online on how to create certificates so I’m not going to go into great detail. This section has three goals:

  1. Create a self-signed certificate
  2. Create a *.CER file that I can use to upload to the Azure portal as a management certificate
  3. Use the *.PFX file I created on the way to creating my *.CER file on my web site

To create the self-signed cert open up IIS Manager (some would prefer to do this using makecert.exe) and click the Server Certificatesfeature.


Then, click the Create Self-Signed Certificate action link.


You get to walk through a wizard:


Then the new certificate will appear in the list:


Select it and click the Export action link:


Now that you’ve got the PFX file exported, it’d be a good time to drop that into the web site. Drop the PFX file into the App_Datafolder…


Once the .PFX is in the App_Data folder, copy it’s location into the Web.Config or in the portal’s configuretab.


Double-click the PFX file. Run through the subsequent steps needed to import the PFX into the personal certificate store. Once the wizard completes you’ll have the certificate installed, so the final step will be to export it. Open up your user certificates tile. I always find mine using the new Modern Tiles method.


Open up the file in the user certificate manager, and select the new certificate just created. Select the Export context menu.


Select the DER option. This is when you’ll output a CER file that can be used as your management certificate in the next step.


Save the output *.CER file on your desktop. With the PFX file set up in the web site and this file created, we’re almost finished.

Uploading the Management Cert to the Portal

With the CER file ready, all one needs to do to upload it is to go to the Management Portal. So long as the web site you’re running WAML in is trying to access resources in the same subscription, everything should work. Go to the management portal, select Settingsfrom the navigation bar, and then select the Management Certificates navigation bar.Click the Upload button to upload the *.CER file only. NOTthe PFX, yet!


Once the CER is uploaded it’ll appear in the list of management certificates.


With those configuration changes in place, I can finish the configuration by adding the password for the PFX to the Web.Config file. This part isn’t perfect, but it’s just to get you started with the difficult connecting-of-the-dots that can occur when embarking on a new feature or prototype.


Deploying the Site

The last step, following the configuration and certificates being set up, is to deploy the site. I can do that from right within Visual Studio using the publish web features. Here, I’m just creating a new site.


Once the site deploys and loads up in a browser, you can see what capabilities it’ll offer – the simple creation of other Azure Web Sites.



This article covers more how to prepare a web site with the proper certificate setup and contains code that explains the actual functional code. I’d welcome you to take a look at the repository, submit questions in the comments below, or even fork the repository and come up with a better way, or to add features, whatever you think of. Have fun, and happy coding!

The stories you hear about working at Microsoft and how we send and receive lots of email is true. It is more true than you could imagine. I’ve been an addicted avid user of Outlook since I’ve had a job but there are some features I’ve not explored with any depth. Even with software, I sometimes strive to live a more Buddhist lifestyle and deny myself the investigation for features that I fear I will not find. That whole expecting it to be there and being disappointed when it isn’t thing is too depressing for me to go through, so I choose to minimize my expectations and not go hunting for features my life would benefit from having. No, really. I’m just lazy. No but seriously, I have this obsessive rule about not seeing a scrollbar in my Inbox.Each day when the little scrollbar icon appears, shortening the width of my Inbox by 20 (or so) pixels, I cringe. I hate having more-than-a-scroll emails in my Inbox.

The feature I’ve wanted (ever since I got the feature of not having to refresh my inbox) is to tell my inbox to stop auto-refreshing. I’d never gone hunting for it. Tonight, I did, and I found it in 5 minutes. I like this feature so much I’m going to show it off. You’ve probably seen this already, but get this – you can leave Outlook open and prevent it from checking your mail.That way, you can clean out your Inbox while simultaneously preventing it from refilling itself as you try to clean it out.

Here’s the trick. On your Outlook ribbon in any of the modes – email, calendar, tasks, whatever – click the Send/Receive ribbon. Then, toggle the Work Offline feature. I’ve highlighted my favorite part of the feature – the “if you do not want to receive new mail” message.


As soon as you do this, Outlook will stop checking your email for you. The status bar reflects my newfound joy, knowing I can keep my old friend open but quiet as I prune away towards inbox-zero Nirvana. In the status bar, I can see that I’m working offline. That way, once I get jittery in 15 minutes after not having received any new email, I can just look down and see why no one’s emailing me. I’ve temporarily put the incoming world on hold.


Whenever I’m ready to stop being anti-social, I can go back to the Send/Receive tab and see that I’m hiding via the greyed-out Work Offline toggle button.


Once I click that, Outlook connects and starts updating my folders…


After a few seconds everything is updated and I’m back online, with new fresh email to read…


You probably already knew about this feature, but I’m so excited I had to share it. Thanks, Outlook team, for being awesome.

The Azure SDK team has been working hard to finish up more of the Azure Management Libraries so you can use .NET code to manage your Azure resources, and today’s blog will highlight one of the newest additions to the WAML stack. Today I’ll introduce you to the Azure SQL Database Management Library. We released the SQL Management Library this week, and it’s loaded with features for managing your Azure SQL Databases. Like the rest of the management libraries, the SQL library provides most of the functionality you’d previously only been able to do using the Azure portal, so you’ll be able to write .NET code to do pretty much any level of automation against your SQL databases and servers.

Here’s a list of some of the features supported by the new SQL library:

  • Create, update, delete, and list your Azure SQL Servers
  • Create, update, delete, and list your Azure SQL Databases
  • Create, update, delete, and list your Azure SQL Servers’ Firewall Rules
  • Import and Export SQL databases to & from Azure Blob Storage

Let’s dive in to some of these features by exploring their usage in the sample code I’ve written to demonstrate all these cool new WAML features. I’ve put this code up in GitHub so you can fork it, add your own functionality and test cases, and [please, feel free] spruce up the UX if you’re so inclined. The code for this demonstration includes the demonstrations from my previous blog posts on WAML, so if you’ve been wanting to see that code, you can dive in as of this latest installment in the blog series.

The WPF app shown below sums up today’s code demonstration for using the SQL management library. Once I select my publish settings file and select the subscription in which I want to work WAML makes a REST call out to Azure to retrieve the list of database servers in my subscription. I data-bind a list view in the WPF app with the list of servers. Next to each you’ll find buttons to allow for convenient access to the databases residing on the servers, as well as a button giving you access to the servers’ firewall rules.


Creating the SQL Management Client

As with the other demonstrations, the first step is to create an instance of the SqlManagementClient class using a subscription ID and an X509 Certificate, both of which are available in my publish settings file. The code below is similar to the manner in which the other management clients (Compute, Infrastructure, Storage, and so on) are created.


SQL Server Operations

The code below shows how, in two lines of code, I can get back the list of servers from my subscription. Once I’ve got the list, I set a property that’s data-bound in the WPF app equal to the list of servers the REST API returned for my subscription.


Database Operations

Once a user clicks the “Databases” button in one of the server lines in the WPF app a subsequent call is made out to the Azure REST API to pull back the list of databases running on the selected server. 


You can do more than just list databases using the SQL management library – you have full control over the creation and deletion of databases, too, using the easily-discoverable syntax. Below, you’ll see how easy it is to figure out using nothing more than the Intellisense features of Visual Studio to figure out how to create a new database.


Firewall Rules

You no longer need to load up a server in the portal to manage your firewall rules – you can do that using the SQL management library, too. The code below demonstrates how easy it is to retrieve the list of firewall rules for a particular SQL Servers. When the user hits the “Firewall Rules” button in the WPF app, this code runs and loads up the rules in the UX.


In addition to the SQL library, we’ve also released the preview libraries for Media Services and Service Bus, too. We’re continuing to improve the landscape of WAML every day, and have some convenience features we’re adding into the overall WAML functionality set, too. Keep watching this blog for more announcements and tutorials on the Azure Management Libraries. As always, if you have any suggestions or ideas you’d like to see bubble up in the management libraries, feel free to post a comment below.

Happy Coding!