Monthly Archives: January 2014

Stupid Azure Trick #3 – Create a Dev Virtual Machine in Windows Azure

“Everyone” knows about using cloud services for running web applications and databases. For example, Windows Azure offers a bevy of integrated compute, storage, messaging, monitoring, networking, identity, and ALM services across its world-wide data centers.

But what about the idea of leveraging the cloud for software development and testing? Of course there is great productivity in using hosted services for a lot of the ancillary tasks in software development – source control, issue tracking, and so on. Example cloud solutions for source control would include two that I use regularly, GitHub and Team Foundation Service (TFS). But what about for hands-on software development – creating, running, testing, and iterating on code?

There are really two significant ways you can go here. One way – that I will not be drilling into – is to use a cloud-hosted web browser-based development environment. This is what’s going on with Monaco, which is a cloud-hosted version of Visual Studio that runs entirely in a web browser – but (very awesomely) integrates with Windows Azure. There are also third-parties playing in this space, such as Cloud 9.

The other way – the one I am going to drill into – is using a Windows Azure Virtual Machine for certain development duties.

[Making a case for when and why one might create a dev-test environment in the cloud will be left for another time…]

With great power comes great responsibility

Spiderman knows this, and you need to know it as well.

Virtual Machines in the cloud cost money while they are deployed. It is your great responsibility to turn them off when you don’t need them.

The pricing for “normal” virtual machines (as opposed to MSDN Pricing which is described below) is listed at http://www.windowsazure.com/en-us/pricing/details/virtual-machines/. For example, at the time of this writing, the price for a Windows Server VM ranges from $0.02 (two cents) to $1.60 per hour, while the price for a Windows Server VM with SQL Server ranges from $2.92 to $7.40 per hour. The $7.40/hour VM is an instance running on a VM with 8 cores and 56 GB of RAM.

NOTE: just before publication time, Windows Azure announced some even larger “compute-intensive” VMs, A8 and A9 sizes. The A9 costs $4.90 per hour and sports 16 cores, 112 GB of memory, and runs on a “40 Gbit/s InfiniBand network that includes remote direct memory access (RDMA) technology for maximum efficiency of parallel Message Passing Interface (MPI) applications. […] Compute-intensive instances are optimal for running compute and network-intensive applications such as high-performance cluster applications, applications using modeling, simulation and analysis, and video encoding.” Nice! These are available for VMs in Cloud Services, and I would expect them to become available for all VMs in due course.

Some VMs cost more per hour (I’m looking at you BizTalk Server) and some costs are as yet unknown (such as for Oracle databases, which are in preview and production pricing has yet to be revealed).

VM prices vary for two reasons: (a) resources allocated (e.g., # of cores, how much RAM) and (b) licensing. For the same sized VM, one running SQL Server will cost more than one running Windows Server only. This is a feature – for example, you can rent a SQL Server license for 45 minutes if you like.

Of course, while inexpensive, and nearly inconsequential in small quantities, these prices can add up if you use a lot of VM hours. The good news is, you can release VM resources when you are not using them. You don’t incur VM costs when the VM is not occupying a VM, though there is a small storage cost that starts at $0.07 (seven cents) per GB per month.

Just don’t forget to free your resources before leaving for vacation.

Fortunately, VMs can easily be stopped in the portal, by using the Remove-AzureVM PowerShell cmdlet, by using the azure vm shutdown command from the cross-platform CLI, through management REST APIs, or using one of the language SDKs.

Example prices were expressed in terms of “per hour” but the pricing granularity is actually by the minute. In some clouds, usage granularity is hourly, or possibly “any part of the hour” meaning a VM deployed from, say, 7:50 to 8:10 would incur 120 minutes of billing (two hours), even though actual time was 20 minutes. In Azure, you would be billed 20 minutes. The billing granularity matters more when using VMs for focused tasks like developers and testers would tend to do.

Further, there’s a data transfer price for data leaving the data center.

You may be interested in Windows Azure Billing Alerts.

MSDN Pricing – A Big Cloudy Discount

If you have an MSDN account (not just for big companies, but also with startups) – as long as you claim your Azure benefits – magically, you are eligible for special MSDN Pricing. Check for the current MSDN discounted pricing, but as of this writing MSDN includes either $50, $100, or $150 of Azure credits per month, depending on your level of MSDN. Anyone on your team with an MSDN account will have their own Azure credits.

This means that your monthly bill will draw from this balance before you incur actual costs. You can also choose to configure the account to not allow overages, such that when your monthly allotment is exhausted, consumption stops. This way you know your credit card will not be charged. You can selectively re-enable it for the rest of the month. This is not a bad default setting to avoid runaway dev-test costs due to forgetting to turn off resources when you didn’t need them.

Beyond this, you get a huge discount on other VMs – no matter what the VM is, you never pay more than $0.06 per hour per small VM unit.

MSDN pricing only applies to resources used for Dev-Test – it is not licensed for production use, nor does it come with an SLA.

But that’s such a good deal, that anyone using Windows Azure for Dev-Test should take a hard look at this option if they don’t already have an MSDN account. But this post is all about creating a Dev-Test VM, so let’s get on with it.

Creating a Dev-Test Virtual Machine in Windows Azure

Let’s set up for C#, Python, and Node.js development.

First, log into your Windows Azure account at https://manage.windowsazure.com.

image

image

image

image

If the MSDN checkbox is disabled, you have logged into a Windows Azure account that is not associated with your MSDN account. Change to the correct account to proceed.

Select the MSDN checkbox to filter out any VM image not specific to MSDN subscribers, and see the list of available VM images change to the following:

image

Note the text on the descriptive text on the right-hand side, which I’ve included here since it provides some useful information.

The Visual Studio Professional 2013 developer desktop is an offering exclusive to MSDN subscribers. The image includes Visual Studio Professional 2013, SharePoint 2013 Trial, SQL Server 2012 Developer edition, Windows Azure SDK for .NET 2.2 and configuration scripts to quickly create a development environment for Web, SQL and SharePoint 2013 development.

To learn how to configure any development environment you can follow the links on the desktop.

We recommend a Large VM size for SQL and Web development and ExtraLarge VM size for SharePoint development.

Please see http://go.microsoft.com/fwlink/?LinkID=329862 for a detailed description of the image. Privacy note: This image has been preconfigured for Windows Azure, including enabling the Visual Studio Experience Improvement Program for Visual Studio, which can be disabled.”

Choose one of the Visual Studio images (I will choose Visual Studio Professional 2013) and go to the next page by clicking the arrow at the bottom-right.

image

Fill in the fields. The username and password will be needed later to RDP into the box. Click the arrow to go to the next page.

image

I kept most of the defaults, only changing the REGION to be “East US” to minimize latency to my current location. Click arrow to go to next page.

If I planned to use this for giving a talk in another geographic location, I may choose a different region. For example, I may choose “North Europe” (Dublin) if I was speaking in Ireland (which would be wonderful and I hope happens some day :-)).

image

No changes on this page, so click check-mark to finish.

image

The portal will “think” for a short time, then your new virtual machine – listed under the name you gave it (“vspro-demo” for me), with the corresponding cloud service that was created (“vspro-demo.cloudapp.net” for me) which also serves as its DNS name (that you’ll use to access it via RDP).

image

Once it finishes, you can select it and hit CONNECT. This will download a file that will launch the RDP client which will allow you to login.

image

I usually check off “Don’t ask me again…” because I know this connection is fine.

image

Note that here you will want to click “Use another account” so you can specify your VM-specific credentials.

image

Click OK then…

image

I usually check off “Don’t ask me again…” because I know this connection is fine.

Now I’m in!

image

Configuring your Dev-Test Machine on Windows Azure

When configuring a new machine, there are many tools you may want to install. For this exercise, I will keep it simple. (The following use my handy “which” function in PowerShell to find locations of commands in the path. If you add “which” to your environment, be sure to close your PowerShell shell and open a new one so that the new $PROFILE is processed. If you
choose to not install “which” then issue the same commands and you should just get errors instead.)

With a PowerShell shell, let’s investigate what we have on a new machine.

image

We can see that, in turn, that:

  • While PowerShell is installed (we are running in a PowerShell shell), there are no PowerShell cmdlets with “Azure” in the name.
  • Node.js is not found (no Node Package Manager (npm) and no Node runtime (node).
  • The cross-platform (xplat) Command Line Interface (CLI) is not installed. This has Node.js as a dependency.
  • No Python interpreter is installed.
  • The Web Platform Installer actually is installed, so let’s use that to add the other pieces to our development environment.

image

After filtering, in succession, (in search box at the top-right)…

.. on PowerShell:

image

Click the “Add” button to add the latest “Windows Azure PowerShell” release.

.. on Cross-platform:

image

Click the “Add” button to add the latest “Windows Azure Cross-platform Command Line Tools” release.

and .. on Python:

image

Click the “Add” button to add the latest “Windows Azure SDK for Python” release.

image

Click the “Add” button to add the latest “Python Tools 2.0 for Visual Studio 2013” release. This includes some really cool python tooling for Visual Studio, though we won’t discuss it further in this post.

Now click the “Install” button to start the installation.

image

You can accept all the licensing with one click.

The installation will download and install the items you selected, including any dependencies.

image

image

image

(compiling Python distribution as part of the installation…)

image

image

image

Installation is complete.

Verifying the Installation

Open a new PowerShell Window to explore once again.

image

Note that we ran the “get-help azure” command through a filter (the Measure-Object cmdlet, which was used to count lines) since output would otherwise not have fit on one screen (there are a couple of hundred Azure cmdlets in the list). Of npm, node, azure, and python, only azure (via azure.cmd, the entry point to the CLI) shows up in our path. This is okay, since we can now run azure at the command line and it knows where to find Node.js.

image

As for python, that is now installed at c:\python27\python.exe. We can either add c:\python to our path, or invoke it explicitly using the full path. For our simple example, we’ll just invoke it explicitly. To see that the Windows Azure SDK for Python is installed, we can use pip, a Python package manager, to list the installed packages.

image

We can see that “azure (0.7.1)” is installed.

Done. Now go write some Python, Node, or C# code!

Useful Links

[This is part of a series of posts on #StupidAzureTricks, explained here.]

Advertisements

Can I use Multiple Monitors with Remote Desktop (RDP)? Yes. Here’s how.

Like lots of developers I know, I am more productive with multiple monitors. I have two displays, though I’m sure many of you have more screens than that.

Picture of Bill's two-monitor setup

I also spend a lot of time connecting into the cloud from my desktop. A common scenario is to use Remote Desktop to connect to a VM running in Windows Azure. I have always been disappointed that my remote desktop session did not take advantage of my multi-monitor setup. To be honest, until recently I assumed it was not even possible. I recently explored the Remote Desktop options and realized I was very wrong. It is very simple!

Why RDP Options are Easy to Overlook

First, let’s suppose you are launching RDP from the Windows Azure portal. You bring up the Virtual Machines screen, click on the VM of interest, and you’ll be looking at a screen like the following.

image

After clicking Connect along the bottom, you see this (or similar – different browsers handle downloads a little differently – this is Firefox):

image

Now you may click Save and the .rdp file is now local, leading to this:

image

You can simply now click Open to open up your session. Up pops a dialog asking for your credentials:

image

After you supply your credentials, you are logged into the VM. Done.

The problem with this is that it is too convenient – it bypasses the main Remote Deskop UI – and that’s where all the fancy options are for enabling support for multiple monitors.

Determining RDP Public Port for Windows Azure VM

For this step you need to know which public port you need to use to access your VM.

This port number is available in a couple of places. One place is in the Remote Desktop client itself. If you bring up a new instance of the Remote Desktop client, it will usually show you the last connection you made. The screen below shows port number 56008 after the DNS name.

image

Another place to check for from the Windows Azure Portal. The Remote Desktop port is configured on the ENDPOINTS tab, so viewing that will give you the information you need:

image

The public port is what you need (56008) in this case. This port number will vary from VM to VM, though will always redirect to private port 3389 (which is the default port at which Remote Desktop servers listen for Remote Desktop Protocol (RDP) connections).

Configuring Multi-Monitor Support in Remote Desktop Client

With the DNS name and port number in hand, you can construct the correct “Computer” value, such as:

image_thumb[5]

Click “Show Options” and then move to the “Display” tab.

image_thumb[6]

Select the “Use all my monitors for the remote session” option.

Done. Yes, it was that easy.

We’ll close out with a screen shot showing PowerShell and Explorer on one monitor and Visual Studio on the other, all running from a Windows Azure Virtual Machine.

image

Dumping objects one property at a time? A Pretty-Printer for C# objects that’s Good Enough™

Over the years, I’ve written a lot of code that simple dumps out an object’s properties. Sometimes this is for debugging, sometimes it is for output to Console.WriteLine. But a lot of those cases are plain old BORING, and the only reason I end up typing in obj.foo, obj.bar, and obj.gizmo is that I was too lazy to figure out how to easily stringify an entire object at a time – so I kept doing it one property (and sub-property (and sub-sub-property ..)) at a time.

I know that ToString() is supposed to help out (in .NET at least), but you probably noticed how uncommon it is for this to be usefully implemented.

There’s a better way.

A Pretty-Printer for C# objects that’s usually Good Enough™

The simple way to dump objects that’s often good enough (but not always good enough) is to use Json.NET’s object serializer.

Add Json.NET using NuGet, then using a code snippet like the following to dump out an object named someObject :

Console.WriteLine(Newtonsoft.Json.JsonConvert.SerializeObject(
someObject
, Formatting.Indented));

That’s pretty much it. That’s the whole trick.

Note: You can use Formatting.None instead of Formatting.Indented if you want a more compact output (though harder to read).

Here are a couple of reasons why is isn’t always better:

  • You get the WHOLE object graph (no filtering – but see this and this)
  • Fields appear in JSON in the order they appear in the object – you don’t get to change it
  • Not easily massaged (e.g., do you want only a certain number of decimal places?)
  • (Probably more since I just started using this…)

Useful in other languages

This hack applies to any language that supports JSON serializers and formatters. For example, in Python, check out the json module.

Examples in C#

Here is are a couple of examples using a CORS tool I was fiddling with. In these examples, the serviceProperties object is of type ServiceProperties, a class from the Windows Azure Storage SDK for .NET.

Dump Just CORS:
Newtonsoft.Json.JsonConvert.SerializeObject(
serviceProperties.Cors, Formatting.Indented);

"Cors": {
   "CorsRules": [
   {
      "AllowedOrigins": [
      "*"
   ],
   "ExposedHeaders": [
      "*"
   ],
   "AllowedHeaders": [
      "*"
   ],
   "AllowedMethods": 1,
   "MaxAgeInSeconds": 36000
   }
   ]
}

Dump Entire Properties object:

Newtonsoft.Json.JsonConvert.SerializeObject(serviceProperties, Formatting.Indented);

{
   "Logging": {
      "Version": "1.0",
      "LoggingOperations": 0,
      "RetentionDays": null
   },
   "Metrics": {
      "Version": "1.0",
      "MetricsLevel": 0,
      "RetentionDays": null
   },
      "HourMetrics": {
      "Version": "1.0",
      "MetricsLevel": 0,
      "RetentionDays": null
   },
   "Cors": {
      "CorsRules": [
      {
         "AllowedOrigins": [
            "*"
         ],
         "ExposedHeaders": [
            "*"
         ],
         "AllowedHeaders": [
            "*"
         ],
         "AllowedMethods": 1,
         "MaxAgeInSeconds": 36000
      }
      ]
   },
   "MinuteMetrics": {
      "Version": "1.0",
      "MetricsLevel": 0,
      "RetentionDays": null
   },
   "DefaultServiceVersion": null
}

To use another concrete example, consider a simple program that I wrote a while back called DumpAllWindowsCerts.cs. The program just iterates through the Certificate Store on the current machine and dumps out a bunch of information. It uses Console.WriteLine statements to do this.

To compare the old and new outputs, I jumped to the LAST Console.WriteLine statement in the file and changed it to a JsonConvert.SerializeObject statement. Here’s what happened.

Note that the old Console.WriteLine statement was very limited since the contents of these objects varied a lot, so I had kept is simple (I didn’t know what I wanted, really). But the JSON output is pretty reasonable.

————————————————– Console.WriteLine

OID = Key Usage
OID = Basic Constraints [Critical]
OID = Subject Key Identifier
OID = CRL Distribution Points
...

————————————————– JSON.NET

{
   "KeyUsages": 198,
   "Critical": false,
   "Oid": {
      "Value": "2.5.29.15",
      "FriendlyName": "Key Usage"
   },
   "RawData": "AwIBxg=="
}
{
   "CertificateAuthority": true,
   "HasPathLengthConstraint": false,
   "PathLengthConstraint": 0,
   "Critical": true,
   "Oid": {
      "Value": "2.5.29.19",
      "FriendlyName": "Basic Constraints"
   },
   "RawData": "MAMBAf8="
}
{
   "SubjectKeyIdentifier": "DAED6474149C143CABDD99A9BD5B284D8B3CC9D8",
   "Critical": false,
   "Oid": {
      "Value": "2.5.29.14",
      "FriendlyName": "Subject Key Identifier"
   },
   "RawData": "BBTa7WR0FJwUPKvdmam9WyhNizzJ2A=="
}
{
   "Critical": false,
   "Oid": {
      "Value": "2.5.29.31",
      "FriendlyName": "CRL Distribution Points"
   },
   "RawData": "MDkw...9iamVjdC5jcmw="
}

Stupid Azure Trick #2 – How do I create a new Organizational Account on Windows Azure Active Directory without any existing accounts or EA?

Suppose your company is ready to create a corporate production environment using Windows Azure. If you are an enterprise of sufficient size, you will want to do this through your company’s Enterprise Agreement (commonly called an “EA”). But suppose you are a smaller company, or a 100% cloud company, and you want to do it the “right” way – but are not ready for an EA. How do you do it?

Microsoft Account is for Personal Use

First, while technically possible, there are reasons to not create production Windows Azure resources for your organization using a Microsoft Account (née Live Id (and many variants of Passport Account before that – it’s been around!)). The reason to avoid a Microsoft Account is that this is decidedly non-corporate – Microsoft accounts are intended for use by individuals. As a consequence, they are based on arbitrary email addresses and offer no way for an organization to manage them centrally. Even using your company email address as your login for a Microsoft Account is not a sufficiently manageable arrangement since you can continue to log into the associated Microsoft Account even after the email address no longer corresponds to a valid company email account.

Though you can get it done from a technical point of view – your Windows Azure assets can be deployed in production for sure from a Microsoft Account – there is a better way.

WAAD Organizational Account is for Organizations

Windows Azure Active Directory (WAAD) accounts are intended for use by organizations and are known as Organizational Accounts. And an “organization” in the context could be your company, school, non-profit, or any other entity from which centralized management of user accounts is beneficial.

Easily Create an Organizational Account from Windows Azure Portal

In the Windows Azure portal it is pretty easy to create additional Windows Azure Active Directory accounts all day long:

image

But the catch with that approach is that in order to create a new WAAD Organizational Account you need to be already logged into the Windows Azure Portal. So you already need an Azure Account. Though I have many accounts on Windows Azure, I wanted to understand the workflow to create a brand new Windows Azure setup without ever using an existing Windows Azure Account or a Microsoft Id…

In other words, what if I want to start from scratch?

Create Organization Account from Scratch

To create a new Organizational Account without already being logged into the portal, took some searching around and trying a few things, but turns out that one accomplish this by starting at https://account.windowsazure.com/organization.

The flow looks like this:

image

Note that later, once your new WAAD account has been established a few steps from now, you will receive a welcome email at the email you provided on this screen that will look something like this:

image

But back to the sign-up workflow… you will next click “check availability” then:

image

Click “Send text message” then type in the verification code:

image

Click “Verify code” then:

image

Click “continue” then:

image

after spinning you are invited to sign into Windows Azure:

image

After logging in…

image

After that spins a bit then asks you to sign up for the Windows Azure Free Trial:

image

Fill it in:

image

Click “Save” then fill in credit card details (not shown :-):

image

image

Then click “Sign up” to complete the process.

Tada! You are ready to go:

image

Now you can begin…

  • Adding users to your WAAD Organizational Account
  • Provisioning Windows Azure resources to the Subscription owned your Organizational Account

You can also configure your Organizational Account with a custom domain name (such as devpartners.com instead of devp.onmicrosoft.com) if desired.

But those are details for another time.

Office 365 Accounts are WAAD Organizational Accounts

Just so you know, Office 365’s directory service uses WAAD under the hood, and any Office 365 account is also a WAAD Organizational Account.

So most of the steps listed above (the ones associated with creating a WAAD Organizational Account) are not needed. You can create an Office 365 Account for your organization then jump directly to creating a Windows Azure account (or Free Trial).

Useful Links

[This is part of a series of posts on #StupidAzureTricks, explained here.]

Stupid Azure Trick #1 – Rename Your Windows Azure Subscription

As a consultant, I have access to a number of my clients’ Windows Azure Subscriptions. When you have many subscriptions to sort through, it is not very helpful if they have subscription names like Subscription-1 or Free Trial – especially when you have multiple of them by these names!

But fear not, you are not stuck with the name. You can change it to something more useful.

BACKGROUND:  How does a “subscription” fit into Windows Azure? When you log into Windows Azure, you log into an “account” where an account is tied to some login credential. Once logged in, that account can see zero, one, or more subscriptions. A subscription can have cloud resources allocated against it, such as virtual machines and web sites and databases. In the simplest case (e.g., not under an enterprise agreement), the subscription is also the unit of billing, typically tied to a credit card and possibly attached to an MSDN account or free trial.

How to Change the Name of Your Windows Azure Subscription

  1. Navigate to https://manage.windowsazure.com and sign in.
  2. Once signed in, in the top-right corner, click on your account name, and then “View my bill” from the drop-down menu:
    image
  3. This will take you to https://account.windowsazure.com/Subscriptions – and of course you could have navigated here directly, but I wanted to start from the more familiar portal experience.
    image
  4. In this example, the subscription we will rename is currently called “Free Trial” – click on that to bring up the details page specific to that subscription.
    image
  5. Scroll down the page a bit until you see “Edit subscription details” along the right-hand side:
    image
  6. Click on “Edit subscription details” to pop up a page that will allow you to change the subscription name or its service administrator:
    image
  7. Change the name to something more descriptive. Here I change my to “DevPartners Production” which indicates this subscription holds assets for DevPartners (which is my company), and these are Production assets (not Dev, Test, UAT, Play, Disposable, Demo, etc.). Some companies might prefer separate accounts for indvidual applications or teams.
    image
  8. Click the check mark, and you’ll see that your Windows Azure Subscription is now helpfully named:
    image

It only takes seconds to make this change, but think of all the mistakes and misunderstanding it could help prevent.

[This is part of a series of posts on #StupidAzureTricks, explained here.]

 

Stupid Azure Tricks are coming your way

I am writing a series of posts on Stupid Azure Tricks. The name is, of course, tongue-in-cheek, inspired by David Letterman‘s segments on Stupid Pet Tricks and Stupid Human Tricks.

A subtle difference is that Stupid Azure Tricks are actually useful tricks, but perhaps not widely known, sometimes the type of thing you’d only do once in a while (so hard to remember), and occasionally just something that’s interesting or cool (like this one).

The first one will be published tomorrow, the others will follow sporadically (though I’m going to try for once a week on Fridays for the first few). Click here to list the current list of Stupid Azure Tricks.

Talk: Windows Azure Web Sites are PaaS 2.0

Last night I had the chance to speak as part of the Some prefer PaaS over IaaS clouds event at the Boston Cloud Services Meetup. Thanks J Singh for inviting me and I enjoyed speaking with many of the attendees.

Some info:

Also, for those interested, next week I am giving an extended version of this talk where there will be more time (60-75 minutes) – and I promise the demos will not be inhibited by screen resolution problems! This will be at the Boston Azure User Group meeting on Tuesday Jan 21 which will take place at the NERD Center at 1 Memorial Drive in Cambridge, with pizza provided (thanks to Carbonite).