MID-Server-Upgrades

Freigeben Version: Zurich

Aktualisiert 31. Juli 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-Server-Paket 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 Application 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 MID-Server-Download-Site: Der MID-Server-Hostcomputer muss Zugriff auf die ServiceNow-Download-Website unter haben install.service-now.com Dient zum automatischen Upgrade. 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 finden Sie unter KB0760123 In der selbst gehosteten Knowledge Base.
MID-Server-Zugriff auf OCSP blockiert: Firewalls und Proxy-Konfigurationen können Aufrufe auf 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 Windows-Anwendungs-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 Virenschutzprogrammen blockiert, die auf Windows-Hosts ausgeführt werden. Informationen zu den Fehlern und einer Liste dieser Virenschutzprogramme 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-Server-Service noch unter 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 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 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 von 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 fügt 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 Fügen Sie eine Systemeigenschaft hinzu .

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.Überschreibung , Die MID-Server-Version 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 angepinnte Version des MID-Servers. Anweisungen finden Sie unter Fügen Sie einen MID-Server-Parameter hinzu . Der in diesem Parameter festgelegte Wert wird von einem Upgrade nicht beeinflusst.

Warnung:

Verwenden 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 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 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 zur nächsten stündlichen automatischen Aktualisierung warten möchten oder wenn das 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: Bevor der tatsächliche MID-Server-Upgrade-Prozess gestartet wird, 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 Upgradepakete von install.service-now.com herunter. Diese Pakete sind im ZIP-Format und werden in den Agent-Ordner im heruntergeladen Paket/eingehend Ordner.
Verifizierung Der Digitalen Signatur
Nach dem Herunterladen jedes Pakets überprüft 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-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 Upgradepakets manuell zu überprüfen, verwenden Sie das Jarsigner-Tool, das kostenlos mit JDK verfügbar ist. Im Folgenden finden Sie den jarsigner-Befehl zum Initiieren der Verifizierung: Jarsigner – Verify – verbose – certs – strikter <zip-file>
Die Ausgabe sollte dem folgenden Beispiel ähnlich sein:
```
- 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 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 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 im extrahiert Arbeit/Upgrade_Temp Ordner unter dem Agent-Ordner. 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 hinzufügen mid.upgrade.use_os_temp_folder An MID-Server config.xml Datei und legen Sie sie auf „wahr“ fest. 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 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, legen Sie fest 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 AI Platform„ Verteilungs-Upgrade und wird heruntergefahren. ServiceNow AI Platform Das Verteilungs-Upgrade wartet, bis der MID-Server ordnungsgemäß heruntergefahren ist, 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 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 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 ServiceNow AI Platform Das Verteilungs-Upgrade startet 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 zur 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 Meldung 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 aus 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 Beginn dieses Schritts und die Nachricht an Paket PACKAGE.ZIP wird in „EXTRAHIEREND_TMP_FOLDER“ extrahiert Wird für jede Paketextraktion angezeigt. Wenn alle erforderlichen ZIP-Dateien erfolgreich extrahiert wurden, startet der MID-Server ServiceNow AI Platform Verteilungs-Upgrade-Prozess und die Nachricht MID-Server wird gestoppt. Bootstrapping-Upgrade wird durchgeführt Zeigt das Ende dieses Schritts an, bevor der MID-Server ausfällt.

ServiceNow AI Platform Verteilungs-Upgrade-Protokolle 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*************** . ServiceNow AI Platform Protokollnachrichten des Verteilungs-Upgrades finden Sie in den folgenden Protokolldateien:

In glide-dist-upgrade.log Datei unter temporärem 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 Prozessstart ein Problem aufgetreten ist, müssen Sie sich dies ansehen Glide-dist-Upgrade.log.
In wrapper.log Unter Agent\Protokolle Ordner. Nach dem Ersetzen von Dateien ServiceNow AI Platform Verteilungs-Upgrade wird 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 in aktiviert werden dist-Upgrade Wrapper-Ebene und Änderungen können getestet werden.

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

MID-Server-status

Wird aktualisiert…

Der MID-Server-Status wird während des Upgrades in Upgrade geändert. Der Upgradestatus ähnelt dem Angehalten status. Dadurch wird eine 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 „Pakete herunterladen/extrahieren“ fehlgeschlagen ist, werden fehlgeschlagene Upgrades je nach Version, die Sie aktualisieren, unterschiedlich behandelt.

Upgrade auf ein anderes Major-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 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 wurde, bleibt der MID-Server erhalten Ausgefallen .

MID-Server-Upgradeverlauf

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 enthalten Schritt-für-Schritt-Statusdetails für den Upgradeprozess jedes MID-Servers. Wenn ein Fehler auftritt, wird er im Schritt vermerkt, 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 TrustStore für die Sicherung manuell wiederhergestellt werden.