SQL Server on-premises not available when creating a Data Quality connection in Microsoft Purview Unified Catalog

Question

Hi Microsoft team,

I am trying to configure Data Quality for an on-premises SQL Server source in Microsoft Purview Unified Catalog.

According to the official documentation, Data Quality for on-premises data sources is supported in preview, and the supported on-premises data sources include Oracle and SQL Server. The documentation also explains that on-premises databases are scanned in the customer’s on-premises infrastructure, using a Kubernetes cluster and the Data Integration Runtime registered with Microsoft Purview.

I am following this documentation:

“Data quality for on-premises data sources (preview)”

However, when I go to:

Unified Catalog > Health management > Data quality > Governance domain > Manage > Connection

and try to create the required connection, the Source type dropdown does not show SQL Server as an available option. I can only see options such as Azure Data Lake Storage Gen2, Azure SQL Database, Azure Blob Storage, Fabric, Oracle, Azure Databricks, BigQuery, Snowflake and Azure Synapse Analytics.

Could you please clarify:

1. Is SQL Server on-premises currently supported for Data Quality in Microsoft Purview Unified Catalog, as stated in the documentation?
2. If it is supported, why is it not appearing in the Source type dropdown when creating the Data Quality connection?
3. Are there any additional prerequisites, feature flags, tenant settings, regions, licenses, permissions, or preview enablement steps required for SQL Server on-premises to appear?
4. Is the setup different from Oracle on-premises?
5. Should SQL Server on-premises be configured through a different source type or workflow?

For context, I am not referring to scanning SQL Server assets in the Data Map, but specifically to configuring the Data Quality connection in Unified Catalog.

Thanks in advance. Best regards,

---

Moderator: Moved from SQL Server | Other.

Answer 1

Here is a diagram and explanation of the Kubernetes cluster you create locally. It’s assumed you already have on-prem Kubernetes support.

https://learn.microsoft.com/en-us/purview/data-map-integration-runtime-kubernetes

Answer 2

SQL Server on-premises is supported for Data Quality in Unified Catalog, but only in the specific on-premises scenario described in the preview documentation and with the required infrastructure in place.

From the documentation:

• On-premises data quality currently supports Oracle and SQL Server as on-premises sources.
• On-premises databases are scanned entirely within customer infrastructure using a Kubernetes cluster hosting a Kubernetes-supported self-hosted data integration runtime.
• Before running a data quality scan, the on-premises assets must first be scanned and registered in the Data Map using a self-hosted integration runtime.
• For on-premises SQL Server, there is separate guidance for registering and scanning an on-premises SQL Server instance in Microsoft Purview.

Given what is in the context, the following points can be stated:

1. Support status
   • SQL Server appears as a supported source for data quality scan in Unified Catalog, specifically marked as on-premises infrastructure:
     • In the “Supported sources” table, SQL Server has Data quality scan = Yes and is explicitly labeled as On-premises infrastructure.
   • The “Data quality for on-premises data sources (preview)” article also lists SQL Server as a supported on-premises data source.
2. Why SQL Server might not appear in Source type
   • The on-premises data quality flow requires:
     • A Kubernetes cluster.
     • The Kubernetes-supported self-hosted data integration runtime installed and registered with Purview.
     • The on-premises SQL Server registered and scanned in Data Map using a self-hosted integration runtime.
   • The connection creation for on-premises sources is described generically: connections are created in Unified Catalog under Health management > Data quality > Governance domain > Manage > Connection, and then associated with a data integration runtime instance.
   • The context does not describe any UI conditions or feature flags that control when “SQL Server” appears in the Source type dropdown, nor does it document region/tenant restrictions or preview enrollment steps beyond the runtime and Kubernetes prerequisites.
   • Therefore, from the available documentation, only the infrastructure and registration prerequisites can be confirmed; any additional UI gating, regional rollout, or tenant-level preview enablement is not documented in the provided context.
3. Additional prerequisites / enablement steps Based on the context, the required steps for on-premises data quality (including SQL Server) are:
   • Set up Kubernetes and the self-hosted data integration runtime:
     • Create a Kubernetes cluster.
     • Download and install the data integration runtime for Kubernetes.
     • Register this runtime with Microsoft Purview.
     • Ensure all required drivers are uploaded to each node in the cluster.
   • Register and scan the on-premises SQL Server in Data Map:
     • In the Purview portal, under Data Map, register the on-premises SQL Server as a data source.
     • Ensure a self-hosted integration runtime is configured and used for scanning the on-premises SQL Server.
     • Run a Data Map scan to extract metadata (instances, databases, schemas, tables, views).
   • Only after these steps are completed does the documentation instruct to proceed with Data Quality connections and scans.
   The context does not mention any extra feature flags, licenses, or region-specific toggles for SQL Server beyond these runtime and scan prerequisites.
4. Differences vs. Oracle on-premises
   • For Oracle, the documentation explicitly describes connection behavior:
     • Connections can be created at database level or schema level.
     • One Oracle database should have only one database-level connection, but multiple schema-level connections.
     • If both schema-level and database-level connections exist, schema-level connections take precedence.
   • For SQL Server, the documentation states:
     • A single database can contain tables from multiple schemas.
     • A single connection is used to scan all schemas in a single database.
     • Therefore, the connection accepts only database information, not schema.
   • So, the main difference is that Oracle supports schema-level connections, while SQL Server connections are database-level only.
5. Whether SQL Server on-premises uses a different source type or workflow
   • The on-premises data quality documentation treats Oracle and SQL Server similarly in terms of high-level workflow:
     • Register and scan in Data Map using a self-hosted integration runtime.
     • Create a connection in Unified Catalog associated with a data integration runtime.
     • Run Data Quality scans using the standard data quality scan documentation.
   • There is no indication in the context that SQL Server on-premises should be configured under a different “Source type” label (for example, via a generic connector) or via a different UI path than the one described for Oracle.

Because the provided documentation does not describe UI behavior for when “SQL Server” appears or is hidden in the Source type dropdown, and does not list tenant/region-specific preview enablement steps, any further explanation for the missing SQL Server option would be speculative and is not supported by the context.

---

References:

• Data quality for on-premises data sources (preview)
• Set up a connection to your on-premises databases
• Kubernetes supported self-hosted data integration runtime for on-premises data sources (preview)
• Set up data source connection for data quality in Unified Catalog
• Data sources and file formats supported for data quality in Unified Catalog
• Connect to and manage an on-premises SQL server instance in Microsoft Purview
• Data quality error records