Azure Virtual Machines
Ein Azure-Dienst zum Bereitstellen virtueller Windows- und Linux-Computer.
AzureVM internal network error
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(275.2, 81%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEH%3C/text%3E%3C/svg%3E)
Eckhard Hauenherm
0
Zuverlässigkeitspunkte
Ich keine keine meine Azure VMs starten, beenden, neuanwenden oder neudeployen. Ich bekomme immer einen "internal Network error"
Azure Virtual Machines
-
Eckhard Hauenherm 0 Zuverlässigkeitspunkte
2026-07-13T17:49:25.6966667+00:00 Die Fehlermeldung lautet: "NetworkingInternalOperationError"
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 4%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPC%3C/text%3E%3C/svg%3E)
Prasad Chaganti 775 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator2026-07-14T00:14:30.4533333+00:00 Hallo Eckhard Hauenherm,
Der Fehler “NetworkingInternalOperationError“ tritt auf, wenn Azure das Netzwerkprofil einer virtuellen Maschine (VM) während eines Vorgangs wie Starten, Beenden, Größenänderung, erneute Bereitstellung (Redeploy) oder anderer netzwerkbezogener Aktualisierungen nicht korrekt verarbeiten kann. Ursache können eine fehlerhafte NSG-/UDR-Konfiguration, ein veralteter oder beschädigter Zustand von Netzwerkressourcen (häufig Netzwerkschnittstellen (NICs)) oder vorübergehende Backend-/Plattformprobleme sein.
Nachfolgend finden Sie die empfohlenen Schritte zur Fehlerbehebung (in der Reihenfolge, die üblicherweise am schnellsten zum Erfolg führt):
1) Azure Service Health überprüfen
- Stellen Sie sicher, dass in Ihrer Region keine laufende Störung oder kein Vorfall im Zusammenhang mit dem Netzwerkdienst vorliegt. Überprüfen Sie dies über Azure Service Health: https://azure.status.microsoft/en-us/status
Falls eine Störung vorliegt, warten Sie bitte, bis diese behoben wurde.
2) Vorgang erneut ausführen (falls es sich um ein vorübergehendes Problem handelt)
- Vorübergehende Probleme können sich innerhalb von bis zu vier Stunden automatisch beheben.
- Führen Sie den gewünschten Vorgang erneut aus (Beispiel: Starten einer VM):
az vm start --name <vm-name> --resource-group <resource-group-name>3) NSG-Regeln überprüfen (insbesondere für RDP/SSH)
Wenn es sich um eine Windows-VM handelt, stellen Sie sicher, dass eingehender RDP-Datenverkehr über Port 3389 zugelassen ist.
Wenn es sich um eine Linux-VM handelt, stellen Sie sicher, dass eingehender SSH-Datenverkehr über Port 22 zugelassen ist.
Überprüfen Sie die NSG-Regeln, die der NIC oder dem Subnetz zugeordnet sind:
az network nsg rule list --resource-group <resource-group-name> --nsg-name <nsg-name>Passen Sie die Regeln bei Bedarf im Azure-Portal oder über die CLI an.
4) Benutzerdefinierte Routen (UDRs) überprüfen
Fehlkonfigurierte Routen können die Netzwerkkonnektivität der VM beeinträchtigen. Überprüfen Sie die UDRs für das betreffende Subnetz oder virtuelle Netzwerk (VNet) und korrigieren oder entfernen Sie problematische Routen.
Beispiel zum Aktualisieren einer Route:
az network route-table route update --resource-group <resource-group-name> \ --route-table-name <route-table-name> --name <route-name> --next-hop-type <next-hop>5) Zustand der Netzwerkschnittstelle (NIC) prüfen und zurücksetzen (häufige Lösung)
Da dieser Fehler häufig mit NICs zusammenhängt, die sich in einem fehlerhaften Zustand befinden, überprüfen Sie zunächst die NIC:
az network nic show --name <nic-name> --resource-group <resource-group-name>Falls sich die NIC im Status „Failed“ befindet, können Sie sie zurücksetzen:
- NIC trennen:
az vm nic remove --resource-group <resource-group-name> --vm-name <vm-name> --nic-name <nic-name>- NIC erneut hinzufügen:
az vm nic add --resource-group <resource-group-name> --vm-name <vm-name> --nic-name <nic-name>6) Netzwerkdiagnose mit Azure Network Watcher durchführen
Falls die Konnektivität beeinträchtigt ist, verwenden Sie die Verbindungsprüfungen von Azure Network Watcher.
Beispiel für Windows-VMs (PowerShell):
Test-NetConnection -ComputerName <target-ip-or-url> -Port <port-number>7) Ressourcensperren überprüfen
Stellen Sie sicher, dass keine einschränkenden Sperren (z. B. „Read-only“ oder „Delete“) für die VM, die NIC oder das Subnetz konfiguriert sind.
- Überprüfen Sie dies im Azure-Portal unter Einstellungen > Sperren (Locks).
8) Neustarten, neu bereitstellen oder freigeben (Deallocate)
- Neustarten:
- Neu bereitstellen (verschiebt die VM auf einen anderen Host und kann Backend-Probleme beheben):
az vm redeploy --name <vm-name> --resource-group <resource-group-name>Wenn das Problem weiterhin besteht, geben Sie die VM frei und starten Sie sie erneut:
az vm deallocate --name <vm-name> --resource-group <resource-group-name> az vm start --name <vm-name> --resource-group <resource-group-name>9) Überprüfung nach jeder Maßnahme
Nach jedem Schritt sollten Sie bestätigen, dass:
- Der VM-Vorgang erfolgreich abgeschlossen wurde und die VM den Status „Running“ erreicht.
- Die Konnektivität funktioniert (RDP für Windows bzw. SSH für Linux).
Rückfragen zur schnelleren Eingrenzung der Ursache
- Handelt es sich um eine Windows- oder Linux-VM?
- Welcher Vorgang schlägt fehl (Starten, Beenden, Größenänderung, Redeploy oder ein anderer Vorgang)?
- Werden im Aktivitätsprotokoll (Activity Log) oder in den Bereitstellungsprotokollen zusätzliche Hinweise auf NICs, Subnetze oder das Netzwerkprofil angezeigt?
- In welchem Zustand befinden sich die NICs der VM (insbesondere, ob eine NIC den Status „Failed“ aufweist)?
- Verwenden Sie benutzerdefinierte Routen (UDRs) oder restriktive NSG-Regeln auf NIC- oder Subnetzebene?
- Betrifft das Problem nur eine einzelne VM oder mehrere VMs innerhalb desselben Subnetzes, VNets oder derselben Region?
Referenzen
Azure VM-Fehlermeldungen: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/error-messages
Problembehandlung bei VM-Konnektivität: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-network/troubleshoot-vm-connectivity
Azure Network Watcher – Verbindungsüberwachung: https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-overview
- Azure Service Health: https://azure.status.microsoft/en-us/status
- Zusätzliche Referenz für interne RDP-Fehler (nur relevant, falls neben dem VM-Problem auch RDP-Verbindungsfehler auftreten): https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-rdp-internal-error
-
Eckhard Hauenherm 0 Zuverlässigkeitspunkte
2026-07-16T16:27:31.5033333+00:00 Zu den Fragen:
- Es handelt sich um Windows-VMs
- Alle Vorgängen, die genannt werden schlagen fehl. Ich kann nichts davon ausführen und bekommen jedesmal den selben Fehler NetworkingInternalOperationError
- Es gibt keine zugehörigen Einträge im Activity oder einem anderen Log.
- Die NICs werden als "Succeeded" angezeigt
- Es gibt keine benutzerdefinierten Routen oder NSG-Regeln
- Das Problem betrifft alle VMs in derselben Ressourcengruppe, bis auf eine, die eine eigene NSG hat, aber im selben Subnetz liegt. Alle eingesetzten Komponenten liegen in derselbe Ressourcengruppe.
-
Prasad Chaganti 775 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator
2026-07-17T17:50:51.4433333+00:00 Hallo Eckhard Hauenherm,
vielen Dank für die Rückmeldung und die zusätzlichen Informationen.
Basierend auf den bereitgestellten Angaben verstehen wir Folgendes:
- Die betroffenen virtuellen Maschinen sind Windows-VMs.
- Alle netzwerkbezogenen Vorgänge schlagen mit demselben Fehler fehl: NetworkingInternalOperationError.
- Weder im Aktivitätsprotokoll noch in anderen verfügbaren Protokollen sind relevante Einträge vorhanden.
- Die Netzwerkschnittstellen (NICs) werden mit dem Bereitstellungsstatus „Erfolgreich“** **(Succeeded) angezeigt.
- Es sind keine benutzerdefinierten Routentabellen oder NSG-Regeln konfiguriert.
- Das Problem betrifft alle VMs in derselben Ressourcengruppe, mit Ausnahme einer VM, die über ein eigenes NSG verfügt, sich jedoch im gleichen Subnetz befindet.
Vielen Dank für die Bestätigung dieser Punkte.
Da das Problem mehrere VMs betrifft und netzwerkbezogene Vorgänge trotz eines fehlerfreien Zustands der NIC-Ressourcen wiederholt fehlschlagen, werden wir die Untersuchung auf Azure-Plattformebene fortsetzen. Ziel ist es festzustellen, ob eine zugrunde liegende Abhängigkeit oder ein Problem in der Steuerungsebene (Control Plane) zu dem Fehler NetworkingInternalOperationError beiträgt.
Um die Analyse weiterzuführen, bitten wir Sie, die folgenden Informationen in einer privaten Nachricht bereitzustellen:
- Einen Screenshot einer fehlgeschlagenen Aktion mit der vollständigen Fehlermeldung.
- Die genaue Aktion, die ausgeführt wird, wenn der Fehler auftritt (z. B. Starten, Beenden, Neustart, Redeploy, Größenänderung, NIC anfügen, NSG aktualisieren usw.).
- Den Zeitstempel des letzten fehlgeschlagenen Versuchs einschließlich Zeitzone.
- Die Ressourcen-ID einer betroffenen VM sowie einer nicht betroffenen VM zum Vergleich.
Sobald wir diese Informationen erhalten haben, werden wir sie mit den Backend-Telemetriedaten korrelieren und die Untersuchung fortsetzen.
-
Eckhard Hauenherm 0 Zuverlässigkeitspunkte
2026-07-22T07:08:55.97+00:00 Ich habe das Problem jetzt eingrenzen können. Wenn ich die NICs anzupassen versuche, bekommen ich die Meldung, dass sie im Status "failed" sind. Ich habe daraufhin neu NICs den Maschinen angefügt und die alten entfernt. Dann lassen die Maschinen sich wieder starten. Allerdings kann ich den neuen NICs keine Public IPs zuweisen, da ich noch einen Loadbalancer mit SKU Basic im Subnet laufen habe. Die SKU kann ich dort aber nicht ändern. Ich werde also wohl einen neuen Loadbalancer implementieren müssen. Den alten habe ich als ARM-Template exportiert.
-
Prasad Chaganti 775 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator
2026-07-22T20:09:52.6966667+00:00 Hallo Eckhard Hauenherm,
vielen Dank für das Update und für die Informationen zu Ihren Erkenntnissen.
Basierend auf den von Ihnen bereitgestellten Informationen scheint die Ursache des Problems mit den ursprünglichen Netzwerkschnittstellen (NICs) zusammenzuhängen, die sich im Status „Failed“ befanden. Nachdem Sie neue NICs erstellt, diese den virtuellen Maschinen zugeordnet und die fehlerhaften NICs entfernt haben, konnten die betroffenen VMs erfolgreich gestartet werden. Dies bestätigt, dass der fehlerhafte Zustand der NICs die erfolgreichen VM-Vorgänge verhindert hat.
Bezüglich des Problems mit der Zuweisung öffentlicher IP-Adressen ist Ihre Beobachtung korrekt. Da das Subnetz derzeit einen Basic SKU Load Balancer verwendet, können die neuen NICs nicht mit Netzwerkressourcen konfiguriert werden, die eine andere SKU erfordern. Die Migration zu einem Standard SKU Load Balancer ist der von Microsoft unterstützte Weg. Die Microsoft-Dokumentation weist darauf hin, dass Basic- und Standard-Load-Balancer-Ressourcen nicht gemeinsam verwendet werden können und empfiehlt die Migration von Basic Load Balancern zu Standard Load Balancern.
Referenzdokument:
Es ist erfreulich zu hören, dass Sie die bestehende Load-Balancer-Konfiguration bereits als ARM-Vorlage exportiert haben. Dies wird dabei helfen, die Konfiguration im Rahmen der Migration einfacher wiederherzustellen.
Könnten Sie uns bitte zu den folgenden Punkten eine Rückmeldung geben:
- Laufen alle betroffenen virtuellen Maschinen inzwischen erfolgreich mit den neuen NICs?
- Benötigen Sie Unterstützung bei der Migration vom Basic- zum Standard-Load-Balancer?
- Gibt es noch weitere Verbindungs- oder Netzwerkprobleme, abgesehen von der Einschränkung bei der Zuweisung öffentlicher IP-Adressen?
Sobald wir Ihre Rückmeldung erhalten, beraten wir Sie gerne zu den nächsten Schritten.Hallo Eckhard Hauenherm,
Zum Kommentieren anmelden
Anmelden, um zu antworten