Mises à niveau de MID Server

Rversion finale: Washingtondc

Mis à jour 1 févr. 2024

15 minutes de lecture

Mettez à niveau les MID Servers manuellement ou automatiquement via l’instance. La mise à niveau automatique du MID Server est déclenchée lorsque l’instance est mise à niveau et que le MID Server n’a plus la même version. Le nouveau package du MID Server est téléchargé à partir de install.service-now.com, remplace l’ancien et le MID Server démarre avec la nouvelle version.

Avertissement :

Le MID Server ne peut pas effectuer la mise à niveau automatique sur un hôte Windows si le service d’expérience applicative Windows est désactivé. Pour plus d’informations sur l’erreur qui s’affiche et les instructions pour réactiver ce service, consultez KB0597552.

Configuration requise pour la mise à niveau du MID Server

Accès au site de téléchargement du MID Server: L’ordinateur hôte du Serveur MID doit avoir accès au site de téléchargement ServiceNow au install.service-now.com pour se mettre à niveau automatiquement. Si vous disposez d’un environnement ServiceNow auto-hébergé qui bloque l’accès au site de téléchargement, vous devez importer manuellement le package d’installation du MID Server dans vos hôtes MID Server. Pour obtenir des instructions, consultez KB0760123 dans la base de connaissances auto-hébergée.
Accès du MID Server à OCSP bloqué: Les pare-feu et les configurations de proxy peuvent bloquer les appels vers le serveur OCSP Entrust, empêchant ainsi le MID Server de fonctionner. Vous devrez peut-être modifier vos autorisations de pare-feu afin que le trafic OCSP passe correctement. Pour plus d’informations et de résolutions, consultez l’article de la base de connaissances HI [KB1216223].
Compatibilité du système d’exploitation du MID Server: La mise à niveau des MID Servers Windows ou Linux avec des systèmes d’exploitation 32 bits n’est pas prise en charge. Pour plus d’informations, consultez [KB0863694].

Le MID Server ne peut pas effectuer la mise à niveau sur un hôte Windows si le service Windows Application Experience est désactivé. Pour plus d’informations sur l’erreur qui s’affiche et les instructions pour réactiver ce service, consultez KB0597552.

La mise à niveau du MID Server est bloquée par certains antivirus exécutés sur les hôtes Windows. Pour plus d’informations sur les erreurs et la liste de ces antivirus, voir KB0870329.

Toute mise à niveau du MID Server Linux dont le service est installé sous le système dans Madrid ou une version antérieure doit réinstaller le service après la mise à niveau. Si vous n’avez pas réinstallé manuellement le service lors des mises à niveau précédentes et que votre service MID Server est toujours installé sur Madrid ou sur des versions antérieures, pendant la mise à niveau, MID Server réinstalle automatiquement le service. Pour réinstaller le service, le serveur MID doit s’exécuter en tant qu’utilisateur administrateur. Si la mise à niveau de votre MID Server doit réinstaller le service, assurez-vous que l’utilisateur du MID Server est administrateur, ou vous pouvez réinstaller manuellement le service avant la mise à niveau. Pour plus d’informations sur la réinstallation manuelle du service, consultez KB0821436.

Quand le MID Server doit-il être mis à niveau ?

Tout MID Server avec une version différente de la version de l’instance doit effectuer une mise à niveau. Les deux propriétés système suivantes contrôlent la version de tous les MID Servers :

mid.buildstamp : identifie la version du MID Server avec un identificateur basé sur la date de la build. Cette propriété utilise le format mm-jj-aa-hhmm. Le MID Server recherche les informations sur la version toutes les heures. Si aucune version de remplacement n’est configurée, le MID Server examine la propriété mid.buildstamp pour la version à utiliser. Cette propriété se réinitialise automatiquement à la version par défaut (la version qui correspond à la version de votre instance) lorsque celle-ci est redémarrée ou mise à niveau, de sorte que toutes les modifications apportées par l’utilisateur sont perdues à ce moment-là. Le système ajoute le nom de la version et les informations de correctif au format de date et d’heure.
Avertissement :
Cette propriété n’est pas visible par défaut et ne doit pas être configurée.
mid.version.override : définit une condition de remplacement pour la version actuelle pour tous les MID Servers de votre environnement. Cette action épingle les MID Server à une seule version et désactive la fonctionnalité de mise à niveau automatique. Cette propriété n’est pas visible dans le système de base et doit être ajoutée à la table Propriétés système [sys_properties] lorsqu’elle est définie. Pour en savoir plus, reportez-vous à la section Ajouter une propriété système.

Lorsque les MID Server vérifient la version toutes les heures, ils examinent d’abord la propriété mid.version.override . Si cette propriété est vide, les MID Server obtiennent leurs informations de version à partir de la propriété mid.buildstamp . Si une version de remplacement est configurée, les MID Server utilisent cette valeur et ignorent les informations de version dans la propriété mid.buildstamp . Cette valeur de remplacement est conservée lorsque l’instance est redémarrée et est transmise aux MID Servers. La valeur de la propriété mid.version.override est effacée lors d’une mise à niveau, ce qui oblige le MID Server à se réinitialiser à la version de la propriété mid.buildstamp .

En plus de mid.version.override, la version du MID Server peut également être contrôlée avec le paramètre de configuration mid.pinned.version qui épingle le MID Server à une version spécifique. Pour épingler un MID Server, définissez le paramètre mid.pinned.version avec le nom de cette version dans le fichier config.xml de chaque MID Server. Utilisez le format <version>-mm-jj-aaaa. Ce paramètre remplace le paramètre de propriété pour la version épinglée du MID Server. Pour obtenir des instructions, consultez Ajouter un paramètre de MID Server. La valeur définie dans ce paramètre n’est pas affectée par une mise à niveau.

Avertissement :

Il n’est pas recommandé d’utiliser mid.version.override et mid.pinned.version . Les différentes versions sur le MID Server et l’instance peuvent entraîner des problèmes de panne sur le MID Server.

Méthodes de mise à niveau

Automatique

La mise à niveau automatique peut être déclenchée par l’instance ou le MID Server lui-même. Cette fonctionnalité est disponible par défaut. La mise à niveau automatique se produit :

Lorsque l’instance est mise à niveau et que le MID Server de cette version est différent de la version actuellement sur le MID Server. L’instance envoie la commande système autoUpgradeaux MID Servers connectés.
Toutes les heures, le MID Server vérifie auprès de l’instance s’il existe une version différente disponible pour la mise à niveau. Vous ne pouvez pas modifier cette période.

Manuel

Démarrez manuellement la mise à niveau en cliquant sur un lien connexe sur l’enregistrement du MID Server. Utilisez cette méthode lorsque vous ne souhaitez pas attendre la prochaine mise à jour automatique toutes les heures ou si votre mise à niveau a échoué et que vous souhaitez forcer une mise à niveau. Reportez-vous à la section Mettre à niveau manuellement le MID Server pour obtenir des instructions.

Processus de mise à niveau

Vérification avant mise à niveau :Avant de commencer le processus de mise à niveau proprement dit du MID Server, celui-ci exécute un ensemble de tests pour s’assurer que l’ordinateur hôte répond aux exigences minimales. Toute erreur rencontrée au cours de ce test automatique empêche la mise à niveau de se produire tant que les problèmes ne sont pas résolus. Le test préalable à la mise à niveau est activé par défaut, mais peut être désactivé en ajoutant et en définissant une propriété système. Consultez Vérification avant mise à niveau du Serveur MID pour plus d'informations.
Téléchargez les packages :Le MID Server télécharge les packages de mise à niveau à partir de install.service-now.com. Ces packages sont au format zip et sont téléchargés dans le dossier agent dans le dossier package/entrant .
Vérification de signature numérique
Après avoir téléchargé chaque package, MID Server vérifie la signature numérique du package. Une exception est générée en cas d’échec de la vérification. L’erreur sera enregistrée dans le journal de l’agent et dans la table des problèmes du MID Server.

Si les packages sont téléchargés et remplacés manuellement, vous pouvez vérifier la signature manuellement. Pour vérifier manuellement la signature d’un package d’installation ou de mise à niveau, utilisez l’outil jarsigner qui est disponible gratuitement avec JDK. Voici la commande jarsigner pour lancer la vérification : Jarsigner -verify -verbose -certs -strict <zip-file>
La sortie doit être similaire à l’exemple suivant :
```
- 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.
```
Extraction des fichiers zip :Après avoir téléchargé tous les packages requis, le MID Server extrait les fichiers zip.
- Avant Rome : les fichiers zip sont extraits dans un dossier sous le dossier temporaire défini par le système d’exploitation. Le nom du dossier est un nombre généré aléatoirement. Le dossier temporaire du système d’exploitation est spécifié par la propriété système java.io.tmpdir. Sur un hôte Unix, la valeur de cette propriété est généralement /tmp ou /var/tmp.
- À partir de Rome : le MID Server évite d’utiliser des dossiers temporaires définis par le système d’exploitation lors de la mise à niveau du MID Server. Les fichiers zip sont extraits dans un dossier du dossier de travail/upgrade_temp sous le dossier de l’agent. Le format du nom de dossier est un nombre généré aléatoirement. Si vous souhaitez passer au comportement précédent et utiliser un dossier temporaire défini par le système d’exploitation, vous pouvez ajouter mid.upgrade.use_os_temp_folderau fichier config.xml du MID Server et le définir sur vrai. Pour changer le comportement de tous les MID Servers, vous pouvez l’ajouter à la propriété du MID Server [ecc_agent_property] en laissant le champ MID Server vide.
Remarque :
Si vous utilisez KB0747569 pour modifierjava.io.tmpdiret que vous souhaitez le conserver pour les futures mises à niveau à partir de Rome, définissez mid.upgrade.use_os_temp_foldersur true après la mise à niveau vers Rome. Si mid.upgrade.use_os_temp_folder n’est pas défini sur vrai, java.io.tmpdir n’est pas appliqué pendant la mise à niveau du MID Server et le dossier sous agent\work\upgrade_temp sera utilisé.
Remplacez les anciens packages par les packages mis à niveau :Après le téléchargement et l’extraction des packages de mise à niveau, le MID Server remplace les anciens fichiers par les nouveaux fichiers et démarre avec la nouvelle version. Pour remplacer les packages, le MID Server démarre un processus nommé Mise à niveau de la distribution de la plateforme ServiceNow et s’arrête. La mise à niveau de la distribution de la plateforme ServiceNow attend que le MID Server s’arrête correctement, puis remplace les fichiers requis comme suit :
- Avant Rome :Le processus supprime tous les fichiers et dossiers des dossiers bin, lib et jre et copie les nouveaux fichiers dans ces dossiers.
- À partir de Rome : Le processus remplace les fichiers dans les fichiers bin, lib et jre uniquement si la nouvelle version du fichier est différente de l’ancienne version. La mise à niveau de la distribution de la plateforme ServiceNow ne nettoie pas les fichiers de mise à niveau et les fichiers inchangés sont conservés.
Si le service de réinstallation était requis dans le cadre de la mise à niveau du MID Server, la mise à niveau de la distribution de la plateforme ServiceNow réinstalle le service avant de démarrer le MID Server. Pour plus d’informations, reportez-vous à KB0821436.
Remarque :
Si la mise à niveau du MID Server échoue à cette étape, le MID Server reste en panne. Certains antivirus bloquent le remplacement du fichier dans cette étape. Pour plus d’informations, reportez-vous à KB0870329.
Démarrez le MID Server :Après avoir remplacé tous les fichiers requis par la nouvelle version, la mise à niveau de distribution de la plateforme ServiceNow démarre le MID Server. Lorsque le MID Server fournit la nouvelle version, il nettoie tous les dossiers temporaires utilisés pour extraire les fichiers de mise à niveau.

Mettre à niveau les messages du journal

Les messages de journal du MID Server sont disponibles dans les fichiers journaux suivants :

Les messages du journal de vérification préalable à la mise à niveau sont disponibles dans agent.log fichier sous le dossier agent/logs. Le message Exécution de tests de validation préalables à la mise à niveau. indique que la vérification préalable à la mise à niveau a commencé. Si tous les tests obligatoires sont réussis, le message Tests de validation préalables à la mise à niveau réussit. Poursuite du processus de mise à niveau. Indique la fin de la vérification préalable à la mise à niveau.
Des messages de journal pour le téléchargement des fichiers manquants sont également disponibles dans agent.log. Chaque téléchargement de package commence par Téléchargement du package à PACKAGENAME.ZIP à partir de https://install.service-now.com/ message PACKAGEINFO . La progression du téléchargement et la taille du fichier téléchargé sont surveillées dans le journal. Après le téléchargement de chaque package, le package a été téléchargé avec succès à partir de https://install.service-now.com/ PACKAGEINFO indique que le téléchargement a réussi.
L’extraction des fichiers zip est la dernière étape disponible dans le agent.log. Le message Mise à niveau de MID Server indique le début de cette étape et le message Extraction du package PACKAGE.ZIP à EXTRACT_TMP_FOLDER s’affiche pour chaque extraction de package. Lorsque tous les fichiers zip requis sont extraits avec succès, le MID Server démarre le processus de mise à niveau de la distribution de la plateforme ServiceNow et le message Arrêt du MID Server. La mise à niveau d’amorçage indique la fin de cette étape avant que Serveur MID ne tombe en panne.

Les journaux de mise à niveau de la distribution de la plateforme ServiceNow incluent des messages de journal pour le démarrage du processus et pour le remplacement des fichiers pendant la mise à niveau du MID Server. Les messages du journal de mise à niveau sont placés entre les messages ***********DÉBUT DE LA CONNEXION PRINCIPALE DE MISE À NIVEAU *********** et ***********FIN DE LA CONNEXION PRINCIPALE DE MISE À NIVEAU***********. Les messages du journal de la mise à niveau de la distribution de la plateforme ServiceNow se trouvent dans les fichiers journaux suivants :

Dans le fichier glide-dist-upgrade.log sous le dossier temp extract. Ce fichier est disponible dans le dossier upgrade-wrapper/logs sous temp extract folder. Ce fichier journal inclut les messages du journal de processus et les messages du journal de mise à niveau.
Dans le fichier dist-upgrade.log dans le dossier agent\logs . Ce fichier inclut uniquement la partie mise à niveau des messages de journal. S’il y a eu un problème avec le démarrage du processus, vous devez examiner glide-dist-upgrade.log.
Dans wrapper.logsous le dossier agent\logs . Après avoir remplacé les fichiers, la mise à niveau de la distribution de la plateforme ServiceNow ajoute glide-dist-upgrade.log au fichier wrapper.log.

Mettre à jour la configuration du wrapper avec upgrade-wrapper-override.conf

La configuration du wrapper pour glide-dist-upgrade peut être mise à jour à l’aide d’un fichier upgrade-wrapper-override.conf . Créez un fichier nommé upgrade-wrapper-override.conf dans le dossier agent/conf . Toutes les configurations du fichier upgrade-wrapper-override.conf sont utilisées pendant le processus de mise à niveau.

En modifiant la configuration avec upgrade-wrapper-override.conf, les journaux de débogage peuvent être activés au niveau du wrapper dist-upgrade et les changements peuvent être testés.

Par exemple, le délai d’expiration par défaut peut ne pas être assez long pour certaines commandes de niveau JVM. Le délai d’expiration peut être augmenté avec upgrade-wrapper-override.conf pour la configuration dist-upgrade wrapper.

États du MID Server

Mise à niveau

L’état du MID Server passe à Mise à niveau pendant l’exécution de la mise à niveau. L’état de mise à niveau est similaire à l’état Pause . Cela permet d’éviter les malentendus potentiels entre la nouvelle version de l’instance et la version précédente du MID Server pendant la mise à niveau. Lorsque vous êtes dans l’état de mise à niveau, vous ne pouvez pas reprendre ou redémarrer le MID Server. Toutefois, vous pouvez effectuer les mêmes actions que lorsque le MID Server est à l’état En pause.

Remarque :

Si vous utilisez une instance Istanbul, mais que vous mettez à niveau un MID Server antérieur à Istanbul vers Istanbul, ces états de mise à niveau ne sont pas disponibles. Ils ne sont disponibles que pour les MID Servers qui se trouvent déjà à Istanbul.

Échec de la mise à niveau

Si la mise à niveau a échoué à l’étape de vérification préalable à la mise à niveau ou à l’étape de téléchargement/extraction de packages, les échecs de mise à niveau sont traités différemment en fonction de la version que vous mettez à niveau.

Mise à niveau vers une autre version majeure (par exemple, Istanbul vers la prochaine version complète) : l’état passe à Échec de la mise à niveau.
Mise à niveau d’une version mineure au sein d’une mise en production (par exemple, Jakarta Patch 1 vers Patch 2) : le MID Server continue d’utiliser la version qu’il est en cours d’exécution. La mise à niveau n’est pas effectuée et l’état finit par passer à Actif, en supposant que le MID Server fonctionnait déjà correctement.
Si la mise à niveau a échoué lors de la dernière étape, lors du remplacement de l’ancienne version des packages par la nouvelle version des packages, le MID Server reste en panne.

Historique des mises à niveau du Serveur MID

Utilisez le module Historique des mises à niveau du serveur MID pour résoudre les problèmes liés aux mises à niveau du serveur MID. Le module contient un enregistrement de chaque mise à niveau d’instance. Ces enregistrements fournissent des détails d’état étape par étape pour le processus de mise à niveau de chaque MID Server. Si une erreur se produit, elle est notée dans l’étape et un message est généré dynamiquement avec plus de détails. La tâche de nettoyage de table supprime automatiquement les problèmes qui n’ont pas été détectés pendant 30 jours, quel que soit leur état. Pour plus d’informations, consultez Historique des mises à niveau du MID Server.

Migration des certificats TrustStore JRE pendant les mises à jour JRE

Pour les mises à jour JRE après la mise à niveau vers Quebec, le MID Server migre les certificats autosignés existants dans le magasin de confiance JRE vers le magasin de confiance de la nouvelle version JRE. Lorsque ces certificats sont migrés, leurs alias sont précédés de la chaîne « snc_ ».

Pour qu’un certificat puisse être migré, il doit :

un certificat X509
Norme de certificat v3
définir l’extension de contrainte de base sur faux (c’est-à-dire qu’elle n’est pas délivrée par l’autorité de certification)

Le MID Server identifie quand une mise à niveau JRE est sur le point d’avoir lieu et commence le processus de migration. Avant la migration, le MID Server crée une sauvegarde du TrustStore d’origine en cas de défaillance. En cas de défaillance, le TrustStore de sauvegarde peut être restauré manuellement.