Just want to fill in a gap in our public documentation. The Account Owner ID (displayed as email address) must be unique across the Azure environment (i.e. unique across the entire public cloud or the entire Azure Government cloud).
This is because subscriptions created by the Account Owner inherit settings like enrollment ID, AD tenant, etc. from the Account Owner. If the Account Owner sits in two enrollments, the subscription won’t know which to inherit from.
When my customers get started with Azure, one of the first things that trips them up is the terminology. This is a quick primer of the terms you’ll encounter as you begin your journey.
The Azure enrollment is an Azure usage agreement often tied to an Microsoft Enterprise Agreement. One enrollment = one bill. Under the enrollment you create Azure accounts, subscriptions, and ultimately resources (VMs, storage, DBs).
A tenant is a instance of Azure Activity Directory (AAD). A tenant is similar to a Windows AD domain. Within the AAD you can have users, groups, etc. Each instance of Azure, O365, Dynamics, etc. requires a tenant. These tenants can be shared or you can use a unique instance for each one.
*each subscription can use a separate tenant*
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant
An Azure subscription is the unit where all resources (VMs, DBs, etc.) reside. The this is the highest level in an enrollment that can incur charges. A subscription is equivalent to an AWS account.
When talking about VM data encryption a lot of customers start looking at Azure Disk Encryption (ADE) and Storage Service Encryption (SSE). These two offerings are similar, but unique. Whether you stick with SSE (always enabled) or add ADE on top is up to you – really it depends on your security needs and design.
Below is my quick breakdown of the pros and cons to help you decide what is the best design for your organization.
SSE (default)
ADE
and thanks for Eric Marks for raising this question!
When you’re getting started with Azure there is so much to learn and so little time! Below is a quick summary of the resources I recommend to my customers as they start ramping.
Update 08/30/2019 – see also https://docs.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit#how-to-maintain-compliance
Hopefully by now you are familiar with the Azure Hybrid [Use] Benefit (https://azure.microsoft.com/en-us/pricing/hybrid-benefit/) which allows you to save ~45% off the list price for Windows VMs, SQL VMs, and Azure SQL in Azure. For those organizations with an Enterprise Agreement that includes Software Assurance this is an easy way save in Azure.
Microsoft doesn’t talk as much about staying compliant – i.e. not using more licenses than your agreement provides.
As the customer, it is your responsibility to stay in legal compliance with your license agreement. While we don’t have a single tool to facilitate this “true up” (after all, the licenses span Azure and your other environments), we do have a high-level process and clear ways to track AHUB usage.
1. Check in Azure to see how many AHUB cores are deployed per https://docs.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit#how-to-maintain-compliance
2. Using your own tools, scan your other environments (on-premises and other clouds) to determine how many licenses are consumed outside Azure
3. Review your agreement and see how many licenses you have paid for
Then simply do the math.
Licenses Paid – licenses used = Licenses remaining
If you used more licenses that you have paid for, you must purchase more licenses or turn off the Hybrid Use Benefit on servers that are in excess of your agreement (see https://www.youtube.com/watch?v=YPv5SpTbzWs&t=23s for instructions).
This is something that will be discussed at enterprise enrollment renewal – but ultimately it is YOUR RESPONSIBILITY to stay in compliance at all times.
When I first meet with new Azure EA customers, one of their first topics is “how do I set this up?” Azure is very flexible, but this means you have design decisions to make:
While there are wrong answers, there is no one right answer. Each organization will need to evaluate their needs, organizational structure, and use case(s) to see what works best for them now. And if things change in the future, this design should change too.
Let’s break down the different control points.
First off, consider if multiple enrollments are needed or if multiple subscriptions within a single enrollment will suffice.
| Subscriptions | Enrollments | |
| Separate Invoice | X | |
| Able to view charges at this level | X | X |
| Can use unique AAD Tenant | X | X |
| Can view charges in EA Portal | X | X |
| Can share an ExpressRoute | X | X |
| Simple to Administer | X | |
Then consider how to further separate resources leveraging subscriptions and resource groups:
| Resource Groups | Subscriptions | |
| RBAC supported | X | X |
| Easy to view Billing | X (in Azure portal only) | X (in EA and Azure portal) |
| Resource can be shared across | X (natively) | Requires additional configuration and only some resources are supported |
| Azure Policy supported | X | X |
| Best for Sandbox | X | |
| Best for restricting access in a common environment (i.e. PROD) | X | |
| Simpler to Administer | X | Multiple subscriptions create administrative overhead |
| Can share a single ExpressRoute | X | X |
Keep in mind subscriptions can be grouped and administered in a hierarchy using Azure Management Groups (https://docs.microsoft.com/en-us/azure/governance/management-groups/). Management groups allow you to set Azure Policy and RBAC centrally for governance with low overhead support.
Finally, in the EA portal itself make sure you are thoughtful in how roles are assigned and controlled.:
That’s my two cents on how to get started, but keep in mind this is a journey. I recommend lots of whiteboard sessions to play with the different options and then test them out again real-world use cases. The best designs appropriately limit access but are easy to implement and maintain.
One of the first things I discuss with new government customers is where they want to deploy – Azure Commercial (aka the public cloud) or Azure Government. Many organizations feel that they should “obviously” be in the government cloud because they are either part of the state, local, or federal government or work closely with those groups.
The fact is Azure Government exists to meet a specific set of guidelines that government agencies often (but not always) must follow (FEDRAMP, DISA IL4, ITAR, etc.). Each organization needs to understand what attestations/certifications/regulations matter to them and chose the LEAST RESTRICTIVE cloud environment that meets those stipulations.
The truth is most “government” organizations in the United States use Azure [commercial] either exclusively or for at least some of their cloud space.
When making your decision:
| Comparison Point | Microsoft Azure Commercial (MAC) | Microsoft Azure Government (MAG) |
| Operational staff | Microsoft screening | Screened US citizens |
| Physical security | Biometrics, isolation, fencing, etc. | Same as MAC |
| Scope of offering | All Azure features | Features limited by certification |
| Portal (ARM) | https://portal.azure.com | https://portal.azure.us |
| Pricing concerns | Base pricing, minus EA/commitment discount (if any) | Base pricing, plus MAG premium, minus EA/commitment discount (if any) |
| Availability | Anyone, on demand | Requires approval from Microsoft |
| Identity (Azure AD) | Integrates Office 365 & 3rd party SaaS | Isolated, no integration |
| Coverage | World Wide | CONUS Only (traffic will not leave US) |
In Azure, the renaming of resources (such as a VM) isn’t allowed. That is, you can rename the OS/FQDN name of the VM at any time, but the display name in Azure is locked in at creation time. If this bugs you, vote up the feature request here: https://feedback.azure.com/forums/216843-virtual-machines/suggestions/6132055-rename-vm
In the meantime, by tweaking a Microsoft provided script we can easily rename a VM by deleting the VM object (keeping all disks, NICs, IPs, etc.) and then recreating the VM using those existing objects. The whole process should take ~10min (although it will vary based on the number of disks and NICs attached).
The below PowerShell script will work as-is for Windows VMs using managed disks and can easily be tweaked to run with Linux VMs or those using storage accounts.
# Nicole Welch, 10 January 2019 # Rename existing Windows VM in Azure Portal (resource name) # Based on https://docs.microsoft.com/en-us/azure/virtual-machines/windows/change-availability-set Add-AzureRmAccount # Set variables $resourceGroup = "Demo" $oldvmName = "myVM" $newvmName = "newVM" # Get the details of the VM to be renamed $originalVM = Get-AzureRmVM ` -ResourceGroupName $resourceGroup ` -Name $oldvmName # Remove the original VM Remove-AzureRmVM -ResourceGroupName $resourceGroup -Name $oldvmName # Create the basic configuration for the replacement VM $newVM = New-AzureRmVMConfig -VMName $newvmName -VMSize $originalVM.HardwareProfile.VmSize Set-AzureRmVMOSDisk -VM $newVM -CreateOption Attach -ManagedDiskId $originalVM.StorageProfile.OsDisk.ManagedDisk.Id -Name $originalVM.StorageProfile.OsDisk.Name -Windows # Add Data Disks foreach ($disk in $originalVM.StorageProfile.DataDisks) { Add-AzureRmVMDataDisk -VM $newVM ` -Name $disk.Name ` -ManagedDiskId $disk.ManagedDisk.Id ` -Caching $disk.Caching ` -Lun $disk.Lun ` -DiskSizeInGB $disk.DiskSizeGB ` -CreateOption Attach } # Add NIC(s) foreach ($nic in $originalVM.NetworkProfile.NetworkInterfaces) { Add-AzureRmVMNetworkInterface ` -VM $newVM ` -Id $nic.Id } # Recreate the VM New-AzureRmVM ` -ResourceGroupName $resourceGroup ` -Location $originalVM.Location ` -VM $newVM ` -DisableBginfoExtension
This week I hit a new oddity while working with a customer. Yes, an Azure customer!
He had setup Express Route (ER) dozens of times before, but this time it just didn’t work! He went thru the VPN gateway setup and when tried to save/create the gateway he got this: Set-AzureVnetConfig : BadRequest: The virtual network xxxxxx has a gateway with connection type ‘Dedicated’, but you are not allowed to use the Express Route feature. Only users who are registered for Express Route can use ‘Dedicated’ gateways. And without a working gateway, there is nothing to connect the ER to your Azure environment.
After a chat with some internal experts, I learned a little known fact: the ability use ER is actually a setting on your subscription! While most subscriptions allow this by default, occasionally this is NOT the case. When that happens, you just need to put in a request for Microsoft to enable that option and you’re good to go!
*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2015/08/azure-express-route-error-setting-up-vpn-gateway/
Recently I had a customer hit an issue that was hard to resolve…..until we stopped looking at the data and reconsidered our design.
The customer installed a relatively small and innocent piece of software, rebooted, and then we entered the BSOD loop — hard to see since it was on a guest in Azure. After working through the night on the Azure aspect and out of ideas, we asked an AD guru to take a look. Within minutes he had figured it out!
Basically our DC is so secure, even we can’t use it! Luckily a DC is easily rebuilt and we all know better than to only have a single DC in the domain, right?
If you want to Bitlocker your DCs, put all those critical DC bits on the C$!
*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/01/bitlocker-and-domain-controller-logical-disks/
Nicole Welch 