Troubleshooting Azure Synapse Studio Connectivity: A Practical Guide

Updated: 06 Mar, 2025 • 0 • min read

Table of Contents

Troubleshooting Azure Synapse Studio Connectivity

Ensuring seamless connectivity to Azure Synapse Studio is crucial for data professionals leveraging its powerful analytics capabilities. However, like any complex system, users may encounter connectivity issues that can disrupt workflows. This guide provides practical troubleshooting steps for common errors encountered while connecting to Azure Synapse Studio, helping you diagnose and resolve these problems efficiently.

Error Code 9054: Linked Service Connection Failure¶

Error code 9054 typically arises when Azure Synapse Studio fails to connect to linked services. This often occurs in scenarios where a workspace is deployed in GIT mode without the Managed Virtual Network (MVN) configuration. The absence of a Managed Virtual Network can lead to connectivity breakdowns between Synapse Studio and external resources defined as linked services, as the secure network perimeter required for these connections is not properly established.

Resolution:

To rectify error code 9054, it is essential to incorporate the Managed Virtual Network configuration into the workspace deployment template. When deploying Azure Synapse workspaces using Infrastructure-as-Code (IaC) practices with tools like ARM templates or Bicep, ensure that the network configuration section explicitly includes the Managed Virtual Network settings. This configuration typically involves defining subnet configurations and network security rules that govern traffic within the managed network and to external services.

By adding the Managed Virtual Network configuration, you enable the workspace to create and manage network resources necessary for secure and reliable communication with linked services. This ensures that when Synapse Studio attempts to access these services, the network infrastructure is in place to facilitate the connection, thereby resolving error code 9054 and enabling successful data integration and analysis workflows.

Error 400 While Loading Synapse Workspace¶

Encountering an HTTP error 400 while attempting to load your Synapse workspace within Azure Synapse Studio usually points to a client-side issue or a misconfiguration related to network access restrictions. This error signifies that the request sent from your browser or client application to the Synapse service was deemed invalid or could not be processed due to configuration problems.

Common Causes and Resolutions:

Network Restrictions: Error 400 often occurs when you are attempting to access Synapse Studio from a network with restrictive firewall rules or security policies. If your network is configured to block outbound traffic to certain Azure services or ports, Synapse Studio may fail to load completely, resulting in the error.
- Resolution: Review your network’s firewall settings and ensure that necessary outbound rules are configured to allow traffic to Azure Synapse Analytics and related Azure services. This may involve whitelisting specific IP ranges or service tags associated with Azure. Refer to the Microsoft documentation on connecting to workspace resources from restricted networks for detailed guidance.
DNS Configuration Issues: Incorrect or incomplete Domain Name System (DNS) configurations can also lead to error 400. Synapse Studio relies on proper DNS resolution to locate and connect to various Azure services. If your network’s DNS settings are not correctly configured to resolve Azure service endpoints, the connection attempt may fail.
- Resolution: Verify your network’s DNS settings and ensure they are correctly configured to resolve public Azure endpoints. In environments with custom DNS servers, ensure that these servers are capable of resolving Azure service names. If using Azure Private Endpoints, proper DNS configuration is critical to ensure that requests are correctly routed within the private network. Consult the Azure Private Endpoint DNS configuration documentation for detailed steps on setting up DNS for private endpoints.

By addressing these potential misconfigurations, particularly focusing on network restrictions and DNS settings, you can effectively troubleshoot and resolve error 400 when loading your Synapse workspace, restoring access to Synapse Studio and its functionalities.

ADLS Gen2 Operation Failed with “Forbidden” Error¶

The error message “ADLS Gen2 operation failed for: Storage operation ‘’ get failed with Operation returned an invalid status code ‘Forbidden.’” indicates an authorization problem when Synapse Studio attempts to access an Azure Data Lake Storage Gen2 (ADLS Gen2) account. This error typically arises due to insufficient permissions granted to the Synapse workspace’s Managed Service Identity (MSI) on the storage account.

Root Cause: Insufficient Permissions

When an Azure Synapse workspace is created, it automatically establishes a default linked service to an associated storage account. This linked service utilizes the workspace’s Managed Service Identity (MSI) for authentication. The MSI acts as a security principal, allowing the Synapse workspace to access other Azure resources securely without needing to manage credentials directly. The “Forbidden” error signifies that the workspace MSI lacks the necessary role-based access control (RBAC) permissions on the target ADLS Gen2 storage account. Specifically, it is missing the “Storage Blob Data Contributor” role, which is required for read and write access to blob data within the storage account.

Resolution: Granting Storage Blob Data Contributor Role

To resolve this error, you must grant the Synapse workspace’s MSI the “Storage Blob Data Contributor” role on the associated ADLS Gen2 storage account. This can be achieved through the Azure portal, Azure CLI, or PowerShell.

Steps in Azure Portal:

Navigate to the ADLS Gen2 storage account in the Azure portal.
Select “Access control (IAM)” from the left-hand menu.
Click “+ Add” and choose “Add role assignment.”
In the “Role” dropdown, select “Storage Blob Data Contributor.”
In the “Assign access to” section, choose “Managed identity.”
Click “+ Select members.”
In the “Managed identity” blade, select “Synapse workspace” from the “Managed identity type” dropdown.
Search for and select your Synapse workspace name.
Click “Select” at the bottom.
Click “Review + assign” to save the role assignment.

By granting the “Storage Blob Data Contributor” role to the Synapse workspace MSI, you authorize it to perform data operations on the ADLS Gen2 storage account. This resolves the “Forbidden” error and enables Synapse Studio to successfully interact with the storage account for data access, processing, and storage tasks. Refer to the Azure Synapse Analytics documentation on access control for detailed guidance on managing workspace MSI permissions.

Instance-Specific Error Connecting to SQL Server: “Deny public network access is set to Yes.”¶

The error message “An instance-specific error occurred while establishing a connection to SQL Server. Connection was denied since Deny public network access is set to Yes.” indicates that you are attempting to connect to an Azure SQL Server that has public network access explicitly disabled. This configuration is often implemented for enhanced security, restricting access to the SQL Server to only within the Azure private network or through designated private endpoints.

Scenario: Workspace with Data Exfiltration Protection (DEP) Enabled

This error is particularly relevant when working with a Synapse workspace that has data exfiltration protection (DEP) enabled. DEP is a security feature that further restricts outbound network traffic from the Synapse workspace, ensuring that sensitive data remains within the controlled environment. When DEP is enabled, and the target SQL Server has public network access denied, direct public connections from Synapse Studio will be blocked.

Resolution: Utilizing Private Endpoints

To establish a secure and compliant connection in this scenario, you must leverage Azure Private Endpoints. Private endpoints provide a secure and private connection to Azure services, including Azure SQL Server, from within your virtual network. They extend your private network address space to the Azure service, making it appear as if it is directly within your VNet.

Steps to Connect via Private Endpoints:

Create a Private Endpoint for Azure SQL Server: In your Azure virtual network, create a private endpoint resource targeting your Azure SQL Server. This private endpoint will be associated with a private IP address within your VNet.
Configure DNS for Private Endpoint: Ensure that your DNS settings are properly configured to resolve the SQL Server’s fully qualified domain name (FQDN) to the private IP address of the private endpoint when accessed from within your VNet. This is crucial for routing traffic correctly through the private endpoint.
Connect from Synapse Workspace via Private Endpoint: When configuring your linked service or connection within Synapse Studio to the Azure SQL Server, use the SQL Server’s FQDN. Due to the DNS configuration, traffic will be automatically routed through the private endpoint, establishing a secure connection without traversing the public internet.

By implementing private endpoints, you bypass the public network access restrictions on the SQL Server and establish a secure, private connection from your Synapse workspace. This ensures that your data interactions are compliant with security policies and data exfiltration protection measures. Refer to the Azure Synapse Analytics documentation on connecting to workspaces with private links and understanding Azure Synapse Private Endpoints for detailed guidance.

COPY Statement Input File Schema Discovery Failed: Cannot Bulk Load¶

The error message “COPY statement input file schema discovery failed Cannot bulk load.” when using the COPY statement in Synapse SQL typically indicates an issue with the schema or format of the input files you are trying to bulk load into a Synapse SQL table. This error can occur due to discrepancies between the expected schema by the COPY statement and the actual structure of the data within the input files.

Common Causes:

Schema Mismatch: The most frequent cause is a mismatch between the schema defined for the external table or the target table in Synapse SQL and the actual schema of the data in the input files. This could involve differences in data types, column order, or the presence of unexpected columns.
File Format Issues: Problems with the input file format, such as incorrect delimiters, encoding issues, or inconsistent row terminators, can also lead to schema discovery failures. The COPY statement relies on consistent formatting to correctly parse and load the data.
Corrupted or Incomplete Files: If the input files are corrupted, incomplete, or contain invalid data that violates schema expectations, the schema discovery process may fail, preventing bulk load operations.

Resolution: Verifying and Correcting Schema and File Format

To resolve this error, you need to carefully examine and correct potential schema and file format issues.

Troubleshooting Steps:

Inspect Input Files: Thoroughly inspect a sample of your input files to understand their actual schema, data types, delimiters, and overall format. Pay attention to any inconsistencies or unexpected data patterns.
Compare Schema Definitions: Compare the schema of your input files with the schema defined for your external table (if using external tables) or the target table in Synapse SQL. Ensure that data types, column names, and column order are consistent.
Verify File Format Parameters: Double-check the file format parameters specified in your COPY statement, such as FORMAT, FIELDTERMINATOR, ROWTERMINATOR, and ENCODING. Ensure these parameters accurately reflect the format of your input files.
Check for Data Quality Issues: Examine your input files for any data quality issues, such as missing values, invalid characters, or data that violates schema constraints. Correct or cleanse the data as needed.
Test with a Sample File: Start by testing your COPY statement with a small sample input file that you have carefully validated. This helps isolate schema and format issues before processing large datasets.

By systematically verifying and correcting schema definitions, file format parameters, and data quality, you can address the “COPY statement input file schema discovery failed” error and successfully perform bulk load operations into Synapse SQL. Consult the Azure Synapse Analytics documentation on using external tables with Synapse SQL for detailed guidance on schema definition and data loading best practices.

Table Lock While Pulling Data from SAP ECC¶

Experiencing table locks when pulling data from SAP ECC (ERP Central Component) into Azure Synapse Analytics is often an expected behavior due to the transactional nature of SAP systems. SAP ECC, like many transactional databases, employs locking mechanisms to maintain data consistency and integrity, especially during data retrieval operations.

Reason: Transaction Isolation

Table locks in SAP ECC during data extraction are primarily a consequence of transaction isolation levels. Transaction isolation ensures that concurrent transactions do not interfere with each other and maintain data consistency. When you initiate a data extraction process from SAP ECC, it may acquire locks on the tables being accessed to guarantee that the data read is consistent and not affected by ongoing transactions within the SAP system.

“By Design” Behavior

This behavior is often considered “by design” in SAP ECC systems. The purpose of these locks is to prevent data inconsistency and ensure the reliability of transactional operations within SAP. While table locks can sometimes lead to performance considerations or delays in data extraction, they are a fundamental aspect of maintaining data integrity in transactional systems like SAP ECC.

Mitigation Strategies (Limited Scope)

While completely eliminating table locks during data extraction from SAP ECC may not be feasible due to the system’s design, certain mitigation strategies can be considered to minimize their impact:

Optimize Extraction Queries: Ensure that your data extraction queries are optimized to retrieve only the necessary data and minimize the duration of table access. Efficient queries can reduce the time locks are held.
Schedule Extractions During Off-Peak Hours: Schedule data extraction processes during off-peak hours or periods of lower transactional activity in SAP ECC. This can reduce the likelihood of lock contention and improve extraction performance.
Consider SAP CDC (Change Data Capture): For near real-time data integration, explore SAP Change Data Capture (CDC) capabilities. CDC methods can extract incremental data changes, potentially reducing the need for full table scans and associated table locks during frequent data updates.
Work with SAP Basis Team: Collaborate with your SAP Basis team to understand the specific locking behavior in your SAP ECC environment and explore any SAP-recommended best practices or configurations for data extraction scenarios.

It’s important to recognize that table locks are an inherent part of transactional database systems like SAP ECC. While mitigation strategies can help minimize their impact, completely avoiding them during data extraction may not always be possible. Understanding this “by design” behavior is crucial for planning and managing data integration processes with SAP ECC.

Per-Machine Installation Stopped: Existing Per-User Gateway Installation¶

The error message “Per-machine installation is stopped because there is existing per-user gateway installation.” indicates a conflict arising from attempting to install a per-machine Self-Hosted Integration Runtime (SHIR) when a per-user SHIR is already installed on the same virtual machine (VM). This error is specific to the installation of Self-Hosted Integration Runtimes, which are crucial components for connecting Azure Synapse Analytics or Azure Data Factory to on-premises data sources or data sources within private networks.

Root Cause: Installation Conflict - Single SHIR per VM

The core reason for this error is a limitation: only one Self-Hosted Integration Runtime (SHIR) installation is permitted per virtual machine (VM). The installation process detects an existing per-user SHIR installation and prevents the per-machine installation to avoid conflicts and ensure proper resource management. This restriction is in place because SHIRs are designed to operate as isolated instances on a VM to manage data integration tasks effectively.

Resolution: Separate VMs for Multiple SHIRs

To install multiple Self-Hosted Integration Runtimes for Azure Synapse Analytics, you need to set up separate virtual machines to host each Integration Runtime instance. Each VM should have its own dedicated SHIR installation, whether per-user or per-machine.

Key Considerations:

Azure Data Factory SHIR Sharing: It’s important to note that currently, only Azure Data Factory supports the Self-hosted IR sharing feature. This feature allows sharing a single SHIR instance across multiple Azure Data Factories. However, this sharing capability is not yet available for Azure Synapse Analytics Self-Hosted Integration Runtimes.
Dedicated VMs for Synapse SHIRs: For Azure Synapse Analytics, if you require multiple SHIR instances for different data integration needs or connectivity requirements, you must deploy each SHIR on a separate Azure Virtual Machine.
Installation Type Consistency (Within a VM): While you can choose between per-user and per-machine installation types, it’s generally recommended to maintain consistency within a VM. If you initially installed a per-user SHIR, subsequent installations on the same VM should also be per-user (though this is not recommended due to the single SHIR per VM limitation).

Steps to Resolve:

Identify Existing SHIR Installation: Determine if a per-user SHIR is already installed on the target VM. You can check the “Programs and Features” or “Apps & features” section in Windows Control Panel to see if “Microsoft Integration Runtime” is listed.
Uninstall Existing SHIR (If Necessary): If you need to install a per-machine SHIR and a per-user SHIR is present, you might need to uninstall the per-user SHIR. However, consider if you can reuse the existing SHIR or if deploying a new SHIR on a separate VM is a better approach.
Deploy New SHIR on a Separate VM: The recommended solution is to provision a new Azure Virtual Machine and install the new Self-Hosted Integration Runtime (either per-user or per-machine) on this dedicated VM.
Register SHIR with Synapse Workspace: After installing the SHIR on the new VM, register it with your Azure Synapse Analytics workspace.

By deploying each Self-Hosted Integration Runtime on a separate virtual machine, you avoid installation conflicts and ensure proper operation of multiple SHIR instances for your Azure Synapse Analytics data integration workloads. Refer to the Azure Data Factory documentation on creating a self-hosted integration runtime for detailed instructions and best practices, keeping in mind the current limitations regarding SHIR sharing for Synapse Analytics.

Error Code 2108: Endpoint Call Failure - Network Connectivity Issues¶

Error code 2108, accompanied by the message “Error calling the endpoint ‘’. Response status code: ‘’. More details: Exception message: ‘’ Request didn’t reach the server from the client.”, is a general error indicating a failure in communication with an endpoint. This error suggests that a request initiated by Azure Synapse Studio or a related service failed to reach the intended server endpoint, resulting in a communication breakdown.

Underlying Causes: Network and DNS Issues

This error typically points to underlying network connectivity problems, DNS resolution failures, server certificate validation issues, or timeout configurations. These issues can prevent the client (Synapse Studio or integration runtime) from successfully establishing a connection with the target endpoint.

Common Scenarios and Resolutions:

Network Connectivity Problems: The most fundamental cause is a lack of network connectivity between the client and the server endpoint. This could be due to network outages, firewall rules blocking traffic, network misconfigurations, or issues with the network infrastructure itself.
- Resolution: Verify network connectivity between the client machine (where Synapse Studio or the integration runtime is running) and the server endpoint. Use network diagnostic tools like ping, traceroute, or nslookup to test connectivity and identify potential network bottlenecks or blockages. Review firewall rules and network security group (NSG) configurations to ensure that traffic is allowed on the necessary ports and protocols.
DNS Failure: Domain Name System (DNS) resolution is crucial for translating domain names into IP addresses. If DNS resolution fails, the client cannot locate the server endpoint by its name.
- Resolution: Check DNS settings on the client machine and ensure that they are correctly configured to resolve the server endpoint’s domain name. Use nslookup to test DNS resolution for the endpoint. If using custom DNS servers, verify their reachability and proper configuration.
Server Certificate Validation Issues: When communicating over HTTPS, server certificate validation is essential for secure connections. Errors in certificate validation can occur if the server’s certificate is invalid, expired, not trusted, or if there are issues with the client’s certificate store.
- Resolution: If the endpoint uses HTTPS, investigate potential certificate validation issues. Ensure that the server’s certificate is valid and trusted by the client. If using custom certificates, ensure they are properly installed and configured on both the server and client.
Timeout Misconfigurations: Timeouts define the maximum duration a client will wait for a response from a server. If timeouts are set too short or if network latency is high, requests may time out before a response is received.
- Resolution: Review timeout settings in your Synapse configurations or integration runtime settings. Increase timeout values if necessary to accommodate potential network latency or server response times. However, ensure that timeouts are not set excessively long, as this can mask underlying issues.

Managed Virtual Network and Data Exfiltration Protection (DEP) Considerations:

The error code 2108 can be particularly relevant when using a Managed Virtual Network (MVN) in Synapse workspaces, especially with Data Exfiltration Protection (DEP) enabled. MVNs provide a secure network boundary for Synapse resources, and DEP further restricts outbound traffic. Misconfigurations in MVN or DEP settings can lead to network connectivity issues and error 2108.

Note: The type of virtual network (Shared or Managed) applied to a Synapse workspace is defined at workspace creation time and cannot be changed afterward.

Private Endpoints and Private Link Services:

In scenarios with MVNs or DEP, Private Endpoints and Private Link Services are often crucial for establishing secure and private connections to Azure services or on-premises resources. These technologies ensure that network traffic remains within the Azure private network or private connections, enhancing security and compliance.

Private Endpoints: Provide private connectivity to Azure services within your VNet.
Private Link Service: Enables you to expose your own services running in Azure VNets privately to consumers.

Many configurations involving MVNs, DEP, Private Endpoints, and Private Link Services require careful DNS configuration within your network to ensure that requests are correctly routed to private endpoints inside the virtual network. Refer to the Azure Private Endpoint DNS configuration documentation for detailed guidance.

By systematically investigating network connectivity, DNS resolution, certificate validation, and timeout settings, and by considering the implications of Managed Virtual Networks and Data Exfiltration Protection, you can effectively troubleshoot and resolve error code 2108 and ensure reliable endpoint communication in your Azure Synapse Analytics environment.

This guide has covered several common connectivity issues you might encounter while working with Azure Synapse Studio. By understanding the root causes and applying the recommended solutions, you can effectively troubleshoot and resolve these problems, ensuring a smooth and productive experience with Azure Synapse Analytics.

If you have encountered other connectivity challenges or have further insights into these errors, please feel free to share your experiences in the comments below. Your contributions can help expand this guide and assist other users in the community.

Computacionvinchi