Changes to Fabric Tenant Settings for API's

If you are a Fabric Administrator, either for your own tenant / company or for customers, you might get the weekly emails from Microsoft 365 Message center. I've mentioned this briefly in an earlier post about Changes to default values for a tenant setting for SQL Database.

I advice you to at least have a look through that weekly email and check for any Fabric or Power BI updates. An example update you can get is like the below. This screenshot is actually from the Message Center itself, not from the email.

The problem with the M365 Message Center is that only people with privileged roles can access it. And not all updates shown there are communicated in other ways by Microsoft. Sometimes they write a blog post, like this one: Cognitive services and Azure ML will be fully retired, sometimes there's a specific info message in Fabric, or there might be a new tag in the tenant settings, but more often you don't see any other communications around the topic.

So if you are not a Fabric Admin, you probably haven't seen the message I want to inform you about today, so that's why I'm writing this post!

Call To Action

TL;DR

Two new admin toggles are live in the Fabric Tenant Settings, under Developer settings. Check your Tenant Settings and see how they relate to your policies and governance!

Action Required on API Access Setting Split

Microsoft Fabric is changing how service principal access to public APIs is controlled. The existing all-or-nothing tenant setting was split into two separate settings — giving us admins more granular control, but also introducing a change you might need to act on after August 1, 2025.

The previous setting

What Has Changed?

From mid-May to early June 2025, the previous admin setting for public API access via service principals was replaced with:

1. Service principals can create workspaces, connections, and deployment pipelines
   → Governs “global” APIs not tied to specific Fabric permissions (e.g., workspace creation).
   → Disabled by default.

2. Service principals can call Fabric public APIs
   → Governs APIs protected by the Fabric permission model (CRUD access to workspaces, folders, etc).
   → Enabled by default.

The new settings

Why This Matters

This split is a long-needed improvement: previously, disabling API access to protect core resources also blocked developers from using safe, permission-based APIs.

Now, you can lock down the high-risk parts (like workspace creation) without blocking everything else.

But: Microsoft may have enabled the second setting (permission-based API access) by default in your tenant unless you opted out.

Why should I care? You might have service principals running scripts to create workspaces, deploy certain items or manage workspace objects for example.

What You Should Do Now

• Check your Fabric admin portal for the two new settings under Developer Settings

• Before August 1, 2025, you could've shown a checkbox labeled "Accept Microsoft’s change to enable...", and you want to keep permission-based API access disabled, uncheck the box and hit Apply

• Check the values of both settings

Timeline Recap

• May–June 2025: Settings split rolls out

• July 31, 2025: Last day to opt out of automatic enablement

• August 1, 2025: Microsoft finalizes the transition

Conclusion

In case you are running a monitoring solution that keeps a history of Tenant Settings, for example FUAM, you can check the Tenant Settings history and see when the change became active in your tenant. If you don't have such a monitoring solution, I highly recommend checking FUAM out. You can get started with setup and deployment of the solution with a few hours of work.

I spotted this setting shift on telemetry around June 1 in my tenant:

There were some changes in how tenant settings can control access for Service Principals to API's. Make sure to check your settings and adjust them accordingly.

If you want to read more info on the exact workings of the tenant settings, have a look at the Tenant Settings documentation.

Did you already notice these changes and take action?

Let me know in the comments.

Governance & Administration - Fabric (Tenant Settings) API's

With all the Fabric announcements in the last months, some of the Admin announcements might have slipped through. As you might know, the Admin part of Fabric is dear to my heart. I've posted about it earlier here, here, here, and here, to name a few 😀.

So in the next weeks I am going to highlight a few things with short, informative posts.

This first post in the series is focused on the Tenant settings API and other Fabric API's available at the time of writing.

You can find other posts in the series here:

• Tenant Settings: Visual Cues
• Tenant Settings: Searching

Get Tenant Settings API

Obviously, to use the Get Tenant Settings API you need to have at least Tenant.Read.All permissions, or have the Fabric Administrator role (or higher) in Azure.

There are a few use cases I see for getting these settings exported with this API:

• Documentation purposes when you have multiple Fabric Administrators
• Distributing tenant settings to users, and explaining why we (as a team of Administrators/within the Center of Excellence) made certain choices
• Get notified of the changes in the tenant settings, without having to use Microsoft Defender or M365 Security & Compliance center like mentioned here

Get Capacities Tenant Settings Overrides

With the introduction of Fabric, there has also been the ability to have capacity admins override certain tenant settings. 

Example of a tenant setting that can be delegated

Some settings in the Admin portal are automatically delegated to capacity admins, like shown above. 

Other Fabric API's

Next to the API's on the tenant settings, there are already a lot more API's in the Admin section for you to check out, for example to handle workspaces, users, domains, and items as a Fabric Admin.

Next to that, so not as a Fabric Admin, you can also interact with Lakehouse tables, and there's a bunch of Core API's, for example to use Git or OneLake Shortcuts.

Preview note

Please note that at the time of writing this post, most of the API's are still in preview and subject to change.

Except for the Get Tenant Settings API, all the API's are currently in preview:

Refresh a Power BI Dataset with PowerShell and a Service Principal

After Installing the PowerShell Power BI Management cmdlets a few months back, I finally managed to get a dataset refresh working, initiated from PowerShell with a Service Principal. Yeej :-)

Congrats on getting this done! Would you write a blog about this adventure? 🙂

— Chuy Varela (@chuy_varela_) June 12, 2020

But as you can imagine, it didn't go without a fight (or 2, or maybe more), so I thought it would probably be good to share my experiences so you don't fall in the same traps as I did.

Use case

At Van Lanschot Kempen, we are doing daily refreshes of the corporate DWH, connected datamarts and extraction marts after that, all on-premises. Then the Power BI data models are refreshed on a time trigger (say 10 AM) to refresh the data from the datamart to Power BI. We would like that dataset refresh to be event-based. So whenever the datamart is refreshed, immediately refresh the corresponding Power BI dataset.

Setup

To get this working I've used the greatest part of this post How To Trigger A Power BI Dataset Refresh Using An Azure Data Factory Web Activity by Dave Ruijter (blog | @DaveRuijter). Although that's aimed at Azure Data Factory, most of the (setup) steps still apply to my scenario. But as you will see, others don't :-)

Permissions

At my company, I am the Power BI Service Administrator (and Power Platform Admin), so I have sufficient rights in the Power BI Admin Portal, but not in Office 365. So I needed the help of other colleagues who do have these rights.

Make sure that you have the right people aligned, or at least know where to go in case you need anything, before you start.

Steps taken

I'll outline the steps I took here to have a complete list of things I did to accomplish my setup. Again, for detailed explanations per step please visit Dave's blog post:

1. Create a Service Principal and also create a secret with that
2. Create an Azure Active Directory (AAD) group and add the Service Principal from Step 1
3. Enable the tenant setting for Service Principals and add the group from Step 2
   
4. Create a (V2!) Power BI workspace (or use an existing one)
5. Add the Service Principal as an Admin to the workspace
6. Use PowerShell to refresh a dataset

I think Step 6 actually deserves a chapter of its own, while it looks so easy afterwards, I think I struggled with this for more than 20 hours over a few weeks time.

Especially because Dave's setup uses ADF, the authentication to the REST API threw me off. In the end, I "just" had to pass the secret to a PSCredential and use Connect-PowerBIServiceAccount with the Service Principal.

Then the next step is getting an Access token, similar to the setup of using the Power BI REST API as Admin, but now using that header in the Invoke-RestMethod call, as shown below.

You can also get the code from my Github page.

As evidence, I also queried the REST API to show the refresh history :)

Next steps

At this time I do have a working solution, executing the script manually, with my secret in plain text. So there are still a few things to have a look at, which I haven't had the time for yet unfortunately:

• Add the PowerShell script to a SQL Agent Job step, which is the specific use case for me
• Make the solution secure, so don't save sensitive data inside the script or on a server
• One option is to use parameters in SSIS as Brett Powell explains in his post
• I'd like to investigate if I can use the Azure Key Vault from a SQL Agent Job and store the secret there, I'll probably have to authenticate to the Key Vault with the Agent user running the job
• Incorporate the success of the refresh itself into the solution as a step, so I can take action if it fails

Let me know if you have any comments, or know how to improve certain steps of this process :)

Resources

• PowerShell script on my GitHub page
• Dave Ruijter's post: How To Trigger A Power BI Dataset Refresh Using An Azure Data Factory Web Activity
• Brett Powel's post: Refresh Power BI Datasets With PowerShell
  
• Power BI PowerShell commandlets: MicrosoftPowerBIMgmt.Profile
• Power BI REST APIs documentation
  
• Azure Key Vault REST API reference