MID Server-Upgrades

Freigeben Version: Washingtondc

Aktualisiert 1. Februar 2024

11 Minuten Lesedauer

Aktualisieren Sie MID Server manuell oder automatisch über die Instanz. Das automatische Upgrade von MID Server wird ausgelöst, wenn die Instanz aktualisiert wird und der MID Server nicht mehr dieselbe Version aufweist. Das neue MID Server-Paket wird von install.service-now.com heruntergeladen, ersetzt das alte und der MID Server startet mit der neuen Version.

Warnung:

Der MID Server kann auf einem Windows-Host nicht automatisch aktualisiert werden, wenn der Windows-Anwendungs-Experience-Service deaktiviert ist. Informationen zum angezeigten Fehler und Anweisungen zum Reaktivieren dieses Diensts finden Sie in KB0597552.

MID Server-Upgrade-Anforderungen

Zugriff auf die MID-Server-Download-Site: Der MID Server-Hostcomputer muss Zugriff auf die ServiceNow-Download-Site unter install.service-now.com haben, um automatisch aktualisiert zu werden. Wenn Sie eine selbst gehostete ServiceNow-Umgebung haben, die den Zugriff auf die Download-Site blockiert, müssen Sie das MID Server-Installationspaket manuell in Ihre MID Server-Hosts importieren. Anweisungen finden Sie unter KB0760123 in der Knowledge Base Self-Hosted.
MID-Serverzugriff auf OCSP blockiert: Aufrufe an den OCSP Entrust-Server werden möglicherweise durch Firewalls und Proxy-Konfigurationen blockiert, wodurch der MID Server nicht funktioniert. Möglicherweise müssen Sie die Firewall-Berechtigungen ändern, damit der OCSP-Datenverkehr ordnungsgemäß verarbeitet wird. Weitere Informationen und Lösungen finden Sie im HI Knowledge Base-Artikel [KB1216223].
Kompatibilität des MID-Server-Betriebssystems: Upgrades von Windows- oder Linux-MID Servern mit 32-Bit-Betriebssystemen werden nicht unterstützt. Weitere Informationen finden Sie unter [KB0863694].

Der MID Server kann auf einem Windows-Host nicht aktualisiert werden, wenn der Windows-Anwendungs-Experience-Dienst deaktiviert ist. Informationen zum angezeigten Fehler und Anweisungen zum Reaktivieren dieses Diensts finden Sie in KB0597552.

Das MID Server-Upgrade wird von einigen Virenschutzprogrammen blockiert, die auf Windows-Hosts ausgeführt werden. Informationen zu den Fehlern und eine Liste dieser Antivirenprogramme finden Sie unter KB0870329.

Jedes Linux-MID-Server-Upgrade, dessen Service unter dem -System in Madrid oder niedriger installiert ist, muss den Service nach dem Upgrade neu installieren. Wenn Sie den Service in früheren Upgrades nicht manuell neu installiert haben und Ihr MID Server-Service noch in Madrid oder niedrigeren Versionen installiert ist, installiert der MID Server den Service während des Upgrades automatisch neu. Um den Service neu zu installieren, muss MID Server als Administratorbenutzer ausgeführt werden. Wenn Ihr MID Server-Upgrade eine Neuinstallation des Service erfordert, stellen Sie sicher, dass der MID Server-Benutzer admin ist, oder Sie können den Service vor dem Upgrade manuell neu installieren. Informationen zur manuellen Neuinstallation des Service finden Sie unter KB0821436.

Wann muss der MID-Server aktualisiert werden?

Jeder MID Server mit einer anderen Version als der Instanzversion muss aktualisiert werden. Die folgenden beiden Systemeigenschaften steuern die Version aller MID Server:

mid.buildstamp: Identifiziert die MID-Server-Version mit einem auf dem Erstellungsdatum basierenden Identifier. Diese Eigenschaft verwendet das Format mm-tt-jjjj-hhmm. Der MID-Server sucht stündlich nach Versionsinformationen. Wenn keine Überschreibungsversion konfiguriert ist, prüft der MID-Server die Eigenschaft mid.buildstamp für die zu verwendende Version. Diese Eigenschaft setzt sich beim Neustart oder Upgrade der Instanz auf die Standardversion (die Version, die Ihrer Instanzversion entspricht) zurück, sodass alle Benutzeränderungen zu diesem Zeitpunkt verloren gehen. Das System hängt den Release-Namen und die Patch-Informationen an das Datums- und Uhrzeitformat an.
Warnung:
Diese Eigenschaft ist standardmäßig nicht sichtbar und sollte nicht konfiguriert werden.
mid.version.override: Legt eine Überschreibungsbedingung für die aktuelle Version für alle MID-Server in Ihrer Umgebung fest. Diese Aktion pinnt die MID-Server an eine einzige Version an und deaktiviert das automatische Upgrade-Feature. Diese Eigenschaft ist im Basissystem nicht sichtbar und muss der Tabelle „Systemeigenschaft“ [sys_properties] hinzugefügt werden, wenn sie festgelegt wird. Weitere Informationen finden Sie unter Systemeigenschaften hinzufügen.

Wenn die MID-Server stündlich die Version überprüfen, wird zuerst die Eigenschaft mid.version.override geprüft. Wenn diese Eigenschaft leer ist, beziehen die MID-Server ihre Versionsinformationen von der Eigenschaft mid.buildstamp. Wenn eine Überschreibungsversion konfiguriert ist, verwenden die MID-Server diesen Wert und ignorieren die Versionsinformationen in der Eigenschaft mid.buildstamp. Dieser Überschreibungswert bleibt beim Neustart der Instanz erhalten und wird an die MID-Server übergeben. Der Wert in der Eigenschaft mid.version.override wird während eines Upgrades gelöscht. Dadurch wird der MID-Server gezwungen, sich auf die in der Eigenschaft mid.buildstamp angegebene Version zurückzusetzen.

Zusätzlich zu mid.version.overridekann die MID-Server-Version auch mit dem Konfigurationsparameter mid.pinned.version gesteuert werden, der den MID-Server an eine bestimmte Version anheftet. Um einen MID-Server anzuheften, legen Sie den Parameter mid.pinned.version fest mit dem Namen dieser Version in der Datei config.xml jedes MID Servers. Verwenden Sie das -Format<version> -mm-tt-jjjj. Diese Einstellung überschreibt die Eigenschaftseinstellung für die angepinnte Version des MID Servers. Anweisungen finden Sie unter MID Server-Parameter hinzufügen. Der in diesem Parameter festgelegte Wert wird von einem Upgrade nicht beeinflusst.

Warnung:

Die Verwendung von mid.version.override und mid.pinned.version wird nicht empfohlen. Die verschiedenen Versionen auf dem MID Server und der Instanz können zu Ausfallproblemen auf dem MID Server führen.

Upgrade-Methoden

Automatisch

Das automatische Upgrade kann von der Instanz oder dem MID Server selbst ausgelöst werden. Diese Funktionalität ist standardmäßig verfügbar. Das automatische Upgrade erfolgt in folgenden Situationen:

Wenn die Instanz aktualisiert wird und der MID-Server für diese Version sich von der aktuell auf dem MID-Server befindlichen Version unterscheidet. Die Instanz sendet den Systembefehl autoUpgradean die verbundenen MID-Server.
Jede Stunde prüft der MID Server bei der Instanz, ob eine andere Version für das Upgrade verfügbar ist. Sie können diesen Zeitraum nicht ändern.

Manuell

Starten Sie das Upgrade manuell, indem Sie im MID Server-Datensatz auf einen zugehörigen Link klicken. Verwenden Sie diese Methode, wenn Sie nicht bis zur nächsten stündlichen automatischen Aktualisierung warten möchten oder wenn das Upgrade fehlgeschlagen ist und Sie ein Upgrade erzwingen möchten. Anweisungen finden Sie unter Manuelles Upgrade des MID Servers.

Upgradeprozess

Prüfung vor dem Upgrade: Vor dem Start des tatsächlichen MID Server-Upgrade-Vorgangs führt der MID Server eine Reihe von Tests durch, um sicherzustellen, dass der Hostcomputer die Mindestanforderungen erfüllt. Bei diesem automatischen Test aufgetretene Fehler verhindern den Upgrade-Vorgang, bis die Probleme behoben sind. Der Test vor dem Upgrade ist standardmäßig aktiviert, kann jedoch durch Hinzufügen und Festlegen einer Systemeigenschaft deaktiviert werden. Weitere Informationen finden Sie unter MID Server-Pre-Upgrade-Test.
Pakete herunterladen:Der MID Server lädt Upgrade-Pakete von install.service-now.com herunter. Diese Pakete liegen im ZIP-Format vor und werden in den Ordner „Agent“ im Ordner „ package/incoming “ heruntergeladen.
Überprüfung der digitalen Signatur
Nach dem Herunterladen jedes Pakets überprüft MID Server die digitale Signatur des Pakets. Es wird eine Ausnahme ausgelöst, wenn die Überprüfung fehlschlägt. Der Fehler wird im Agent-Protokoll und in der MID Server-Problemtabelle aufgezeichnet.

Wenn die Pakete manuell heruntergeladen und ersetzt werden, können Sie die Signatur manuell überprüfen. Um die Signatur eines Installations- oder Upgrade-Pakets manuell zu überprüfen, verwenden Sie das Tool „jarsigner“, das kostenlos mit JDK verfügbar ist. Im Folgenden finden Sie den Befehl „jarsigner“ zum Initiieren der Überprüfung: „jarsigner -verify -verbose -certs -strict“.<zip-file>
Die Ausgabe sollte dem folgenden Beispiel ähneln:
```
- Signed by "CN=ServiceNow Inc., O=ServiceNow Inc., L=Santa Clara, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Tue Nov 05 19:55:37 UTC 2019
Timestamp digest algorithm: SHA-256
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
 
jar verified.
 
The signer certificate will expire on 2021-08-09.
The timestamp will expire on 2029-03-22.
```
ZIP-Dateien werden extrahiert:Nach dem Herunterladen aller erforderlichen Pakete extrahiert der MID Server die ZIP-Dateien.
- Vor Rome: Die ZIP-Dateien werden in einen Ordner unter dem vom Betriebssystem definierten temporären Ordner extrahiert. Der Ordnername ist eine zufällig generierte Nummer. Der temporäre Ordner des Betriebssystems wird durch die Systemeigenschaft java.io.tmpdirangegeben. Auf einem UNIX-Host lautet der Wert für diese Eigenschaft normalerweise /tmp oder /var/tmp.
- Ab Rome: Der MID Server vermeidet die Verwendung von vom Betriebssystem definierten temporären Ordnern während des MID Server-Upgrades. Die ZIP-Dateien werden in einen Ordner im Ordner work/upgrade_temp unter dem Agent-Ordner extrahiert. Das Format des Ordnernamens ist eine zufällig generierte Zahl. Wenn Sie zum vorherigen Verhalten wechseln und einen vom Betriebssystem definierten temporären Ordner verwenden möchten, können Sie mid.upgrade.use_os_temp_folderzur Datei config.xml des MID Servers hinzufügen und auf „true“ festlegen. Um das Verhalten für alle MID Server zu ändern, können Sie es der MID Server-Eigenschaft [ecc_agent_property] hinzufügen, wobei das Feld MID Server leer sein muss.
Hinweis:
Wenn Sie KB0747569 verwenden, um java.io.tmpdir zu ändern, und es für zukünftige Upgrades von Romebeibehaltenmöchten, legen Sie mid.upgrade.use_os_temp_foldernach dem Upgrade auf Rome auf true fest. Wenn mid.upgrade.use_os_temp_folder nicht auf „wahr“ festgelegt ist, wird java.io.tmpdir während des MID Server-Upgrades nicht angewendet, und der Ordner unter agent\work\upgrade_temp wird verwendet.
Alte Pakete durch aktualisierte Pakete ersetzen:Nach dem Herunterladen und Extrahieren der Upgrade-Pakete ersetzt der MID Server alte Dateien durch die neuen Dateien und startet mit der neuen Version. Um die Pakete zu ersetzen, startet der MID Server einen Prozess namens ServiceNow Platform Distribution Upgrade und fährt fort. Das Upgrade der ServiceNow-Plattformverteilung wartet darauf, dass der MID Server ordnungsgemäß heruntergefahren wird, und ersetzt dann die erforderlichen Dateien wie folgt:
- Vor Rome:Der Prozess löscht alle Dateien und Ordner in den Ordnern bin, lib und jre und kopiert die neuen Dateien in diese Ordner.
- Ab Rome: Der Prozess ersetzt die Dateien in bin, lib und jre nur dann, wenn sich die neue Version der Datei von der alten Version unterscheidet. Upgrade derServiceNow-Plattformverteilung bereinigt die Upgrade-Dateien nicht und die unveränderten Dateien bleiben erhalten.
Wenn die Neuinstallation des Service als Teil des MID Server-Upgrades erforderlich war, installiert ServiceNow Platform Distribution Upgrade den Service neu, bevor der MID Server gestartet wird. Weitere Informationen finden Sie in KB0821436.
Hinweis:
Wenn das MID Server-Upgrade in diesem Schritt fehlschlägt, bleibt der MID Server ausgefallen. Einige Antivirenprogramme blockieren die Dateiersetzung in diesem Schritt. Weitere Informationen finden Sie in KB0870329.
MID Server starten:Nachdem alle erforderlichen Dateien durch die neue Version ersetzt wurden, startet das Upgrade der ServiceNow Platform Distribution den MID Server. Wenn der MID Server mit der neuen Version gestartet wird, werden alle temporären Ordner bereinigt, die zum Extrahieren der Upgrade-Dateien verwendet werden.

Upgrade-Protokollnachrichten

Die MID Server-Protokollnachrichten sind in den folgenden Protokolldateien verfügbar:

Protokollnachrichten der Prüfung vor dem Upgrade sind in der Datei agent.log im Ordner agent/logs verfügbar. Die Nachricht Validierungstests werden vor dem Upgrade durchgeführt. gibt an, dass die Prüfung vor dem Upgrade gestartet wurde. Wenn alle obligatorischen Tests bestanden wurden, wird die Meldung Validierung vor dem Upgrade erfolgreich getestet. Upgradevorgang wird fortgesetzt. gibt das Ende der Prüfung vor dem Upgrade an.
Protokollnachrichten zum Herunterladen fehlender Dateien sind auch in agent.log verfügbar. Jeder Paketdownload beginnt mit der Nachricht Downloading Package to Packagename.zip from https://install.service-now.com/ Packageinfo. Der Downloadfortschritt und die Größe der heruntergeladenen Datei werden im Protokoll überwacht. Nach dem Herunterladen jedes Pakets gibt „Paket wurde erfolgreich von https://install.service-now.com/ heruntergeladen“ PAKAGEINFO den erfolgreichen Download an.
Das Extrahieren der ZIP-Dateien ist der letzte verfügbare Schritt in agent.log. Die Nachricht Upgrade MID Server wird angezeigt, um den Beginn dieses Schritts anzuzeigen, und die Nachricht „Package.zip wird extrahiert in EXTRACT_TMP_FOLDER“ wird für jede Paketextraktion angezeigt. Wenn alle erforderlichen ZIP-Dateien erfolgreich extrahiert wurden, startet der MID Server den Upgrade-Prozess der ServiceNow-Plattformverteilung und die Meldung MID Server wird gestoppt. Bootstrapping-Upgrade zeigt das Ende dieses Schritts, bevor MID Server ausfällt.

Upgrade-Protokolle für die ServiceNow-Plattformverteilung enthalten Protokollnachrichten für den Prozessstart und das Ersetzen von Dateien während des MID Server-Upgrades. Die Upgrade-Protokollnachrichten werden zwischen den Nachrichten ***********UPGRADE HAUPTLOGIN START*********** und ***********UPGRADE HAUPTLOGIN platziert ENDE***********. Protokollnachrichten zum Upgrade der ServiceNow-Plattformverteilung finden Sie in den folgenden Protokolldateien:

In der Datei glide-dist-upgrade.log im temporären Extraktordner. Diese Datei ist im Ordner upgrade-wrapper/logs unter dem temporären Extraktordner verfügbar. Diese Protokolldatei enthält Prozessprotokollnachrichten und Upgrade-Protokollnachrichten.
In der Datei dist-upgrade.log im Ordner agent\logs Diese Datei enthält nur den Upgrade-Teil der Protokollnachrichten. Wenn beim Start des Prozesses ein Problem aufgetreten ist, müssen Sie nach glide-dist-upgrade.log suchen.
In wrapper.logim Ordner agent\logs. Nach dem Ersetzen von Dateien wird von ServiceNow Platform Distribution Upgrade glide-dist-upgrade.log an die Datei wrapper.log angehängt.

Aktualisieren Sie die Wrapper-Konfiguration mit upgrade-wrapper-override.conf

Die Wrapper-Konfiguration für glide-dist-upgrade kann mithilfe einer upgrade-wrapper-override.conf- Datei aktualisiert werden. Erstellen Sie eine Datei mit dem Namen upgrade-wrapper-override.conf im Ordner agent/conf. Alle Konfigurationen in upgrade-wrapper-override.conf werden während des Upgrade-Vorgangs verwendet.

Durch Ändern der Konfiguration mit upgrade-wrapper-override.confkönnen Debug-Protokolle auf der Ebene des Wrappers dist-upgrade aktiviert und Änderungen getestet werden.

Beispielsweise kann die Standardzeitüberschreitung für bestimmte Befehle auf JVM-Ebene nicht lang genug sein. Die Zeitüberschreitung kann mit upgrade-wrapper-override.conf für die Wrapper-Konfiguration dist-upgrade erhöht werden.

Status des MID Servers

Wird aktualisiert…

Der MID Server-Status wird während der Ausführung des Upgrades in „Wird aktualisiert“ geändert. Der Status „Upgrade wird durchgeführt“ ähnelt dem Status „Angehalten“. Dadurch werden potenzielle Fehlkommunikation zwischen der neuen Version der Instanz und der vorherigen Version des MID Servers während des Upgrades vermieden. Im Zustand Wird aktualisiert können Sie den MID-Server nicht fortsetzen oder neu starten. Sie können jedoch dieselben Aktionen ausführen, die Sie ausführen können, wenn sich der MID-Server im Zustand Angehalten befindet.

Hinweis:

Wenn Sie eine Istanbul-Instanz verwenden, jedoch ein Upgrade eines Vor-Istanbul-MID-Servers zu Istanbul durchführen, sind diese Upgrade-Zustände nicht verfügbar. Sie sind nur für MID Server verfügbar, die sich bereits in Istanbul befinden.

Upgrade fehlgeschlagen

Wenn das Upgrade im Schritt „Prüfung vor dem Upgrade“ oder im Schritt „Pakete herunterladen/extrahieren“ fehlgeschlagen ist, werden fehlgeschlagene Upgrades je nach Version, die Sie aktualisieren, unterschiedlich behandelt.

Führen Sie ein Upgrade auf einen anderen Hauptrelease durch (z. B. Istanbul auf den nächsten vollständigen Release): Der Status ändert sich in Upgrade fehlgeschlagen.
Upgrade von einer Nebenversion innerhalb eines Release (z. B. „Jakarta“ Patch 1 auf Patch 2): Der MID Server verwendet weiterhin die aktuell ausgeführte Version. Es wird kein Upgrade durchgeführt, und der Status ändert sich schließlich zu Aktiv, vorausgesetzt der MID-Server funktionierte bereits ordnungsgemäß.
Wenn das Upgrade im letzten Schritt fehlgeschlagen ist (Ersetzen der alten Version von Paketen durch die neue Version von Paketen), bleibt der MID Server inaktiv.

MID Server-Upgradeverlauf

Verwenden Sie das Modul MID Server-Upgradeverlauf zur Behebung von Problemen bei MID Server-Upgrades. Das Modul enthält einen Datensatz für jedes Instanz-Upgrade. Diese Datensätze enthalten Schritt-für-Schritt-Statusdetails für den Upgrade-Prozess jedes MID Servers. Wenn ein Fehler auftritt, wird dies im Schritt vermerkt, und es wird dynamisch eine Nachricht mit weiteren Details generiert. Die Tabellenbereinigungsaufgabe löscht automatisch Probleme, die seit 30 Tagen nicht erkannt wurden, unabhängig von ihrem Status. Weitere Informationen finden Sie unter MID Server-Upgradeverlauf.

JRE TrustStore-Zertifikatmigration während JRE-Updates

Für JRE-Updates nach dem Upgrade auf Quebec migriert der MID Server vorhandene selbstsignierte Zertifikate im JRE TrustStore in den TrustStore der neuen JRE-Version. Wenn diese Zertifikate migriert werden, wird ihren Aliassen die Zeichenfolge „snc_“ vorangestellt.

Damit ein Zertifikat migriert werden kann, muss es Folgendes sein:

ein X509-Zertifikat
-Zertifikat Standard v3
Die Basiseinschränkungserweiterung muss auf „falsch“ gesetzt sein (d. h. nicht von der Zertifizierungsstelle ausgegeben).

Der MID Server erkennt, wann ein JRE-Upgrade bevorsteht, und startet den Migrationsprozess. Vor der Migration erstellt der MID Server eine Sicherung des ursprünglichen TrustStore als Fallback für den Fall eines Fehlers. Bei einem Fehler kann der Sicherungs-TrustStore manuell wiederhergestellt werden.