Share via

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

Anna Llop 20 Reputation points
2026-06-16T10:17:45.8266667+00:00

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.

Microsoft Security | Microsoft Purview

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Manoj Kumar Boyini 16,895 Reputation points Microsoft External Staff Moderator
    2026-06-18T06:08:14.4766667+00:00

    Hey @Anna Llop — this is a good catch, and it definitely sounds blocking.

    Based on the provided docs, Data Quality for on-premises data sources (preview) does include “SQL Server” as a supported on-premises data source, alongside Oracle. The connection you’re creating in Unified Catalog → Health management → Data quality → … → Manage → Connection is also described as being created by selecting a Source type and then setting up the connection using a data integration runtime registered with Microsoft Purview (and on-premises scanning is hosted on customer infrastructure using Kubernetes + the registered runtime).

    1) Is on-premises SQL Server supported for Data Quality?

    Yes (preview) — the “Data quality for on-premises data sources (preview)” doc explicitly lists SQL Server as supported on-premises data sources.

    2) Why might SQL Server not appear in the “Source type” dropdown?

    The provided information doesn’t include a general, user-facing explanation for why the dropdown would omit SQL Server. However, there is a relevant supportability note (from the provided “Issue: On-premises SQL Server not available for Purview connection” snippet) indicating a backend feature-flag can be missing/not enabled for the account/tenant, which results in SQL Server not showing as an available source type even when the customer has the required SHIR + DIR infrastructure.

    So in your scenario, the most likely explanation (per the provided material) is:

    • A backend feature flag for Unified Catalog Data Quality on-prem SQL Server isn’t enabled for the Purview account/tenant.

    3) Additional prerequisites / feature flags / tenant settings / regions / licenses

    From the on-premises Data Quality prerequisites doc, the user-facing prerequisites are:

    • Set up a Kubernetes cluster
    • Download the data integration runtime
    • Register it with Microsoft Purview
    • Also: before running data quality, you must scan the assets through a Data Map scan (using a self-hosted integration runtime)

    From the dropdown-missing case, additionally:

    • A backend feature flag may need to be enabled (per the provided “Issue…” support note)

    The provided docs don’t specify region/ licensing / tenant settings beyond the above, so I can’t confirm anything else from the supplied content.

    4) Is the setup different from Oracle on-premises?

    The connection workflow is broadly the same (Unified Catalog → Health management → Data quality → Manage → Connections → New). But the connection configuration model has an Oracle-specific nuance:

    • For SQL Server connections: a connection accepts database information but not schema (single database can contain multiple schemas; you can scan schemas within that database).
    • For Oracle: you can create connections at schema level or database level, with rules about precedence.

    So yes, configuration details differ, even though the high-level workflow is the same.

    5) Should SQL Server on-premises be configured through a different workflow?

    The on-premises Data Quality doc says to set up connections the same way you create connections for other data source types in Unified Catalog (Health management → Data quality). It does not indicate a different workflow for SQL Server versus Oracle—rather, it indicates SQL Server should be selectable as a supported on-premises data source.

    Given that SQL Server should be supported, if it’s missing from the dropdown, the “feature flag not enabled” scenario (above) is the most consistent explanation from the provided materials.

    https://learn.microsoft.com/purview/unified-catalog-data-quality-on-premises-data-sources
    https://learn.microsoft.com/purview/unified-catalog-data-quality-supported-sources-connection
    https://learn.microsoft.com/purview/unified-catalog-data-quality-troubleshooting
    https://learn.microsoft.com/en-us/purview/data-map-integration-runtime-kubernetes
    https://learn.microsoft.com/en-us/purview/data-map-integration-runtime-choose#supported-data-sources

    Was this answer helpful?

    0 comments
  2. Bruce (SqlWork.com) 84,086 Reputation points
    2026-06-16T14:21:43.37+00:00

    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

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-06-16T10:18:48.0066667+00:00

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.