Share via

"Something went wrong" errors when browsing Microsoft Purview with private networking

Piotr Tybulewicz 145 Reputation points
2025-12-12T13:03:18.03+00:00

Hi Team,

Starting this week, I began encountering “Something went wrong” errors in Microsoft Purview Governance solutions (Unified Catalog and Data Map) when using private networking. The issue affects core portal functionality such as browsing governance domains and data products.

Environment details

  1. Using the new Microsoft Purview portal.
  2. Public network access disabled.
  3. Platform private endpoint configured and in use.
  4. DNS resolution for the private endpoint (<tenantid>-api.purview-service.microsoft.com) works correctly and resolves to the expected private IP.
  5. User account is assigned:
    1. Purview Administrator
    2. Data Governance - tenant-wide roles

Observed issues

  1. In Unified Catalog → Catalog Management → Data Products, the portal displays: "Failed to load facets for data products. Something went wrong."
  2. When opening Data Map, the portal displays: "Failed to load permissions. AxiosError: Network Error"

Troubleshooting performed

  1. Tested with multiple browsers and cleared cache.
  2. Tested with different user accounts (same permissions).
  3. Deployed a brand new Microsoft Purview account in a separate tenant (without firewall) - same behavior.
  4. Verified there were no DNS, networking, or firewall changes on our side.
  5. Confirmed that:
    1. Everything works correctly when Public Access is enabled
    2. The issue occurs only when Private Endpoint is used
  6. This setup was working without issues until Monday (08-12-2025)

Network inspection details

  1. While inspecting network traffic in browser developer tools, I observed failed requests such as: https://<tenantid>-api.purview-service.microsoft.com/account/domains?api-version=2023-12-01-previewor https://<tenantid>-api.purview-service.microsoft.com/datagovernance/catalog/businessdomains
  2. Both of them had Referrer Policy: strict-origin-when-cross-origin
  3. In both cases, Referrer contained prod.ext phrase, e.g. https://datasource.prod.ext.web.purview.azure.com/ or https://catalog.prod.ext.web.purview.azure.com/
  4. When I manually edited and resent the request without the prod.ext value in the Referer header, the API returned a valid response without errors.

Questions

  1. Are you aware of any recent Microsoft Purview changes or updates (portal, networking, or security-related) that could explain this behavior?
  2. Do you have any guidance on what might be misconfigured or what additional checks we should perform when using Private Endpoints with the new Purview portal?

Thank you in advance for any insights or confirmation.

Best regards,

Piotr

Microsoft Security | Microsoft Purview
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2025-12-12T13:04:48.76+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    It seems that the errors you are encountering in Microsoft Purview when using private networking may be related to the configuration of your private endpoint and DNS settings. Here are some insights and recommendations based on the context provided:

    1. Private Endpoint Configuration: Since you mentioned that everything works correctly when public access is enabled, it indicates that the issue is likely tied to the private endpoint configuration. Ensure that the private endpoint is correctly set up and that the necessary permissions are granted to access the resources.
    2. DNS Resolution: You noted that DNS resolution for the private endpoint works correctly. However, you might want to double-check the DNS settings to ensure that they are configured to resolve to the private IP addresses when accessed from within the virtual network. This includes verifying that the DNS records for your Purview account are correctly set up to resolve to the private endpoint.
    3. Network Connectivity: Use tools like Test-NetConnection to verify network connectivity to the Microsoft Purview endpoints. This can help confirm that there are no underlying network issues preventing access to the services.
    4. Referrer Policy: The network inspection details you provided suggest that the referrer policy might be affecting the requests. Since the API returned valid responses when you modified the request, this could indicate a potential issue with how the requests are being handled when originating from the private endpoint. You may want to explore any recent updates or changes in the Microsoft Purview service that could have affected this behavior.
    5. Recent Changes: As for recent changes or updates in Microsoft Purview, it would be beneficial to check the official Microsoft documentation or support channels for any announcements regarding updates that could impact private endpoint functionality or security settings.
    6. Additional Checks: Ensure that there are no firewall rules or network security group settings that might be blocking traffic to the private endpoint. Also, consider testing with different configurations or settings to isolate the issue further.

    If the problem persists, reaching out to Microsoft support for more tailored assistance may be necessary, especially if this behavior started suddenly without any changes on your end.

    References:

    0 comments

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.