FAQ
- How long does enterprise-scale architecture take to deploy?
- Why are there custom policy definitions as part of enterprise-scale architecture?
- Where can I see the policy definitions used by enterprise-scale landing zones reference implementation?
- Why does enterprise-scale architecture require permission at tenant root '/' scope?
- The Azure landing zone accelerator portal-based deployment doesn't display all subscriptions in the drop-down lists?
- Can we use and customize the ARM templates for enterprise-scale architecture and check them into our repository and deploy it from there?
- What if we can't deploy by using the Azure landing zone accelerator portal-based experience, but can deploy via infrastructure-as-code?
- If we already deployed enterprise-scale architecture without using infrastructure-as-code, do we have to delete everything and start again to use infrastructure-as-code?
- The
AzureDiagnosticstable in my Log Analytics Workspace has hit the 500 column limit, what should I do? - What happens if I have existing Management Groups that have the same Name/IDs as ones that will be deployed in the ALZ Portal Accelerator?
- What are the ALZ Portal Accelerator Management Group Name/IDs that are created?
- Why hasn't Azure landing zones migrated to the Azure Monitor Agent yet?
This article answers frequently asked questions relating to Enterprise-scale.
Some FAQ questions that relate more to the architecture are based over in the CAF docs here: Enterprise-scale architecture FAQ
Deployment time depends on the options you select during the implementation experience. It varies from around five minutes to 40 minutes, depending on the options selected.
For example:
- Reference implementation without any networking or connectivity options can take around five minutes to deploy.
- Reference implementation with the hub and spoke networking options, including VPN and ExpressRoute gateways, can take around 40 minutes to deploy.
We work with and learn from our customers and partners. This collaboration helps us evolve and enhance the reference implementations to meet customer and partner requirements. As part of this interaction with customers and partners, we might notice policy definition gaps. In those cases, we create and test a definition to fill the gap and include it in enterprise-scale architecture for everyone to use.
We then work with the Azure Policy and associated engineering teams to continuously transition the new custom policy definitions into built-in policy definitions.
Where can I see the policy definitions used by the enterprise-scale landing zones reference implementation?
You can find a list of policy definitions here: Policies included in enterprise-scale landing zones reference implementations
We also add changes to our What's New? wiki page.
Management group creation, subscription creation, and placing subscriptions into management groups are APIs that operate at the tenant root "/" scope.
To establish the management group hierarchy and create subscriptions and place them into the defined management groups, the initial deployment must be invoked at the tenant root "/" scope. Once you deploy enterprise-scale architecture, you can remove the owner permission from the tenant root "/" scope. The user deploying the enterprise-scale reference implementation is made an owner at the intermediate root management group (for example "Contoso").
For more information about tenant-level deployments in Azure, see Deploy resources to tenant.
The enterprise-scale (also known as the Azure landing zone accelerator) portal-based deployment doesn't display all subscriptions in the drop-down lists?
When you deploy enterprise-scale via the portal-based deployment (also known as the Azure landing zone accelerator), the portal lists subscriptions to be selected for deployment from the platform subscriptions (management, connectivity, identity) and the landing zones (corp and online).
We updated our Subscription selection method in October 2022 to increase the limit from 50 to 1,000. If you have more than 1,000 subscriptions, the API may still not be able to display all of them in the drop-down list. If this causes you a problem, please let us know via the issues.
Can we use and customize the ARM templates for enterprise-scale architecture and check them into our repository and deploy it from there?
All of the ARM templates for enterprise-scale architecture are developed and optimized for the Azure landing zone accelerator portal-based experience. We don't recommend or support customization of these templates because they're complex. To handle all of the options and variations we provide for the Azure landing zone accelerator portal-based experience, ARM template expressions would need numerous logical operators and conditions. ARM deployments (nested templates) need to deploy in a specific order to be successful.
Finally, taking the same templates for future operations requires you to redeploy to the entire tenant for any change, and also requires permanent owner role-based access control assignment on the tenant root "/" scope.
However, if you want to deploy and manage enterprise-scale architecture via infrastructure-as-code, see What if we can't deploy using the Azure landing zone accelerator portal-based experience, but want to deploy via infrastructure-as-code?.
What if we can't deploy by using the Azure landing zone accelerator portal-based experience, but can deploy via infrastructure-as-code?
The following implementation options are available when you use infrastructure-as-code:
- The Azure landing zone accelerator portal-based experience can integrate and bootstrap a CI/CD pipeline using GitHub with AzOps as documented at Deploying Enterprise Scale.
- The Enterprise-scale Do-It-Yourself (DIY) ARM templates method
- The Terraform Module for Cloud Adoption Framework Enterprise-scale
- The Azure Landing Zone (formerly Enterprise-scale) Bicep Modules - Public Preview
If we already deployed enterprise-scale architecture without using infrastructure-as-code, do we have to delete everything and start again to use infrastructure-as-code?
If you used the Azure landing zone accelerator portal-based experience to deploy enterprise-scale architecture into your Azure tenant, see the guidance for the infrastructure-as-code tooling you want to use.
To use ARM templates to deploy, manage, and operate your enterprise-scale deployment, you don't have to delete everything and start again. You can configure and connect AzOps tooling by using the AzOps Accelerator and associated instructions, regardless of the stage of your Azure tenant.
Once configured, AzOps connects to your Azure tenant, scans it, and then pulls individual ARM templates into your repository in a structure that represents the four Azure scopes.
To see a demo of AzOps being used, check out this YouTube video on the Microsoft DevRadio channel: Enterprise-scale landing zones DevOps and automation step by step
The AzOps tooling supports deploying Bicep files at the four Azure scopes. Its pull process only stores the scan of your Azure tenants resources in ARM templates that use JSON.
Leave us feedback via GitHub issues on the AzOps repository if you want to see something added to AzOps.
Terraform builds its own state file to track and configure resources. If you already deployed enterprise-scale architecture to your Azure tenant, import each resource into the state file to learn what it manages as part of your Terraform code. Then you can deploy, manage, and operate your enterprise-scale deployment via Terraform.
Terraform import is currently done on a per resource basis and can be time consuming and complex to do at scale. It's often easier to delete and redeploy via Terraform than to import everything that's been deployed by the Azure landing zone accelerator portal-based experience. Most customers know from the start that they want to use Terraform to manage their Azure tenant, so this scenario is uncommon.
To deploy enterprise-scale architecture by using Terraform, you might want to use the Terraform module we provide. It deploys everything that the Azure landing zone accelerator portal-based experience does. The module, Terraform Module for Cloud Adoption Framework Enterprise-scale, is available from the Terraform Registry page.
To see a demo of Terraform being used, check out this YouTube video on the Microsoft DevRadio channel: Terraform Module for Cloud Adoption Framework Enterprise-scale Walkthrough
The AzureDiagnostics table in my Log Analytics Workspace has hit the 500 column limit, what should I do?
In larger environments that uses a range of different Azure services and associated features it can be common for you to hit the 500 maximum columns in a table limit. When this occurs data is not lost however, it is instead stored in a column called AdditionalFields as a dynamic property.
However, some customers may not want this as it can make it more difficult and complex to query the data when the 500 column limit is breached and data is stored in the AdditionalFields column.
More details on this can be found here: AzureDiagnostics Table Docs
To overcome this issue the Azure Monitor team has created a new collection type for diagnostic settings for resources called Resource-specific collection mode. In this mode a separate table per Azure service is created in the Log Analytics Workspace which will mean the 500 column limit will not be hit and therefore querying and managing the data in the Log Analytics Workspace is simplified and more performant.
An explanation of the 2 modes can be found here: Azure resource logs
As of today only a limited number of services support the Resource-specific collection mode which are listed here.
We are working closely with the relevant Azure engineering teams to ensure the services add support for the Resource-specific collection mode and also create/update the built-in Azure Policies so we can then utilise them as part of our solution.
Stay tuned to our What's New page where we will be announcing when we migrate services to the new collection type. Also watch Azure Updates for announcements from service teams for adding support to their services for this collection type.
What happens if I have existing Management Groups that have the same Name/IDs as ones that will be deployed in the ALZ Portal Accelerator?
As raised in issue #1080 it is possible for you to deploy the ALZ Portal Accelerator in a Microsoft Entra Tenant with existing Management Groups. If these existing Management Groups have the same Name/ID (not Display Name) as the ones deployed as part of the ALZ Portal Accelerator these existing Management Groups will be targeted in the deployment and brought into the ALZ hierarchy and deployment. This means that the Management Groups will be:
- Display Name will be changed to ALZ default for that Management Group
- Moved into the ALZ Management Group hierarchy
- Have Subscriptions placed beneath them based on selections during ALZ portal accelerator deployment
- Have Azure Policy Definitions and Assignments created upon them
- Have Azure RBAC Custom Role Definitions & Assignments created upon them
You should be aware of this and decide if this is something you want to happen, if not you need to ensure the naming prefix entered is unique for the Management Group Name/IDs that the ALZ Portal Accelerator will create to ensure the existing Management Groups are not targeted in the deployment. These are listed in the following FAQ Q&A: What are the ALZ Portal Accelerator Management Group Name/IDs that are created?
The Management Group Names/IDs created via the ALZ Portal Accelerator deployment are all based on the Resource Prefix (Root ID) that you enter in the ALZ Portal Experience on the "Azure core setup" blade that is shown below:
The Management Group Names/IDs created via the ALZ Portal Accelerator Deployment are listed below:
-
<Resource Prefix (Root ID)>- Intermediate Root Management Group - e.g.Contoso-
<Resource Prefix (Root ID)>-platform<Resource Prefix (Root ID)>-management<Resource Prefix (Root ID)>-connectivity<Resource Prefix (Root ID)>-identity
-
<Resource Prefix (Root ID)>-landingzones<Resource Prefix (Root ID)>-online<Resource Prefix (Root ID)>-corp
<Resource Prefix (Root ID)>-decommissioned<Resource Prefix (Root ID)>-sandbox
-
Great question! Don't worry we are aware of this required migration and change to Azure landing zones with the Log Analytics Agent (Microsoft Monitoring Agent - MMA) being retired in August 2024 as detailed here: Migrate to Azure Monitor Agent from Log Analytics agent.
We are working hard internally with the Azure Monitor Product Group (PG) to ensure everything that Azure landing zones requires and gets from the Log Analytics Agent (Microsoft Monitoring Agent - MMA) approach today is covered and has a path for migration to the Azure Monitor Agent (AMA) approach. This has been underway for sometime and continues to progress.
The AMA agent brings a number of new concepts, resources and changes to existing integrations with other services, such as Microsoft Defender for Cloud, that all require validation by each of the associated PGs as well as the Azure landing zone team, prior to migrating to AMA from MMA.
We will, when ready, provide Azure landing zones specific migration guidance that supports existing and to be created PG documentation. We will also make the relevant changes to each of the implementation options (Portal, Bicep, Terraform) to support the migration, especially for greenfield scenarios.
We have an existing GitHub Issue (#1055) opened for this feature request. Please feel free to give it a 👍 or add a comment.
Another good question. You will need to plan, and complete, the migration to the Azure Monitor Agent before the Log Analytics Agent is retired as documented here.
Where do I find more information about the Azure Monitor Baseline Alerts initiative included in the Azure landing zones Portal Accelerator?
Great question! As this is maintained in a repository outside of the Azure landing zones repository please refer to Azure Monitor Baseline Alerts wiki for more details.
There may be circumstances in which deploying services into ALZ are blocked by policy, as an example, managed services that can potentially fail to deploy to ALZ due to being blocked by enforced policies, such as public network access should be disabled for PaaS services or deny network interfaces having a public IP associated. When a service is deployed to ALZ, be mindful of default ALZ Policies and understand which policy is being violated. If the service such a Service Fabric Managed Cluster fails due to security reasons, you can follow several workarounds:
- create an exclusion where you can exclude a specific scope of resources to be excluded from the policy assignment
- create a temporary policy exemption where you can exclude a specific scope of resources to be excluded from the policy assignment for the duration of deployment (recommended)
Azure Policy exemptions are used to exempt a resource hierarchy or an individual resource from evaluation of a definition. Resources that are exempt count toward overall compliance but can't be evaluated or have a temporary waiver. If you want to monitor a resource that is non-compliant by design, you may use an exemption. If you do not want to monitor a resource by a default policy, you may use an exception.