In den letzten Tagen wollte ich das Azure Local System eines Kunden endlich von Release 2602 auf 2603 aktualisieren. Im Azure Portal wurde mir jedoch unerwarteterweise der Update Readiness Status des Azure Local Systems mit „Kritisch“ angezeigt und damit der Start des Update-Vorgangs verweigert! In diesem Blogbeitrag erfahren Sie, wie es zu dieser Problematik kommt und wie sie behoben werden kann.
Fehlersuche des kritischen Update Readiness Status über das Azure Portal
Ein Blick in das Ergebnis des Readiness Checks zeigte mir den fehlgeschlagenen „Test Network intent on existing cluster nodes“ als Ursache an:
Als “Remediation” wurde im Ergebnis des Tests benannt:
To check cluster network intent status, run below cmdlet on your cluster:
Get-NetIntentStatus
ConfigurationStatus should be "Success" ProvisioningStatus should be "Completed"Der entsprechend ausgeführte Befehl zeigte für alle Cluster Knoten eine fehlgeschlagene Konfiguration des Network ATC Netintents „compute_management“ und als Fehlerursache „PhysicalAdapterNotSymmetric“ an:
Eingrenzung der Fehlerquelle für den kritischen Update Readiness Status
Aufgrund dieser Fehlermeldung vermutete ich, dass die Ursache in einem Unterschied zwischen den physikalischen Netzwerkadaptern liegt, die dem NetItent „compute_management“ zugewiesen sind. Diese Vermutung wurde zunächst auch durch meine Frage an Copilot bestätigt.
Mögliche Ursachen hierfür könnten abweichende Treiber-/Firmware-Versionen, unterschiedliche Konfigurationen von Netzwerkadapter-Einstellungen oder -Beschreibungen oder nach einem OS-Update auf den Windows-Standard zurückgesetzte Netzwerkadapternamen oder Ähnliches sein.
Andererseits wunderte ich mich, da
- dieser Fehler (oder überhaupt ein Fehler) in der Update Readiness Prüfung vor den früheren Release Updates nie auf diesem System aufgetreten war,
- keine Treiber- und/oder Firmware-Updates außerhalb der Solution Builder Extension des OEMs im Zuge des Azure Local Update-Flows durchgeführt wurden und somit von einem identischen Patch- bzw. Versionsstand ausgegangen werden kann und
- die Konfiguration der physikalischen Netzwerkadapter bei der Implementierung auf allen Cluster-Knoten durch mich bzw. Net ATC über die NetIntent-Zuweisung identisch erfolgte und die seit Release 2601 beinhaltete Drift-Detection Abweichungen hier ggf. schon früher hätte finden müssen.
Aber auch der inzwischen hinzugezogene OEM-Support der hier vorliegenden Azure Local Premier Solution kam zu derselben Interpretation des Fehlerbildes. Also sammelte ich im nächsten Arbeitsschritt die entsprechenden Informationen von den Clusterknoten ein und verglich diese auf Differenzen untereinander. Das Ergebnis: Es gab keine!
Fehleranalyse und Troubleshooting mit den Azure Local Supportability Tools
Da ich bei der Sammlung der Informationen und dem Troubleshooting auf die Azure Local Supportability Tools zurückgegriffen habe, ist mir aufgefallen, dass es seit Februar 2026 eine neue Version der Tools gibt. Im Bereich „HostNetwork“ enthält diese nun Skripte, mit denen sich die Net-ATC-Konfiguration und damit das NetIntent überprüfen lässt. Ist das Zufall oder eine Ergänzung als Pendant, die zumindest ab Januar 2026 in der Update-Historie nachvollziehbar ist und „Test Network intent on existing cluster nodes“ ausführt?
Auch etwas anderes fiel mir dann in einem über den Get-AzsSupportHostNetworkDiagnosticData-Befehl eingesammelten Logs auch noch auf: Der „Test Network intent on existing cluster nodes“ führt selbst gar keine Prüfung der physikalischen Netzwerkadapter aus. Er prüft lediglich die Ergebniswerte „ConfigurationStatus“ und „ProvisioningStatus“ des Get-NetIntentStatus-Befehls und schlägt bei anderen Ergebnissen als „Success“ oder „Completed“ Alarm.
Sowohl ich als auch der Azure Local Support des OEMs hatten uns durch den dort angezeigten Fehler „PhysicalAdapterNotSymmetric” in die Irre leiten lassen und ihn als Ergebnis einer in dem Moment durchgeführten Prüfung der Netzwerkadapter verstanden.
Problemlösung für den bestehenden kritischen Update Readiness Status
Aufgrund der nicht feststellbaren Differenzen zwischen den Netzwerkadaptern war der nächste Schritt dann logischerweise zu versuchen, durch erneute Anwendung der NetIntent-Configuration „compute_management“ auf die hierfür vorgesehenen physikalischen Netzwerkadapter in einen „ConfigurationStatus: Success“ zukommen.
Hierzu verwendete ich den Set-AzsSupportNetworkATCIntentApplyWithTracing-Befehl um bei einem erneuten Fehler, die Ursache hierfür über die hier erzeugten Traces nachvollziehen zu können:
Da aber die NetItent-Anwendung jetzt auf beiden Cluster-Knoten erfolgreich abgeschlossen wurde, änderte sich tatsächlich auch der Get-NetIntentStatus wie erhofft auf „ConfigurationStatus: Success“:
Mit der nächsten täglichen Durchführung des Update Readiness Checks war damit dann auch der „Test Network intent on existing cluster nodes“ erfolgreich, und mit einem Update Readiness Status „Healthy“ konnte ich dann beruhigt und problemlos den Update-Vorgang anstoßen.
Microsoft Azure Beratung der Next Iteration
Gerne unterstützen wir Sie im Rahmen unserer Microsoft Azure Beratung bei Ihrem Azure Local Projekt und begleiten Sie strukturiert von der ersten Einordnung bis zur konkreten Umsetzung.
