Orphaned FQDN routing constraint in Global Secure Access after application hard-deletion.

Question

Orphaned FQDN routing constraint in Global Secure Access after application hard-deletion.

Neel Patel 0

Problem Description

We are experiencing a backend synchronization issue where a Global Secure Access (GSA) Application Segment routing rule was orphaned after its parent Enterprise Application was deleted.

The original application (named "Grafana") was soft-deleted and subsequently permanently purged from the Deleted Applications recycle bin. However, GSA did not release the underlying Fully Qualified Domain Name (FQDN) and port bindings. When attempting to create a new GSA application using the same endpoint, the system blocks creation with a network access settings conflict.

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-06-08T18:08:46.0666667+00:00

Hello @Neel Patel

Following up to see if the above provided information was helpful. If you have any further queries do let us know.

1 answer

Your answer

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-06-08T18:08:46.0666667+00:00

Hello @Neel Patel

Following up to see if the above provided information was helpful. If you have any further queries do let us know.

Answer 1

Hey Neel, it sounds like you ran into a gap where GSA still held on to the Grafana FQDN+port binding even after the parent Enterprise Application was permanently purged. GSA treats those per-app routing rules independently, so deleting the EA in Entra ID doesn’t automatically clear the underlying application segment in Global Secure Access. When you went to re-use the same hostname + port, the old segment was still “live,” causing the conflict.

Here’s what you can try:

Locate and delete the orphaned application segment • In the Entra admin center, go to Global Secure Access → Per-app access (or Quick Access, if you had it under that) → Applications → Your Grafana entry. • If you don’t see it in the UI, use the Graph API to list applicationSegments, filter on displayName or FQDN: • GET https://graph.microsoft.com/beta/conditionalAccess/applicationSegments • Look for entries with your Grafana FQDN/port • Once you have the segment ID, delete it: DELETE https://graph.microsoft.com/beta/conditionalAccess/applicationSegments/{segment-id} • Wait ~5–10 minutes for policy propagation.
Clear client-side cached forwarding profiles • On a test device, open the GSA client → Advanced Diagnostics → Forwarding Profile → click “Refresh.” • Or manually delete the ForwardingProfile registry key and restart the Policy Retriever service (per the Troubleshoot Private Access doc).
Recreate your Grafana segment with the same FQDN/port • It should now succeed without a network access settings conflict.

If you still hit the block after those steps, lets continue over private messages

Note: This content was drafted with the help of an AI system.