Freigeben über

Behandeln von Problemen mit Wartungskonfigurationen

  • Artikel

In diesem Artikel werden häufige Probleme und Fehler beschrieben, die während der Bereitstellung oder Verwendung von Wartungskonfigurationen für geplantes Patchen auftreten können, sowie Strategien zur effektiven Behebung.

Ein virtueller Computer wird heruntergefahren und reagiert nicht, wenn Sie einen statischen Bereich in der Gastwartung verwenden.

Problem

Eine Wartungskonfiguration installiert keinen geplanten Patch auf den virtuellen Computern und gibt einen ShutdownOrUnresponsive-Fehler aus.

Lösung

In einem statischen Bereich ist es von entscheidender Bedeutung, sich nicht auf veraltete VM-Konfigurationen zu verlassen. Daher müssen Sie sicherstellen, dass die VM in Betrieb ist, während der Patch installiert wird. Wenn die VM-Instanz mit demselben Namen neu erstellt wird, müssen Sie die Konfiguration priorisieren, nachdem die VM-Instanz neu erstellt wurde.

Das System führt diese Aktion automatisch innerhalb von 12 Stunden nach der Erholung durch, wenn sie nicht vom Benutzer ausgeführt wird. Wenn die Wartungskonfiguration der angefügten neu erstellten VM innerhalb von 12 Stunden nach der Neuerstellung der VM mit demselben Namen ausgelöst wird, wird ein ShutdownOrUnresponsive-Fehler angezeigt. Daher wird empfohlen, entweder die zuvor erwähnte Aktion auszuführen oder 12 Stunden zu warten, bevor Sie den Patch über die Wartungskonfiguration auf den Computer anwenden.

Geplante Zeitüberschreitungen oder Fehler beim Patching

Problem

Geplantes Patchen schlägt mit dem Fehler TimeOut oder Failed fehl, nachdem Sie einen virtuellen Computer verschoben haben, indem Sie ihn erneut mit demselben Namen in einer anderen Region erstellt haben. Das Portal zeigt möglicherweise zweimal denselben virtuellen Computer an, da der zuvor erstellte virtuelle Computer aus dem Back-End entfernt wird.

Lösung

Wenn die VM-Instanz mit demselben Namen neu erstellt wird, ist es wichtig, die Neuzuweisung der Konfiguration zu priorisieren, nachdem die VM-Instanz in einer anderen Region neu erstellt wurde.

Das System führt diese Aktion automatisch innerhalb von 12 Stunden nach der Erholung durch, wenn sie nicht vom Benutzer ausgeführt wird. Wenn die Wartungskonfiguration der angefügten neu erstellten VM innerhalb von 12 Stunden nach der Neuerstellung des virtuellen Computers mit demselben Namen ausgelöst wird, wird ein TimeOut- oder Failed- Fehler angezeigt. Daher wird empfohlen, entweder die zuvor erwähnte Aktion auszuführen oder 12 Stunden zu warten, bevor Sie den Patch über die Wartungskonfiguration auf den Computer anwenden.

Die Konfigurationszuweisung konnte nicht gelöscht werden

Problem

Die Konfigurationszuweisung konnte nicht aus einer bestimmten Wartungskonfiguration entfernt oder gelöscht werden.

Lösung

Führen Sie die folgenden Schritte aus, um das Problem zu lösen:

  1. Löschen Sie die vorhandene Wartungskonfiguration, in der dieses Problem auftritt.
  2. Erstellen Sie eine neue Wartungskonfiguration und weisen Sie den erforderlichen Satz von dynamischen Bereichen und VMs zu, wie in der gelöschten Wartungskonfiguration angehängt.

Wenn Sie eine neue Wartungskonfiguration mit demselben Namen wie die gelöschte Wartungskonfiguration erstellen möchten, müssen Sie 20 Minuten warten, bis die Bereinigung im Back-End erfolgt ist. Das System lässt die Erstellung einer Wartungskonfiguration mit demselben Namen nicht zu, wenn im Back-End keine Bereinigung vorgenommen wird.

Geplantes Patchen funktioniert nicht mehr, nachdem die Ressource verschoben wurde

Problem

Wenn Sie eine Ressource in eine andere Ressourcengruppe oder ein anderes Abonnement verschieben, funktioniert das geplante Patching für die Ressource nicht mehr.

Lösung

Das System unterstützt derzeit kein Verschieben von Ressourcen über Ressourcengruppen oder Abonnements hinweg. Verwenden Sie als Problemumgehung die folgenden Schritte für die Ressource, die Sie verschieben möchten. Entfernen Sie als Voraussetzung zuerst die Zuweisung, bevor Sie die Schritte ausführen.

Wenn Sie einen static-Bereich verwenden:

  1. Verschieben der Ressource in eine andere Ressourcengruppe oder ein anderes Abonnement.
  2. Erstellen Sie die Ressourcenzuordnung neu.

Wenn Sie einen dynamic-Bereich verwenden:

  1. Initiieren Sie die nächste geplante Ausführung, oder warten Sie, bis sie ausgeführt wird. Mit dieser Aktion wird das System aufgefordert, die Zuweisung vollständig zu entfernen, damit Sie mit den nächsten Schritten fortfahren können.
  2. Verschieben der Ressource in eine andere Ressourcengruppe oder ein anderes Abonnement.
  3. Erstellen Sie die Ressourcenzuordnung neu.

Wenn einer der Schritte ausgelassen wird, verschieben Sie die Ressource in die vorherige Ressourcengruppe oder Abonnement-ID, und wiederholen Sie die Schritte.

Hinweis

Wenn die Ressourcengruppe gelöscht wird, erstellen Sie sie mit demselben Namen neu. Wenn die Abonnement-ID gelöscht wird, wenden Sie sich zur Entschärfung an das Supportteam.

Die Wartungskonfiguration wurde nicht am konfigurierten Datum bzw. zur konfigurierten Uhrzeit ausgelöst.

Problem

Nachdem Sie eine Wartungskonfiguration mit dem Wiederholungswert „Woche“ oder „Monat“ erstellt haben, erwarten Sie, dass der Zeitplan am angegebenen Datum und zur angegebenen Uhrzeit beginnt und dann basierend auf dem ausgewählten Intervall wiederholt wird. Der Zeitplan wurde jedoch nicht am Startdatum und zur Startzeit ausgelöst.

Lösung

Die erste Ausführung der Wartungskonfiguration erfolgt zum ersten Wiederholungswert nach dem angegebenen Startdatum, nicht unbedingt am Startdatum selbst. Wenn die Wartungskonfiguration beispielsweise am 17. Januar (Mittwoch) beginnt und jeden Montag wiederholt wird, erfolgt die erste Ausführung des Zeitplans am ersten Montag nach dem 17. Januar, also am 22. Januar.

Sie können die ersten vier Instanzen der geplanten Ausführung anzeigen, wenn Sie eine neue Wartungskonfiguration über das Azure-Portal erstellen.

Fehler beim Erstellen eines dynamischen Bereichs

Problem

Sie können aufgrund der rollenbasierten Zugriffssteuerung keinen dynamischen Bereich erstellen.

Lösung

Um einen dynamischen Bereich erstellen zu können, müssen Sie über die Berechtigung auf Abonnementebene oder auf Ressourcengruppenebene verfügen. Im Folgenden sind die Anforderungen aufgeführt, die Sie erfüllen müssen.

  1. Das Abonnement, unter dem der dynamische Bereich erstellt wird, sollte für Wartungs-RP registriert werden.
  2. Es wird empfohlen, die Rolle „Mitwirkender am geplanten Patching“ den folgenden Bereichen zuzuweisen:
    1. Die Abonnement-/Ressourcengruppe, in der der dynamische Bereich erstellt wird.
    2. Der Wartungskonfigurationsbereich.

Weitere Informationen finden Sie hier in der Liste der Berechtigungen für verschiedene Ressourcen.

Ein Update bleibt hängen und wird nicht ausgeführt.

Problem

Gilt für: ✔️ dedizierte Hosts ✔️ VMs

Wenn Sie eine Ressource in einem anderen Cluster erneut bereitstellen und eine ausstehende Updateanforderung unter Verwendung des alten Clusterwerts erstellen, bleibt die Anforderung auf unbestimmte Zeit hängen.

Lösung

Wenn der Status eines Vorgangs zum Anwenden eines Updates geschlossen oder nicht gefunden wird, versuchen Sie es nach 120 Stunden erneut. Sollte das Problem weiterhin bestehen, erhalten Sie vom Supportteam Unterstützung.

Ein dedizierter Host wird nach dem Anfügen der Wartungskonfiguration aktualisiert.

Problem

Eine Wartungskonfiguration blockiert das Update eines dedizierten Hosts nicht, und der Host wird auch nach dem Anfügen einer Wartungskonfiguration aktualisiert.

Lösung

Wenn ein dedizierter Host mit demselben Namen neu erstellt wird, behalten die Wartungskonfigurationen die alte dedizierte Host-ID bei und verhindern dadurch, dass Updates blockiert werden. Sie können dieses Problem beheben, indem Sie die Wartungskonfiguration entfernen und neu zuweisen. Das System führt diese Aktion automatisch innerhalb von 12 Stunden nach der Erholung durch, wenn sie nicht vom Benutzer ausgeführt wird. Es wird empfohlen, entweder die zuvor erwähnte Aktion auszuführen oder 12 Stunden zu warten, bevor diese Aktion automatisch ausgeführt wird.

Ein Zeitplan wird nicht ausgelöst

Problem

Wenn eine Ressource über zwei Wartungskonfigurationen mit der gleichen Auslöserzeit und Patchinstallationskonfiguration verfügt und beide derselben VM oder Ressource zugewiesen sind, wird nur eine Wartungskonfiguration ausgelöst.

Lösung

Ändern Sie die Startzeit einer der Wartungskonfigurationen, um das Problem zu beheben. Dies ist eine Problemumgehung für eine aktuelle Systembeschränkung, bei der Wartungskonfigurationen nicht identifizieren können, welche Wartungskonfiguration ausgelöst werden soll.

Sie können keinen dynamischen Bereich für eine Ressourcengruppe erstellen.

Problem

Dynamische Bereichsüberprüfung schlägt aufgrund eines NULL-Werts am Speicherort fehl.

Lösung

Dieses Problem mit der dynamischen Bereichsprüfung führt zu Regression im Überprüfungsprozess. Es wird empfohlen, dass Sie die erforderlichen Positionen für einen dynamischen Bereich auf Ressourcengruppenebene bereitstellen.

Ein dynamischer Bereich wird nicht ausgeführt und keine Ressourcen werden gepatcht

Problem

Aufgrund der Drosselung tritt beim Vereinfachen des dynamischen Bereichs ein Fehler auf, und der Dienst kann nicht ermitteln, welche virtuellen Computer der VM zugeordnet sind.

Lösung

Stellen Sie sicher, dass die Anzahl der Abonnements pro dynamischem Bereich nicht größer als 200 ist. Erfahren Sie mehr über die Dienstgrenzen für dynamische Bereiche.

Die Zuweisung der Konfiguration eines dedizierten Hosts wird nach dem Entfernen des Hosts nicht bereinigt

Problem

Nach dem Löschen der dedizierten Hosts sind noch Konfigurationszuweisungen vorhanden, die dedizierten Hosts zugeordnet sind.

Lösung

Stellen Sie vor dem Löschen eines dedizierten Hosts sicher, dass Sie auch die zugehörige Wartungskonfiguration löschen. Wenn der dedizierte Host gelöscht wurde, aber weiterhin im Portal angezeigt wird, wenden Sie sich an das Supportteam. Für dedizierte Hosts sind derzeit Bereinigungsprozesse vorhanden, die sicherstellen, dass es keine Auswirkungen auf die Kunden hat.

Sie können nicht mehrere Tagwerte für den dynamischen Umfang bereitstellen

Problem

Falls Sie das Azure-Portal verwenden, können Sie nicht mehrere Tagwerte für den dynamischen Umfang bereitstellen.

Lösung

Dieses Feature steht im Portal zurzeit nicht zur Verfügung. Sie können die Azure CLI oder Azure PowerShell als Problemumgehung verwenden, um einen dynamischen Bereich zu erstellen. Das System akzeptiert mehrere Werte für Tags, wenn Sie die Azure CLI- oder Azure PowerShell-Option verwenden.

Eine Wartungskonfiguration wurde erneut mit älterer Triggerzeit ausgelöst

Problem

Es gibt ein bekanntes Problem in Wartungskonfigurationen im Zusammenhang mit dem Zwischenspeichern alter Wartungsrichtlinien. Wenn eine alte Richtlinie zwischengespeichert wird und eine neue Instanz die Verarbeitung der neuen Richtlinie verschiebt, kann der alte Computer den Zeitplan mit der veralteten Startzeit auslösen.

Lösung

Wir empfehlen, die Wartungskonfiguration mindestens 1 Stunde vor der geplanten Zeit zu aktualisieren. Sollte das Problem weiterhin bestehen, erhalten Sie vom Supportteam Unterstützung.

Zeitüberschreitung bei der Wartungskonfiguration beim Warten auf den Abschluss eines laufenden Updates für eine Ressource

Problem

In seltenen Fällen kann es passieren, dass das Hostupdatefenster mit einem Patchfenster für die Gast-VM zusammenfällt. Wenn das Gast-Patchfenster nach dem Hostupdate nicht genügend Zeit für die Ausführung erhält, zeigt das System die folgende Fehlermeldung an: „Timeout für Zeitplan, es wird darauf gewartet, dass die Ressource durch ein fortlaufendes Update abgeschlossen wird.“ Der Grund dafür ist, dass die Plattform jeweils nur ein Update zulässt.

Lösung

Ändern Sie den Wartungskonfigurationszeitplan für das Gastupdate für eine Zeit nach Abschluss des laufenden Updates.

Neue Wartungskonfiguration behält Attribute der gelöschten Konfiguration bei

Problem

Eine neu erstellte Wartungskonfiguration mit demselben Namen wie eine zuvor gelöschte Konfiguration erbt Eigenschaften von der gelöschten Konfiguration.

Lösung

Stellen Sie zwischen dem Löschen einer Wartungskonfiguration und dem Erstellen einer neuen Konfiguration mit demselben Namen eine minimale Wartezeit von 20 Minuten sicher. Sollte das Problem weiterhin bestehen, erhalten Sie vom Supportteam Unterstützung.

Wartungszuweisung schlägt mit InternalServerError-Fehler fehl

Problem

Die Wartungszuweisung schlägt bei Verwendung der Bicep-Vorlage oder der MRP-API mit InternalServerError fehl. Die Zuweisung kann erfolgreich mithilfe des Portal oder der CLI oder PowerShell durchgeführt werden.

Lösung

Es wird empfohlen, den Standort/die Region in einem normalisierten Formular für die Bicep-Vorlage und die MRP-API zu verwenden. Das normalisierte Formular umfasst das Entfernen von Leerzeichen und das Konvertieren des Texts in Kleinbuchstaben. EAST US 2 führt beispielsweise zu einem internen Serverfehler, während eastus2 erfolgreich verarbeitet wird.

Wartungskonfigurationen unterstützen keine API

Das Feature unterstützt folgende APIs derzeit nicht.

  • Abrufen von „Update anwenden“ auf Abonnementebene
  • Abrufen von „Update anwenden“ auf Ressourcengruppenebene
  • Abrufen von „Ausstehendes Update“ auf Abonnementebene
  • Abrufen von „Ausstehendes Update“ auf Ressourcengruppenebene