Free Azure Training Resources

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.

Azure Hybrid Use Benefit – Staying Compliant

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.

Azure Design Considerations–Enrollments, Subscriptions, and Resource Groups

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:

  • how many enrollments do I need?
  • should I use departments?
  • should I separate teams using subscriptions or resource groups?
  • where do I apply RBAC (define access)?

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.

image

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.

image

Finally, in the EA portal itself make sure you are thoughtful in how roles are assigned and controlled.:

image

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.

Choosing the right Azure Environment – Should I use the Public or the Government Cloud?

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:

  1. Take time to see which environments meet your needs.  Many people are surprised at how robust the Azure [commercial] compliance space is.  https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings
  2. Take our 1.5hr FREE online class that goes into greater detail on what Azure Government is and is not.  https://docs.microsoft.com/en-us/learn/modules/intro-to-azure-government/
  3. Take a look at the list of services you need versus those available at https://azure.microsoft.com/en-us/global-infrastructure/services/
  4. Take a look at the table below for the quick and dirty overview of both environments.
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)

Renaming an Azure Windows VM (Managed Disks)

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

Express Route: Error Setting up VPN Gateway

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/

Bitlocker and Domain Controller Logical Disks

Recently I had a customer hit an issue that was hard to resolve…..until we stopped looking at the data and reconsidered our design.

What We Had

  1. Virtual DC (Hyper-V guest running in Azure, but the location and virtualization doesn’t matter!)
  2. C$ OS, E$ Sysvol/NTDS
  3. Bitlocker enabled for all drives

What Happened

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!

So what was going on?

  1. When the VM boots up, it tries to unencrypts the OS drive first. This OS disk key is stored in AD (accessible on another DC) or in 3rd party tool, like CloudLink
  2. Once the OS is unencrypted, Bitlocker frantically tries to unlock any data drives…..
  3. Meanwhile AD services are starting up (among the first services), but they can’t get to the AD database (it’s sitting on that locked E$…..)
  4. AD determines it can’t get to it’s database, crashes, throws the BSOD (with a nice pause so you can frantically try to write down the error message), and then reboots the server.
  5. The cycle repeats….

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?

Lesson Learned

If you want to Bitlocker your DCs, put all those critical DC bits on the C$!

A big thanks to John Bay, our AD guru!

 

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/01/bitlocker-and-domain-controller-logical-disks/