At some select events (like Boston Azure Firestarter, Boston Azure User Group hands-on meeting, or even Protein Folding with Azure @home), Microsoft sometimes provides tokens for participants who wish to try out Windows Azure for real – by deploying real bits into the cloud – deploying multiple instances of Web Roles and Worker Roles, using Queue for scaling, storing data and blobs in Azure Storage and exercising SQL Azure… Some of the tokens are good for up to 4 weeks – which is awesomely convenient for really kicking the tires on Azure if you are a developer. Which I am… Here is a little guidance on getting your account set up once you have a token in hand.

Note that you will be interacting with the Windows Azure Developer Portal (or Dev Portal for short) to redeem your token and establish your temporary account. The Dev Portal is useful to learn about and get to know.

1. First visit http://windows.azure.com and log in with the provided credentials. Use the provided email address for your Windows Live ID.

(NOTE: If any of the images in this post are too small to read, click on them to see a larger version.)

2. You will see a screen like the following. Note the row with the light blue background; this background color only appears when your mouse is hovering there. Click on the Project Name that matches your token account name.

(Notice that the account owner is “waaccts@microsoft.com” – this is because you are using a Token. Azure supports having an overall account that pays the bills, then sub-accounts for developers. This is an example.)

3.  Now you are in! You can proceed to review some of the help resources lists, or click around on any of the tabs to the left. But to create a new application that you can host on the Azure cloud, you can click on the “New Service” link next to the green “+” sign.

4. After you choose “New Service” you will see the following. Note the two main options in the middle for Storage Account and Hosted Services.

Select Hosted Services to begin. Be sure to click on the words “Hosted Services” as opposed to the “Learn More” link, as they are different.

5. The next page will ask you for a name – this name will only be used to help you identify this service from a list in the developer portal, so don’t spend too much time coming up with the perfect name. You don’t need to provide anything for the Description.

After providing a name, click Next.

6.  Now you are faced with a form where the choices you make actually do matter.  Here’s what’ you’ll need to do:

Type in a “Public Service Name” – this will be the Internet-visible sub-domain from which your deployed application will be visible. For example, if you choose “foo” then your Azure Service will live at http://foo.cloudapp.net after you publish it.

After you settle on a Public Service Name (using Check Availability button as need), you also need to select a Region. Pick the “anywhere” region in your continent (or closest to your continent) such as Anywhere US and click Create.

Here’s what mine looked like before I clicked Create:

Now your Azure Service has been created.

7. You will see a screen inviting you to Deploy a Hosted Service Package. We won’t do that now (though you could if you had an application ready). Instead, we will create an Azure Storage Account. From here:

Click on the “New Service” link which is near the top-left – below the large Windows Azure logo – and you will see the same screen you saw in step 4:

This time select Storage Account and you will see the following:

Give it a name, as I did in screenshot, and click Next.

8. As in step 5, this is also an important choice, though not visible to humans visiting your site. You will need to know this address to program against it. Of course you can look it up in the Dev Portal at any time, but why not choose a logical name. Fill in the fields similar to step 5 – be sure to choose the same Region you chose with step 5 – and click Create.

9. You are now ready to build and deploy Azure applications that use Web Roles, Worker Roles, and various kinds of storage.

You will need the keys shows to programmatically access your storage.

You can always come back and look up the values of these keys, of course. Also, if a key is compromised, you can regenerate it easily, invalidating the prior one. There are two separate keys that can be used/invalidated independently. These keys are specific to this Storage Service you created; you can create more Storage Services with different keys and even use multiple of them together.