Think Twice Before Enabling Fabric’s Inbound Network Protection

Fabric’s inbound network protection gives you two tenant-level controls: Private Link, which routes traffic through your virtual network instead of the public internet, and Block Public Internet Access, which closes the public internet off entirely once Private Link is in place. Together they look like the obvious move if you’re trying to get a data platform off the public internet. Flip two settings, close off the internet, ship a more secure platform. That’s the pitch.

Diagram of Fabric tenant-level inbound network protection. A client connects two ways: over the public internet, which is blocked once Block Public Internet Access is enabled, or through a customer virtual network with a private endpoint, across the Microsoft private network backbone, into the Fabric tenant. The tenant box lists items that generally support Private Link, such as OneLake, Warehouse, Pipelines, Power BI, and Eventhouse — support varies by specific feature and operation within each, not uniformly across the item.

As of July 2026, it isn’t that simple. Enabling them changes how a specific, and fairly long, list of Fabric features behaves. Some keep working but in a degraded state; others stop working entirely. None of it is undocumented. It’s just spread across a dozen different Microsoft Learn pages, and almost nobody reads all of them before changing a tenant setting. Here’s what stands out on that list.

The ones that redesign your architecture

I’d flag on-premises data gateways first. Turn on Private Link, and you can no longer register a new gateway or migrate, restore, or take over an existing one. Every Fabric item that leans on an on-premises gateway is exposed to that: Dataflow Gen2, pipelines, semantic model data sources, mirroring. A virtual network data gateway is the only supported replacement, and if your organization has gateway infrastructure built around the on-premises gateway, moving it to a VNet data gateway is its own migration project.

Mirroring has an extra problem on top of that. A virtual network data gateway looks like it should fix this one, and it doesn’t. If you’re mirroring a SQL Server 2016 through 2022 database into Fabric, whether it’s on-premises, on an Azure VM, or on another cloud, that mirroring uses Change Data Capture under the hood, not the change feed mechanism SQL Server 2025 uses. Microsoft’s Private Link exception list for mirroring is short: open mirroring, Azure Cosmos DB, Azure SQL Managed Instance, SAP, SharePoint List, and SQL Server 2025 mirroring specifically. CDC-based mirroring for 2016–2022 isn’t on it. Turn on Block Public Internet Access, and active mirrors for those databases pause while new ones can’t be started.

That gateway solves connectivity to the source, which is a different problem from the one Block Public Internet Access creates. The restriction isn’t about whether Fabric can reach your database. It’s about which mirroring mechanism Microsoft has explicitly cleared for Private Link, and CDC-based mirroring isn’t one of them.

The realistic options are migrating the affected databases to SQL Server 2025, where native mirroring is on the supported list; switching to open mirroring, which means writing and maintaining your own publisher that pushes data into the OneLake landing zone; or dropping mirroring for those databases entirely and building the ingestion yourself with a pipeline or a notebook pulling from the source on a schedule. None of these is a small decision, and none is one you want to be making after the setting is already flipped and mirrors have already paused.

There’s more that forces a rethink. If any part of your build leans on a Fabric Data Warehouse, know that a pipeline’s Copy Data activity can’t move data into or out of it at all under Private Link.

Eventhouse loses even more ground: it can’t ingest from OneLake, can’t be the target of a shortcut, can’t be connected to a pipeline, and loses both queued ingestion and T-SQL support. If real-time analytics is part of the plan, Private Link takes most of Eventhouse’s usefulness with it, which usually means designing around it from the start rather than bolting it on later.

Purview is affected too. Data Map scanning of Fabric is unsupported over Private Link, so if Purview is how you catalog and govern this data, that scanning simply stops. The OneLake Catalog’s Govern tab, Fabric’s own governance surface, stops working as well. Separately, Purview Information Protection also breaks in Power BI Desktop: sensitivity labels stop resolving, the Sensitivity button grays out, and pbix decryption fails. That last one only matters if the label is tied to a Purview publishing policy that encrypts the file. When that’s the case, Desktop has to call out to the rights management service to decrypt the file before it’ll open at all, and without that call, it just won’t open. Sensitivity labeling in Desktop depends on Exchange Online Protection and Azure Information Protection behind the scenes, so opening service tags for those two services restores label resolution and pbix decryption there. It’s a client-side network exception, though, not Fabric itself gaining Private Link support for Purview Information Protection. If you’re actually relying on Purview to govern this data, neither of these is a detail to find out about after go-live.

If you were planning on using cross-tenant OneLake shortcuts to collaborate with vendors, partners, or customers, those are not supported over Private Link.

The capabilities you lose

Below that tier, but still enough to change what you can build, is a set of items where the setting doesn’t just reroute traffic, it removes product functionality outright.

The first Spark job or Lakehouse table operation you run provisions a managed VNet for the workspace it runs in, which disables the prewarmed starter pools Fabric normally uses to get notebooks running fast. That managed VNet allocation is permanent, so once it happens, you lose the ability to migrate the workspace to a capacity in a different region.

Email subscriptions for Power BI reports fail across every subscription type. The paginated report side of that is the one to take seriously. People often choose paginated reports over interactive ones for exactly this reason. They’re built for pixel-perfect print and PDF output. They also export to Excel, Word, and CSV. And they can be emailed on a schedule to people who never log into Power BI at all. If that’s the requirement you’re building for, losing subscriptions doesn’t degrade the report. It removes the reason it exists.

Data agents can’t use Kusto/Eventhouse, semantic models, or mirrored databases as sources under Private Link. Only lakehouse, warehouse, and Fabric SQL Database sources still work.

Copilot in Power BI is unsupported in a Private Link environment. That covers the chat pane for Q&A over a semantic model, report and visual creation from a prompt, DAX query generation and explanation, measure descriptions, and narrative summaries in reports and email subscriptions.

The annoyances

Then there’s the stuff that hits lesser-used features. Each one still stops working completely, not just gets worse, but none of it is going to stop a project on its own.

Exporting a Power BI report to PDF or PowerPoint stops working. Power BI usage metrics start returning partial data, or none at all. Power BI’s Publish to Web stops working too, though plenty of organizations already have that disabled at the tenant level for unrelated reasons. Externally hosted images referenced in a Power BI report fail to load for the same reason: resolving them means an outbound fetch, and that’s exactly what Block Public Internet Access blocks.

If a semantic model or Dataflow Gen1 is built to pull from another semantic model or dataflow as its source (a composite model layered on an existing imported semantic model, for example), that connection breaks, because it relies on a network path that Block Public Internet Access blocks.

Individually, none of these is a reason to abandon the plan, though a couple of them, like the composite model case above, mean planning around them if that’s part of your design.

A couple of things are worth planning around before you start building. Trial capacities don’t work over Private Link at all. And a freshly created F-SKU capacity won’t support Private Link until its endpoint propagates into the private DNS zone, which can take up to 24 hours, so a capacity you just spun up can look broken when it’s really just waiting on DNS to catch up.

Why the gap exists

Based on how Private Link and Block Public Internet Access are documented to work, public endpoints appear to be Fabric’s baseline path for a lot of its traffic, since anything that doesn’t support Private Link either falls back to the public internet or gets blocked outright. Private Link and Block Public Internet Access change that at the tenant level, but not every service was built to work within that constraint. The list above is what happens when a tenant-wide security setting gets layered onto services that predate it.

What to do instead

If the list above outweighs what Private Link and Block Public Internet Access actually buy you in security, there are alternatives worth knowing about, none of them a perfect substitute, all of them worth understanding before you commit to one.

Lean on Conditional Access instead of network blocking. Every Fabric request already authenticates through Microsoft Entra ID. A policy requiring MFA, a compliant device, and sign-in only from named locations controls who gets in and from where, without touching Fabric’s network configuration. None of the breakage described earlier in this post happens with this approach. The tradeoff: traffic still crosses the public internet, encrypted but not privately routed. If your actual requirement is that data never touches the public internet, this doesn’t satisfy it. If the requirement is about controlling access, it usually does.

Protect the data, not just the path. Sensitivity labels tied to a Purview publishing or protection policy can encrypt content in a way that’s bound to identity, so where that’s set up, only authorized users can open the file, even if it crosses the public internet. That’s not automatic for every label. It depends on the policy attached to it. Pair that with Purview DLP policies scoped to Power BI and Fabric: they can flag a sensitive item with a policy tip, alert admins, or restrict access to it entirely, evaluated against the item’s data and labels, not the network path it travels.

One thing worth clarifying: workspace-level protection isn’t a lighter-weight version of the tenant-level decision. It has its own use cases, but it trades one set of limitations for another, plus adds more networking infrastructure to build and maintain.

Go in with eyes open

None of this is an argument against securing the tenant. It’s an argument for being specific about what you’re actually protecting against: unauthorized access, data exfiltration, or a hard requirement that data never leave a private network. Those are three different problems with three different tools, and Private Link plus Block Public Internet Access is only the right answer to one of them. Read the exception lists before you flip the switch, not after a mirror pauses in the middle of a project.

As always, the limitations will change as Fabric receives updates. Be sure to check the documentation for the latest information.

The post Think Twice Before Enabling Fabric’s Inbound Network Protection first appeared on Data Savvy.

/by

The $150 Challenge: What We’re Building and Why

, ,

Series: Building a SQL Server Always On Lab in Azure

Before You Begin

This is the first post in the series. There are no prerequisites beyond an active Azure subscription with the Visual Studio credit activated. If you haven’t done that yet, the next post covers it as its first step.

Who Is This Series For

I’m a DBA with about ten years of experience. I feel like know SQL Server inside and out. Whether it is execution plans, AG internals, backup strategies, or something in between, I feel comfortable with all of it. What I’ve been less confident about is a lot of what surrounds SQL Server. It could be the networking, the Windows configuration, or the Active Directory setup that the sysadmin team always handled while I waited for a server to be handed to me.

This series is my attempt to understand the full picture by building it myself, from scratch, in Azure and writing down everything I learn along the way.

If you’re a DBA, this will hopefully teach you enough Windows administration and Azure networking to stop feeling like a passenger when infrastructure conversations happen. If you’re a sysadmin, the SQL Server sections will explain why DBAs make the configuration requests they do, not just what those requests are. If you’re on the security side of things, the series tries to make a point to call out every decision that has a security implication and explains the reasoning, not just the steps.

My goal is for anyone in a tech background to be able to do this just like me, I try not to assume you’ve done any of this before and explain everything.

So What Are We Building

By the end of this series, we’ll have a Management/Monitoring server and a fully functional SQL Server Always On Availability Group running in Azure, built on a real domain, with proper networking, service accounts, and backups. The environment will look like this:

Machine Role Size Private IP
JUMPBOX01 Management/Monitoring Server B2s 10.10.0.4
DC01 Domain Controller and file share witness B2s 10.10.1.4
SQL01 SQL Server Primary D2s_v3 10.10.2.4
SQL02 SQL Server Secondary D2s_v3 10.10.2.5

All four machines live inside a single Azure Virtual Network (vnet-pcsql-lab-eus-001, 10.10.0.0/16) in East US, divided into dedicated subnets by role. The only machine with a public IP is JUMPBOX01, and that IP is locked to your home IP address via a Network Security Group. Everything else is completely private.

The domain is procuresql.local. The company in all examples is Procure SQL.

The SQL nodes will be members of a Windows Server Failover Cluster (SQLCluster01) with DC01 providing the third vote via a file share witness at \\DC01\SQLWitness. The Availability Group and listener will follow the naming pattern we’ve established for the series, but we’ll get to that later in this page.

Backups go to Azure Blob Storage. Service accounts are Group Managed Service Accounts. No plaintext passwords in scripts, anywhere.

Why Azure? Why $150?

The Visual Studio subscription credit gives you $150 per month in Azure resources. It resets monthly, it doesn’t roll over, and if you go over the limit Azure will suspend your subscription rather than charge you, which makes it a hard ceiling that forces you to actually think about cost, which is a valuable skill in itself.

Here’s what this environment costs assuming 9 hours of uptime per day (8am to 5pm), 22 working days a month, with auto-shutdown handling the rest. If you don’t use it the entire work day and/or if you don’t use it every work day, these estimated costs will be lower.

Resource Notes Est Monthly Cost
JUMPBOX01 – B2s 9hrs/day × 22 days @ $0.042/hr $8
DC01 – B2s 9hrs/day × 22 days @ $0.042/hr $8
SQL01 – D2s_v3 9hrs/day × 22 days @ $0.188/hr $37
SQL02 – D2s_v3 9hrs/day × 22 days @ $0.188/hr $37
OS Disks (x4 Standard SSD) Disks are billed at rest, this covers each VM’s C drive $8
SQL Data Disks (x2 Premium SSD P10) One per SQL AG Node $10
SQL Log Disks (x2 Premium SSD P10) One per SQL AG Node $10
Blob Storage for backups 50GB of Azure Locally Redundant Storage (LRS) $3
Internal Load Balancer and Public IP ILB for the AG Listener, Static Public IP for JUMPBOX01 $7
Key Vault, VNet, NSGs Free Tier $0
Total $138

A note on the SQL disks: unlike a traditional active/passive failover cluster where the storage floats between nodes, an Always On AG keeps a completely independent copy of every database on each replica. SQL01 and SQL02 each need their own data disk and their own log disk.

The $12 of headroom is tighter than it looks. Disks are billed whether the VM is running or not, so the ~$28 in disk costs hits every month regardless of how disciplined you are with uptime. The budget alert we’ll set in the next post will warn you at $140, so at $138 estimated, a few extra hours of VM uptime in a given month is genuinely enough to clip the ceiling. Which brings me to the final note on cost.

Auto-shutdown is non-negotiable here. A single D2s_v3 left running 24/7 for a full month costs around $137 by itself. Two of them running wide open and you’ve blown the budget before you’ve touched a SQL setting. We’ll configure auto-shutdown on every VM at deploy time, not as an afterthought.

How The Series Is Structured

I am trying to break this down so that each post covers a single topic. Every post follows the same structure:

  • Why we’re doing this – the reasoning behind the decision, not just the steps
  • How to do it – step by step, with individual commands and code blocks inline as you read
  • How to verify it worked – because “it didn’t throw an error” is not a test

Throughout each post, individual steps are broken into small code blocks so you read what you’re about to do, do that one thing, and then move on. At the end of every post is a consolidated PowerShell script that runs everything from that post in one shot, which I always found to be useful once you’ve read through it once and understand what it’s doing.

Posts reference each other. If something was set up in an earlier post, you’ll see a link like “we set the static IPs back in post 6” so you can jump back if you need a refresher without the current post re-explaining it.

If you’re following along from the beginning, each post’s testing section produces a state that the next post assumes. If something breaks, the testing sections are your breadcrumb trail back to where things went sideways.

Some Additional Notes

Naming Conventions

I have a naming convention for things that works for me, it might not work for you. But if you want to try to follow it, every resource in this series follows this one. This table is your reference for the entire series.

Thing Convention Example
Servers ALLCAPS## SQL01, DC01, JUMPBOX01
Domain (FQDN) procuresql.local
NetBIOS PROCURESQL
Databases PascalCase HRSystem, WidgetTracker
AG name AppNameAG (max 14 characters) HRSystemAG
AG listener AppNameAGL (max 15 characters) HRSystemAGL
Cluster SQLCluster01
File Share Witness \\DC01\SQLWitness
Service Accounts svc_ServiceName (gMSA) svc_SQLEngine$, svc_SQLAgent$
Resource Group rg-{workload}-{env} rg-pcsql-lab
VNet vnet-{workload}-{env}-{region}-{instance} vnet-pcsql-lab-eus-001
Subnets snet-{role}-{env}-{instance} snet-mgmt-lab-001
Storage Accounts st{type}{workload}{env}{instance} stblobbackuplab001
Network Security Groups nsg-{subnet}-{env}-{instance} nsg-mgmt-lab-001

Why A File Share Witness Instead Of A Cloud Witness

This comes up quickly when you start reading about Windows Server Failover Clustering in Azure. Microsoft’s own documentation often defaults to Azure Blob Storage as the cluster quorum witness, and it works fine. We’re doing something slightly different: using DC01 as a file share witness instead.

There are two reasons. First, we have a domain controller, so we have a third machine that can serve as the tiebreaker vote without adding cost. This also gives you insight into how a typical on prem setup would work. Second and more importantly for this series, understanding why WSFC needs a third vote, and how a file share witness actually provides it, teaches you more about quorum mechanics than pointing a script at a blob container does. The manual approach here is intentional.

What’s Next

Post 2 will be Subscription Setup & Cost Guardrails is where we start actually touching Azure. We’ll activate the Visual Studio credit, create the resource group, set up budget alerts, and configure the auto-shutdown policy that keeps us inside the $150 ceiling for the rest of the series.

/by