Azure SQL DB Fabric Mirroring with Private Endpoint
Introduction Overview steps for configuration of Mirroring between Azure SQL Database to Fabric Mirrored Database over Private Endpoint and Public Connectivity Disabled on source. Prerequisites #1 - The minimum requirement for the source Azure SQL Database tier is - it is Standard Tier with DTUs equal or greater than 100. Free, Basic Tier, or <100 DTUs are NOT supported. All vCore model tiers supported. #2 - System Assigned Managed Identity (SAMI) must be enabled on the Azure SQL logical server. #3 - Microsoft.PowerPlatform should be registered as a source provider at the subscription level. If this step is not completed, you'll face error in the next steps, while creating the 'Virtual Network Data Gateway', example below. #4 - The Virtual Network Subnet of the configured Private Endpoint should have the following selected. Select Microsoft.PowerPlatform/netaccesslinks for the Subnet Delegation tab. This is a required step, otherwise the subnet is grayed out to select while configuration of the Virtual Network Data Gateway at Fabric level. High Level Configuration Steps #1 - Go to Fabric Portal > Settings Click on Settings button on top right > Click on Manage Connections and Gateways Go to 'Virtual Network Data Gateway' tab > Click New In the new page, Select your Capacity, Subscription, Resource Group, VNET and Subnet of the source Azure SQL DB and create it. #2 - Go back to your workspace, and click new item > Search 'Mirrored Azure SQL Database' #3 - Here, in Data Gateway section, chose your new created gateway which we created in previous step, and fill the required source Azure SQL Database details and click connect. #4 - Select the tables to be mirrored in the next steps and you will be able to successfully mirror from Azure SQL Database to Mirrored Azure SQL Database without Public Connectivity and using Private Endpoint.‘TCP Provider: An Existing Connection Was Forcibly Closed by the Remote Host’ in MS Fabric SQL DB
Microsoft Fabric continues to unify data engineering, analytics, and storage across the OneLake platform, including fully managed SQL Database in Fabric. While the platform is designed to provide reliable replication and analytics integration, customers may occasionally encounter connectivity‑related errors—particularly during replication workflows. One commonly reported issue appears in the Replication Monitor: TCP Provider: An existing connection was forcibly closed by the remote host. (provider: TCP Provider, error: 0) This blog explains why this occurs, what scenarios trigger it, and how to resolve cases where a table does not appear in the SQL Analytics Endpoint, even though replication is enabled. Scenario Overview Working on support cases with customers reported: Replication Monitor shows “TCP Provider: An existing connection was forcibly closed by the remote host." A table (e.g., TestTable) is not visible in the SQL Analytics Endpoint. Dropping and recreating the table does not resolve the issue. Running diagnostic queries such as EXEC sp_help_change_feed shows metadata, but replication state does not align with the monitor. The issue has been present since the table was created, not something that started later. What This Error Actually Means According to Microsoft documentation on connection termination errors (Azure SQL & Fabric SQL): The TCP provider reports this error when the remote host forcibly terminates the connection. It is a client‑side error, not a SQL engine error. It may occur during: Pre‑login handshake Connection initialization Login processing Data‑stream operations In Fabric SQL Database, this error can surface when replicators or mirroring agents reset or fail a connection unexpectedly. Why This Happens in Fabric SQL Database Replication The issue is often tied to internal replication pipeline health. Replication may fail for a specific table even though other tables replicate successfully. The Fabric SQL replicator may hit an internal exception or unexpected disconnect. Because replication is asynchronous, intermittent platform‑side resets may trigger the TCP provider error on the client (replication monitor) even when the database itself is healthy. One key detail: Customers confirmed the issue existed since the table was first created, suggesting the replicator failed to initialize its metadata or state for that table. Table Not Visible in SQL Analytics Endpoint A second symptom is that the affected table does not appear in the SQL Analytics Endpoint, even after: Dropping and recreating the table Rechecking change feed metadata Confirming workspace and database permissions Executing EXEC sp_help_change_feed This indicates the replicator never successfully onboarded the table. Backend Investigation The issue was isolated to publisher‑side replication components. Telemetry showed no systemic availability incidents. Restarting the replicator mitigated the problem in multiple cases. After restart, the table became visible in the SQL Analytics Endpoint, and replication turned green. Thus, the root cause is typically replicator state corruption or partial initialization, not table schema or user configuration. Available Workarounds Today Fabric currently provides public REST APIs for customers to control mirroring/replication using the Mirroring – Start Mirroring API: POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/sqlDatabases/{sqlDatabaseId}/startMirroring This API allows: Restarting mirroring/replication Recovering replicator state without waiting for backend intervention Important notes: UI controls for “Start / Stop Replicator” are not yet available but planned for future releases. Proper permissions are required (SQLDatabase.ReadWrite.All). Recommended Troubleshooting Steps 1. Check whether the issue existed since table creation If yes → strongly indicates replicator never initialized the table. 2. Validate replication metadata Run: EXEC sp_help_change_feed; Compare table info with Replication Monitor output. 3. Try restarting the replicator Use: REST API (available now) or Open a support ticket to request replicator restart. 4. Confirm table visibility in SQL Analytics Endpoint Once the replicator is healthy, the table should appear automatically. 5. If issue persists Collect replicator traces (support can request internal telemetry) Provide workspace ID, database ID, and full error text Open a support ticket with Microsoft to get replicator restart by engineering team Key Takeaways The error “TCP Provider: An existing connection was forcibly closed by the remote host” usually indicates a replicator‑side interruption, not a customer misconfiguration. Fabric SQL replication depends on internal mirroring pipelines; failures or state corruption for a specific table can prevent visibility in SQL Analytics Endpoint. Restarting the replicator often resolves the issue. REST APIs are available to automate this until UI controls ship. Dropping/recreating the table does not fix underlying replicator state issues. Conclusion Microsoft Fabric SQL Database provides powerful integrated replication for analytics, but occasional replication initialization issues can surface as TCP provider disconnection errors. Understanding the behavior of the replicator, combined with using available REST APIs and diagnostic tools, allows rapid mitigation and ensures tables appear in the SQL Analytics Endpoint as expected. If you encounter this error consistently for a specific table, follow the steps above—or open a Microsoft support incident for deeper platform‑side investigation.
