Why is Microsoft Fabric complaining about my Azure AD tenant location?

Microsoft Fabric, announced during Build 2023, is an exciting new capability. In short, it’s a SaaS service that handles all your data and integration needs. It utilizes Microsoft Azure for its capacity.

When you want to provide the capacity for Microsoft Fabric, you can initiate the process from Azure Marketplace through Azure Portal. Once here, you’ll need to select a name and a preferred location for your Microsoft Fabric capacity:

Depending on the region, you might get the following note:

Your tenant’s location is ‘North Europe’. You can now create the resource in a different location using new Microsoft Fabric multi-geo capabilities. Be aware it can have implications on compliance and performance. Learn more

The tenant location, in this case, is set to North Europe (Ireland). However, I’d prefer to provision my Microsoft Fabric to West Europe, which is in the Netherlands. Why is this, and which one should you choose – the preferred location or the exact location where your Azure AD tenant resides?

You can check your current location via the Power BI portal at https://powerbi.microsoft.com. Sign in, and click the question mark in the top-right corner:

Select About Power BI, and you’ll see the exact region for your tenant:

Ideally, you would select North Europe in this case. This becomes evident when we look at the limitations of Microsoft Fabric if your tenant is in a different region from your Fabric capacity. During the preview, there are several limitations:

• Confirm that any movement you initiate between regions follows all corporate and government compliance requirements prior to initiating data transfer.
• Cached data and queries stored in a remote region stays in that region at rest. Additionally, the data at rest is replicated to another region in the same Azure geography for disaster recovery if the Azure geography contains more than one region. Data in transit might go back and forth between multiple geographies.
• The source data might remain in the region from which the data was moved for up to 30 days when moving data from one region to another in a Multi-Geo environment. During that time end users don’t have access to it. It’s removed from this region and destroyed during the 30-day period.
• Query text and query result traffic for imported and DirectQuery data models doesn’t transit through the home region. The report metadata does still come from the home region, and certain DNS routing states might take such traffic out of the region.
• Certain features such as screenshots, data alerts and others will still process data in the home region.
• The detailed dataset metadata that is cached as part of enhanced metadata scanning is always stored in the home region, even if the scanned dataset is located in a remote region.
• The dataflows feature isn’t supported on Multi-GEO at this time.
• It’s possible to create and maintain large-storage format datasets in remote regions to meet data residency requirements. However, you can’t move storage format datasets to another region. Moving large-storage format datasets from the region where they were created results in reports failing to load the dataset. Move the large-storage dataset back to its original region to make it available. If you must move such a model, deploy it as if it was a new model, and then delete the old model from the undesired region.
• Multi-Geo doesn’t support Metrics.

(source: Microsoft)

Consider carefully if these limitations might affect your use of Microsoft Fabric. For example, if you plan on using dataflows as part of your Fabric deployment, you’d be forced to deploy your Microsoft Fabric capacity in the same region as your Azure AD tenant.

In closing, unless you have specific regional or compliance needs, and if your Azure AD tenant is in a suitable location, opt for the same region with Microsoft Fabric.