[wpdm_package id=’781′]


Getting Started (Accounts & Users)

To get started with Azure, we’ll need to set up an account and at least one user.  While it’s likely that we can get through the basic steps of doing so easily enough without much guidance, the accounts, subscriptions and user system for Azure can be quite complicated to set up in a manner that lends itself well to how we’ll ultimately want to use it, so a bit of foresight on how to best approach this can help us to get it right the first time and keep us from having to backtrack later on.

Much as Azure’s service offerings are designed to allow much flexibility depending upon the needs to be met, so does their account infrastructure.  This article will attempt to cover the basics and provide the basis that we can use in two primary approaches: the first to set up our own development shop account, where we can include and manage client Azure services under the umbrella of our own entity, and the second to see how we might walk our clients through the setup of their own accounts, and then including us as developers into their system so that we can provide the services as required.

Accounts, Subscriptions and Services (Resources)

An Azure account is a top level account under which various services and subscriptions reside.  A Subscription can be thought of as a collection of services of which provides a means of billing.  An account can have multiple subscriptions.  Examples of where multiple subscriptions might be used would be a) a development shop with multiple client services, each client being under a separate subscription, or b) large companies who may separate subscriptions based on project or department to better handle the billing as separate entities.

For each Azure account, the subscription is an umbrella for billing various services, though it plays little to no part in the actual development or usage of any services other than billing.  That is, while services will be used under a subscription, we have other means of treating groups of services as correlated entities for development purposes (Resource Groups, which we’ll touch base on later).  Any given instance of any given service cannot be spread among multiple subscriptions.  It’s worth noting here that service implementations such as datacenter location, geo considerations and the like are not relevant to choosing subscriptions: a single subscription can handle the entire array of services and service dependencies, locations, etc.

In database parlance, Azure Account 1:M to Subscriptions 1:M to Services.


Azure Portals

Having loosely defined a few prerequisite terms, let’s now take a look at the different Azure portals, and which is used for what (one might think that there’d be a single portal, or a portal capable of handling everything, but that’s not really the case, which in a way makes sense because billing administrators, for example, have no real need for tapping into the development side of things).

  • Account Portal (https://account.windowsazure.com): This is where you manage the top level account information and subscriptions, billing and related.
    02_000_Account Portal
  • Management Portal (https://manage.windowsazure.com): This is the primary management portal.   While you can manage most (all?) of the services from within this portal, I tend to use it more for Active Directory work, leaving the actual service management to the “Development” portal show below.
  • “Development” Portal (https://portal.azure.com): I put “development” in quotes here because I’m not sure what the actual name of this portal is, but it’s the primary point of use for handling services, and as developers, it’s where we’ll spend most of our time when we need to configure things.

Accounts, Subscriptions and Users Overview

One of the most confusing and generally unclear parts of Azure is trying to understand the user setup.  As previously mentioned, we can work our way through, click the right buttons and wind up with access to Azure easily enough, but that doesn’t really give us an ideal structure to work off, unless we’re only going to have a single person using it at any given time.

A few key points:

  • If you have your own domain for your company, I strongly suggest creating an “azure” email account for that domain (e.g., azure@dymeng.com). While this email account won’t get used much, it’ll help keep things separated and will act as a master account for all of Azure.
  • You *must* have a separate Microsoft account (@live.com, @outlook.com, @hotmail.com) aside from anything else. Azure Subscriptions are required to be linked to a Microsoft account rather than any internal accounts that we might set up on Active Directory.  This seems to be due to the fact that it’s a lot harder to delete a separate Microsoft email account than it is to delete an internal AD user, and deleting the associated account for a Subscription would be a bad thing.
  • If you have your own domain for your company, you can set up internal organizational accounts on Active Directory. For example, I would set up a basic Azure account, I would add a custom domain (more on this later) of dymeng.com, I’d verify it (more on this later), then I could create internal AD accounts such as jleach@dymeng.com, that exist independently of my existing jleach@dymeng.com email, but allow me to sign into the azure portal.
  • You can use Active Directory to link organizational accounts (such as described above), or other external Microsoft accounts.

Subscriptions, Active Directory and Services (and the funky structuring between them)

Let’s stop here for a second to touch base on a point I mentioned briefly in the previous article.  Azure Account/Subscription management, Azure Active Directory (AAD or perhaps just the usual AD) and all of the various services relate to each other in strange ways.  From a billing perspective, Services are “underneath” Subscriptions, but from an Active Directory perspective, you can manage users and services, and also the same users and subscriptions, so there’s some different layers of correlation here.

Here’s a practical example: I might have two subscriptions set up, and one user that we’ll work with.  Subscription “Dymeng” is for my internal stuff and subscription “Client” is for a client project.  User “Jack” is set up in AD, and by default is under the Dymeng subscription, just because that’s what happened due to me creating Dymeng first.  The AD entry for Jack might control permissions/roles for various services under the Dymeng subscription, and it might do the same for the Client subscription.  Additionally, I want the Jack user to be a global admin for the Client subscription.

As you can see, there’s a somewhat loose correlation between Subscriptions, Active Directory and Services… just try to keep that in mind when we work through the rest of this article (fun fun).

Account Setup

Ok, let’s set up the account.  Find one of the “Free Trial” links or whatever to get to the Azure landing page where you can sign up for an account.  I’ll throw this link here for now, but it’s likely subject to change: http://azure.microsoft.com/en-us/pricing/free-trial/

A couple things you’ll need before going too far:

  • A Microsoft email account
  • A “master” email account that you’ll use for Azure (e.g., azure@dymeng.com)
  • A phone (they’ll text you a verification code), and
  • A credit card (even though you’re probably starting on a free trial, they’ll need this as well)

You’ll wind up at this screen, work your way through it.  One point of note is that you’re going to wind up with an “onmicrosoft.com” account here… record that, as you’ll need to later to log in as the master account:

02_001_Account Signup

Ok, so it’s really hard for me to recreate a demo account, and I might have missed a step or two in the mix there, but eventually you’ll wind up at the Azure Management Portal, looking like this:


Assigning our Domain

Scroll to the bottom of the left nav bar area and click Active Directory:


In there, you’ll see one item in the list.  Click the Name of that item to enter the detail screen for it:


You’ll enter the AAD detail area, where you’ll notice some links across the top portion of the page.  We’re going to associate our company’s domain with the Azure account so we can later sign in using our domain emails (e.g., jleach@dymeng.com).  Click the Domains link at in the top navbar portion:

02_005_AAD_Domains - Copy

From there, you’ll see the default .onmicrosoft.com domain that was created as part of the account creation process.  At the bottom of the browser, you’ll see a grey footer bar with an Add button.  Click that button then enter your company’s domain name into the dialog (e.g., dymeng.com), then click the add button in the dialog (leave the “I plan to configure this domain for single sign-on with my…” checkbox unchecked, unless you’re familiar with AD and want to do so).

You’ll see that the domain was added, then click the arrow at the bottom right of the dialog to go to page two.  Here you’ll have the info you need to verify that you own the domain.  This is done by adding a TXT record to your DNS records via your domain registrar (this doesn’t affect anything else related to your domain, the txt record is basically just a miscellaneous key/value pair that MS will look for to verify that you have access to the domain).


This will vary depending on your hosting/registrar provider, but here’s an example anyway (you can usually find these under DNS Records or Zones and will be listed with a number of other DNS records including A, CNAME, MX, NS and a few others):


From here, I’ll usually switch the primary domain in Azure to the company’s domain.  While still in the Active Directory Domains tab, click the Change Primary button/icon in the grey footer bar at the bottom and select your primary accordingly.

Creating a new User

Now that we’ve associated our company’s domain with this Azure Active Directory, we can go ahead and create a user in AD that will use our regular email address to log in.  Still in the AD details view, click the Users tab in the top navbar area, then click Add User from the bottom grey action bar.  This ought to be self explanatory… proceed as required.  Note that the “role” (selection on Page 2) is applicable *only* to the Active Directory end of things, not actual services.  For now you can chose Global Administrator, as this is the account you’ll be using regularly to sign in.

Note that if you were to log out now and try to log in with this new user, you’d get a “subscription not found” error.  Let’s now link this AD user to the subscription…

Enabling the new User on the Subscription

Scroll down in the main (left side) navbar until you see Settings at the very bottom.  Click that to pull up the Settings detail page, then look in the top navbar/tabs for Administrators and click that.  You’ll see the master account listed as a Service Administrator for the subscription.  What we want to do is add another user as a co-administrator (side note: there can be only one service administrator per subscription, but there can be up to 200 co-administrations.  The only difference is that the Co-administrator cannot add new co-administrators).

Click the Add button at the bottom grey footer/action/nav/whatever bar, enter the email address (e.g., jleach@dymeng.com that we just set up for the AD user), check the subscription you want to apply to, then click the check mark (“ok” button…) at the bottom right of the dialog.

NOW you can log in with that user and get to where you need to be.

User Roles & Groups

Ok, I’ll be honest here – I was going to get into a rundown on this, but there’s a lot of information to cover and it’s not really required at this point, so I think I’ll set you off with a few links and touch base on it deeper in a later write up.

One point of note is that you can apply permissions to resource groups and individual resources for users as well as subscriptions, so we’ve got a more granular level of control than what I’ve touched base on above.  (also note that it’s generally a better practice to create a user group, assign permissions to that group, then assign users to that group, rather than assigning permissions directly to users themselves).

Without further ado, your furtherance links:


Bits & Pieces

Here’s a few oddball things to help you along:

  • If you log in with a non-Microsoft account, you’ll only be able to manage one Azure account without having to log out and back in again as an administrator for a different account. For example, if I log in to Dymeng’s Azure account using jleach@dymeng.com, I can only manage Dymeng’s stuff, and not Client A’s stuff (regardless of whether my company account is linked with Microsoft).  However, if you log in with a Microsoft account (Hotmail, outlook, live), and you are set up with that account as a co-administrator for various other Azure accounts, then you can manage other Azure accounts from the Azure portal without having to log out and back in again.From the Azure portal (https://portal.azure.com), click your name at the top right of the home screen and the dropdown will show you other directories (in entirely separate top level Azure accounts) that you’ve been added to.  Now you can click one of these and the portal will be refreshed to show that company’s subscription resources.

    If you expect that you’ll be co-administering a number of separate accounts that clients have set up, it may helpful to start off with a Microsoft based account just to avoid this bit of headache of continual logouts and logins to switch between them.



[contact-form-7 id=”764″ title=”Blog Subscribe”]