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*
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.
see also https://docs.microsoft.com/en-us/office365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings
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:
- 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
- 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/
- Take a look at the list of services you need versus those available at https://azure.microsoft.com/en-us/global-infrastructure/services/
- Take a look at the table below for the quick and dirty overview of both environments.
||Microsoft Azure Commercial (MAC)
||Microsoft Azure Government (MAG)
||Screened US citizens
||Biometrics, isolation, fencing, etc.
||Same as MAC
|Scope of offering
||All Azure features
||Features limited by certification
||Base pricing, minus EA/commitment discount (if any)
||Base pricing, plus MAG premium, minus EA/commitment discount (if any)
||Anyone, on demand
||Requires approval from Microsoft
|Identity (Azure AD)
||Integrates Office 365 & 3rd party SaaS
||Isolated, no integration
||CONUS Only (traffic will not leave US)
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
- Virtual DC (Hyper-V guest running in Azure, but the location and virtualization doesn’t matter!)
- C$ OS, E$ Sysvol/NTDS
- Bitlocker enabled for all drives
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?
- 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
- Once the OS is unencrypted, Bitlocker frantically tries to unlock any data drives…..
- 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$…..)
- 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.
- 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?
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/
*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/)
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.
SoureComputerID: all zeros
OperationStatus = Failed
OperationCategroy = Azure Activity Log Collection
- OMS is attempting to reach a subscription that has been deleted or is expired
- The AAD tenant associated with the subscription has changed
Disconnect the “problem” subscription from the Azure Activity Logs via the Azure ARM Portal.
- Open the ARM Portal
- Go to Log Analytics -> [your workspace] -> Azure Activity Logs (under Workspace Data Sources)
- From the listing of subscriptions, select the one you wish to disconnect
- In the new blade, click “Disconnect” from the blade header
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.
- 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/
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.
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)
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.
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)
*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:
*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2017/03/using-oms-to-alert-on-azure-service-outages/
Below are the quick and dirty details you need to connect your Windows servers to OMS hosted in Microsoft Azure Government (MAG). Any server with internet access can report to an OMS workspace (including but not limited to servers located on-premises, in the Azure Commercial cloud, hosted by other cloud providers, etc.).
- Azure Extension – Note: Azure VMs only, VM must be in the same subscription as the OMS Workspace. In portal.azure.us goto Log Analytics –> Your Workspace –> Workspace Data Sources –> Virtual Machines –> Connect the desired VM (click on the VM, in the new blade click connect). The extension installs the full OMS agent on your VM. For details see https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-azure-vm-extension
- OMS Agent (MSI) – the MSI can be installed interactively or via command line. Download the agent from the OMS Portal (settings –> connected sources –> Windows Servers). For full details, see https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-windows-agents#download-the-agent-setup-file-from-oms
- If installing the agent interactively, be sure you specify the cloud as Azure Government
- If installing the agent via the command line, you’ll need to use the “OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=1 parameter to point to Azure Government. For example:
- run: extract MMASetup-AMD64.exe
- then run: setup.exe /qn ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=1 OPINSIGHTS_WORKSPACE_ID=yourid OPINSIGHTS_WORKSPACE_KEY=yourkey AcceptEndUserLicenseAgreement=1
Adding an OMS Workspace to an Existing Installation
To update an existing OMS or SCOM agent to point to a new/additional OMS workspace you can either manually configure the new workspace via the GUI or leverage PowerShell.
1. Interactively via the GUI, see https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-windows-agents#configure-an-agent-manually-or-add-additional-workspaces
2. Programmatically via PowerShell. Note: the 1 at the end of the AddCloudWorkspace cmdlet indicates the workspace is in Azure Government.
$mma = New-Object -ComObject ‘AgentConfigManager.MgmtSvcCfg’
$mma.AddCloudWorkspace($workspaceId, $workspaceKey, 1)
*previously posted at https://blogs.msdn.microsoft.com/nicole_welch/2017/05/the-oms-agent-for-azure-government-a-cheat-sheet/