Manuelle Updates

Die folgenden manuellen Upgradeschritte können bei Fehlern bei automatischen Upgrades verwendet werden.

1. Manuelles Upgrade für Palo Alto Networks

Die folgenden bedienbaren Komponenten werden in diesem Schritt aktualisiert.

Bei diesem Upgrade kommt es zu minimalen Unterbrechungen des Traffics für externe Verbindungen. Die Ausfallzeit beträgt etwa eine Minute. Solche Upgrades sind manuell. PANW wird im Modus für hohe Verfügbarkeit (HA) betrieben.

1.1 Definitionen

Palo Alto-Firewall-Softwareversionen werden im Format X.Y.Z angezeigt.

1.2 Upgradeverfahren

1.2.1 Upgrade-Pfad

Bevor Sie fortfahren, müssen Sie feststellen, welcher Fall Ihren Anforderungen entspricht: Fall 1, Fall 2 oder Fall 3:

• Fall 1: X.Y ist die Zielversion.
• Fall 2: X.Y ist nicht die Zielversion.
• Fall 3: Die Firewallversion ist X.Y, wobei X.Y die letzte FEATURE-Version für X ist.

In den folgenden Beschreibungen von Fall 1, Fall 2 und Fall 3 sehen Sie, welche Upgrade-Pfade jeweils infrage kommen.

Zusätzlich zu den hier angegebenen Informationen zum Upgrade-Pfad finden Sie weitere Informationen unter https://www.paloaltonetworks.com/.

1.2.2 Upgrade einrichten

Distributed Cloud verwendet zwei Firewalls. Prüfen Sie vor dem Starten eines Upgrades, ob beide Firewalls dieselbe Version haben. Wenn nicht, führen Sie die erforderlichen Upgrades durch, um die Versionen anzugleichen, bevor Sie ein Upgrade auf die nächste Zielversion starten. Führen Sie diese Schritte jedes Mal aus, wenn Sie ein Upgrade durchführen möchten.

1. Sicherstellen, dass beide Firewalls ordnungsgemäß funktionieren:
   1. Prüfen Sie im Dashboard, ob die Hochverfügbarkeit (HA) grün angezeigt wird.
   2. Prüfen Sie, ob im Netzwerk keine inaktiven Links vorhanden sind.

2. Sichern Sie die Konfigurationen auf beiden Firewalls.

3. Gehen Sie zu Gerät > Hochverfügbarkeit.

4. Suchen Sie auf der Seite Gerät nach dem Tab Betriebsbefehle und klicken Sie darauf.

   1. Suchen Sie im Navigationsbereich nach Hohe Verfügbarkeit und klicken Sie darauf.
   2. Klicken Sie auf die Option Lokales Gerät für hohe Verfügbarkeit anhalten, wenn sie angezeigt wird.

   

   Abbildung 1. Hochverfügbarkeit aussetzen

5. Prüfen Sie, ob der zurückgegebene Status der lokalen Firewall als suspended angezeigt wird.

   

   Abbildung 2. Prüfen, ob die Firewall deaktiviert ist

6. Aktualisieren Sie die Firewall.

7. Wiederherstellung aus dem Status suspended: Klicken Sie auf Lokales Gerät für hohe Verfügbarkeit verfügbar machen.

   

   Abbildung 3. Hochverfügbarkeit verfügbar machen

   Kehren Sie zum ersten Schritt zurück und wiederholen Sie den Vorgang für die zweite Firewall gemäß Ihrem Upgradepfad.

1.3 Beispiel für Details zum Upgradevorgang

1. Prüfen Sie die aktuelle PAN‑OS-Version.

   show system info | match sw-version
   

   Wenn auf dem Gerät nicht die Zielsoftwareversion von PAN-OS installiert ist, führen Sie ein Upgrade durch.

2. Folgen Sie dem pfadspezifischen Upgradeverfahren.

3. Prüfen Sie den Upgrade-Pfad auf der Website paloaltonetworks.com unter https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-upgrade/upgrade-pan-os/upgrade-the-firewall-pan-os/determine-the-upgrade-path.html auf Ihrem lokalen Computer, bevor Sie fortfahren.

4. Prüfen Sie, ob das Gerät registriert und lizenziert ist.

5. So finden Sie die aktuelle Firmware für die Extraktion:

   gdcloud artifacts tree ${ARTIFACTS_ROOT}/oci | grep "gdch-firewall"
   

   Der Dateiname enthält die Build-Version. Beispielausgabe:

   │   │   └── gdch-firewall/os:1.10.0-gdch.1426
   

   Im vorherigen Beispiel wird die Build-Version als 1.10.0-gdch.1426 angezeigt.

6. Kopieren Sie den Dateinamen und extrahieren Sie die Firmware. Beispiel:

   1. Kopieren Sie gdch-firewall/os:1.10.0-gdch.1426 als Dateinamen. Ersetzen Sie FIRMWARE_FILENAME im folgenden Befehl durch diesen Wert:

      export FW_FIRMWARE_TAR_FILENAME=FIRMWARE_FILENAME
      

   2. Extrahieren Sie die Firmware aus dem OCI-Image:

      gdcloud artifacts extract ${ARTIFACTS_ROOT}/oci firmware \
          --image-name=${FW_FIRMWARE_TAR_FILENAME:?}
      

      Ersetzen Sie FW_FIRMWARE_TAR_FILENAME durch den Dateinamen der TAR-Datei für die Firewall-Firmware.

   3. Extrahieren Sie die Firmware:

      tar -xvf firmware/gdch-firewall/os.tar.gz
      

7. Suchen Sie die Datei für das Upgrade des Betriebssystems und laden Sie sie auf das Firewallgerät hoch, um das Upgrade zu starten.

2. Automatisches Upgrade für HSM auslösen

Die folgenden bedienbaren Komponenten werden in diesem Schritt aktualisiert.

Für das HSM-Upgrade muss ein HSMUpgradeRequest erstellt und der Status der Upgradeanfrage regelmäßig geprüft werden.

Es werden automatisch ein oder mehrere CTMClusterUpgradeRequests generiert, um jedes HSMCluster auf die nächste Firmwareversion im Upgradepfad zu aktualisieren, damit die Zielfirmwareversion erreicht wird. Das HSM-Upgrade ist ein Upgrade ohne Unterbrechung, das etwa zwei Stunden dauert.

Die Dauer der Ausfallzeit für dieses Upgrade hängt von der Integration ab. Ein HSM, das mit mehreren Adressen konfiguriert ist, kann ohne Unterbrechung aktualisiert werden.

1. Setzen Sie KUBECONFIG auf die kubeconfig-Datei für den Administratorcluster auf Stammebene.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   

2. Erstellen Sie eine benutzerdefinierte HSMUpgradeRequest-Ressource. Erstellen Sie ein hsmupgrade.yaml und fügen Sie CurrentGDCHVersion und TargetGDCHVersion ein.

   Beispiel für eine benutzerdefinierte Ressource:

   apiVersion: "upgrade.private.gdc.goog/v1alpha1"
   kind: HSMUpgradeRequest
   metadata:
      name:  HSM_UPGRADE_REQUEST_NAME
      namespace: gpc-system
   spec:
      currentGDCHVersion: "1.10.X-gdch-xxx"
      targetGDCHVersion: "1.11.y-gdch.yyyy"
   

3. Wenden Sie die neue benutzerdefinierte Ressource an:

   kubectl --kubeconfig=${KUBECONFIG:?} apply -f hsmupgrade.yaml
   

4. Überwachen Sie das HSM-Upgrade, indem Sie sich den Status der erstellten Ressourcen HSMUpgradeRequest und CTMClusterUpgradeRequest ansehen.

   kubectl --kubeconfig=${KUBECONFIG:?} describe HSMUpgradeRequest HSM_UPGRADE_REQUEST_NAME -n gpc-system
   

   Beispiel für die Status-Ausgabe einer abgeschlossenen HSMUpgradeRequest:

   Status:
   Conditions:
    Last Transition Time:  2023-08-03T18:20:50Z
    Message:
    Observed Generation:   1
    Reason:                PullFirmwareImages
    Status:                True
    Type:                  FirmwareImagesPulled
    Last Transition Time:  2023-08-03T18:20:50Z
    Message:               CTM upgrade request to version:2_12_0 is in progress
    Observed Generation:   1
    Reason:                CTMClusterUpgradeInProgress
    Status:                True
    Type:                  InProgress
    Last Transition Time:  2023-08-03T18:41:54Z
    Message:               CTM upgrade request to target version:2_12_0 completed
    Observed Generation:   1
    Reason:                AllCTMClusterUpgradeRequestsCompleted
    Status:                True
    Type:                  AllComplete
   

   kubectl --kubeconfig=${KUBECONFIG:?} get ctmclusterupgraderequests -n gpc-system
   

   kubectl --kubeconfig=${KUBECONFIG:?} describe ctmclusterupgraderequests CTM_CLUSTER_UPGRADE_REQUEST_NAME -n gpc-system
   

   Beispiel für die Status-Ausgabe einer abgeschlossenen CTMClusterUpgradeRequest:

   Status:
   Conditions:
    Last Transition Time:  2023-09-11T18:08:25Z
    Message:               CTM pre upgrade checks succeed. The system is eligible to upgrade.
    Observed Generation:   1
    Reason:                CTMPreUpgradeChecksReady
    Status:                True
    Type:                  PreUpgradeCheckCompleted
    Last Transition Time:  2023-09-11T18:18:31Z
    Message:               HSM backup completed. The system is ready to upgrade.
    Observed Generation:   2
    Reason:                HSMBackupCompleted
    Status:                True
    Type:                  BackupCompleted
    Last Transition Time:  2023-09-11T18:18:31Z
    Message:               Starting HSM upgrades for cluster.
    Observed Generation:   2
    Reason:                hsmclusterClusterUpgradeInProgress
    Status:                True
    Type:                  ClusterUpgradeInProgress
    Last Transition Time:  2023-09-11T19:46:22Z
    Message:
    Observed Generation:   2
    Reason:                ReconcileCompleted
    Status:                True
    Type:                  AllComplete
   
   

3. Manuelles ONTAP-Upgrade

Wenn Sie ein manuelles Upgrade auf einem System mit einem vorhandenen Speichercluster durchführen, gehen Sie so vor:

Rufen Sie das Betriebssystem-Upgrade-Image entweder mit 12.4.1 Abrufmethode 1 oder mit 12.4.2 Abrufmethode 2 ab. Die Schrittfolgennummer ist dieselbe, da Sie nur eine der beiden verwenden:

3.1 – Abrufmethode 1

Mit dieser Methode können Sie die aktualisierbaren Pakete aus gdch.tar.gz abrufen.

1. Wenn Sie sich auf einem Hostcomputer befinden und Zugriff auf das Release-Bundle haben, rufen Sie das Image aus der Harbor-Registry ab:

   # Download the upgrade OS package
   OCI_PATH=$ARTIFACTS_ROOT/oci
   gdcloud artifacts extract $OCI_PATH storage --image-name=gpc-system-storage/storage:9.13.1P1
   
   tar -xvzf storage/gpc-system-storage/storage.tar.gz
   

   Wenn die Extraktion fehlschlägt, suchen Sie mit folgendem Befehl nach dem richtigen Archiv: sh gdcloud artifacts extract $OCI_PATH tree | grep storage

2. Suchen Sie die Datei in storage/9.13.1P1.tar.

3. Sammeln Sie die Datei für das Upgrade des Betriebssystems und laden Sie sie auf die Speicherwebsite hoch, um das Upgrade zu starten. Wenn ONTAP noch nicht installiert ist, stellen Sie diese Dateien auf dem Bootstrapper bereit und lassen Sie das Image vom Knoten abrufen.

3.2 – Abrufmethode 2

Wenn der Root-Administratorcluster bereits ausgeführt wird, können Sie das Upgrade-Image direkt aus der GDC Artifact Registry abrufen.

1. Image aus Artifact Registry abrufen:

   https://gpc-istio-ingressgateway-IP/artifacts/serve/base64url encoding of the artifact reference
   

2. Laden Sie die Upgradedatei herunter:

   IMAGE_BASE64_URL=$(echo "gpc-system-storage/storage:ontap" | base64)
   
   # The OS file is located at:
   https://gpc-istio-ingressgateway-IP/artifacts/serve/IMAGE_BASE64_URL
   

Die Artefaktreferenz ist gpc-system-storage/storage:ontap..

1. Rufen Sie die URL auf, die als https://gpc-istio-ingressgateway-IP/artifacts/serve/IMAGE_BASE64_URL angegeben ist, und laden Sie das Betriebssystempaket lokal herunter.
2. Sammeln Sie die Datei für das Upgrade des Betriebssystems und laden Sie sie auf die Speicherwebsite hoch, um das Upgrade zu starten.

3.3 Bild in ONTAP hochladen

1. Öffnen Sie die ONTAP-Verwaltungs-URL und suchen Sie die Seite Übersicht.

2. Klicken Sie auf die Schaltfläche ONTAP Update (ONTAP-Update).

   

   Abbildung 8. Schaltfläche „ONTAP Update“ (ONTAP-Update)

3. Klicken Sie auf +Bild hinzufügen und laden Sie das Bild hoch, das Sie mit Abrufmethode 1 oder Abrufmethode 2 abgerufen haben.

   

   Abbildung 9. Schaltfläche „+ Bild hinzufügen“

3.4 Preflight-Prüfung für ONTAP-Upgrade

Klicken Sie nach dem Hochladen des Bildes auf Upgrade, um die Preflight-Prüfung zu starten. Es wird eine Warnmeldung wie in der folgenden Abbildung angezeigt: „Update mit Warnungen“.

Abbildung 10. Schaltfläche „Mit Warnungen upgraden“

Wenn die Warnmeldung angezeigt wird, gehen Sie so vor:

1. Prüfen Sie, ob Sie Maßnahmen ergreifen müssen. Prüfen Sie, ob etwas aufgeführt ist, das sich auf das Upgrade auswirken könnte.

2. Führen Sie die folgende Preflight-Prüfung durch:

   • Prüfen Sie, ob der Cluster fehlerfrei ist und die Knoten fehlerfrei sind, wenn das Speicher-Failover konfiguriert ist.
   • Prüfen Sie, ob für das Speichersystem Warnungen gemeldet werden.
   • Prüfen Sie, ob die CPU- und Festplattenauslastung im Upgrade-Zeitraum unter 50% liegt.

   • Prüfen Sie, ob im Speichersystem keine Jobs ausgeführt werden.
     Beispielsweise können Volumen- und Aggregatjobs ausgeführt werden oder in der Warteschlange stehen. Warte, bis sie abgeschlossen sind.
     

   • Prüfen Sie, ob DNS aktiv ist (falls es konfiguriert wurde).

   • Prüfe, ob sich alle Netzwerkschnittstellen im Home-Knoten befinden. Falls nicht, setzen Sie sie zurück, damit sie auf den Home-Knoten landen.

   • Wenn SnapMirror konfiguriert ist, muss es zum Zeitpunkt des Upgrades angehalten werden.

   • Befolgen Sie bei allen Verfahren die Empfehlungen für das Upgrade des Speichersystems.

3.5 Upgrade starten

1. Erstellen Sie im Administratorcluster auf Stammebene ein Kubernetes API-Objekt und wenden Sie es mit der kubectl-CLI auf den Administratorcluster auf Stammebene an:

   apiVersion: upgrade.storage.private.gdc.goog/v1alpha1
   kind: FileStorageUpgradeRequest
   metadata:
    name: test
    namespace: gpc-system
   spec:
    fileStorageUpgradeMode: Manual
    storageClusterRef:
      name: $StorageClusterName
      namespace: gpc-system
    targetVersion: 9.10.1
   

2. Klicken Sie auf Mit Warnungen aktualisieren.

   

   Abbildung 11. Schaltfläche „Mit Warnungen aktualisieren“

3.6 Upgrade auf einem leeren System

Wenn der ONTAP-Speicher aus irgendeinem Grund zurückgesetzt wurde und noch kein Cluster vorhanden ist, müssen Sie die Knoten einzeln aktualisieren. So gehts:

1. Laden Sie die neueste Version der ONTAP-Software herunter. Die Dateibenennungskonvention ähnelt dem folgenden Beispiel: 9.13.1P1_ONTAP_image.tgz.

2. Erstellen Sie ein Verzeichnis zum Hosten der ONTAP-Imagedatei.

   mkdir files
   mv 9.13.1P1_ONTAP_image.tgz files
   

3. Hosten Sie das Bild auf dem Bootstrapper mit Python 3.

   # create a webserver with python
   python3 -m http.server -d files
   Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
   

4. Verwenden Sie die system node reboot-Befehlszeile, um den Knoten neu zu starten.

5. Drücken Sie Strg + C, um den Startvorgang zu unterbrechen. Wählen Sie im Bootmenü die Option 7 aus: Install new software first (Zuerst neue Software installieren). Das Bootmenü sieht so aus:

   > system node reboot
   
   Warning: Are you sure you want to reboot node "ag-ad-stge02-02"?
   {y|n}: y
   
   # interrupt the boot cycle using Ctrl-C
   
   *******************************
   *                             *
   * Press Ctrl-C for Boot Menu. *
   *                             *
   *******************************
   ^CBoot Menu will be available.
   
   Please choose one of the following:
   
   (1)  Normal Boot.
   (2)  Boot without /etc/rc.
   (3)  Change password.
   (4)  Clean configuration and initialize all disks.
   (5)  Maintenance mode boot.
   (6)  Update flash from backup config.
   (7)  Install new software first.
   (8)  Reboot node.
   (9)  Configure Advanced Drive Partitioning.
   (10) Set Onboard Key Manager recovery secrets.
   (11) Configure node for external key management.
   Selection (1-11)? 7
   

   Die Ausgabe sieht dann ungefähr so aus:

   This procedure is not supported for Non-Disruptive Upgrade on an HA pair.
   The software will be installed to the alternate image, from which the node is
   not currently running. Do you want to continue? {y|n} y
   
   In order to download the package, a temporary network interface needs to be
   configured.
   
   Select the network port you want to use for the download (for example, 'e0a')
   

6. Konfigurieren Sie die IP-Adresse auf der e0M-Schnittstelle. Starten Sie dann den Knoten neu.

   Select the network port you want to use for the download (for example, 'e0a')
   > e0M
   
   The node needs to reboot for this setting to take effect.  Reboot now? {y|n}
   (selecting yes will return you automatically to this install wizard) y
   
   Rebooting...
   
   ## Configure the mgmt interface (e0M)
   
   In order to download the package, a temporary network interface needs to be
   configured.
   
   Enter the IP address for port e0M: 172.22.115.131
   Enter the netmask for port e0M: 255.255.255.0
   Enter IP address of default gateway: 172.22.115.1
   
   What is the URL for the package? http://172.22.112.67:8000/files/9.13.1P1_ONTAP_image.tgz
   What is the user name on "172.22.112.67", if any?
   

7. Verwenden Sie die version CLI, um die aktuelle Softwareversion zu bestätigen. Die Ausgabe sieht etwa so aus:

   > version
   NetApp Release 9.13.1P1: Tue Jul 25 10:19:28 UTC 2023
   

   3.7 MTU der LIFs des Sicherungs-Agents aktualisieren

Das Sicherungs- und Wiederherstellungssystem verwendet LIFs in ONTAP. Die MTU muss unter dem Höchstwert von 9.000 liegen. Dies erfolgt über den Backup-Agent. Nachdem ONTAP ausgeführt wird und fehlerfrei ist, verringern Sie die MTU-Größe (Maximum Transmission Unit) für die LIFs des Sicherungs-Agents:

net port broadcast-domain modify -broadcast-domain backup-agent-network -mtu 8000

Mit dem folgenden Befehl können Sie prüfen, ob dies erfolgreich war:

net port broadcast-domain show -broadcast-domain backup-agent-network

Sie sollten jetzt den neuen MTU-Wert von 8.000 sehen.

4. Manuelles Upgrade des Infrastrukturkerns der Operations Suite

Dieses Upgradeverfahren gilt nur für das Upgrade von Version 1.12.x auf 1.13.0.

4.1 Sicherungen durchführen

1. Sichern Sie die VM gemäß der Anleitung in der Einrichtungsanleitung für das Operation Center.
2. Sichere das Laufwerk „H:\operations_center“. (Diese Aktion unterstützt das Rollback des Upgrades.)
3. Sichern Sie C:\dsc, C:\operations_center\ und C:\config\ auf CONFIG1. Dieses Backup dient als Referenz beim Erstellen der neuen Konfiguration „config.ps1“.

4.2 Vorhandene virtuelle Maschinen aktualisieren

1. Rufen Sie das Installationsverzeichnis ab.

   1. Laden Sie das OIC-Komponentenpaket herunter. Folgen Sie dazu der Anleitung im Abschnitt Dateien herunterladen.

   2. Extrahieren Sie das Verzeichnis „operations_center“ aus der heruntergeladenen Datei „prod_IT_component_bundle.tar.gz“.

      tar -zxvf prod_IT_component_bundle.tar.gz ./release/operations_center
      

   3. Ersetzen Sie H:\operations_center durch das im vorherigen Schritt extrahierte Verzeichnis.

2. config.ps1 mit standortspezifischen Daten aktualisieren

   Die Konfigurationsdatei config.ps1 enthält alle Informationen, die zum Erstellen und Konfigurieren der Operations Suite Infrastructure-Umgebung (OI) erforderlich sind. Um die Konfigurationsdatei zu aktualisieren, müssen Sie alle folgenden Informationen erfassen. Die Sicherung der vorhandenen Datei „config.ps1“ ist eine gute Referenz, um ein unbeabsichtigtes Überschreiben vorhandener Einstellungen zu verhindern. Wichtig: Fahren Sie erst fort, wenn config.ps1 abgeschlossen und korrekt ist.

   • Die Netzwerkkonfiguration, die vom occonfigtool-Tool ausgegeben wird, insbesondere die Datei ocinfo.common.opscenter.local.txt. Die in den folgenden Schritten erwähnten Netzwerknamen, z. B. OCCORE-SERVERS, beziehen sich auf die Spalte Name in diesem Dokument.
   • Der Domainname und die DNS-Server-IP-Adresse aller GDC-Zellen, die von diesem OI verwaltet werden. Diese Daten sind in den Ausgaben des Customer Intake Questionnaire (CIQ) verfügbar.

   Nehmen Sie alle Änderungen auf dem Host BM01 als Administrator vor.

3. Kopieren Sie den richtigen Beispielcode für die Konfiguration für den Bereitstellungstyp:

   1. Wenn OIC zuerst als einzelne Website bereitgestellt wird, kopieren Sie H:\operations_center\dsc\config.single-site-example.ps1 nach H:\operations_center\config\config.ps1.
   2. Wenn OIC anfangs als Multi-Site bereitgestellt wird, kopieren Sie H:\operations_center\dsc\config.multi-site-example.ps1 nach H:\operations_center\config\config.ps1.

4. Überprüfen und aktualisieren Sie die Werte in config.ps1 mit Powershell ISE.

   1. Aktualisieren Sie HardwareVersion, sofern der Standardwert (3.0) nicht korrekt ist.

   2. Aktualisieren Sie PrimarySiteCode, sofern der Standardwert (DC1) nicht korrekt ist.

   3. Der Standortcode wird in vielen Namen verwendet. Suchen Sie nach allen Instanzen von DC1 und ersetzen Sie sie durch den richtigen Websitecode. Verwenden Sie die Suche ohne Berücksichtigung der Groß- und Kleinschreibung. Prüfen Sie jede Änderung, da einige möglicherweise nicht erforderlich sind. Wenn der Websitecode beispielsweise AB1 ist, muss der Hostname DC1-DC1 in AB1-DC1 geändert werden, nicht in AB1-AB1.

   4. Aktualisieren Sie DnsDomain, wenn die Standardeinstellung nicht korrekt ist. Wenn dieser Wert geändert wird, suchen Sie in der Datei config.ps1 nach opscenter.local und ersetzen Sie alle Vorkommen. Der Standardwert ist an mehreren Stellen fest codiert.

   5. Aktualisieren Sie die Objekte in DnsConditionalForwarder mit standortspezifischen Informationen. Es muss mindestens ein Weiterleitungsobjekt vorhanden sein. Unnötige Beispiele entfernen

      So rufen Sie standortspezifische Informationen aus dem Administrator-Root-Cluster ab:

      export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
      kubectl get -n dns-system service gpc-coredns-external-udp -o jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}'

      1. Domain: Der DNS-Domainname der GDC-Zelle, z. B. dns.delegatedSubdomain in ciq.yaml.

      2. Master: Eine Liste von DNS-Server-IPs (in der Regel nur eine). Suchen Sie im cellcfg nach dem Typ DNSReservation. Wenn die GDC-Zelle bereitgestellt wird, suchen Sie im Namespace dns-system des Root-Administratorclusters nach der EXTERNAL-IP des gpc-coredns-external-udp-Dienstes und dem FQDN der Zelle bert.sesame.street.

      3. Bei Bereitstellungen mit mehreren Standorten gibt es ein Hashtable-Objekt pro Zelle.

   6. Ändern Sie nicht den Inhalt der Objekte Users, Groups und GroupPolicy.

   7. Aktualisieren Sie DNSServers, sodass sie die beiden IP-Adressen enthält, die den primären und sekundären Domaincontrollern zugewiesen sind, z. B. <SITE>-DC1 und <SITE>-DC2.

   8. Aktualisieren Sie NTPServers auf eine Liste der SyncServer-IP-Adressen aus den benutzerdefinierten TimeServer-Ressourcen des Root-Administrators. Sie können diese IP-Adressen mit dem folgenden Befehl abrufen:

      kubectl get timeserver -A -o json | jq '.items[].address'
      

      Sie müssen diese IP-Adressen in NTPServers formatieren, wie im folgenden Beispiel gezeigt:

      NtpServers = @(
        '10.251.80.2',
        '10.251.80.3',
        '10.251.80.4',
        '10.251.80.5'
      )
      

   9. Aktualisieren Sie bei Bedarf den Standardwert für SubnetPrefix, also 24, mit dem vom Kunden bereitgestellten Subnetzpräfixwert für das OCCORE-SERVERS-Subnetz.

   10. Aktualisieren Sie den Standardwert von DefaultGateway mit dem vom Kunden bereitgestellten Standardgateway für das OCCORE-SERVERS-Subnetz.

   11. Suchen Sie den Standardwert für WorkstationCider und aktualisieren Sie ihn mit dem vom Kunden angegebenen Wert für das Subnetz OC-WORKSTATIONS in IPv4-CIDR-Notation.

   12. Suchen Sie nach dem Beispiel-Subnetzpräfix 172.21.0. und ersetzen Sie es durch das vom Kunden bereitgestellte OCCORE-SERVERS-Subnetzpräfix.

   13. Suchen Sie nach dem Beispiel-Subnetzpräfix 172.21.2. und ersetzen Sie es durch das vom Kunden bereitgestellte Subnetzpräfix OCCORE-JUMPHOSTS.

   14. Suchen Sie das Beispiel-Subnetzpräfix 172.21.32. und ersetzen Sie es durch das vom Kunden bereitgestellte OC-WORKSTATIONS-Subnetzpräfix.

   15. Suchen Sie die Beispiel-Tagesbotschaft legalnoticecaption mit dem Wert Pref caption und ersetzen Sie sie durch die vom Kunden bereitgestellte Bildunterschrift.

   16. Suchen Sie den Beispielwert für die Tagesbotschaft legalnoticetext von Pref text und ersetzen Sie ihn durch den vom Kunden bereitgestellten Text.

   17. Prüfen Sie jedes „node“-Objekt und aktualisieren Sie es bei Bedarf.

       1. NodeName – Prüfen Sie, ob der Hostname korrekt ist. Einige Namen werden an vielen Stellen verwendet, z. B. für Domaincontroller. Wenn Sie hier einen Namen ändern, prüfen Sie, ob er auch an anderer Stelle in der Konfiguration geändert werden muss.

       2. IPv4Addr: Das muss die IP-Adresse des Hosts sein. Das letzte Oktett kann in der Regel so belassen werden. Einige davon wurden möglicherweise bei der Suche und dem Ersetzen im Netzwerk in früheren Schritten aktualisiert.

       3. HyperVHost: Dieser Wert muss die IP-Adresse des Hyper-V-Servers sein, auf dem diese VM gehostet wird. Die IP-Adresse für jeden BM??-Server finden Sie im Abschnitt „Hyper-V Servers“ der Konfiguration. Ändern Sie die Hyper-V-Hostzuweisung in diesem Feld nicht, da nicht alle Hyper-V-Hosts jeden VM-Typ unterstützen. Ändern Sie nur den Hyper-V-Hostnamen in die entsprechende IP-Adresse.

   18. Aktualisieren Sie alle Strophen für die Knoten mit splunk_indexer, um eine große zweite Festplatte einzuschließen. Jede Strophe sollte die folgenden Zeilen enthalten:

       ExtraDiskSize   = 5120GB # No quotes -- PowerShell converts this to an integer.
       ExtraDiskFolder = 'H:\Hyper-V\Virtual Hard Disks'
       

   19. Prüfen Sie die Details der zweiten Netzwerkschnittstelle auf allen Knoten mit Role=jumphost. Verwenden Sie für diese Schnittstelle die Subnetzdetails von OCCORE-JUMPHOSTS. Prüfen:

       1. JumphostIPv4Cidr
       2. JumphostDefaultGateway

   20. Aktualisieren Sie die ADFS-spezifische Stanza auf dem Knoten, auf dem Role=adfs.

       1. Ersetzen Sie alle Instanzen von bert.sesame.street und GDCH.sesame.street durch den richtigen Domain-Wert aus einem der Absätze im Abschnitt DnsConditionalForwarder der Konfiguration.
       2. Ersetzen Sie das Wort Bert (Groß-/Kleinschreibung wird nicht beachtet) durch die kurze Kennung der GDC-Zelle, die für die Verwendung von ADFS konfiguriert wird.

   21. Aktualisieren Sie die DHCP-Bereiche nach Bedarf, damit sie dem IP-Plan des Kunden entsprechen. Prüfen Sie für jeden Bereich, ob die folgenden Werte korrekt sind. Die Namen der Bereiche stimmen mit den Namen im ocinfo.common.opscenter.local.txt-Netzwerkplan überein. Verwenden Sie daher Folgendes für die Validierung:

       1. ScopeId
       2. IpStartRange
       3. IpEndRange
       4. Router
       5. SubnetMask

   22. Prüfen Sie, ob die Werte mit den Werten in der gesicherten Datei „config1.ps1“ übereinstimmen.

   23. Speichern Sie die Datei.

5. CONFIG1-VM-Upgrade

   Das CONFIG1-Upgrade wird auf BM01 durchgeführt, um mit der Erstinstallation übereinzustimmen. Alle anderen Upgrades werden nach dem Upgrade von CONIFIG1 ausgeführt.

   1. Kopieren Sie das Verzeichnis „operations_center“ auf die CONFIG1-VM.

   2. Öffnen Sie auf dem Host BM01 eine PS-Konsole als Administrator.

   3. Führen Sie das Copy-ConfigHostFiles.ps1-Skript aus, um die für die CONFIG1-VM erforderlichen Dateien bereitzustellen.

      # CD to the script's directory
      cd H:\operations_center\dsc
      

      # Staging files for CONFIG1 VM
      .\Copy-ConfigHostFiles.ps1 `<SITE>-CONFIG1`
      

   4. Hyper-V-Zeitsynchronisierung deaktivieren

      1. Melden Sie sich als Administrator auf dem BM01-Host an.

      2. Öffnen Sie PowerShell unter Windows als Administrator und führen Sie den folgenden Befehl aus:

      # Disabling Hyper-V Time Sync
      Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
      

   5. CONFIG1-Aktualisierungsskript ausführen

      .\Update-RemoteHost.ps1 -ComputerName DC1-CONFIG1 -Credentials $domain_admin_creds -SetLcm -RemoveExisting
      

   6. Nachdem das Skript ausgeführt wurde, wird die VM CONFIG1 neu gestartet.

   7. CONFIG1-VM-Validierung

      1. Stellen Sie auf dem Host BM01 über Remote Desktop (RDP) eine Verbindung zur IP-Adresse der VM CONFIG1 her und melden Sie sich als Marvin an. Beispiel: mstsc /v 192.168.100.99

      2. Öffnen Sie als Marvin-Nutzer eine PS-Konsole mit Als Administrator ausführen.

      3. Prüfen Sie, ob die Build-Umgebung bereit ist, indem Sie Build-Mof.ps1 ausführen. Dadurch werden MOF-Dateien (Managed Object Format) für alle OI-Maschinen generiert.

      # Running Build-MOf.ps1
      cd C:\dsc
      ./Build-Mof.ps1
      

6. CA-ISSUING und CA-WEB aktualisieren

   1. Führen Sie auf CONFIG1 als Marvin die folgenden Skripts aus, um die CA-ISSUING-VM zu konfigurieren. powershell $la_creds = Get-Credential -Message "Provide local admin credentials for CA- VMs" ./Update-RemoteHost.ps1 -ComputerName <SITE>-CA-ISSUING1 -Credentials $la_creds -SetLcm -RemoveExisting

   2. Führen Sie auf CONFIG1 als Marvin die folgenden Skripts aus, um den Server CA-WEB1 zu konfigurieren.

   $la_creds = Get-Credential -Message "Provide local admin credentials for CA- VMs"
   .\Update-RemoteHost.ps1 -ComputerName <SITE>-CA-WEB1 -Credential $la_creds SetLcm -RemoveExisting
   

7. CA_ROOT upgraden

   1. Schalten Sie CA-ROOT1 ein.

      1. Melden Sie sich als Administrator auf dem BM01-Host an.

      2. Öffnen Sie PowerShell unter Windows als Administrator und führen Sie den folgenden Befehl aus:

      Start-VM -Name <SITE>-CA-ROOT1
      

   2. Initialisieren Sie die CA-ROOT1-VM über die CONFIG1-VM.

      .\Update-RemoteHost.ps1  -ComputerName <SITE>-CA-ROOT1 -Credential $la_creds SetLcm -RemoveExisting
      

   3. Wenn die VM CA_ROOT nach dem vorherigen Skript nicht neu gestartet wurde, starten Sie sie manuell neu.

   w32tm /query /peers
   
   #Peers: 1
   
   Peer: DC2-DC1.hq.local
   State: Active
   Time Remaining: 31.2997107s
   Mode: 3 (Client)
   Stratum: 1 (primary reference - syncd by radio clock)
   PeerPoll Interval: 6 (64s)
   HostPoll Interval: 6 (64s)
   

8. DHCP-VMs aktualisieren

   1. Führen Sie auf CONFIG1 als Marvin-Nutzer ein Upgrade der DHCP-VMs durch. Beginnen Sie mit DHCP2 und dann mit DHCP1.

      • DHCP2 konfigurieren:

      .\Update-RemoteHost.ps1 -ComputerName <SITE>-DHCP2 -Credential $da_creds SetLCM -RemoveExisting
      

      • DHCP1 konfigurieren

      .\Update-RemoteHost.ps1 -ComputerName <SITE>-DHCP1 -Credential $da_creds SetLCM -RemoveExisting
      

9. Domänencontroller aktualisieren

   1. Führen Sie auf CONFIG1 als Marvin-Nutzer ein Upgrade des primären Domaincontrollers durch.

   .\Update-RemoteHost.ps1 -ComputerName <SITE>-DC1 -Credential $da_creds SetLCM -RemoveExisting
   

   1. Zeitsynchronisierung mit dem SyncServer validieren

      1. Stellen Sie über RDP eine Verbindung zu <SITE>-DC1 als Domainadministrator her.
      2. Öffnen Sie ein Powershell-Fenster als Administrator.

      3. Führen Sie den folgenden Befehl aus, um die Zeitkonfiguration zu validieren.

         # Checking time status
         w32tm /query /status /verbose
         

      4. Führen Sie die folgenden Befehle aus, um die Zeitsynchronisierung zu testen:

         # Testing time resyncronization
         w32tm /resync
         

         # Desired output
         Sending resync command to local computer
         The command completed successfully.
         

      5. Prüfen Sie noch einmal, ob die Zeitkonfiguration korrekt ist und keine Fehler enthält.

        # Checking time status
        w32tm /query /status /verbose
      

   2. Zweite DC-VM (<SITE>-DC2) auf BM02 aktualisieren

      1. Melden Sie sich mit dem lokalen Administratorkonto marvin in CONFIG1 an.
      2. Öffnen Sie ein PowerShell-Terminal als Administrator und führen Sie das folgende Script aus.

      cd c:\dsc
      
      .\Update-RemoteHost.ps1 -ComputerName <SITE>-DC2 -Credential $da_creds -SetLCM -RemoveExisting
      
      

      1. Der Server wird neu gestartet. WARTEN Sie 15 Minuten oder bis die AD-Replikation abgeschlossen ist.

      2. AD-Replikation validieren

      3. Sobald der zweite DC betriebsbereit ist, führen Sie die folgenden Befehle auf einem der Domaincontroller aus, um die Active Directory-Replikation zu prüfen:

      repadmin /replsummary
      

      1. Validieren Sie die Ergebnisse gemäß der Anleitung in #validate-ad-replication.

10. Microsoft Config Manager-VMs aktualisieren

    Richten Sie im PowerShell-Fenster von Marvin auf DC1-CONFIG1 die DSC-Konfiguration ein und führen Sie sie aus:

    .\Update-RemoteHost.ps1 -ComputerName <SITE>-MCMDB1 -Credential $da_creds -SetLCM -RemoveExisting
    

    .\Update-RemoteHost.ps1 -ComputerName <SITE>-MCM1 -Credential $da_creds -SetLCM -RemoveExisting
    

    .\Update-RemoteHost.ps1 -ComputerName <SITE>-MCM2 -Credential $da_creds -SetLCM -RemoveExisting
    

11. Splunk-VMs aktualisieren

    Richten Sie im PowerShell-Fenster von Marvin auf DC1-CONFIG1 die DSC-Konfiguration ein und führen Sie sie aus:

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-heavyfwd -Credential $da_creds -SetLCM -RemoveExisting
    

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-indexer -Credential $da_creds -SetLCM -RemoveExisting
    

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-manager -Credential $da_creds -SetLCM -RemoveExisting
    

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-splunk-searchhead -Credential $da_creds -SetLCM -RemoveExisting
    

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-universal -Credential $da_creds -SetLCM -RemoveExisting
    

12. Nessus-VMs aktualisieren

    Richten Sie im PowerShell-Fenster von Marvin auf DC1-CONFIG1 die DSC-Konfiguration ein und führen Sie sie aus:

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-NESSUS1 -Credential $da_creds -SetLCM -RemoveExisting
    

     .\Update-RemoteHost.ps1 -ComputerName <SITE>-NESSUS2 -Credential $da_creds -SetLCM -RemoveExisting