MID-Server-Upgrades

Yokohama Now Platform-Fähigkeiten

Release

yokohama

ft:locale

de-DE

ft:publication_title

Yokohama Now Platform-Fähigkeiten

ft:clusterId

platcap

bundleId

platcap

workflow

Platform

MID-Server-Upgrades

Freigeben Version: Yokohama

Aktualisiert 30. Januar 2025

11 Minuten Lesedauer

Führen Sie ein manuelles oder automatisches Upgrade von MID-Servern über die Instanz durch. Das automatische Upgrade des MID-Servers wird ausgelöst, wenn die Instanz aktualisiert wird und der MID-Server nicht mehr dieselbe Version hat. Das neue MID-Serverpaket wird von install.service-now.com heruntergeladen, ersetzt das alte, und der MID-Server beginnt mit der neuen Version.

Warnung:

Der MID-Server kann auf einem Windows-Host kein automatisches Upgrade durchführen, wenn der Windows-Anwendungs-Experience-Service deaktiviert ist. Informationen zum angezeigten Fehler und Anweisungen zum erneuten Aktivieren dieses Service finden Sie unter KB0597552 .

Upgrade-Anforderungen für MID-Server

Zugriff auf die Download-Website des MID-Servers: Der MID-Server-Hostcomputer muss Zugriff auf die ServiceNow-Download-Website unter haben install.service-now.com Um automatisch ein Upgrade durchzuführen. Wenn Sie über eine selbst gehostete ServiceNow-Umgebung verfügen, die den Zugriff auf die Download-Website blockiert, müssen Sie das MID-Server-Installationspaket manuell in Ihre MID-Server-Hosts importieren. Anweisungen finden Sie unter KB0760123 In der selbst gehosteten Knowledge Base.
MID-Serverzugriff auf OCSP blockiert: Firewalls und Proxy-Konfigurationen können Aufrufe an die OCSP Entrust- und DigiCert-Server blockieren, wodurch der MID-Server nicht funktioniert. Möglicherweise müssen Sie Ihre Firewall-Berechtigungen ändern, damit der OCSP-Datenverkehr durchläuft. Weitere Informationen und Lösungen finden Sie im HI-Knowledge Base-artikel [KB1216223] .
Kompatibilität des MID-Server-Betriebssystems: Das Upgrade von Windows- oder Linux-MID-Servern mit 32-Bit-Betriebssystemen wird nicht unterstützt. Weitere Informationen finden Sie unter [KB0863694] .

Der MID-Server kann auf einem Windows-Host nicht aktualisiert werden, wenn der Service für die Windows-Anwendungs-Experience deaktiviert ist. Informationen zum angezeigten Fehler und Anweisungen zum erneuten Aktivieren dieses Service finden Sie unter KB0597552 .

Das MID-Server-Upgrade wird von einigen Virenschutzprogrammen blockiert, die auf Windows-Hosts ausgeführt werden. Informationen zu den Fehlern und einer Liste dieser Virenschutzmaßnahmen 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 vorherigen Upgrades nicht manuell neu installiert haben und Ihr MID-Serverservice noch unter Madrid oder niedrigeren Versionen installiert ist, installiert der MID-Server den Service während des Upgrades automatisch neu. Zum erneuten Installieren des Service muss DER MID-Server als Administratoranwender ausgeführt werden. Wenn Ihr MID-Server-Upgrade den Service neu installieren muss, stellen Sie sicher, dass der MID-Server-Anwender Administrator 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 die Instanzversion muss aktualisiert werden. Die folgenden zwei Systemeigenschaften steuern die Version aller MID-Server:

Mid.Buildstamp : Identifiziert die MID-Serverversion mit einem Bezeichner basierend auf dem Datum des Builds. Diese Eigenschaft verwendet das Format von Mm-TT-JJJJ-hhmm . Der MID-Server sucht stündlich nach Versionsinformationen. Wenn keine Überschreibungsversion konfiguriert ist, überprüft der MID-Server Mid.Buildstamp Eigenschaft für die zu verwendende Version. Diese Eigenschaft setzt sich selbst auf die Standardversion (die Version, die Ihrer Instanzversion entspricht) zurück, wenn die Instanz neu gestartet oder aktualisiert wird, sodass alle Anwenderä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.Überschreibung : Legt eine Überschreibungsbedingung für die aktuelle Version für alle MID-Server in Ihrer Umgebung fest. Mit dieser Aktion werden die MID-Server an eine einzelne Version angehängt und die automatische Upgradefunktion deaktiviert. Diese Eigenschaft ist im Basissystem nicht sichtbar und muss der Tabelle „Systemeigenschaft“ [sys_properties] hinzugefügt werden, wenn sie festgelegt ist. Weitere Informationen finden Sie unter Fügen Sie eine Systemeigenschaft hinzu .

Wenn die MID-Server die Version jede Stunde überprüfen, sehen sie sich an Mid.Version.Überschreibung Eigenschaft zuerst. Wenn diese Eigenschaft leer ist, erhalten die MID-Server ihre Versionsinformationen von Mid.Buildstamp Eigenschaft. Wenn eine Überschreibungsversion konfiguriert ist, verwenden die MID-Server diesen Wert und ignorieren die Versionsinformationen in Mid.Buildstamp Eigenschaft. Dieser Überschreibungswert bleibt bestehen, wenn die Instanz neu gestartet wird, und wird an die MID-Server übergeben. Der Wert in Mid.Version.Überschreibung Eigenschaft wird während eines Upgrades gelöscht, wodurch der MID-Server gezwungen wird, sich selbst auf die Version in zurückzusetzen Mid.Buildstamp Eigenschaft.

Zusätzlich zu Mid.Version.Überschreibung , Die MID-Serverversion kann auch mit dem Konfigurationsparameter gesteuert werden Mid.angeheftet.Version Welche den MID-Server an eine bestimmte Version anheftet.um einen MID-Server anzuheften, legen Sie fest Mid.angeheftet.Version Parameter mit dem Namen dieser Version in config.xml Datei jedes MID-Servers. Verwenden Sie das Format <version>-mm-tt-jjjj . Diese Einstellung überschreibt die Eigenschaftseinstellung für die angeheftete MID-Serverversion. Anweisungen finden Sie unter Fügen Sie einen MID-Serverparameter hinzu . Der in diesem Parameter festgelegte Wert ist von einem Upgrade nicht betroffen.

Warnung:

Wird Verwendet Mid.Version.Überschreibung Und Mid.angeheftet.Version Wird nicht empfohlen. Die verschiedenen Versionen auf dem MID-Server und der Instanz können zu Ausfällen 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. Automatisches Upgrade erfolgt:

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

Manuell

Starten Sie das Upgrade manuell, indem Sie auf einen zugehörigen Link im MID-Server-Datensatz klicken. Verwenden Sie diese Methode, wenn Sie nicht bis zum nächsten stündlichen automatischen Update warten möchten oder wenn Ihr Upgrade fehlgeschlagen ist und Sie ein Upgrade erzwingen möchten. Siehe Führen Sie ein manuelles Upgrade des MID-Servers durch Für Anweisungen.

Upgradeprozess

Prüfung vor dem Upgrade: Vor dem Starten des tatsächlichen MID-Server-Upgradeprozesses führt der MID-Server eine Reihe von Tests aus, um sicherzustellen, dass der Hostcomputer die Mindestanforderungen erfüllt. Alle während dieses automatischen Tests aufgetretenen Fehler verhindern, dass das Upgrade auftritt, bis die Probleme gelöst 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 Prüfung vor dem Upgrade des MID-Servers.
Pakete herunterladen: Der MID-Server lädt Upgradepakete von install.service-now.com herunter. Diese Pakete sind im ZIP-Format und werden in den Agent-Ordner in heruntergeladen Paket/eingehend Ordner.
Verifizierung Der Digitalen Signatur
Nach dem Herunterladen jedes Pakets überprüft der MID-Server die digitale Signatur des Pakets. Wenn die Verifizierung fehlschlägt, wird eine Ausnahme ausgelöst. Der Fehler wird im Agent-Protokoll und in der MID-Serverproblem-Tabelle aufgezeichnet.

Wenn die Pakete manuell heruntergeladen und ersetzt werden, können Sie die Signatur manuell verifizieren. Um die Signatur eines Installations- oder Upgradepakets manuell zu überprüfen, verwenden Sie das Jarsigner-Tool, das kostenlos mit JDK verfügbar ist. Folgendes ist der jarsigner-Befehl zum Initiieren der Verifizierung: Jarsigner – Verifizieren – verbose – zert – strikte <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 Rom : Die ZIP-Dateien werden in einem Ordner unter dem vom Betriebssystem definierten temporären Ordner extrahiert. Der Ordnername ist eine zufällig generierte Zahl. Der temporäre Ordner des Betriebssystems wird durch die Systemeigenschaft angegeben java.io.tmpdir . Auf einem UNIX-Host ist der Wert für diese Eigenschaft normalerweise /Tmp Oder /Var/tmp .
- Ab Rom : 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 in extrahiert Arbeit/Upgrade_Temp Ordner unter dem Agent-Ordner. Das Ordnernamen-Format 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 hinzufügen mid.upgrade.use_os_temp_folder An MID-Server config.xml Datei und auf „wahr“ festlegen. Um das Verhalten für alle MID-Server zu ändern, können Sie es der MID-Servereigenschaft [ecc_Agent_property] hinzufügen, wobei das Feld „MID-Server“ leer ist.
Hinweis:
Wenn Sie verwenden KB0747569 Zum Ändern von java.io.tmpdir Und Sie möchten es für zukünftige Upgrades aus Rom behalten, festgelegt mid.upgrade.use_os_temp_folder Auf „wahr“ nach dem Upgrade auf Rom. Wenn mid.upgrade.use_os_temp_folder Ist dann nicht auf „wahr“ festgelegt java.io.tmpdir Wird während des MID-Server-Upgrades und des Ordners unter nicht angewendet Agent\Arbeit\Upgrade_Temp Wird verwendet.
Ersetzen Sie alte Pakete durch die aktualisierten Pakete: Nach dem Herunterladen und Extrahieren der Upgrade-Pakete ersetzt der MID-Server alte Dateien durch die neuen Dateien und beginnt mit der neuen Version. Um die Pakete zu ersetzen, startet der MID-Server einen Prozess mit dem Namen ServiceNow-Plattformverteilungs-Upgrade Und wird heruntergefahren. ServiceNow-Plattformverteilungs-Upgrade wartet darauf, dass der MID-Server ordnungsgemäß heruntergefahren wird, und ersetzt dann die erforderlichen Dateien wie folgt:
- Vor Rom: Der Prozess löscht alle Dateien und Ordner in den Ordnern bin, lib und JRE und kopiert die neuen Dateien in diese Ordner.
- Ab Rom: Der Prozess ersetzt die Dateien in bin, lib und JRE nur, wenn sich die neue Version der Datei von der alten Version unterscheidet. ServiceNow-Plattformverteilungs-Upgrade Bereinigt die Upgradedateien nicht, und die unveränderten Dateien werden beibehalten.
Wenn die Neuinstallation des Service als Teil des MID-Server-Upgrades erforderlich war, installiert ServiceNow-Plattformverteilungs-Upgrades den Service neu, bevor der MID-Server gestartet wird. Weitere Informationen finden Sie unter KB0821436 .
Hinweis:
Wenn das Upgrade des MID-Servers in diesem Schritt fehlschlägt, bleibt der MID-Server inaktiv. Einige Antiviren blockieren den Dateiersatz in diesem Schritt. Weitere Informationen finden Sie unter KB0870329 .
Starten Sie den MID-Server: Nachdem alle erforderlichen Dateien durch die neue Version ersetzt wurden, startet das ServiceNow-Plattformverteilungs-Upgrade den MID-Server. Wenn der MID-Server die neue Version bereitstellt, werden alle temporären Ordner bereinigt, die zum Extrahieren der Upgradedateien verwendet werden.

Upgradeprotokollnachrichten

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

Protokollnachrichten für die Prüfung vor dem Upgrade sind in der Datei agent.log im Ordner „Agent/Protokolle“ verfügbar. Die Nachricht Validierungstests vor dem Upgrade werden durchgeführt. Gibt an, dass die Prüfung vor dem Upgrade gestartet wurde. Wenn alle obligatorischen Tests bestanden wurden, wird die Nachricht angezeigt Validierungstests vor dem Upgrade erfolgreich. Upgrade-Prozess 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 Paket wird von https://install.service-now.com/ PACKAGEINFO auf PACKAGENAME.ZIP heruntergeladen Nachricht. Der Download-Fortschritt und die Größe der heruntergeladenen Datei werden im Protokoll überwacht. Nach dem Herunterladen jedes Pakets Paket wurde erfolgreich von https://install.service-now.com/ PACKAGEINFO heruntergeladen Gibt den erfolgreichen Download an.
Das Extrahieren der ZIP-Dateien ist der letzte Schritt, der in verfügbar ist agent.log . Die Nachricht MID-Server wird aktualisiert Gibt den Start dieses Schritts und die Nachricht an Paket wird extrahiert PACKAGE.ZIP in „EXTRAHIEREN_TMP_FOLDER“ Wird für jede Paketextraktion angezeigt. Wenn alle erforderlichen ZIP-Dateien erfolgreich extrahiert wurden, startet der MID-Server den Prozess „ServiceNow-Plattformverteilung aktualisieren“ und die Nachricht MID-Server wird gestoppt. Bootstrapping-Upgrade Zeigt das Ende dieses Schritts an, bevor der MID-Server ausfällt.

Die Upgradeprotokolle der ServiceNow-Plattformverteilung enthalten Protokollnachrichten für den Prozessstart und zum Ersetzen von Dateien während des MID-Server-Upgrades. Die Upgradeprotokollnachrichten werden zwischen den Nachrichten platziert ************ UPGRADE DER HAUPTANMELDUNG STARTEN************** Und ************ UPGRADE DER HAUPTANMELDUNG ENDE************* . Die Protokollnachrichten zum Upgrade der ServiceNow-Plattformverteilung finden Sie in den folgenden Protokolldateien:

In glide-dist-upgrade.log Datei im temporären Extraktionsordner. Diese Datei ist im Ordner „Upgrade-Wrapper/logs“ im Ordner „Temp. Extraktion“ verfügbar. Diese Protokolldatei enthält Prozessprotokollnachrichten und Upgradeprotokollnachrichten.
In dist-upgrade.log Datei in Agent\Protokolle Ordner. Diese Datei enthält nur den Upgrade-Teil von Protokollnachrichten. Wenn beim Starten des Prozesses ein Problem aufgetreten ist, müssen Sie sich das ansehen Glide-dist-Upgrade.log.
In wrapper.log Unter Agent\Protokolle Ordner. Nach dem Ersetzen von Dateien wird das ServiceNow-Plattformverteilungs-Upgrade angehängt glide-dist-upgrade.log In die Datei wrapper.log.

Aktualisieren Sie die Wrapper-Konfiguration mit Upgrade-Wrapper-override.conf

Die Wrapper-Konfiguration für Glide-dist-Upgrade Kann mit aktualisiert werden Upgrade-Wrapper-override.conf Datei. Erstellen Sie eine Datei mit dem Namen Upgrade-Wrapper-override.conf In Service Desk-Mitarbeiter/Konf Ordner. Alle Konfigurationen in Upgrade-Wrapper-override.conf Werden während des Upgradeprozesses verwendet.

Durch Ändern der Konfiguration mit Upgrade-Wrapper-override.conf , Debug-Protokolle können auf aktiviert werden dist-Upgrade Wrapper-Ebene und Änderungen können getestet werden.

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

MID-serverstatus

Wird aktualisiert…

Der MID-Serverstatus wird während des Upgrades in „Upgrade“ geändert. Der Upgradestatus ähnelt dem Angehalten status. Dadurch wird vermieden, dass während des Upgrades potenzielle Missverständnisse zwischen der neuen Version der Instanz und der vorherigen Version des MID-Servers auftreten. Im Upgradestatus können Sie den MID-Server nicht fortsetzen oder neu starten. Sie können jedoch die gleichen Aktionen ausführen, die Sie ausführen können, wenn sich der MID-Server im Status „Angehalten“ befindet.

Hinweis:

Wenn Sie eine Istanbul-Instanz verwenden, aber einen MID-Server vor Istanbul auf Istanbul upgraden, sind diese Upgrade-status 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 „Pakete herunterladen/extrahieren“ fehlgeschlagen ist, werden fehlgeschlagene Upgrades je nach Version, die Sie aktualisieren, unterschiedlich behandelt.

Upgrade auf ein anderes schwerwiegendes Release (z. B. Istanbul auf das nächste vollständige 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 derzeit ausgeführte Version. Das Upgrade wird nicht durchgeführt, und der Status ändert sich schließlich in Aktiv , Vorausgesetzt, der MID-Server funktionierte bereits ordnungsgemäß.
Wenn das Upgrade im letzten Schritt fehlgeschlagen ist und die alte Version von Paketen durch die neue Version von Paketen ersetzt wird, bleibt der MID-Server erhalten Ausgefallen .

Upgradeverlauf des MID-Servers

Verwenden Sie das Modul „MID-Server-Upgradeverlauf“ zur Behebung von Problemen mit MID-Server-Upgrades. Das Modul enthält einen Datensatz jedes Instanz-Upgrades. Diese Datensätze bieten Schritt-für-Schritt-Statusdetails für den Upgradeprozess jedes MID-Servers. Wenn ein Fehler auftritt, wird er im Schritt bemerkt, und eine Nachricht mit weiteren Details wird dynamisch generiert. Der Tabellenbereinigungsauftrag 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 zum 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:

Ein X509-Zertifikat
Zertifikatstandard v3
Legen Sie die Erweiterung der Standardeinschränkung auf „falsch“ fest (d. h. es handelt sich nicht um EINE CA-Ausgabe).

Der MID-Server identifiziert, wann ein JRE-Upgrade stattfinden soll, und beginnt den Migrationsprozess. Vor der Migration erstellt der MID-Server eine Sicherung des ursprünglichen TrustStore als Fallback im Falle eines Fehlers. Bei einem Fehler kann der Sicherungs-TrustStore manuell wiederhergestellt werden.