Die Wartungsaktivitäten des Systems umfassen eine automatische Aktualisierung der Softwarekomponenten des Pods, um neue Funktionen sowie Fehlerbehebungen und Verbesserungen für die Serviceunterstützung und die Ausfallsicherheit einzubeziehen. Die Wartungsaktivität, bei der ein vorhandener Pod auf ein neueres Manifest aktualisiert wird, wird vom System von der Cloud-Ebene aus initiiert und erfolgt an einem vom System festgelegten Tag und zu einer bestimmten Uhrzeit. Um Ihre Präferenz anzugeben, dass eine solche Systemwartungsaktivität zu einer bestimmten Stunde und an einem bestimmten Wochentag beginnen soll, geben Sie über die Konsole das bevorzugte Wartungsfenster für jeden Pod an. Ein Pod, für den in der Konsole kein bevorzugtes Wartungsfenster angegeben ist, bedeutet, dass VMware jederzeit eine Wartung für diesen Pod planen kann.

Wenn die in einem bereitgestellten Pod verwendeten Softwarekomponenten auf eine neue Version aktualisiert werden, erhöht sich die Manifestnummer für den Pod auf eine höhere Versionsnummer, z. B. 2632.0. Wenn es Verbesserungen gibt, die für die Wartbarkeit des Pods und den Supportbetrieb als wichtig erachtet werden, kann VMware ein neues Manifest erstellen, das eine Punktversion ist, z. B. 2632.1. Die Konsole zeigt das Manifest eines Pods auf der Seite „Kapazität“ an.

Wissenswertes zur Pod-Wartung

Die Wartung der VMware-Softwarekomponenten, aus denen der bereitgestellte Horizon Cloud-Pod besteht, ist ein notwendiger und erforderlicher Vorgang, um den Zustand und die Stabilität der virtuellen Desktops und Anwendungen zu erhalten, die von diesem Pod bereitgestellt werden. Wie in der PDF-Datei der Horizon-Dienstbeschreibung festgehalten, ist VMware für die Softwarekomponenten verantwortlich, die sich auf dem Pod befinden und von der Steuerungsebene auf diesen Pod heruntergeladen werden. Das Dokument Horizon-Dienstbeschreibung enthält auch:

  • Die Rollen und Verantwortlichkeiten von VMware in Bezug auf die Änderungsmanagementverfahren zur Aufrechterhaltung des Zustands der Softwarekomponenten, die in den Pod heruntergeladen werden. Zu den Wartungsaktivitäten gehört das Aktualisieren der Softwarekomponenten des Pods.
  • Die Rolle und die Verantwortlichkeiten des (Ihres) Kunden in Bezug auf die Änderungsmanagementverfahren, einschließlich der Zusammenarbeit mit VMware, wenn eine geplante oder Notfallwartung erforderlich ist.

Das Dokument Horizon-Dienstbeschreibung enthält eine Definition der geplanten Wartung, der Wartungsfenster und der Notfallwartung. Weitere Informationen dazu finden Sie im Dokument. Bei Widersprüchen zwischen dem Inhalt dieser Dokumentationsseite und dem Inhalt des Dokuments Horizon-Dienstbeschreibung hat das Dokument Horizon-Dienstbeschreibung Vorrang.

Achtung: Bevor der Pod aktualisiert wird, müssen Sie sicherstellen, dass die Image-VMs, Farm-VMs und VDI-Desktop-VMs des Pods alle über den neuesten Agenten verfügen, der für den Pod verfügbar ist. Wenn Sie sie vor der Pod-Aktualisierung nicht auf den neuesten Agenten aktualisieren, laufen auf ihnen nach der Pod-Aktualisierung möglicherweise inkompatible Agentenversionen, wodurch der Pod in einen nicht unterstützten Zustand versetzt wird. Wie können Sie feststellen, ob Sie einen der Agenten aktualisieren müssen? Prüfen Sie in der Konsole, ob neben einem Image oder einer Zuweisung blaue Punkte zu sehen sind. Wenn Sie blaue Punkte sehen, müssen Sie dafür sorgen, dass alle blauen Punkte vor der Pod-Aktualisierung von der Konsole verschwinden. Siehe Horizon Cloud-Pod-Aktualisierungen – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung

Festlegen des bevorzugten Wartungsfensters des Pods

Um anzugeben, dass Sie es vorziehen, dass jede Wartungsaktivität auf Ihrem Pod zu einer bestimmten Uhrzeit und an einem bestimmten Wochentag beginnt, geben Sie in der Konsole das sogenannte bevorzugte Wartungsfenster für diesen Pod an. Navigieren Sie auf der Seite „Kapazität“ zur Registerkarte Wartung auf der Detailseite des Pods. Suchen Sie nach der Beschriftung Bevorzugter Wartungszeitpunkt und folgen Sie dann den Bedienelementen auf dem Bildschirm, um einen Wochentagsnamen und eine Uhrzeit (UTC) an diesem Tag auszuwählen. Sie können nur aus den angezeigten, vom System vordefinierten Voreinstellungen wählen.

Geben Sie die bevorzugte Wartungszeit für jeden Pod separat auf der Detailseite jedes Pods in der Konsole an.

Hinweis: Ein Pod, für den in der Konsole kein bevorzugtes Wartungsfenster angegeben ist, bedeutet, dass Sie VMware berechtigen, jederzeit eine Wartung für diesen Pod zu planen.

Das System liest den Wochentag und die Uhrzeit, die Sie in der Konsole angeben, und bezieht diese Daten in seinen Planungsalgorithmus ein. Wenn ein neues Pod-Manifest als Standard in der Cloud-Ebene festgelegt wird, berechnet der Scheduler des Systems den tatsächlichen Aktualisierungstag und die Uhrzeit, zu der die Aktualisierung auf jedem Pod in Ihrer Pod-Flotte erfolgen kann. Obwohl das System sein Bestes tut, um die bevorzugten Wartungsstartzeiten, die auf der Registerkarte Wartung des Pods angegeben sind, zu berücksichtigen, kann nicht garantiert werden, dass das System in der Lage ist, diese bevorzugte Wartungsstartzeit für einen bestimmten Aktualisierungsvorgang zu berücksichtigen.

Zu diesem Zeitpunkt weist der Scheduler des Systems vier (4) Stunden für die Dauer der Wartungstätigkeit zu. Die typische Pod-Aktualisierung dauert weniger als diese zugewiesene Zeitspanne.

Wartungswarnungen und -benachrichtigungen

Das System alarmiert und benachrichtigt die Administratoren Ihrer Mandantenumgebung, wenn das System ein bestimmtes Kalenderdatum und eine bestimmte Uhrzeit für die Wartung eines bestimmten Pods eingeplant hat. Zu diesen Warnungen und Benachrichtigungen gehören die folgenden:

Innerhalb der Konsole
  • Ein dauerhaftes Banner am oberen Rand der Konsole. Die Zeit im Banner ist die lokale Wartungszeit in der Zeitzone Ihres Browsers, in der Sie die Konsole anzeigen. Der folgende Screenshot zeigt ein Beispiel, bei dem die Aktualisierung des Pods für den 7. Juli 2020 um 16 Uhr Eastern Time in den USA geplant ist. Verwenden Sie die Schaltfläche Ansicht, um auf die Detailseite des Pods zu klicken und weitere Informationen über die geplante Wartung auf der Registerkarte Wartung des Pods anzuzeigen.
    Screenshot-Beispiel des Banners in der Konsole, das Informationen über die geplante Wartung eines Pods liefert
  • Auf der Registerkarte Überwachungsprotokolle des Pods und auf der Konsole Aktivität > Überwachungsprotokoll wird in einem Überwachungsprotokoll angegeben, dass ein Upgrade des Pods von VMware Operations geplant ist. Die Audit-Protokollzeile enthält die UUID des Pods.
  • Auf der Registerkarte Wartung des Pods werden im Abschnitt Geplante Wartung Informationen über die geplante Wartung angezeigt.
E-Mails
Das System sendet E-Mails über die Wartung des Pods an die Administratoren Ihrer Mandantenumgebung, die in den Einstellungen der Konsole Allgemeine Einstellungen > My VMware-Konten angegeben sind. Eine der E-Mails wird versendet, wenn das System das spezifische Kalenderdatum und die Uhrzeit für die geplante Wartung festgelegt hat. Beispiele für solche E-Mails sind regelmäßige Erinnerungen in den Tagen und Wochen vor dem geplanten Datum und der geplanten Uhrzeit, sowie wenn die Wartungsaktivität begonnen hat und wenn sie abgeschlossen ist.
Hinweis: Wenn Sie ein geplantes Wartungsdatum und eine geplante Wartungszeit verschieben möchten, müssen Sie sich an den VMware Support wenden.

System-Vorabprüfungen vor der Durchführung der Pod-Wartung

Wenn Sie eine Benachrichtigungs-E-Mail erhalten, die besagt, dass ein Pod Fehler bei der Pod-Aktualisierung aufweist, oder Sie sehen, dass die Konsole Fehler bei der Pod-Aktualisierung für einen Pod meldet, müssen Sie Maßnahmen ergreifen, um die Situation zu beheben. Befolgen Sie in diesem Fall die Bildschirmanweisungen der Konsole oder die Anweisungen in der E-Mail. Die übliche Lösung für solche Fehler besteht darin, dass Sie im Microsoft Azure-Portal im dortigen Abonnement des Pods Schritte durchführen. Weitere Informationen zu Abhilfemaßnahmen bei typischen Pod-Aktualisierungsfehlern finden Sie unter Horizon Cloud-Pods – Abhilfe bei häufigen Vorabprüfungsfehlern.

Was ist der Zweck dieser Vorabkontrollen? Die Wartungsaktivität für eine Pod-Aktualisierung findet in den Microsoft Azure-Abonnement- und Ressourcengruppen des Pods statt. Kurz bevor das System ein bestimmtes Kalenderdatum und eine bestimmte Uhrzeit für eine bestimmte Aktualisierung auf einem bestimmten Pod einplant, führt das System eine Vorabprüfung durch, um festzustellen, ob Bedingungen vorliegen, die eine erfolgreiche Aktualisierung bei einem Pod verhindern würden. Das System prüft dabei beispielsweise, ob Ihr Microsoft Azure-Abonnement über genügend vCores der entsprechenden VM-Serie verfügt, um die Anforderungen der Aktualisierung zu erfüllen. Wenn eine der Vorabprüfungen fehlschlägt und die Behebung des dabei festgestellten Fehlers Ihr Eingreifen erfordert, tritt Folgendes ein:

  • Sie erhalten eine Benachrichtigungs-E-Mail, die Sie auf diesen Umstand hinweist und Details zu den erforderlichen Maßnahmen zur Behebung des Fehlers enthält.
  • Die Konsole zeigt eine visuelle Warnung an, dass Ihre Maßnahmen zur Behebung der Vorabprüfungsfehler für diesen Pod erforderlich sind.
Wichtig: Wenn Sie Benachrichtigungen über Pod-Upgrade-Fehler erhalten, führen Sie die angegebenen Maßnahmen durch, um die Fehler rechtzeitig zu beheben. Die Zeit ist von entscheidender Bedeutung. Wenn diese Fehler nicht in der von VMware geforderten Zeit behoben werden, geht der Pod in einen nicht unterstützten Zustand über, da der Pod-Aktualisierungsprozess nicht eingeleitet werden kann.

Pod-Aktualisierungen – Überblick

Wenn es sich bei der Wartungsaktivität um die Aktualisierung eines Pods auf eine neuere Manifestversion handelt, verschiebt das System die aktuellen Infrastrukturkomponenten des Pods entsprechend auf eine höhere Software-Manifeststufe. Die Infrastrukturkomponenten sind in erster Linie die Pod-Manager-VMs und alle Unified Access Gateway-VMs, die für den Pod konfiguriert sind. Beispielsweise kann ein Pod-Update Aktualisierungen für die Pod-Verwaltungssoftware oder für die Unified Access Gateway-Software oder für beides enthalten.

Der Pod-Aktualisierungsvorgang entspricht in seinem Muster einer Technik aus der Software-Branche, die als Blue-Green Deployment (also Blau-Grün-Bereitstellung) bezeichnet wird. Die vorhandenen zu aktualisierenden Pod-Komponenten werden als „Blue“-Komponenten bezeichnet.


Konzeptionelle Darstellung des Blau-Grün-Aktualisierungsvorgangs.

Obwohl die Pod-Aktualisierung in den meisten Punkten einem branchenüblichen blau-grünen Muster folgt, gibt es einige kleinere Unterschiede zu einer kanonischen blau-grünen Aktualisierung. Die Pod-Aktualisierung dupliziert nicht zu 100 % jede einzelne blaue Ressource im grünen Build-Out. Einige der vorhandenen blauen Ressourcen werden im neuen grünen Build-Out wiederverwendet, z. B. die NICs für die Unified Access Gateway-Instanzen. Ein weiterer Unterschied besteht darin, dass beim Pod-Aktualisierungsvorgang beispielsweise die neueren Instanzen neben den vorhandenen erstellt werden. Dann werden die neueren Instanzen aktiviert und weiterhin ausgeführt, bis die Migration des Pods zu den neueren Instanzen abgeschlossen ist. Außerdem werden die älteren blauen VMs aus der Ressourcengruppe gelöscht, nachdem das System den Pod auf den grünen Build-Out migriert und überprüft hat, dass der Pod erfolgreich mit der neuen Manifestversion ausgeführt wird. (Ein kanonisches Blau-Grün-Update würde typischerweise die älteren blauen Artefakte nach dem Wechsel zu Grün beibehalten und die älteren in einem Ruhezustand halten.)

  • Die vorhandenen, zu aktualisierenden Pod-Komponenten – wie die Pod-Manager-VMs und die Unified Access Gateway-VMs – werden als die blauen Komponenten betrachtet.
  • Der Dienst erstellt automatisch den erforderlichen grünen Satz von Komponenten für den Pod in Ihrem Microsoft Azure-Abonnement – neue grüne Pod-Manager-VMs, Unified Access Gateway-VMs und die Gateway-Connector-VM (wenn Ihr externes Gateway in einem eigenen VNet bereitgestellt wird).
  • Eine temporäre Jumpbox-VM wird automatisch im Abonnement des Pods erstellt, um diesen grünen Build-Out zu orchestrieren. Diese temporäre Jumpbox-VM und ihre Ressourcengruppe werden gelöscht, nachdem die grüne Parallelumgebung erfolgreich aufgebaut wurde.
  • Die neu erstellten Komponenten im grünen Build-Out werden neben den blauen Komponenten in denselben Ressourcengruppen erstellt.
  • Der Prozess der Erstellung des grünen Build-Outs verursacht keine Ausfallzeiten oder Datenverluste, und die parallelen VMs beeinträchtigen den Betrieb des Pods nicht.
  • Das grüne Set ist eine parallele Umgebung, die auf die geplante Wartungsaktivität wartet, die den Wechsel von der blauen zur grünen Umgebung ermöglicht. Die Art und Weise, wie das System die Wartungstätigkeit an einem Pod terminiert, wurde in den vorangegangenen Abschnitten behandelt.
  • Diese grünen VMs werden gestartet und laufen weiter, bis die geplante Wartungsaktivität abgeschlossen ist, also die Wartungsaktivität, die die blauen zu den grünen VMs migriert.
  • Nachdem die geplante Wartungsaktivität für die Migration zum grünen Build-Out abgeschlossen ist und der Pod erfolgreich auf den neuen Instanzen ausgeführt wird, löscht das System die blauen VMs aus den Ressourcengruppen des Pods. Einige Ressourcen, wie z. B. die Netzwerkkarten für die vorherigen Unified Access Gateway-Instanzen, werden nicht gelöscht, damit Konfigurationswerte erhalten bleiben können, die für das nächste Pod-Update erforderlich sind.
Hinweis: Sie müssen vermeiden, im Microsoft Azure-Portal und im Abonnement des Pods Änderungen vorzunehmen, die sich auf den Aufbau der grünen Komponenten des Systems oder auf die Pod-Aktualisierungs- und Wartungsprozesse des Systems auswirken.

Reihenfolge der Wartungsaktivitäten

Diese Sequenz beschreibt die Migration zum grünen Build-Out – den Wechsel von Blau zu Grün in der Pod-Aktualisierung.

  1. Das System prüft das bevorzugte Wartungsfenster des Pods, das Sie in der Konsole angegeben haben, um diese Informationen im Algorithmus des Zeitplaners zu verwenden und das tatsächliche Kalenderdatum und die Uhrzeit für die Wartungsaktivität des Pods zu planen.
  2. Der Zeitplaner des Systems wählt das tatsächliche Kalenderdatum und die Uhrzeit, zu der die Wartung stattfinden soll. Wie in den vorangegangenen Abschnitten beschrieben, zeigt die Konsole das geplante Datum und die Uhrzeit an und es wird eine E-Mail an die Administratoren des Mandanten gesendet.
  3. Wichtig: Bevor die geplante Wartung läuft:
    • Stellen Sie sicher, dass die Image-VMs, Farm-VMs und VDI-Desktop-VMs des Pods alle über den neuesten Agenten verfügen, der für den Pod verfügbar ist. Wenn Sie blaue Punkte in der Konsole sehen, ist es das Ziel, alle blauen Punkte vor der Pod-Aktualisierung von der Konsole verschwinden zu lassen. Siehe Horizon Cloud-Pod-Aktualisierungen – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung
    • Entfernen Sie alle gegebenenfalls in Microsoft Azure festgelegten Verwaltungssperren für die virtuellen Maschinen (VMs) des Pods. Alle VMs mit Namen, die einen Teil wie vmw-hcs-podID aufweisen, wobei podID der ID-Wert des Pods ist, gehören zum Pod. Microsoft Azure bietet die Möglichkeit, das Microsoft Azure-Portal zum Sperren von Ressourcen zu verwenden, um Änderungen an diesen zu verhindern. Solche Verwaltungssperren können auf eine gesamte Ressourcengruppe oder auf einzelne Ressourcen angewendet werden. Wenn Sie oder Ihre Organisation Verwaltungssperren für die VMs des Pods festgelegt haben, müssen diese Sperren vor der Aktualisierung entfernt werden. Andernfalls kann die Aktualisierung nicht erfolgreich abgeschlossen werden. Sie finden den ID-Wert des Pods auf der Detailseite des Pods auf der Seite „Kapazität“.

    Wenn es die Anforderungen Ihres Unternehmens erfordern, können Sie ein anderes geplantes Datum für die Wartung anfordern, indem Sie sich jederzeit vor der geplanten Wartungszeit an den VMware Support wenden.

    Wichtig: Die geplante Zeit, die in der Konsole angezeigt wird, entspricht der lokalen Zeitzone Ihres Browsers.
  4. Zum geplanten Wartungszeitpunkt setzt der Dienst erneut eine Jumpbox-VM ein, um die Wartungsaktivität zu orchestrieren. Obwohl der Vorgang bei Pods, die sowohl eine externe als auch eine interne Unified Access Gateway-Konfiguration haben, in der Regel bis zu zwanzig Minuten dauert, plant das System vier (4) Stunden für die gesamte Wartungsaktivität ein, um ein erfolgreiches Ergebnis zu gewährleisten.

    Während der Wartungstätigkeit gelten die folgenden Einschränkungen:

    • Sie können keine Verwaltungsaufgaben auf dem Pod ausführen, auf dem das Update ausgeführt wird.
    • Endbenutzer, die keine Verbindung zu ihren virtuellen Desktops oder Remoteanwendungen haben, die vom aktualisierten Pod bereitgestellt werden, und versuchen, eine Verbindung herzustellen, können dies nicht tun.
    • Endbenutzer mit über den Pod verbundenen Sitzungen werden von ihren aktiven Sitzungen getrennt. Nachdem die Wartung abgeschlossen ist, können diese Benutzer erneut eine Verbindung herstellen. Es kommt zu keinem Datenverlust, es sei denn, Sie haben die Option Sofort für das Timeout-Handling in den Farmen und VDI-Desktop-Zuweisungen verwendet.
    Vorsicht: Benutzer mit verbundenen Sitzungen auf Desktops oder Remoteanwendungen, die von Farmen und VDI-Desktop-Zuweisungen bedient werden, die die Einstellung Getrennte Sitzungen abmelden auf Sofort gesetzt haben, werden sofort abgemeldet und diese abgemeldeten Sitzungen werden ebenfalls sofort abgemeldet. Unter diesen Bedingungen geht jede noch nicht abgeschlossene Arbeit des Benutzers verloren.

    Um den Verlust laufender Endbenutzerdaten für dieses Szenario zu vermeiden, passen Sie vor Beginn der Wartungsaktivität die Einstellung Getrennte Sitzungen abmelden in den Farmen und VDI-Desktop-Zuweisungen auf einen Zeitwert an, der diesen Benutzern Zeit gibt, ihre Arbeit zu speichern. Nachdem das Update abgeschlossen ist, können Sie die Einstellung wieder ändern.

  5. Nach Abschluss der Wartungsaktivität löscht das System die nicht mehr benötigten Komponenten, z. B. die Jumpbox-Ressourcengruppe und ihren Inhalt sowie die blauen Komponenten, die im grünen Build-Out nicht wiederverwendet werden, z. B. die Pod-Manager-VMs und Unified Access Gateway-VMs. Einige Artefakte, wie z. B. bestimmte Netzwerkkarten für die Unified Access Gateway-Instanzen, werden nicht gelöscht, damit Konfigurationswerte erhalten bleiben können, die für die nächste Wartung erforderlich sind.

Nach der Wartungsaktivität

Wenn die Wartungsaktivität beendet ist, können Sie administrative Aufgaben auf dem Pod durchführen. Um die Softwareversion anzuzeigen, die ein Pod derzeit ausführt, wählen Sie Einstellungen > Kapazität aus und klicken Sie auf den Pod, um die Seite „Übersicht“ zu öffnen. Auf der Seite wird die derzeit ausgeführte Software-Version angezeigt.

Achtung: Stellen Sie nach einer Pod-Aktualisierung sicher, dass die Agenten in allen vorhandenen Images, Farmen und VDI-Zuweisungen auf die neueste verfügbare Version aktualisiert werden. Wenn die installierten Agenten dieser VMs nicht aktualisiert werden, befindet sich der Pod in einer nicht unterstützten Konfiguration. Der Wartungsprozess aktualisiert diese installierten Agenten nicht automatisch. Wenn Sie in der Konsole blaue Punkte für Ihre Images oder Zuweisungen sehen, bedeutet dies, dass die Agenten aktualisiert werden müssen. Horizon Cloud-Pod-Aktualisierungen – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung.
Wichtig: Wenn Ihr konfigurierter Radius-Server im selben VNet bereitgestellt wird, müssen Sie nach der Wartungsaktivität auch die Einstellungen auf Ihrem Radius-Server aktualisieren, damit die neuen privaten IP-Adressen für die neuen internen Unified Access Gateway-VMs akzeptiert werden. Dies ist eine einmalige Anforderung für die erste Aktualisierung auf dem Pod und muss für zukünftige Aktualisierungen dieses Pods nicht wiederholt werden.
Wichtig: Ab der vierteljährlichen Dienstversion vom September 2019 wird die Pod-Architektur aktualisiert, sodass die Hochverfügbarkeit unterstützt wird. Selbst wenn die Hochverfügbarkeitsfunktion nicht aktiviert ist, enthält die neue, hochverfügbarkeitsfähige Architektur einen Lastenausgleichsdienst („Load Balancer“) von Microsoft Azure vor der Manager VM des Pods. Nachdem Sie Ihren Pod auf Manifestversion 1600 aktualisiert und anschließend für Direktverbindungen konfiguriert haben, sollten Sie Ihre DNS-Einstellungen neu zuordnen, sodass sie auf die Azure Load Balancer-IP-Adresse von Pod Manager verweisen, die von nun an auf der Detailseite des aktualisierten Pods angezeigt wird. Bis zur Aktualisierung der DNS-Zuordnung – selbst wenn diese direkten Benutzerverbindungen weiterhin funktionieren – verfügen diese Verbindungen bei einem Ausfall der aktiven Pod-Manager-VM nicht über HA-Failover, für das ein HA-fähiger Pod ausgelegt ist. Für diesen Anwendungsfall ordnen Sie der IP-Adresse im Feld IP-Adresse des Lastenausgleichsdienstes für den Pod Manager einen FQDN zu, der auf der Detailseite des Pods angezeigt wird, wie unter Konfigurieren von SSL-Zertifikaten direkt auf den Pod-Manager-VMs, z. B. beim Integrieren der Workspace ONE Access Connector Appliance mit dem Horizon Cloud-Pod in Microsoft Azure, damit der Connector Verbindungen mit den Pod-Manager-VMs vertrauen kann beschrieben. Vor der Pod-Manifestversion 1600 war diese IP-Adresse diejenige, die der Netzwerkkarte der Manager-VM des Pods im Mandantensubnetz zugewiesen wurde. Ab Pod-Manifestversion 1600 oder höher ist die zuzuordnende IP-Adresse des Pods die die private IP-Adresse des Microsoft Azure Load Balancers, der für die Manager-VMs des Pods verwendet wird. Wenn Sie für vorhandene Pods, die auf die Manifestversion dieser Version aktualisiert werden, einen DNS-Namen so konfiguriert hatten, dass er auf die IP-Adresse der Mandanten-Appliance für einen Pod des Manifests 1493.1 oder früher verweist, sollten Sie Ihre DNS-Einstellungen neu zuordnen, sodass sie auf die IP-Adresse verweisen, die unter IP-Adresse des Lastenausgleichsdienstes für den Pod Manager auf der Detailseite des aktualisierten Pods angezeigt wird.