Azure EA Portal – Account Owner must be Unique

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.

Explained: Azure Enrollments, Tenants, and Subscriptions

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.

Azure Enrollment

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).

https://docs.azure.cn/en-us/articles/azure-global-purchasing-guidance/go-global-playbook-purchase-process-of-enterprise-azure

Azure Tenant

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

Azure Subscription

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.

image

see also https://docs.microsoft.com/en-us/office365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings

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)

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/

Moving Azure Images from the Commercial to the Azure Government Cloud (MAG)

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2016/04/moving-azure-provider-images-from-the-commercial-to-azure-government-cloud-mag/

Some times we see customers move Microsoft provided images from the Azure commercial cloud to the Azure Government (MAG) cloud.  While this is technically supported, there are several things to consider.  When using the Microsoft provided images, there are configuration settings that are specific to the cloud environment.  When you move the VM (by moving the VHD), you risk having the wrong settings for your new cloud location.

Below is a list of settings that need to be changed.  This is NOT comprehensive and will be updated as needed.  Keeping mind the various endpoint that are different as well (https://azure.microsoft.com/en-us/documentation/articles/azure-government-developer-guide/)

Commercial Value MAG Value
KMS kms.core.windows.net:1688 kms.core.usgovcloudapi.net:1688

OMS – Azure Activity Logs Solution – Access to the Subscription was Lost

Error

Seen in the Azure Activity Logs solution view.

Detail: Access to the subscription was lost. Ensure that the XXX subscription is in the XXX Azure Active Directory tenant. If the subscription is transferred to another tenant, there is no impact to the services, but information for the tenant could take up to an hour to propagate.
SourceSystem: OpsManager
SoureComputerID: all zeros
OperationStatus = Failed
OperationCategroy = Azure Activity Log Collection
Solution: AzureActivity

 

Possible Causes

  1. OMS is attempting to reach a subscription that has been deleted or is expired
  2. The AAD tenant associated with the subscription has changed

 

Solution

Method 1:

Disconnect the “problem” subscription from the Azure Activity Logs via the Azure ARM Portal.

  1. Open the ARM Portal
  2. Go to Log Analytics -> [your workspace] -> Azure Activity Logs (under Workspace Data Sources)
  3. From the listing of subscriptions, select the one you wish to disconnect
  4. In the new blade, click “Disconnect” from the blade header

Method 2:

Remove the OMS Azure Activity Logs solution (also known as Activity Log Analytics) either via the OMS portal or the Azure ARM Portal.  Then re-add the solution to your workspace.

Notes:

  • do NOT delete Log Analytics from the ARM portal.  This is NOT a solution and will delete your OMS workspace
  • Removing the Azure Activity Logs solution will NOT delete existing data.  Once you re-add the solution all events will reappear

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2017/03/oms-azure-activity-log-error-access-to-the-subscription-was-lost/

Using OMS to Alert on Azure Service Outages

If you are unable to alert from the Azure Portal, or simple wish to have all your alerting from one source, consider leveraging OMS (Operations Management Suite).  With the free tier option (7 days of day retained) there is no additional cost!

Azure Service events are logged automatically in the Azure Portal –> Monitoring –> Activity Log (only incidents believed to impact your subscription(s) will be listed).  This article will show you how to use OMS to review and alert on these events.

image

 

Setup OMS (if you do not already have an OMS workspace)

1. Create a new workspace – https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-get-started#2-create-a-workspace

  • select the free pricing tier unless you have further plans for OMS

 

Configure OMS to Pull the Azure Activity Logs

1. Add the Activity Logs Analytics solution – https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-get-started#3-add-solutions-and-solution-offerings (only steps 1-4 are required)

 

Setup Alerting

1. Open the OMS portal (URL varies based on your cloud)

2. Click on Log Search

3. In the query window, enter: Type=AzureActivity Category=ServiceHealth

    • This will looks for alerts from the Azure Activity logs of type Service Health.  This is how Azure Service outages are categorized in the Azure Activity Logs
    • it is OK if no results are returned.  That just means there were no Azure Service Incidents that impacted your subscription the time range.

image

4. Click Alert in the top left

5.Configure the alerting options (see https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-alerts-creating#create-an-alert-rule for more details)

image

*The alert looks every 15min (alert frequency) for events matching the query that were raised in the past 15min (time window).  If there are more than 0 found (number of results), then an email is sent to all recipients listed.  These emails do NOT need to be associated with an Azure logon, etc.  Any publically routable email address will work.

Your recipients will now receive an email for Azure Service incidents.  It will look something like this:

image

*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2017/03/using-oms-to-alert-on-azure-service-outages/