MID-Server-Upgrades

Freigeben Version: Yokohama

Aktualisiert 30. Januar 2025

11 Minuten Lesedauer

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

Warnung:

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

MID-Server-Upgrade-Anforderungen

Zugriff auf die MID-Server-Download-Site: Der Hostcomputer des MID-Servers muss Zugriff auf die ServiceNow-Download-Website unter install.service-now.com haben, um das Upgrade automatisch durchzuführen. Wenn Sie über eine selbst gehostete ServiceNow-Umgebung verfügen, die den Zugriff auf die Download-Site blockiert, müssen Sie das MID-Server-Installationspaket manuell in Ihre MID-Server-Hosts importieren. Anweisungen hierzu 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 weitergeleitet wird. Weitere Informationen und Lösungen finden Sie im HI Knowledge Base-Artikel [KB1216223].
Kompatibilität mit MID-Server-Betriebssystemen: Ein 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 Windows Application Experience-Service deaktiviert ist. Informationen zum angezeigten Fehler und Anweisungen zum erneuten Aktivieren dieses Service finden Sie unter KB0597552.

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

Jedes Upgrade von Linux MID Server, 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-Server-Service noch auf Madrid-Versionen oder niedriger installiert ist, installiert der MID-Server den Service während des Upgrades automatisch neu. Zur erneuten Installation des Service muss MID-Server als Administratorbenutzer ausgeführt werden. Wenn Ihr MID-Server-Upgrade den Service neu installieren muss, stellen Sie sicher, dass der MID-Server-Anwender Administrator ist, oder installieren Sie den Service vor dem Upgrade manuell neu. Informationen zur manuellen Neuinstallation des Service finden Sie unter KB0821436.

Wann muss der MID-Server aktualisiert werden?

Jeder MID Server mit einer Version, die sich von der Instanzversion unterscheidet, 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 Releasenamen und Patchinformationen an das Datums- und Uhrzeitformat an.
Warnung:
Diese Eigenschaft ist standardmäßig nicht sichtbar und darf 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. Einzelheiten finden Sie unter Systemeigenschaft 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 hierzu 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 vom 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.
Der MID Server fragt stündlich bei der Instanz nach, 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 den zugehörigen Link im MID-Server-Datensatz 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 MID-Server manuell upgraden.

Upgrade-Prozess

Prüfung vor dem Upgrade:Vor dem Start des tatsächlichen MID-Server-Upgrade-Prozesses führt der MID-Server eine Reihe von Tests aus, 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.
Verifizierung der digitalen Signatur
Nach dem Herunterladen jedes Pakets überprüft der MID-Server die digitale Signatur des Pakets. Es löst eine Ausnahme aus, wenn die Verifizierung 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 Verifizierung: „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 Zahl. 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 einem Ordner im Ordner „ work/upgrade_temp“ unter dem Ordner „agent“ 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_folder“zur Datei „config.xml“ des MID-Servers hinzufügen und auf „wahr“ setzen. Um das Verhalten für alle MID-Server zu ändern, können Sie sie der MID-Server-Eigenschaft [ecc_agent_property] hinzufügen, indem Sie das Feld „MID-Server“ leer lassen.
Hinweis:
Wenn Sie KB0747569 verwenden, um „java.io.tmpdir“zu ändern, und es für zukünftige Upgrades von Rome beibehalten möchten, legen Sie „mid.upgrade.use_os_temp_folder“nach dem Upgrade auf Rome auf „wahr“ 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 Upgradepakete ersetzt der MID-Server die alten Dateien durch die neuen Dateien und startet dann 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 ServiceNow Platform Distribution Upgrade wartet, bis 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. Beim Upgrade der ServiceNow Platform Distribution werden die Upgrade-Dateien nicht bereinigt, und die unveränderten Dateien werden beibehalten.
Wenn die Neuinstallation des Services 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 unter KB0821436.
Hinweis:
Wenn das Upgrade des MID-Servers in diesem Schritt fehlschlägt, bleibt der MID-Server ausgefallen. Einige Antivirenprogramme blockieren den Dateiaustausch in diesem Schritt. Weitere Informationen finden Sie unter KB0870329.
MID-Server starten:Nachdem alle erforderlichen Dateien durch die neue Version ersetzt wurden, startet das Upgrade der ServiceNow-Plattformverteilung den MID-Server. Wenn der MID-Server mit der neuen Version hochgefahren wird, bereinigt er alle temporären Ordner, die zum Extrahieren der Upgradedateien verwendet werden.

Upgrade-Protokollnachrichten

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

Protokollnachrichten zur Prüfung vor dem Upgrade sind in der Datei „agent.log“ im Ordner „agent/logs“ verfügbar. Die Meldung 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 Meldung Validierungstests vor dem Upgrade erfolgreich angezeigt. 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 Meldung Paket wird in PACKAGENAME.ZIP von https://install.service-now.com/ PACKAGEINFO heruntergeladen. Der Download-Fortschritt und die Größe der heruntergeladenen Datei werden im Protokoll überwacht. Nach dem Herunterladen aller Pakete gibt „Paket wurde erfolgreich von https://install.service-now.com/ heruntergeladen“ PACKAGEINFO gibt den erfolgreichen Download an.
Das Extrahieren der ZIP-Dateien ist der letzte im agent.logverfügbare Schritt. Die Meldung MID-Server wird aktualisiert zeigt den Beginn dieses Schritts an, und die Meldung Paket PACKAGE.ZIP wird nach EXTRACT_TMP_Folder extrahiert wird für jede Paketextraktion angezeigt. Wenn alle erforderlichen ZIP-Dateien erfolgreich extrahiert wurden, startet der MID-Server den Upgrade-Prozess der ServiceNow Platform Distribution und die Meldung , MID-Server wird beendet, wird angezeigt. Das Bootstraping-Upgrade zeigt das Ende dieses Schritts, bevor der MID-Server ausfällt.

Die Upgrade-Protokolle der ServiceNow Platform Distribution enthalten Protokollnachrichten für den Prozessstart und für das Ersetzen von Dateien während des MID-Server-Upgrades. Die Upgradeprotokollnachrichten werden zwischen den Nachrichten ***********UPGRADE MAIN LOGIN START*********** und ***********UPGRADE MAIN LOGINplatziert ENDE********** . Protokollnachrichten für das Upgrade der ServiceNow-Plattformverteilung sind in den folgenden Protokolldateien zu finden:

In der Datei glide-dist-upgrade.log im Ordner für temporäre Extrakte. Diese Datei ist im Ordner „upgrade-wrapper/logs“ im Ordner für temporäre Extrakte verfügbar. Diese Protokolldatei enthält Prozessprotokollnachrichten und Upgradeprotokollnachrichten.
In der Datei „dist-upgrade.log“ im Ordner „agent\logs“. Diese Datei enthält nur den Upgrade-Teil von Protokollnachrichten. Wenn beim Starten des Prozesses ein Problem aufgetreten ist, müssen Sie glide-dist-upgrade.log überprüfen.
In „ wrapper.log“ im Ordner „agent\logs“. Nach dem Ersetzen von Dateien fügt ServiceNow Platform Distribution Upgrade „glide-dist-upgrade.log“ an die Datei „wrapper.log“ an.

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

Die Wrapper-Konfiguration für „glide-dist-upgrade“ kann mit der Datei „upgrade-wrapper-override.conf“ aktualisiert werden. Erstellen Sie im Ordner „agent/conf“ eine Datei mit dem Namen upgrade-wrapper-override.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 Ebene des Wrappers „dist-upgrade“ aktiviert und Änderungen getestet werden.

Beispielsweise ist die standardmäßige Zeitüberschreitung für bestimmte Befehle auf JVM-Ebene möglicherweise nicht lang genug. 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…

Während das Upgrade ausgeführt wird, ändert sich der Status des MID Servers in „Wird aktualisiert“. Der Status „Upgrade wird durchgeführt“ ähnelt dem Status „ Angehalten “. Dadurch wird verhindert, dass während des Upgrades eine Fehlkommunikation zwischen der neuen Version der Instanz und der vorherigen Version des MID-Servers auftritt. 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.

Upgrade auf einen anderen Hauptrelease durchführen (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 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 und die alte Version von Paketen durch die neue Version von Paketen ersetzt wird, bleibt der MID-Server ausgefallen.

Upgradeverlauf des MID-Servers

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 Upgradeprozess jedes MID-Servers. Wenn ein Fehler auftritt, wird er im Schritt vermerkt, und es wird dynamisch eine Nachricht mit weiteren Details generiert. Die Tabellenbereinigungsaufgabe löscht automatisch Probleme, die 30 Tage lang 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:

ein X509-Zertifikat
Zertifizierungsstandard v3
Die grundlegende Einschränkungserweiterung ist auf „falsch“ festgelegt (d. h. nicht von CA ausgestellt).

Der MID Server erkennt, wann ein JRE-Upgrade bevorsteht, und beginnt den Migrationsprozess. Vor der Migration erstellt der MID-Server eine Sicherungskopie des ursprünglichen Truststore, um bei einem Ausfall zurückgreifen zu können. Bei einem Fehler kann der Sicherungs-TrustStore manuell wiederhergestellt werden.