Deleted Azure Bastion still visible in portal list after ARM deletion

Question

Deleted Azure Bastion still visible in portal list after ARM deletion

Thomas 20

An Azure Bastion resource was successfully deleted. ARM confirms deletion: - az resource list with --resource-type Microsoft.Network/bastionHosts returns [] - Direct portal access returns 404 ResourceNotFound - Get-AzBastion returns no result

However, the resource is still shown in:

The Bastions list view -

The VM "Connect → Bastion" blade (status "Provisioning State: Succeeded")

This blocks deploying a new Bastion via the VM Connect blade. The AzureBastionSubnet in the VNet is clean (ipConfigurations: null, provisioningState: Succeeded).

Please advise how to clear the portal index cache for this stale entry.

Thank you very much.

Venkatesan S 10,830 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-11T12:35:27.6+00:00

Hi Thomas,

Thank you for contacting us about the azure bastion deletion issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Thanmayi Godithi 11,905 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-11T12:37:07.74+00:00
Thomas , Vielen Dank, dass Sie die detaillierten Validierungsschritte geteilt haben – sie bestätigen eindeutig, dass die Azure Bastion-Ressource auf ARM-/Kontrollebene-Ebene erfolgreich gelöscht wurde (CLI, PowerShell und direktes GET gibt 404 zurück).

Nach deinen Beobachtungen ist dieses Verhalten höchstwahrscheinlich auf den Azure Portal UI-Cache oder eine verzögerte Metadaten-Synchronisation zurückzuführen, bei der die Ressource in ARM nicht mehr vorhanden ist, aber in bestimmten Portal-Erfahrungen (Bastion-Liste und VM Connect Blade) weiterhin erscheint.

Bitte versuchen Sie die folgenden Schritte, um einen veralteten Portalzustand zu beseitigen:

Portal-Aktualisierung und Sitzungsreset

Melden Sie sich ab und melden Sie sich wieder im Azure-Portal an

Versuche, über einen anderen Browser oder eine InPrivate-Sitzung zuzugreifen

Reset Azure Portal Settings (löscht gecachte Metadaten)

Gehe zu Portal-→-Einstellungen → Standardeinstellungen wiederherstellen

Dies entfernt zwischengespeicherte Daten, einschließlich veralteter Ressourcenreferenzen [stackoverflow.com]

Erlauben Sie Backend-Propagation

In manchen Fällen kann die Verzögerung der Portal-Indizierung nach der Löschung eine Weile dauern, bevor alle Blades den aktualisierten Zustand widerspiegeln (nicht explizit dokumentiert, aber häufig in ARM/UI-Synchronisationsszenarien beobachtet)

Validiere nicht, dass abhängige Ressourcen verbleiben

Auch wenn dein Subnetz sauber ist, stelle sicher, dass keine verbleibenden Referenzen bleiben:

Öffentliche IP (falls zuvor zugeordnet)

Diagnostische Einstellungen oder Richtlinienartefakte

Azure-Ressourcen können Inkonsistenzen zeigen, wenn Abhängigkeiten noch abgestimmt werden.

Bitte lassen Sie uns wissen, ob das oben Genannte hilft oder Sie weitere Unterstützung bei diesem Thema benötigen.

Wenn die Antwort hilfreich ist, klicken Sie bitte auf "Antwort akzeptieren" und geben Sie ihr ein Upvote. Wenn Sie weitere Fragen zu dieser Antwort haben, klicken Sie bitte auf "Kommentar".
Thomas 20 Zuverlässigkeitspunkte

2026-05-11T13:04:38.1766667+00:00
Hello Thanmayi, Thank you for the suggestions and your quick reply.

I have already performed all of them:

Sign out / sign in / InPrivate browser session → no change

Restore default portal settings → no change

Public IP check via "az network public-ip list" returns empty (no orphaned IPs)

Diagnostic settings query returns ResourceNotFound (as expected, ARM has no record of the resource)

The AzureBastionSubnet is clean: ipConfigurations: null, state: Succeeded The stale entry persists in the Bastions list view and in the VM Connect → Bastion blade.

This appears to be a server-side portal index / metadata cache issue, not something resolvable from the customer side?
Thomas 20 Zuverlässigkeitspunkte

2026-05-11T13:04:50.4066667+00:00
Hello Thanmayi, Thank you for the suggestions and your quick reply.

I have already performed all of them:

Sign out / sign in / InPrivate browser session → no change

Restore default portal settings → no change

Public IP check via "az network public-ip list" returns empty (no orphaned IPs)

Diagnostic settings query returns ResourceNotFound (as expected, ARM has no record of the resource)

The AzureBastionSubnet is clean: ipConfigurations: null, state: Succeeded The stale entry persists in the Bastions list view and in the VM Connect → Bastion blade.

This appears to be a server-side portal index / metadata cache issue, not something resolvable from the customer side?
Thanmayi Godithi 11,905 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-11T13:28:14.8066667+00:00

Hi Thomas,

No worries, please share the details requested over Private message.

Antwort, die vom Frageautor angenommen wurde

0 zusätzliche Antworten

Ihre Antwort

Venkatesan S 10,830 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-11T12:35:27.6+00:00

Hi Thomas,

Thank you for contacting us about the azure bastion deletion issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Thomas 20 Zuverlässigkeitspunkte

2026-05-11T13:04:38.1766667+00:00

Hello Thanmayi, Thank you for the suggestions and your quick reply.

I have already performed all of them:

Sign out / sign in / InPrivate browser session → no change

Restore default portal settings → no change

Public IP check via "az network public-ip list" returns empty (no orphaned IPs)

Diagnostic settings query returns ResourceNotFound (as expected, ARM has no record of the resource)

The AzureBastionSubnet is clean: ipConfigurations: null, state: Succeeded The stale entry persists in the Bastions list view and in the VM Connect → Bastion blade.

This appears to be a server-side portal index / metadata cache issue, not something resolvable from the customer side?
Thomas 20 Zuverlässigkeitspunkte

2026-05-11T13:04:50.4066667+00:00

Hello Thanmayi, Thank you for the suggestions and your quick reply.

I have already performed all of them:

Sign out / sign in / InPrivate browser session → no change

Restore default portal settings → no change

Public IP check via "az network public-ip list" returns empty (no orphaned IPs)

Diagnostic settings query returns ResourceNotFound (as expected, ARM has no record of the resource)

The AzureBastionSubnet is clean: ipConfigurations: null, state: Succeeded The stale entry persists in the Bastions list view and in the VM Connect → Bastion blade.

This appears to be a server-side portal index / metadata cache issue, not something resolvable from the customer side?
Thanmayi Godithi 11,905 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-11T13:28:14.8066667+00:00

Hi Thomas,

No worries, please share the details requested over Private message.

Answer 1

Hi Thomas,

Willkommen auf der Microsoft Q&A-Plattform.

Ich übersetze den Inhalt derzeit von Englisch nach Deutsch. Bitte entschuldigen Sie eventuelle grammatikalische Fehler.

Wie bereits besprochen, wurde das Problem nun behoben. Dies bestätigt, dass das Verhalten durch eine Backend-Propagation-/Cache-Synchronisationsverzögerung verursacht wurde und nicht durch eine tatsächlich verbleibende Bastion-Ressource.

Dieses Verhalten ist bei Azure-Netzwerkressourcen relativ häufig, da mehrere Backend-Ebenen asynchron aktualisiert werden, darunter:

ARM-Ressourcenstatus
Resource Graph Index
Portal UX Cache
VM Connect Experience-Metadaten
Netzwerktopologie-Dienste

Selbst nachdem die Ressource vollständig gelöscht wurde, können einige Portalbereiche weiterhin veraltete Einträge anzeigen, bis die Backend-Abstimmung abgeschlossen ist.

Zur zukünftigen Referenz sind die wichtigsten Validierungsindikatoren:

Get-AzBastion liefert keine Ergebnisse zurück
az resource list zeigt keine Bastion-Ressource an Direkte Resource-GET-Anfrage gibt 404 zurück
AzureBastionSubnet ist getrennt/bereinigt

Sobald diese Validierungen bestätigt sind, handelt es sich in der Regel um ein kosmetisches bzw. Portalstatus-bezogenes Problem, das sich nach Abschluss der Backend-Synchronisierung normalerweise automatisch behebt.

Bitte geben Sie ein „Accept“, wenn die bereitgestellten Informationen hilfreich waren. Dies kann auch anderen Mitgliedern der Community zugutekommen.