Skip to main content

1. September 2026

Horizon Cloud-Pods – Abhilfemaßnahmen für häufige Fehler bei Vorabprüfungen

In diesem Thema werden die Abhilfemaßnahmen beschrieben, die bei häufigen Fehlern bei der Vorabprüfung der Wartung zu ergreifen sind. Wenn die Vorabprüfungen des Systems Bedingungen aufzeigen, die Wartungsaktivitäten auf einem Pod blockieren würden, werden diese Fehler Ihnen in der Horizon Universal Console angezeigt, damit Sie die erforderlichen Maßnahmen zur Behebung ergreifen können.

Wichtig: Wenn Sie Benachrichtigungen über Pod-Aktualisierungsfehler erhalten, müssen Sie die angegebenen Maßnahmen ergreifen, um die Fehler rechtzeitig zu beheben. Die Zeit drängt. Wenn diese Fehler nicht in der vom Dienst geforderten Zeit behoben werden, geht der Pod in einen nicht unterstützten Zustand über, da der Pod-Aktualisierungsprozess nicht eingeleitet werden kann. .

Wie unter Horizon Cloud Pods – Wartung und Updates beschrieben, benachrichtigt Sie das System über die wartungshemmenden Bedingungen, die in Ihrer Microsoft Azure-Umgebung unter Ihrer Kontrolle stehen. Da die Abhilfemethode Ihrer Kontrolle unterliegt und nicht von uns behoben werden kann, müssen Sie, wenn Sie eine Benachrichtigung über Aktualisierungsfehler in der Konsole sehen oder eine Benachrichtigungs-E-Mail über solche Fehler erhalten, die Aktionen zur Behebung der Fehler abschließen und sich dann an das Horizon Cloud-Supportteam wenden, um die Wartungsaktivität fortzusetzen.

Update-blockierende Fehler, die in der Regel auftreten können

Dies sind die Fehler, die die Aktualisierung verhindern können, die häufig auftreten können und die Sie in Ihrer Microsoft Azure-Umgebung beheben können.

  • Abonnementrichtlinien blockieren die Nutzung von Azure Marketplace-Angeboten des Herausgebers des Diensts.

    Wie auf dieser Dokumentationsseite beschrieben, hat der Dienst ab Anfang des Kalenderjahres 2022 den Upgrade-Code so erweitert, dass Angebote, die wir im Azure Marketplace bereitstellen, programmgesteuert verwendet werden. Wenn die Upgrade-Vorabprüfungen ergeben, dass die programmgesteuerte Verwendung dieser Angebote im Abonnement verhindert wird, müssen Sie die auf dieser Dokumentationsseite beschriebenen Aktionen ausführen, um die Fehler zu beheben, die die Aktualisierung blockieren.

  • Das Abonnement verfügt nicht über die entsprechenden Kerne (vCPUs) oder VM-Größen, die für die Instanziierung aller VMs für die parallel einzurichtenden VMs verfügbar sind.

    Wenn die "Green"-Komponenten erstellt sind, wird für jede VM in Ihrem aktuellen Pod eine andere VM erstellt. Infolgedessen verfügen Sie in dem Zeitraum zwischen dem Aufbau der "Green"-Komponenten und der Migration von den "Blue"- zu den "Green"-Komponenten zum in der Konsole festgelegten Zeitpunkt über eine doppelte Anzahl von Pod-Manager-VMs und Unified Access Gateway-VMs. Um das Erstellen dieser "Green"-VMs unterstützen zu können, müssen die Kontingentebenen Ihres Abonnements für Kerne (vCPUs) aus den entsprechenden Microsoft-VM-Familien ausreichen, um die parallel ausgeführten einzurichtenden VMs zusammen mit dem Kontingent zu umfassen, das Sie bereits von diesem Abonnement für die vorhandenen zugeordneten Pods verwendet haben. In der Tabelle mit den Kontingenten und Kernen unten finden Sie die erforderlichen Kerne für die verschiedenen VM-Typen und -Nutzungen.

  • Pod ist derzeit offline oder kann derzeit nicht mit Horizon Cloud kommunizieren.

    Stellen Sie auf der Seite "Kapazität" sicher, dass der zu aktualisierende Pod den Status "Online" anzeigt. Melden Sie sich beim Microsoft Azure-Portal an und überprüfen Sie, ob die Pod Manager-VM und deren Unified Access Gateway-VMs (sofern Ihr Pod diese hat) ausgeführt werden. Wenn eine VM nicht ausgeführt wird, schalten Sie sie ein. Weitere Informationen zu den Ressourcengruppen, in denen sich diese VMs befinden, finden Sie unter First-Gen-Mandanten – Für einen in Microsoft Azure bereitgestellten Pod erstellte Ressourcengruppen.

  • Die Berechtigung zum Erstellen oder Löschen von Ressourcengruppen ist für dieses Microsoft Azure-Abonnement nicht aktiviert.

    Die Systemvorabprüfung überprüft, ob der mit diesem Pod verknüpfte Dienstprinzipal über die erforderlichen Berechtigungen verfügt, die der Dienst benötigt. Wenn die Berechtigung zum Erstellen oder Löschen von Ressourcengruppen im Abonnement des Pods nicht aktiviert ist, wird diese Automatisierung blockiert. Um diese Situation zu beheben, folgen Sie der Anleitung der Validierung, wie Sie die erforderlichen Berechtigungen über das Microsoft Azure-Portal aktivieren können. Weitere Informationen zu den Berechtigungen, die der Dienst für den Dienstprinzipal benötigt, um die für den Dienst erforderlichen Vorgänge auszuführen, finden Sie unter Wenn Ihre Organisation die Verwendung einer benutzerdefinierten Rolle bevorzugt.

Für die Zeit von der Bereitstellung der grünen VMs bis zum Abschluss der Migration von blauen VMs benötigte Kontingente und Kerne

Wenn Sie über einen Aktualisierungsfehler aufgrund fehlender verfügbarer Kerne benachrichtigt werden, verwenden Sie die folgende Tabelle, um das zusätzliche Kontingent anzuzeigen, das Sie benötigen. Für die verschiedenen VM-Typen, die im aktuellen Ist-Pod verwendet werden, wird in der Tabelle am Ende dieses Themas das von diesen Typen verwendete Kontingent, das zusätzliche Kontingent, das bei der Erstellung der grünen Pod-VMs benötigt wird, und das Gesamtkontingent beschrieben, das für die Ausführung sowohl der blauen als auch der grünen VMs von der Erstellung der grünen VMs bis zum Abschluss der Migration zum grünen Build-Out erforderlich ist. Weitere Informationen zu den VM-Familientypen und -Kernen, die von einem Pod verwendet werden, finden Sie auf der Seite VM-Anforderungen für einen -Pod im Bereitstellungshandbuch.

VM-Typen und ihre KerneBeschreibungGesamtkontingent für die Ausführung von blauen VMs und grünen VMs, bis der Wechsel zu grünen VMs abgeschlossen ist
Standard_D4_v3 VM-Typ, jeweils 4 Kerne Hinweis: Wenn der Standard_D4_v3 Typ in Ihrer Microsoft Azure-Region nicht verfügbar ist, verwendet Ihr Pod in der Regel Standard_D3_v2 VM-Typ. Dieser Typ verwendet ebenfalls 4 Kerne.Dieser VM-Typ wird für die Pod-Manager-VMs verwendet.
  • Für einen Pod mit einer einzelnen Manager-VM : Ihr Kontingent muss die Verwendung der 4 Kerne der vorhandenen ("Blue"-)Manager-VM sowie 4 zusätzlicher Kerne für die parallel ausgeführte geplante Manager-VM ermöglichen. Acht (8) Kerne zur Abdeckung dieser Nutzung.
  • Für einen Pod mit aktivierter Hochverfügbarkeit, der über zwei Manager-VMs verfügt: Ihr Kontingent muss die Verwendung der 8 Kerne der vorhandenen ("Blue"-)Manager-VMs (2 VMs mit je 4 Kernen) sowie 8 zusätzlicher Kerne für die parallel ausgeführten zukünftigen Manager-VMs ermöglichen. Sechzehn (16) Kerne zur Abdeckung dieser Nutzung.
Je nachdem, was Sie bei der Bereitstellung des Pods ausgewählt haben:
  • VM-Typ Standard_A4_v2 (hat 4 Kerne)
  • Standard_F8s_v2 (hat 8 Kerne)
Dieser VM-Typ wird für die Unified Access Gateway-VMs in den Gateway-Konfigurationen Ihres Pods verwendet. Die Anzahl der Kerne, die Ihr Abonnement unterstützen muss, hängt davon ab, welche Gateway-Typen auf Ihrem Pod konfiguriert sind.
  • Für einen Pod mit nur einem externen Gateway – Dieses externe Gateway verfügt über zwei Unified Access Gateway-VMs, also zweimal so viele VMs wie die Anzahl Kerne, die sie jeweils haben. Für die Sollkomponenten muss Ihr Kontingent die Verwendung der gesamten Kerne der vorhandenen ("Blue"-)Unified Access Gateway-VMs sowie eine zusätzliche doppelte Anzahl von Kernen für die parallel ausgeführten "Green"-Unified Access Gateway-VMs ermöglichen.
    • Wenn Ihre VMs beispielsweise die Standard_A4_v2 mit jeweils 4 Kernen sind, benötigen Sie 2 mal 4 mal 2 gleich 16 Kerne, um diese Nutzung abzudecken.
    • Wenn Ihre VMs eine VM-Größe mit jeweils 8 Kernen aufweisen, benötigen Sie 2 mal 8 mal 2 entspricht 32 Kernen, um diese Nutzung abzudecken.
  • Für einen Pod mit nur einem internen Gateway – Dieses Gateway verfügt über zwei Unified Access Gateway-VMs, also zweimal so viele VMs wie die Anzahl Kerne, die sie jeweils haben. Für die Sollkomponenten muss Ihr Kontingent die Verwendung der gesamten Kerne der vorhandenen ("Blue"-)Unified Access Gateway-VMs sowie eine zusätzliche doppelte Anzahl von Kernen für die parallel ausgeführten "Green"-Unified Access Gateway-VMs ermöglichen.
    • Wenn Ihre VMs beispielsweise die Standard_A4_v2 mit jeweils 4 Kernen sind, benötigen Sie 2 mal 4 mal 2 gleich 16 Kerne, um diese Nutzung abzudecken.
    • Wenn Ihre VMs eine VM-Größe mit jeweils 8 Kernen aufweisen, benötigen Sie 2 mal 8 mal 2 entspricht 32 Kernen, um diese Nutzung abzudecken.
  • Für einen Pod mit beiden Gateway-Typen: Dieses Gateway verfügt über vier Unified Access Gateway-VMs, also 4 VMs mal der Anzahl Kerne, die sie jeweils haben. Für die Sollkomponenten muss Ihr Kontingent die vierfache Anzahl Kerne der vorhandenen ("Blue"-)Unified Access Gateway-VMs sowie das Zweifache für die parallel ausgeführten "Green"-Unified Access Gateway-VMs ermöglichen.
    • Wenn Ihre VMs beispielsweise die Standard_A4_v2 mit jeweils 4 Kernen sind, benötigen Sie 4 mal 4 mal 2 gleich 32 Kerne, um diese Nutzung abzudecken.
    • Wenn Ihre VMs eine VM-Größe mit jeweils 8 Kernen aufweisen, benötigen Sie 4 mal 8 mal 2 entspricht 64 Kernen, um diese Nutzung abzudecken.

War diese Seite hilfreich?

Feedback zu diesem Thema geben

War dieses Thema hilfreich?

Bitte geben Sie keine personenbezogenen oder vertraulichen Daten an.

Link wird erstellt…