Archive for June, 2013

Hanu Kommalapati (Microsoft) and I wrote this with tremendous assistance from Jason Roth (Microsoft). It fills a key gap in Microsoft’s documentation story with respect to Azure.

This paper focuses on high availability for applications running in Windows Azure. An overall strategy for high availability also includes the area of disaster recovery (DR). Planning for failures and disasters in the Cloud requires you to recognize the failures quickly and implement a strategy that matches your tolerance for the application’s downtime. Additionally you have to consider the extent of data loss the application can tolerate without adverse business consequences as it is restored.

When we ask customers if they are prepared for temporary and large-scale failures, most say they are. However, before you answer that question for yourself, does your company rehearse these failures? Do you test the recovery of databases to ensure you have the correct processes in place? Chances are probably not. That’s because successful DR starts with lots of planning and architecting to implement these processes. Just like many other non-functional requirements, such as security, disaster recovery rarely gets the up-front analysis and time allocation required. Also, most customers don’t have the budget for geographically distributed datacenters with redundant capacity. Consequently even mission critical applications are frequently excluded from proper DR planning.

Cloud platforms, such as Windows Azure, provide geographically dispersed datacenters around the world. These platforms also provide capabilities that support availability and enable a variety of DR scenarios. Now, every mission critical Cloud application can be given due consideration for disaster proofing of the system. Windows Azure has resiliency and DR built into many of its services. These platform features must be studied carefully and supplemented with application strategies.

The whitepaper outlines the necessary architecture steps to be taken to disaster-proof a Windows Azure deployment so that the larger business continuity process can be implemented. A business continuity plan is a roadmap for continuing operations under adverse conditions. This could be a failure with technology, such as a downed service, or a natural disaster, such as a storm or power outage. Application resiliency for disasters is only a subset of the larger DR process as described in this NIST document: Contingency Planning Guide for Information Technology Systems.

You can find the whitepaper at this MDSN location:


Organizational Identity/Microsoft Accounts and Azure Active Directory – Part 2

In Part 1 of this blog we defined some key terms to help us now move into a deeper discussion of how to best integrate Azure Active Directory (AAD), Organizational Identities (OrgIDs), and Microsoft IDs.  We defined Azure subscriptions and AAD tenants, then discussed the different types of administrative access for each entity.  The goal of integrating all of these entities is to manage your Azure subscription(s) using only organizational accounts (as opposed to Microsoft accounts).

Within Part 2 of this blog we focus on specific use cases to accomplish this integration.  We will look at different use cases related to existing Azure and AAD subscriptions to accomplish this.  Each use case describes how to leverage the use of organizational accounts. To bring your Azure subscription under management of ONLY OrgIDs (no Microsoft accounts) follow the tasks outlined in the “Use Cases” section and then perform the following:

  1. Ensure that an organizational account identity which has co-administrator privileges within Azure can log in to the Azure Portal to manage his organization’s users in the environment.
  2. Remove the Microsoft accounts users from the being co-administrators. This may require a support call to move the Azure Service Subscription to a different co-administrator if the Azure Service administrator is a Microsoft account.  In some cases you can also accomplish this from your subscription management UI.


Scope of Use Cases

The goal of these use cases are to bring your Azure subscription under management of ONLY organizational accounts (no Microsoft accounts).  Items such as synchronization of on premise Active Directory to Azure Active Directory or the use of Active Directory Federation Services (ADFS) for single sign-on (SSO) between your on premise environment and your Azure Portal is outside the scope of this document.

Use Cases

  • Case 1 – No existing AAD or Azure subscriptions
  • Case 2 – Existing AAD tenant / no Azure subscription
  • Case 3 – Existing Azure subscription / no AAD tenant
  • Case 4 – Existing Azure subscription and existing AAD tenant


Case 1 – No Azure or AAD Subscriptions

In this situation there are no existing AAD or Azure subscription so we are starting from the beginning with respect to both of these. Here are two options to get started. Once you accomplish either or one of these you can go to one of the other three use cases.

Case 2 – Existing AAD Tenant / No Azure subscription

Your organization has an AAD tenant (that may be associated with an O365 subscription) but does not yet have an Azure subscription. You would like to sign-up for an Azure subscription and allow a select group of users in the AAD tenant to log on to the Azure Portal using their organizational accounts. Once subscribed to Azure your existing AAD tenant will automatically be accessible in the Azure Portal to a specified set of administrators.

An organization can use their OrgID credentials to login to Azure today and sign-up for their Azure trial subscription.

1. Subscribe to Azure by going to

AAD and ID part 2 pic 1

2. Log on using OrgID credentials by selecting the link circled in the above image and then entering your OrgID user id and password.

3. Select the link that is circled below to sign up for Windows Azure

AAD and ID part 2 pic 2

4. Proceed through the sign-up process for your trial Azure subscription.

Key Point – Your AAD tenant will now be accessible automatically within the Azure Portal.

5. Additionally, you can add the OrgIDs (and Microsoft accounts) of the users you want to be co-administrators of your Azure subscription(s).

AAD and ID part 2 pic 3

6. You may want to use the Azure Portal to register applications and/or add organizational accounts to the AAD tenant.  The account(s) used to perform these tasks will need to have Global Administrator privileges for the AAD tenant.

AAD and ID part 2 pic 4

Note: A co-administrator of the Azure Portal is not by themselves a Global Administrator of the AAD tenant.  To administer the AAD tenant the user needs to be assigned the “Global Administrator” organizational role.

Case 3 – Existing Azure Subscription/ No AAD tenant

Your organization used a Microsoft account to set up their Azure subscription and does not have an AAD tenant. You would like to better manage the identities that administer the Azure subscription(s) via the Azure Portal by instantiating an AAD tenant. Since your organization started their Azure subscription(s) using Microsoft accounts, you can log into Azure Portal using the Microsoft account and get an AAD tenant.

Azure allows one AAD tenant per subscription.  So when you create an AAD here you will enter all the OrgIDs you want to be a part of that AAD.  Once an OrgID is part of an AAD, you can then make it a co-administrator in the Azure portal. You can then use that OrgID (instead of the Microsoft account used to originally create the Azure subscription) to log in to Azure and manage the AAD.  If you want to delete the Microsoft account totally you can change this either by calling Azure support or doing it in account settings.

1. Log into Azure portal with Microsoft ID and click on Active Directory.

AAD and ID part 2 pic 5

2. Add new users to the new AAD tenant. Use the OrgIDs of those users you would like to be co-administrators on your Azure subscription(s) and who are maintained in this new AAD tenant.

Note: You could also add Microsoft accounts to administer the AAD tenant. But the goal of this blog post is to get away from Microsoft account and use solely OrgIDs in the AAD tenant and login process.

3. When adding an Azure co-administrator assure that the correct subscription box is selected and the correct email address is entered.

AAD and ID part 2 pic 8

If you would like integrate this Azure subscription with an AAD tenant created using an organizational account (perhaps in conjunction with O365) see the next case (Case 4).


Case 4 – Existing Azure Subscription / Existing AAD tenant

Your organization has an existing AAD tenant that was perhaps obtained via subscription to O365, Intune, CRM, etc.   Your organization also has an existing Azure subscription, but it was created using a Microsoft account.

You would like a select group of users to use their OrgIDs to access the Azure Portal of the Azure subscription created using a Microsoft account. You also want the users to use their organizational accounts for registering applications and services in AAD.

1. Add the Azure account administrator’s Microsoft account to your AAD tenant.

Key PointBy adding an Azure account administrator to your AAD tenant this enables the Azure subscription to query the AAD tenant.

Hopefully the Azure account administrator is the same person as the Service Administrator. How do you tell if this is the case? You can use the Microsoft account in question and log in here with that account.   If you see the target Azure subscriptions listed you have the proper Microsoft account. If you do not see the target subscription or if you see the image below you do not have the proper account.

AAD and ID part 2 pic 9

2. Log into the Azure portal at using an OrgID from your AAD tenant that has Global Administrator rights.

AAD and ID part 2 pic 10

3. Log in using OrgID credentials by selecting the link circled in the above image and then entering your OrgID user id and password. If the AAD Global administrator does not have an Azure subscription, sign up for a free trial Azure subscription.

Note: This step is required so the AAD Global Administrator can access the AAD management interface. This step will be eliminated in the future.

4. Add the Azure account administrator’s Microsoft account (Live ID) to the AAD tenant. Make sure the user name field matches their Microsoft account.

5. If the Azure account administrator and the Azure Service Administrator are not the same then add the Azure Service administrator’s Microsoft Account to the AAD tenant as well.

6. Once the Azure account/Service administrator of the Azure subscription is in the AAD tenant that account can be used within Azure to add an organizational account from the AAD tenant to be a co-administrator on the Azure subscription.


In Part 2 of this blog we looked at four different combinations of how to use OrgIDs within both AAD and Azure subscriptions.   There are various combinations you may have of existing Azure and AAD subscriptions that need to be handled slightly differently.

User User Experience in Azure Portal
Organizational account, Global   Administrator Sees AAD and can manage it
Organizational account, not Global   Administrator Does not see AAD in Azure portal
Microsoft account, Global Administrator Sees AAD  and   can manage it
Microsoft account, not a member of a   directory Sees UX to create a directory

The key to all this is the Account Administrator (AA) for your Azure subscription.  That is the user that needs to be added to the AAD tenant so that tenant can be queried and is visible in the Azure AAD portal. Once the Account Administrator is part of the AAD tenant the Service Administrator (SA) can add other OrgIDs as Co-Administrators (CAs) to the Azure portal.  The SA and CAs can then add OrgIDs to the AAD tenant in the Azure portal.

Best practices would suggest that the eventual owner of an Azure subscription should be the entity that is assigned/owns the Azure Account/Service Administrator role. For example, if an Azure development or test subscription is created for an organization it is highly recommended that the Azure Service Administrator role be assigned to an organizational account and not a Microsoft account. This will make the management of Co-Administrators within the subscription much easier during the life-cycle of the Azure subscription.  You can also allow administrators from your AAD tenant to administer and manage your organizations users within Azure.

Here are some key links you can use to help you manage all this.

The preferred flow of this process is to obtain an Azure subscription, an AAD tenant, and an organizational account at  The end result of all this is that you can now use your organization’s AAD OrgIDs to log in and manage your Azure subscription and no longer need to use Microsoft IDs.

This is part 1 of a 2 part series on the synergy between O365 Organizational IDs, Microsoft Accounts, and Azure Active Directory. In this first post we lay the groundwork with terms and key points. In the second part we show how to use and leverage these concepts in unison with each other.

A Microsoft account is the new name for what was previously called a “Windows Live ID.” Your Microsoft account is the combination of an email address and a password that you use to sign in to services like Hotmail, Messenger, SkyDrive, Windows Phone, Xbox LIVE, or If you use an email address and password to sign in to these or other Microsoft services, you already have a Microsoft account. Examples of a Microsoft account may be or and can be managed here: Once you log in you can manage your personal account information including security, billing, notifications, etc.


An Organizational Identity (aka OrgID) is a user’s identity stored in Azure Active Directory (AAD). O365 users automatically have an OrgID as AAD is the underlying directory service for O365. An example of an organizational account might be

Why Two Different Identities?

A person’s Microsoft account is used by services generally considered consumer oriented. The user of a Microsoft account is responsible of the management (i.e. password resets) of the account.

A person’s Organizational Identity is managed by their organization in that organization’s AAD tenant. The identities in the AAD tenant be synchronized with the identities maintained in the organization’s on-premise identity store (i.e. on-premise Active Directory).  If an organization subscribes to Office 365, CRM Online, or Intune, user organizational accounts for these services are maintained in AAD.

AAD and ID Pyramids

Tenants and Subscriptions

AAD tenants are cloud-based directory service instances and are only indirectly related to Azure subscriptions through identities. That is identities can belong to an AAD tenant and identities can be co-administrator(s) of Azure subscription. There is no direct relationship between the Azure subscription and the AAD tenant except the fact that they might share user identities. An example of an AAD tenant may be An identity in this AAD tenant the same as a user’s OrgID.

Azure subscriptions are different than AAD tenants. Azure subscriptions have co-administrator(s) whose permissions are not related to permissions in an AAD tenant. An Azure subscription can include a number of Azure services and are managed using the Azure Portal. An AAD tenant can be one of those services managed using the Azure Portal.

Many Types of Administrators

Once you understand the types of accounts, tenants, and subscriptions, it makes sense to discuss the many types of administrators within AAD and Azure.

Admins in AAD

An AAD Global Administrator is an administrator role for an AAD tenant.

  • If integration of duties across Azure and AAD is desired an AAD Global Administrator will require assignment as a co-administrator to an Azure subscription to manage. This allows that Global Admin to manage their Azure subscription as well as the AAD tenant.
  • If the desire is separation of duties those that manage the organization’s production Azure subscription are separate from those that manage the AAD tenant.   Create a new Azure subscription and only add AAD Global Administrators as Azure co-administrators. This will provide an AAD management portal while separating the two different administration functions – Azure production versus AAD production. In the near future the Azure Portal will provide more granular management capabilities eliminating the need for an additional Azure subscription for separation of duties.

Admins in Azure

Depending upon the subscription model there are many types of Admins in Azure.

Azure co-administrator is an administrator role for an Azure subscription(s). An Azure co-administrator will require Global Administrator privileges (granted in their AAD’s organizational account) to manage the AAD tenant as well as the Azure subscription.

Azure Service administrator is a special administrator role for an Azure subscription(s) who is assigned the subscription. This user cannot be removed as an Azure administrator until they are unassigned from the Azure subscription.

Azure account administrator/owner monitors usage and manages billings through the Windows Azure Account Center. A Windows Azure subscription has two aspects:

  1. The Windows Azure account, through which resource usage is reported and services are billed. Each account is identified by a Windows Live ID or corporate email account, and is associated with at least one subscription.
  2. The subscription itself, which governs access to and use of Windows Azure subscribed service. The subscription holder uses the Management Portal to manage services.

The account and the subscription can be managed by the same individual or by different individuals or groups. In a corporate enrollment, an account owner might create multiple subscriptions to give members of the technical staff access to services. Because resource usage within an account billing is reported for each subscription, an organization can use subscriptions to track expenses for projects, departments, regional offices, and so forth. In this scenario, the account owner uses the Windows Live ID associated with the account to log into the Windows Azure Account Center, but does not have access to the Management Portal unless they create a subscription for themselves.

Further information about Azure administrator roles can be found here:

In Part 2 of this post (upcoming) we will examine the different use cases for AAD and Azure with respect to administrative access and the ability to authenticate and provide permissions to your directory and Cloud resources.

Within Azure IaaS exists the often overlooked, yet important, subtleties of Virtual Machine (VM) Disks and Images.  Both of these allow you to generate Azure IaaS VMs using differing strategies.  In this post, I will clear up misunderstandings on the relationship between the two and how they map into the VM and VHD model for Azure.

Creating and Uploading VHDs

Azure VMs use Hyper-V fixed format VHDs.  So if you upload a dynamically formatted VHD it will be converted to fixed format. This may cause an unexpected bloat during the upload and yield a size greater than the 127 GB disk size limit imposed for Azure IaaS VM images. Thus it is recommended that you create a fixed format VHD before you upload it to Azure and don’t rely upon the conversion from dynamic to fixed format during the upload process.  VHDs can be uploaded using a PowerShell cmdlet Add-AzureVhd or using the CSUPLOAD SDK utility.

To generalize the VM Image, you must first run the Sysprep utility and check the Generalize checkbox.  The Sysprep utility sterilizes a VHD by removing system-specific data.  This permits you to use it generically as an image base for more than one VM instances.   So if you run Sysprep on a VHD you can load it as an Azure VM Image.

Note: Make sure that file C:\windows\system32\Sysprep\unattend.xml is removed from the location before you run Sysprep. If you don’t, the VHD may never load successfully into an Azure VM in later steps when you convert the VHD to a VM image.

There are situations when you don’t want to run Sysprep on a VHD since in some cases making that disk generic can render it useless for its desired application. For instance, you may have a Domain Controller on your VHD and executing Sysprep would make it ineffective as a DC. You will also most likely not be creating duplicate VMs from an image of a DC and therefore not need to run Sysprep.  If you don’t Sysprep the VHD can only load as an Azure VM Disk. This serves as a specific base type for a VM. It is not a generic image from which you will be creating multiple generic images.  In summary:

  • VM Disks are sterile images from Sysprep and create generic Azure VMs
  • VM Disks are not sterilized with Sysprep and create unique Azure VMs

Creating Azure VM Images

To create a generic Azure VM Image from a Sysprep’d VHD you will enter the blob URL of the location where you uploaded the VHD.  For a VM Image it is required that you check the box that says “I have run Sysprep on the virtual machine associated with this VHD”.


Using PowerShell you can also create a VM disk from a VHD using Add-AzureVMImage.

Creating Azure VM Disks

To create a unique Azure VM Disk from a VHD you will enter the blob URL of the location you uploaded the VHD. You are not given a Sysprep option since a VM Disk is not generic. It is based upon a specific VHD from which there will probably be only one instance.  Check “The VHD contains an operating system” if this is an OS disk.


Using PowerShell you can also create a VM disk from a VHD using Add-AzureDisk.

Once you have converted the VHDs into either Azure Disks or Images you can create Azure VMs from them.

Creating Azure VMs from Azure VM Image

You can create one or more Azure VMs from an Azure VM Image. Once you create an Azure VM Image (from a VHD) you will see your image(s) by clicking My Images in the Create a Virtual Machine wizard. You select your image just like you would one of the pre-defined Platform Images from the Gallery.


Creating an Azure VM from Azure VM Disk

You can create an Azure VM from an Azure VM Disk. Once you create an Azure VM Disk (from a VHD) you will see you disk(s) by clicking My Disk in the Create a Virtual Machine wizard. You select your disk just like you would one of the pre-defined Platform Images from the Gallery.



Azure VM Best Practices

Here are a few tips when work with Azure VMs and VHDs:

  • Make sure when you attempt to create an image from a VHD that if you have previously done it before you delete the Azure Cloud Service that Azure creates for you when a VM is deleted.
  • Make sure you delete the link between the VHD and a VM by deleting the VM but retain the VHD. You can delete the VHD as well when doing this but you will have to upload the VHD again to blob storage which may take considerable time. Unless you are updating with a new VHD, deleting the VHD with the link is not desirable.
  • Azure will create its temporary drive on the D drive. So if you are uploading a VHD with a logical D drive then D: will be renamed to the E: drive. If you have any logging or application functionality that uses the D drive as a permanent drive you will need to change the logic of your application since there is no way to change the drive letter of the Azure temp drive to anything other than D.
  • If you take a VHD image that contains more than just the C: logical drive (say J: and K: drive as well) when converted to an Azure VM all logical drives will still exist in Azure. But they will be part of the one VHD file at the file system level. In other words, you won’t see one VHD for each logical disk on the volume.
  • Using PowerShell you can also create a VM Image from a VHD using Add-AzureVM.
  • Once a VM is created you can attach additional disks to your VM. It is a best practice for disks that will hold data, such as SQL Server and AD log files, to have them on a permanent drive that is not the main C: drive. The C: drive should be reserved for the OS and application installs. Utilize the other disks for log files and backups.
  • When creating a VM as a part of a VNET, open any firewall ports on the VM to allow traffic in or out.  For instance, you can open port 1433 for SQL Server to communicate with that VM
  • Create the virtual machine inside an affinity group to reduce latency with storage services and any networks of which it may be configured.

Do you agree with these best practices? Are there any that I have missed? Let me know in the comments below.