Important: Azure Government PowerShell change

A change was recently made to the Login-AzureRmAccount PowerShell cmdlet which may break existing scripts. 

For older versions of Azure PowerShell you would use the following to log into Azure US Government:

Login-AzureRmAccount –EnvironmentName AzureUSGovernment

With the new version of Azure PowerShell you will instead use:

Login-AzureRmAccount –Environment AzureUSGovernment

It is a simple change but you need to be aware of it in case you upgrade your Azure PowerShell and notice your scripts are no longer working.

Best practices for hosting Active Directory Domain Controllers in Azure

Recently I was having a discussion with another Cloud Solutions Architect about hosting domain controllers in Azure and how to protect them.  I thought I would post some of the best practices that we discussed:

  • Review the guide for hosting Active Directory domain controllers in Azure.
  • Use a dedicated Azure storage account for Active Directory domain controller disks. 
  • Ensure that the storage container for the domain controller’s OS and data disks is set to private access type (this is the default for new containers).
  • Use role based access control (RBAC) to limit who has access to manage the storage account and access keys.
  • Enable Azure Disk Encryption with key encryption key (KEK) for both the operating system and data disks.   This will utilize Azure Key Vault for storing the keys.   The Key Vault must reside in the same Azure region and subscription as the virtual machine.
  • Use RBAC to limit who has access to manage the Key Vault.
  • Keep domain controllers in their own virtual network subnet.
  • Implement an incoming deny all network security group rule on the domain controller subnet and then configure only the required ports for the domain controllers.
  • Set a static IP for the domain controller using PowerShell or the Azure Management Portal.  Never set a static IP address directly in the operating system.  You must always set the operating system to use DHCP.
  • Do not set public IP addresses on domain controllers.

Deploying domain controllers in Azure is an important step for providing an organization with resilient identity.  By taking precautions like you would on-premises you can have a safe and secure cloud environment.  The best practices listed above are not an exhaustive list of all configurations and settings that you should implement in order to have a secure domain controller environment in the cloud.  Please review all of the documentation and apply your own security requirements and standards to your cloud deployment.

Networking to and within the Azure Cloud

Microsoft’s Olivier Martin recently wrote a three part series called Networking to and within the Azure Cloud.  This is an excellent primer on understanding the options you have as an organization to connect different virtual networks and regions together using VPN or ExpressRoute connections.  I highly recommend checking this out even if you feel you have a solid understanding of networking in Microsoft Azure.

Part 1: Hybrid networking connectivity options
Part 2: Intra-cloud connectivity options
Part 3: Putting all these concepts together

Virtual Azure Gov Discovery Day

Put the cloud to work for you. Join us as we explore how your agency can achieve more while helping stay compliant and secure with Microsoft Azure Government. You’ll hear from industry leaders, analysts, and experts over the course of eight sessions designed to help you modernize your agency and kick off your digital transformation.

Don’t miss the Virtual Azure Gov Discovery Day on April 25th at 12:00 PM ET/9:00 PT.

Automating ARM Policies

In a previous post I discussed using Azure Resource Manager Policies for enhancing governance.  I mentioned that I had put together a simple Azure Automation demonstration that automatically applies policies to resource groups within a subscription.  I have made this sample PowerShell script available for download to demonstrate one possible option for applying ARM policies.  This is a demonstration script only and has not been fully reviewed for production use.  Use at your own risk.

This script is designed to be executed by Azure Automation on a scheduled basis.  It utilizes an AzureRunAsConnection that has been configured with ownership permissions over the subscription.  You will need to use the New-AzureRmRoleAssignment cmdlet to assign ownership permissions to the AzureRunAsConnection account.  The contributor role cannot  apply policies.

To use this script you need to setup an Azure Storage account which will hold the ARM JSON policy templates.  The storage account needs to provide anonymous access to the policy files.  Policies should be placed inside of a container named according to the resource group where the policies should be applied. For example, if you have a resource group named myRG you would create a container in the storage account called myrg and place all of the policies which should be assigned to the resource group in that container.

Inside of the script there are variables that need to be set for the AzureRunAsConnection name, subscription ID, storage account name, and storage account key.

Once the storage account is setup, script updated and Azure Automation configured the policies will be automatically applied on a scheduled basis.  This enables the addition, removal or change of policies by only making changes to the files in the storage account.  No additional steps are required.

vnet peering demo

Recently a new feature was released in the Azure US Government regions that enables the peering of multiple virtual networks within a region.  This features replaces the need to use site to site VPNs between virtual networks which are hosted in the same Azure region.  To explain a bit more about VNet peering, and to provide a demo, I have created this short 6 minute video.

For more information on VNet peering, please review the Azure documentation.

Azure Resource Manager Policies

Organizations that choose to utilize cloud computing can find that they are able to be more agile and deliver more services quicker.  Microsoft Azure can provide virtually unlimited access to compute, networking, storage and platform services which can be provisioned in a very short timeframe.   Many organizations find that it is often faster and cheaper to utilize cloud services than to go through a long hardware procurement cycle.  Unfortunately many organizations are not prepared for this new way of working.  Frequently I see organizations adopt cloud computing only to find that their outdated policies and procedures become the reason for slow cloud adoption.

How can IT organizations become a better enabler of agile cloud solution delivery?  One way is to provide a self-service model to agencies and departments where they can request and receive access to cloud resources in minutes instead of days.  Microsoft has many partners that offer comprehensive (and sometimes customized) solutions to enable self service of both Microsoft Azure and on-premises resources.  But what if you are just getting started?  Microsoft Azure provides many options in the management portal such as role based access control (RBAC) and Azure Resource Manager Policies which can help an organization enforce basic governance rules while enabling users from departments and agencies to create cloud resources.   In this post, I will be providing some insight into the often overlooked Azure Resource Manager Policies.

Azure Resource Manager Policies enables Azure subscription administrators the ability to attach specific governance policies to the subscription or to specific resource groups in a subscription.   With RBAC you are assigning roles which allow them to perform specific actions at different scopes within Azure.  For example an RBAC role may allow a user to create resources in a resource group but they cannot manage permissions for that resource group.   Policies, on the other hand, focuses on resource actions at a specific scope.   For example, a policy may require that resources created in a specific resource group can be only created in a specific region.  Other common policy scenarios include:

  • Requiring a CostCenter tag for each resource that is created, or automatically appending a CostCenter tag when a resource is created
  • Only allow a user to create resources from a predefined service catalog
  • Only allow the creation of storage accounts configured for  geographically redundant storage
  • Require that all storage accounts are configured for at rest encryption

Azure Resource Manager Policies are defined using JavaScript Object Notation (JSON).   These policy definitions include one or more conditions or logical operators that define the actions, and an effect that describes what happens when the condition is fulfilled.  Below is a sample policy definition that will deny the creation of a resource unless it has a costCenter tag defined.

"not" : {
     "field" : "tags",
     "containsKey" : "costCenter"
    "then" : {
      "effect" : "deny"

To create the policy definition in Azure you can use the New-AzureRMPolicyDefinition PowerShell cmdlet and pass in either the raw JSON or you can specify a local file that contains the JSON definition.   Once the policy definition has been added to Azure you can use the New-AzureRMPolicyAssignment cmdlet to assign the policy to a specific scope such as the subscription or a resource group.   For an in-depth look at how to create and assign policies, please review the Azure documentation article titled Use Policy to Manage Resources and Control Access.

Creating and deploying Azure Resource Manager Policies is quick and simple, but what happens when you need to manage a large number of polices which might be unique to different resource groups?   How can you ensure that the official policies are always in place and not drifting from the desired state?   The answers to both of these questions is automation.  

One option for automation and management is to use Visual Studio and Visual Studio Online to maintain all of your JSON police files under source control.  You can then utilize the build features of Visual Studio Online to move the JSON policy definition files into an Azure Storage account when a change has been checked in.  Once these files are in a storage account you can utilize PowerShell in Azure Automation runbooks to clear out existing policy assignments and then apply the updated policies.

I recently put together a simple Azure Automation demonstration that automatically applies policies to resource groups in my subscription.   This all starts with an Azure Storage account which is used only for my JSON policy files.   In the storage account I create containers which will hold the actual JSON policy files.  These containers are named exactly the same as the resource group where the policies should apply.    Once I have the storage account and containers in place I uploaded my JSON policy definition files to the appropriate containers.  The final step is to create an Azure Automation runbook that uses PowerShell to read the JSON definitions from each container and apply them to the related Azure Resource Group.   All of this took less than 2 hours to build from scratch.   Once I had everything in place and tested, I setup a recurring schedule to execute the runbook on an hourly basis.   This simple configuration allows me to easily add or remove policies to specific resource groups just by adding or removing JSON files from the containers in the storage account.  

By utilizing the built in RBAC and Policy features in Microsoft Azure you can quickly establish some basic governance which can enable you to empower more people within your organization to use Azure while still maintaining your standards.

Azure Resource Tagging for Charge-Back

Resource tagging in Microsoft Azure is a feature introduced with Azure Resource Manager (ARM).  Resource tagging enables you to attach multiple key/value pairs to resources for categorization and management.

In Microsoft Azure you can place tags on individual ARM based resources or you can place tags on the resource group level.   You cannot place tags on resources created under the Azure Service Manager (ASM / classic) model.

Tags are commonly used for charge-back purposes in large organizations.   In these cases, resources are tagged with a cost center or some other identifier that would relate the resource back to the entity which should be charged for the usage of the resource.    These tags will then show up in the enterprise Azure usage report.

Although there is a resource group field in the usage report, not all of the resource types return the resource group name to the Azure usage reporting system.   This means that you cannot rely on the resource group name field in the usage report as a way to monitor usage for all resources in that group.

When working with tagging it is import to remember:

  • You can only tag resources created through the Azure Resource Manager (ARM).  Classic resources created through Azure Service Manager (ASM) cannot be tagged.
  • If you place tags at the resource group level, those tags will not be automatically placed on all resources within that group.   There is no tag inheritance, however, you can use a scheduled PowerShell task to copy tags from the resource group to all ARM based resources in that group.
  • The Azure usage report does have a field for Resource Group Name.  It may be tempting to use a resource group name as a way to identify resources for charge-back.   This will not work because not all resources output their resource group to the Azure usage report.

Below are a few additional resources which I find valuable when working with resource tagging:

Azure Resource Tagging Best Practices
Using tags to organize your Azure resources – Tags and billing
Using Resource Groups and Tagging in Azure Government

Technology Blog