Skip to content
github-actions edited this page Oct 5, 2022 · 18 revisions

In this Section


Enterprise-scale FAQ

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

How long does enterprise-scale architecture take to deploy?

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.

Why are there custom policy definitions as part of enterprise-scale reference implementation?

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.

Why does the enterprise-scale reference implementation require permission at tenant root '/' scope?

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:

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.

ARM Templates

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

Bicep

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

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

Next steps

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.

Wiki content

Clone this wiki locally