A unified data governance solution that helps manage, protect, and discover data across your organization
Hi @Dhanoordaran V , Hope you are doing well.
Thanks for the detailed screenshot — 136 discovered / 134 classified / 0 ingested is a very specific pattern, and it narrows things down well.
You're right that connectivity and credentials are fine: discovery and classification both completing proves Purview reached the source and read the schema. The break is at the point where that metadata gets written into the Data Map.
Two causes account for the large majority of these, so check them first.
- Self-hosted Integration Runtime version — check this first
This is the most common cause and it's counter-intuitive: newer SHIR versions have caused this exact symptom. A customer with an identical case (discovery fine, ingested always 0, no errors anywhere, db_owner on the source, default rule set) resolved it this way:
- 5.51 → ingested 0
- 5.8 → IR showed
Running (unhealthy) - 5.49 → resolved
Check your version in Microsoft Integration Runtime Configuration Manager. If you recently upgraded and ingestion stopped, roll back and re-run the scan.
Newer SHIR builds enforce stricter TLS 1.2, .NET, and Windows patch-level requirements. If your server doesn't meet them, the runtime can appear healthy while failing to write to the ingestion pipeline. Before upgrading again, confirm Windows is fully patched, TLS 1.2 is enabled, and .NET meets the current SHIR prerequisites.
2**.** Ingestion private endpoint (if you use Private Link)
These are two different things and they're easily conflated:
- The account private endpoint controls access to your Purview account.
- The ingestion private endpoint is what allows Purview's scanning infrastructure to write scanned metadata into the Data Map.
If the ingestion private endpoint isn't configured — or the SHIR VM isn't inside the same or a peered VNet — you get precisely this pattern: the scan connects, discovers, classifies, reports Completed, and ingests nothing.
Check Purview portal → Data Map → Networking and confirm an ingestion private endpoint exists and is Approved. This has been the resolution in multiple cases with your exact symptom.
- Get the actual logs
The portal often shows no warnings even when ingestion fails. Look on the SHIR machine instead:
C:\Program Files\Microsoft Integration Runtime\5.0\Shared\Logs
Also check Event Viewer under Applications and Services Logs → Microsoft Integration Runtime. Errors from the ingestion stage surface here when they don't surface in the portal.
- Confirm your collection role
You need Data Curator or Data Source Admin on the collection the scan publishes to. Without it, ingestion can silently return 0 while the scan reports success. Check Data Map → Collections → (your collection) → Role assignments.
- Isolate with a test scan
Register a small Azure-native source (an Azure SQL Database or a storage account) and scan it using the Azure integration runtime rather than your SHIR. If that ingests successfully, the problem is the SHIR or its network path, not your Purview account or collection permissions. That's a fast, decisive split.
One clarification on the counters: discovered 136 → ingested 0 is not explainable as "assets already exist." Ingested Assets counts assets written to the Data Map after filtering unsupported and duplicate items — a re-scan of existing assets still registers. Zero means ingestion genuinely failed, so it's worth pursuing rather than dismissing.
Could you confirm:
- Your SHIR version, and whether it was upgraded recently?
- Is your Purview account behind Private Link, and is an ingestion private endpoint configured?
- Does anything appear in the SHIR logs at the path above during the scan window?
References
- Scans and ingestion in Microsoft Purview Data Map
- Use private endpoints for your Microsoft Purview account
- Register and scan an on-premises SQL Server
- Self-hosted integration runtime prerequisites
Kind Regards,
Microsoft Support Team.