Behandeln von Problemen mit Wartungskonfigurationen
In diesem Artikel werden häufige Fehler beschrieben, die während der Bereitstellung oder Verwendung der Wartungskonfiguration für geplantes Patchen auftreten können, sowie Strategien zur effektiven Behebung.
Heruntergefahrene und nicht reagierende VM bei Verwendung des dynamic-Bereichs in Gastwartung
Abgang
Geplantes Patching installiert die Patches nicht auf den virtuellen Computern (VMs) und führt zu einem Fehler ShutdownOrUnresponsive
Lösung
Es dauert 12 Stunden, bis der Bereinigungsprozess für die Wartungskonfigurationszuweisung abgeschlossen ist. Achten Sie daher darauf, den Puffer von 12 Stunden beizubehalten, bevor Sie den virtuellen Computer mit demselben Namen neu erstellen. Wenn vor der Bereinigung eine neue VM mit demselben Namen neu erstellt wird, kann der Wartungskonfigurationsdienst den Zeitplan nicht auslösen.
Heruntergefahrene und nicht reagierende VM bei Verwendung des static-Bereichs in Gastwartung
Abgang
Geplantes Patching installiert die Patches nicht auf den virtuellen Computern und führt zu einem Fehler ShutdownOrUnresponsive
Lösung
In einem statischen Bereich ist es für Kunden von entscheidender Bedeutung, sich nicht auf veraltete VM-Konfigurationen zu verlassen. Stattdessen sollten sie das erneute Zuweisen von Konfigurationen priorisieren, wenn Instanzen neu erstellt wurden.
TimeOut- oder Failed Scheduled Patching Job
Abgang
Geplantes Patchen schlägt mit einem Fehler TimeOut oder Failed fehl, nachdem der virtuelle Computer in eine andere Region verschoben wurde.
Lösung
Wenn eine VM mit demselben Namen neu erstellt wird, aber in einer anderen Region, schlägt die Patchinstallation möglicherweise mit dem Fehler TimeOut oder Failed fehl. Das Portal zeigt möglicherweise zweimal denselben virtuellen Computer an, da der zuvor erstellte virtuelle Computer aus dem Back-End entfernt wird. Dieser Fehler ist dem Team bekannt, und das Team arbeitet daran, ihn zu beseitigen. Wenn dieses Problem auftritt, wenden Sie sich an das Supportteam, um sofortige Hilfe zu erhalten.
Geplantes Patchen funktioniert nicht mehr, nachdem die Ressource verschoben wurde
Abgang
Wenn eine Ressource in eine andere Ressourcengruppe oder ein anderes Abonnement verschoben wird, funktioniert das geplante Patching für die Ressource nicht mehr.
Lösung
Die Funktion für die Ressourcenverschiebung oder Wartungskonfigurationsverschiebung wird derzeit vom System nicht unterstützt. Das Team arbeitet daran, diese Funktion bereitzustellen, aber in der Zwischenzeit als Problemumgehung für die Ressource, die Sie verschieben möchten (im statischen Bereich)
- Entfernen Sie die Zuweisung.
- Verschieben der Ressource in eine andere Ressourcengruppe oder ein anderes Abonnement.
- Erstellen Sie die Zuweisung erneut.
Im dynamischen Bereich sind die Schritte ähnlich, aber nach dem Entfernen der Zuweisung in Schritt 1 müssen Sie einfach die nächste geplante Ausführung initiieren oder auf sie warten. Mit dieser Aktion wird das System aufgefordert, die Zuweisung vollständig zu entfernen, sodass Sie mit den Schritten 2 und 3 fortfahren können.
Wenn Sie eines der oben genannten Schritte vergessen/verpassen, können Sie die Ressource erneut der ursprünglichen Zuweisung zuweisen und die Schritte erneut sequenziell wiederholen.
Fehler bei der Erstellung dynamischer Bereiche
Abgang
Fehler beim Erstellen eines dynamischen Bereichs aufgrund der rollenbasierten Zugriffssteuerung (RBAC)
Lösung
Um einen dynamischen Bereich erstellen zu können, müssen Benutzer*innen über die erforderliche Berechtigung auf Abonnementebene oder auf Ressourcengruppenebene verfügen. Weitere Informationen finden Sie in der Liste der Berechtigungen für verschiedene Ressourcen.
Anwendung des Updates bleibt hängen, und Update wird nicht ausgeführt
Abgang
Gilt für: ✔️ dedizierte Hosts ✔️ VMs
Das vom Benutzer initiierte Update bleibt lange hängen und das Update wird nicht ausgeführt.
Lösung
Wenn eine Ressource in einem anderen Cluster erneut bereitgestellt wird und eine ausstehende Updateanforderung unter Verwendung des alten Clusterwerts erstellt wird, bleibt die Anforderung auf unbestimmte Zeit hängen. Wenn der Status des angewendeten Aktualisierungsvorgangs geschlossen/nicht gefunden wird, versuchen Sie es nach 120 Stunden erneut. Wenn das Problem weiterhin besteht, wenden Sie sich an das Supportteam, um Abhilfe zu erhalten.
Dedizierte Hostupdates auch nach dem Anfügen der Wartungskonfiguration
Abgang
Dediziertes Hostupdate wird nicht durch die Wartungskonfiguration blockiert und auch nach dem Anfügen der Wartungskonfiguration aktualisiert.
Lösung
Wenn ein dedizierter Host mit demselben Namen neu erstellt wird, behält der Wartungskonfigurationsdienst die alte dedizierte Host-ID bei und verhindert dadurch, dass Updates blockiert werden. Kunden können dieses Problem beheben, indem Sie die Wartungskonfiguration entfernen und sie neu zuweisen. Wenn das Problem weiterhin besteht, wenden Sie sich an das Supportteam, um weitere Unterstützung zu erhalten.
Fehler beim Installieren des Patchvorgangs für ungültigen Klassifizierungstyp
Abgang
Fehler beim Patchinstallationsvorgang aufgrund eines ungültigen Klassifizierungstyps in der Wartungskonfiguration.
Lösung
Aufgrund eines vorherigen Fehlers konnte der Systempatchvorgang keine Überprüfung durchführen, und in der Wartungskonfiguration wurde ein ungültiger Klassifizierungstyp gefunden. Der Fehler wurde behoben und bereitgestellt. Um dieses Problem zu beheben, können Kunden die Wartungskonfiguration aktualisieren und den richtigen Klassifizierungstyp festlegen.
Zeitplan wird nicht ausgelöst
Abgang
Wenn eine Ressource über zwei Wartungskonfigurationen mit der gleichen Auslöserzeit und Installationspatchkonfiguration verfügt und beide derselben VM/Ressource zugewiesen sind, wird nur eine Wartungskonfiguration ausgelöst.
Lösung
Ändern Sie die Startzeit einer der Wartungskonfigurationen, um das Problem zu beheben. Es handelt sich um eine bekannte Systemeinschränkung, aufgrund der die Wartungskonfiguration nicht identifizieren kann, welche Wartungskonfiguration ausgelöst wird. Das Team arbeitet daran, diese Einschränkung zu beheben.
Dynamischer Umfang kann nicht erstellt werden (auf Ressourcengruppenebene)
Abgang
Dynamische Bereichsüberprüfung schlägt aufgrund eines NULL-Werts am Speicherort fehl.
Lösung
Aufgrund dieses Problems bei der Überprüfung dynamischer Bereiche erfolgt eine Regression im Überprüfungsprozess. Es wird empfohlen, dass Kunden die erforderlichen Positionen für den dynamischen Umfang auf Ressourcengruppenebene bereitstellen.
Dynamischer Bereich nicht ausgeführt und keine Ressourcen gepatcht
Abgang
Die dynamische Umfangsreduzierung ist aufgrund der Drosselung fehlgeschlagen, und der Dienst kann die Liste der VMs, die mit der VM verbunden sind, nicht ermitteln.
Lösung
Dieses Problem kann aufgrund der Anzahl der Abonnements pro dynamischem Bereich auftreten. Diese sollte kleiner als 30 sein. Weitere Informationen zu den Diensteinschränkungen der dynamischen Umfangsdefinitionen finden Sie auf dieser Seite.
Zuweisung der dedizierten Hostkonfiguration wird nach dem Entfernen des dedizierten Hosts nicht bereinigt
Abgang
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 worden ist, 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.
Bereitstellung mehrerer Tagwerte für den dynamischen Umfang nicht möglich
Abgang
Portalbenutzer sind möglicherweise nicht in der Lage, mehrere Tagwerte für den dynamischen Umfang bereitzustellen
Lösung
Dieses Verhalten ist eine bekannte Einschränkung auf dem Portal. Das Team arbeitet daran, dieses Feature auch im Portal zugänglich zu machen. In der Zwischenzeit können Kunden jedoch CLI/PowerShell verwenden, um einen dynamischen Umfang zu erstellen. Das System akzeptiert mehrere Werte für ein Tag unter Verwendung der CLI/PowerShell-Option.
Die Wartungskonfiguration wurde erneut mit älterer Triggerzeit ausgelöst
Abgang
Die Wartungskonfiguration wird nach dem Update erneut mit der älteren Triggerzeit ausgeführt.
Lösung
Es gibt ein bekanntes Problem im Wartungsplan 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. Wir empfehlen, die Wartungskonfiguration mindestens 1 Stunde vorher zu aktualisieren. Wenn das Problem weiterhin besteht, wenden Sie sich an das Supportteam, um weitere Unterstützung zu erhalten.
Zeitüberschreitung planen, warten, bis eine fortlaufende Aktualisierung abgeschlossen ist
Abgang
Timeout der Wartungskonfiguration aufgrund des Hostupdatefensters, das mit dem Patchfenster für die Gast-VM gepatcht wird
Lösung
In seltenen Fällen kann es passieren, dass ein Hostupdatefenster zum Plattformcatchup mit einem Patchfenster für die Gast-VM zusammenfällt. Wenn das Patchfenster für die Gast-VM nach dem Hostupdate nicht genügend Zeit für die Ausführung erhält, zeigt das System den Fehler Timeout für Zeitplan, es wird darauf gewartet, dass die Ressource durch ein fortlaufendes Update abgeschlossen wird an, da die Plattform jeweils nur ein einziges Update zulässt.
Nicht implementierte APIs
Nachfolgend finden Sie die Liste der APIs, die noch nicht unterstützt werden.
- Abrufen von „Update anwenden“ auf Abonnementebene
- Abrufen von „Update anwenden“ auf Ressourcengruppenebene
- Abrufen von „Ausstehendes Update“ auf Abonnementebene
- Abrufen von „Ausstehendes Update“ auf Ressourcengruppenebene