2.3 Dépannage

En cas d'échec de la mise à niveau du serveur ZENworks, vous devez résoudre le problème et réexécuter le programme d'installation de la mise à niveau ZENworks.

  • Vous devez réexécuter le programme d'installation de la mise à niveau sur le serveur sur lequel la mise à niveau a été démarrée.

  • Si la mise à niveau échoue pendant l'opération de mise à niveau de la base de données postérieure au paquetage, lors de la réexécution et après authentification de la zone, la page Résumé préalable à la mise à niveau s'ouvre et la mise à niveau se charge d'effectuer les opérations de la base de données.

  • Si une base de données PostgreSQL intégrée est utilisée, assurez-vous que les fichiers .dbR et .logR ont été supprimés du dossier de la base de données avant de réexécuter le programme d'installation de la mise à niveau.

Les sections suivantes fournissent des solutions aux problèmes susceptibles de survenir pendant la mise à niveau du serveur primaire ZENworks :

La mise à niveau de ZENworks échoue en raison de l'échec de la mise à niveau du moteur PostgreSQL

Explication : Lors de la mise à niveau de ZENworks, l'opération échoue si la mise à niveau du moteur PostgreSQL a échoué. Cela peut être dû au fait que le service PostgreSQL était dans un état incohérent avant le lancement de la mise à niveau.
Opération : Si l'exception La création du service de base de données (dbsvc) a échoué avec le code de retour : 2 est consignée dans le journal de la mise à niveau, ouvrez le fichier zen20u2_upgrade_status présent à l'emplacement /etc/opt/novell/zenworks sous Linux et %ZENWORKS_HOME%\conf sous Windows et supprimez la ligne POSTGRES_ENGINE_UPGRADE = stop service du fichier. Démarrez le service de base de données intégrée, puis relancez la mise à niveau.

La solution ne doit être appliquée qu'en cas d'échec de l'arrêt du service. Cette solution n'est pas recommandée en cas d'échec à d'autres étapes.

La mise à niveau se termine avec une erreur sur un serveur primaire Linux

Explication : Une explication du message.
Cause possible : Lorsque vous mettez à niveau un serveur primaire Linux, l'opération peut se terminer avec une erreur. Cependant, il peut s'agir d'une fausse alerte et la mise à niveau peut être réussie.
Dépannage : Ouvrez le journal de mise à niveau et vérifiez si l'instruction suivante est consignée :

« ![CDATA[Docker service check failed: Format specifier '%s']]. Severity is CDATA[8]]” ([CDATA[Échec de la vérification du service Docker : spécificateur de format '% s']] La gravité est CDATA[8]]).

Recherchez le nombre d'instances de «![CDATA [8]] » dans le journal de mise à niveau. S'il n'existe qu'une seule instance, avec l'instruction ci-dessus, la mise à niveau a réussi. Vérifiez la même chose en vous connectant à ZCC.

La mise à jour système de renouvellement n'est pas établie comme référence lorsqu'elle est appliquée à un périphérique comportant les deux agents ZENworks et MDM

Source : ZENworks 
Explication : Lorsque vous lancez le processus de renouvellement sur un périphérique comportant les deux agents ZENworks et MDM, le certificat est appliqué avec succès sur l'agent ZENworks et l'état de ce dernier affiche Terminé, mais l'état de l'agent MDM indique Activation du certificat en attente et garde cette valeur même si l'enregistrement de MDM est annulé à l'aide de la tâche rapide Annuler l'enregistrement du périphérique MDM. Par conséquent, la mise à jour de renouvellement n'est pas établie comme référence même une fois l'heure d'activation atteinte.
Opération : Pour établir la mise à jour comme référence, ignorez la mise à jour système de renouvellement sur le périphérique.

La mise à niveau vers ZENworks 2020 échoue sur le serveur Windows primaire

Explication : Lors de la mise à niveau du serveur Windows primaire vers ZENworks 2020, la mise à niveau échoue.
Opération : Procédez comme suit :
  1. Si la mise à niveau du serveur a déjà échoué, exécutez la commande suivante en tant que superutilisateur :

    icacls "%zenworks_home%\cache" /remove:d Users

  2. Après avoir exécuté la commande, réessayez la mise à niveau à l'aide de ZENworks 2020 Media Upgrade (ISO).

Le périphérique MDM affiche un état incohérent après la mise à niveau vers ZENworks 2020 Update 2

Source : ZENworks 
Explication : Lorsque vous appliquez ZENworks 2020 Update 2 sur un périphérique MDM qui a été enregistré dans ZENworks 2020 ou 2020 Update 1 (MDM uniquement), l'état du périphérique Mise à jour système affiche Mise à jour non applicable.
Opération : Aucune

Après avoir mis à jour tous les périphériques de la zone, vous pouvez ignorer les périphériques MDM pour établir la mise à jour comme référence.

Échec de la mise à jour système en raison d'une erreur de redémarrage en attente

Source : ZENworks 
Explication : Lors du déploiement de la mise à jour système, le système redémarre plusieurs fois. Même après l'arrêt du système, la mise à jour système reste un échec et affiche l'erreur de redémarrage en attente.
Opération : Il est recommandé de redémarrer ou de relancer le périphérique après l'avoir mis à jour. Sur les périphériques Windows les plus récents, en raison du mode Démarrage rapide, l'arrêt et le démarrage ne sont pas considérés comme un redémarrage du périphérique. Par conséquent, vous devez redémarrer ou relancer le périphérique, ou désactiver le mode Démarrage rapide.

Échec de la mise à jour système IOA sur les périphériques SLED 15 SP1

Source : ZENworks 
Explication : Lorsque vous déployez une mise à jour système IOA sur des périphériques SLED 15 à l'aide de la commande « zac su », la mise à jour système peut échouer. Cela peut être dû au fait que le paquetage « at » n'est peut-être pas installé par défaut sur les périphériques SLED 15.

Pour vérifier cela, les utilisateurs ou les administrateurs IOA peuvent consulter le fichier zmd-messages.log et rechercher l'erreur « Cannot run program "at": error=2, No such file or directory » (Impossible d'exécuter le programme "at" : erreur=2, aucun fichier ou répertoire de ce type).

Opération : Si le paquetage « at » n'est pas installé sur le périphérique IOA, installez la commande « at » à l'aide de la commande zypper ou d'autres outils. Après avoir installé la commande « at », réexécutez la commande zac su.

Si la commande zypper ne parvient pas à identifier le paquetage « a t», les fichiers RPM suivants peuvent être installés :

Les fichiers RPM peuvent être téléchargés à partir du site https://rpmfind.net/linux/rpm2html/search.php.

  1. Recherchez « libHX28 » et téléchargez le fichier RPM applicable à votre plate-forme OS.

    Exemple : libHX28-3.22-lp150.1.7.x86_64.rpm

  2. Recherchez « libfl2 » et téléchargez le fichier RPM applicable à votre plate-forme OS.

    Exemple : libfl2-2.6.4-lp150.2.48.x86_64.rpm

  3. Recherchez « at » et téléchargez le fichier RPM applicable à votre plate-forme OS.

    Exemple : at-3.1.20-lp150.2.27.x86_64.rpm

Pendant la mise à niveau d'un serveur primaire Windows, l'explorateur Windows redémarre à plusieurs reprises

Explication : Pendant la mise à niveau d'un serveur primaire Windows, l'explorateur Windows redémarre à plusieurs reprises et la fenêtre d'invite de commande s'ouvre automatiquement avec le message suivant :
For each prompt presented, press 'enter' to accept the <default> value, type 'back' to return to the previous action, or type 'quit' to exit.
Opération : Vous pouvez ignorer ces messages.

Si la base de données exécute des transactions lors du lancement de la mise à niveau ZENworks, un conflit risque de se produire.

Source : ZENworks ; mise à niveau
Explication : Si la base de données exécute des transactions lors du lancement de la mise à niveau de ZENworks, un conflit risque de se produire.
Opération : Mettez fin à la session de base de données qui entre en conflit avec le processus de mise à niveau. Pour mettre fin à une session de base de données, procédez comme suit :
  1. Connectez-vous à la base de données en tant qu'utilisateur système et lancez le client SQL.

  2. Exécutez l'un des scripts ci-dessous en fonction du type de base de données :

    • Oracle :

      select 'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||''';' AS "Drop Query",b.sql_text,a.* from gv$session a, gv$sql b where (case when a.sql_id is null then a.prev_sql_id else a.sql_id end)=b.sql_id and a.program='JDBC Thin Client' and a.logon_time< (sysdate-3/60/24) and a.username='<<UTILISATEUR_ZENWORKS>>';

      Où :

      UTILISATEUR_ZENWORKS est le nom de l'utilisateur de la base de données ZENworks.

    • MS SQL :

      select 'KILL '+cast(spid as varchar(100)) as "Drop Query", r.text,s.* from sys.sysprocesses s cross apply sys.dm_exec_sql_text (sql_handle) r where s.program_name='jTDS' and s.spid!=@@spid and s.login_time < dateadd(minute,-3,getdate()) and s.loginame='<<UTILISATEUR_ZENWORKS>>';

      Où :

      UTILISATEUR_ZENWORKS est le nom de l'utilisateur de la base de données ZENworks.

    • SQL Anywhere :

      SELECT 'Drop connection '+cast(sa_conn_info.Number as varchar(100))+';' as "Drop Query", sa_conn_info.Number AS connection_number, DB_NAME( DBNumber ) AS database_name, sa_conn_info.name AS connection_name, sa_conn_info.userid, CONNECTION_PROPERTY( 'LoginTime', Number ) as "Login Time", CONNECTION_PROPERTY( 'LastStatement', Number ) As "Query" FROM sa_conn_info() where sa_conn_info.Number != @@spid and CONNECTION_PROPERTY( 'LoginTime', Number ) < dateadd(minute,-3,getdate()) and userid='<<UTILISATEUR_ZENWORKS>>';

      UTILISATEUR_ZENWORKS est le nom de l'utilisateur de la base de données ZENworks.

Si vous utilisez une base de données Oracle pendant la création ou la mise à niveau de la base de données, le message d'erreur TNS s'affiche

Source : ZENworks ; mise à niveau
Explication : Si vous utilisez une base de données Oracle pendant la création ou la mise à niveau de la base de données, vous obtenez le message d'erreur suivant : TNS:listener could not find available handler with matching protocol stack (Le module d'écoute TNS n'a pas pu trouver de gestionnaire disponible doté d'une pile de protocoles correspondante).
Opération : Augmentez la charge maximale pour les connexions dédiées. Celle-ci est déterminée par le paramètre PROCESSES. Si ce problème persiste, contactez le support client Micro Focus.

Si vous utilisez une base de données MS-SQL pendant la création ou la mise à niveau de la base de données, cela occasionne des problèmes de connexion

Source : ZENworks ; mise à niveau
Explication : Si vous utilisez une base de données MS-SQL pendant la création ou la mise à niveau de la base de données, cela entraîne des problèmes de connexion et le message d'erreur suivant s'affiche :
org.hibernate.exception.JDBCConnectionException: Cannot open connection
Caused by: java.sql.SQLException: I/O Error: Connection reset
Caused by: java.net.SocketException: Connection reset
Opération : Exécutez select * from sys.configurations where name='user connections'

Par défaut, la connexion maximale est 32 767. Vous pouvez adapter cette valeur en définissant un nombre de serveurs primaires * 200. Pour plus d'informations sur la configuration des connexions utilisateur, reportez-vous à l'article http://technet.microsoft.com/fr-fr/library/ms187030.aspx.

Vérifiez si le serveur MS-SQL ne sollicite pas trop l'UC et que la charge du serveur de base de données n'est pas trop élevée. Contactez le support client Micro Focus pour obtenir une assistance.

Valeurs incorrectes affichées pour les enregistrements d'inventaire à nettoyer

Source : ZENworks ; mise à niveau
Explication : Lorsque vous choisissez l'option de nettoyage dans l'assistant de mise à niveau, le nombre d'enregistrements spécifiés pour la suppression est affiché sur la page de résumé de pré-nettoyage.

Par exemple, si vous avez marqué 8 000 000 enregistrements à nettoyer sur un total de 10 000 000, alors 8 000 000 sur 10 000 000 sont affichés dans le champ Nombre d'enregistrements à purger.

Une fois le nettoyage réussi, lorsque vous redémarrez l'assistant de mise à niveau pour le nettoyage, la page Nettoyage de la base de données affiche une valeur incorrecte dans le champ Nombre total d'enregistrements marqués en vue d'être purgés.

Par exemple, si 8 000 000 enregistrements d'inventaire ont été supprimés sur un total de 10 000 000, la valeur idéale à afficher dans le champ Nombre total d'enregistrements marqués en vue d'être purgés est 200 000 000.

Pour le moment, la valeur affichée est incorrecte. Par conséquent, les valeurs affichées pour les enregistrements d'inventaire supprimés et les enregistrements d'inventaire à supprimer ne correspondent pas.

Opération : Il n'existe aucune solution pour contourner ce problème.

Une erreur se produit lorsque vous supprimez un dossier dont le nom est trop long

Source : ZENworks ; mise à niveau
Explication : Dans une zone ZENworks qui utilise une base de données SQL Server, lorsque vous tentez de supprimer un objet ZENworks (un périphérique ou un dossier, par exemple) dont la longueur du nom est supérieure à 900 octets, le message d'erreur suivant s'affiche :

com.novell.zenworks.datamodel.exceptions.InternalDataModelException: org.hibernate.exception.GenericJDBCException: Operation failed. The index entry of length 912 bytes for the index 'idx_zZENObject_Name' exceeds the maximum length of 900 bytes (L'entrée d'index d'une longueur de 912 octets de l'index 'idx_zZENObject_Name' dépasse la longueur maximale de 900 octets).

Opération : Assurez-vous que la longueur des noms d'objet ZENworks de la zone ne dépasse pas 900 octets. Pour plus d'informations, consultez l'article https://technet.microsoft.com/fr-fr/library/ms191241%28v=sql.105%29.aspx.

Échec de la mise à niveau du schéma ZENworks en raison d'une incompatibilité d'assemblage dans la base de données MS SQL

Source : ZENworks ; mise à niveau
Explication : La mise à niveau du schéma ZENworks échoue si les assemblages du serveur MS SQL et de la base de données d'audit sont incompatibles.
Opération : Exécutez les requêtes SQL suivantes sur les deux bases de données (ZENworks et d'audit) pour vérifier la compatibilité des assemblages des bases de données :
  • Requête SQL pour obtenir les assemblages des bases de données :

    SELECT collation_name FROM sys.databases WHERE name = db_name();

  • Requête SQL pour obtenir les assemblages des colonnes de base de données :

    select distinct collation_name from information_schema.columns where collation_name is not null;

Partagez les journaux de mise à niveau et le résultat des requêtes avec le support client Micro Focus pour une analyse plus approfondie.

Le fichier journal XML de mise à niveau ne s'affiche pas correctement dans Google Chrome et Firefox

Source : ZENworks ; mise à niveau
Explication : Lorsque vous essayez d'afficher le fichier journal XML de mise à niveau dans Google Chrome et Firefox, il ne s'affiche pas correctement.
Opération : Pour afficher le fichier journal dans un navigateur, exécutez l'opération de configuration suivante :

microfocus-zenworks-configure -c

ConvertLogToHTMLConfigureAction -DlogFile=<chemin_fichier_journal>

L'opération de configuration convertit le fichier journal XML au format HTML et l'ouvre dans un navigateur Web.

Vous pouvez également afficher le fichier journal à l'aide de n'importe quel éditeur de texte.

Sur un serveur primaire Linux, les services Novell hérités sont répertoriés dans l'opération de démarrage de la configuration

Source : ZENworks ; mise à niveau
Explication : Après la mise à niveau vers ZENworks 2020 Update 2 sur un serveur Linux primaire, lorsque vous exécutez la commande suivante :

novell-zenworks-configure -c Start

Les services Novell hérités sont répertoriés au lieu des nouveaux services Micro Focus. Si vous essayez de démarrer, d'arrêter ou de redémarrer des services, une erreur d'exception s'affiche.

Opération : Déconnectez-vous du serveur Linux, puis reconnectez-vous. Ouvrez une nouvelle fenêtre de terminal et exécutez la commande suivante :

novell-zenworks-configure -c Start

Les nouveaux services Micro Focus sont désormais répertoriés. Vous pouvez démarrer, arrêter ou redémarrer les services.

La mise à niveau du serveur ZENworks primaire échoue avec l'erreur « Zulu Platform x64 Architecture has stopped working »

Source : ZENworks ; mise à niveau
Explication : Lors de la mise à niveau du serveur Windows primaire ZENworks 2020 ou Update 1 vers 2020 Update 2, la mise à niveau échoue avec l'erreur suivante :

Zulu Platform x64 Architecture has stopped working (Zulu Platform x64 Architecture a cessé de fonctionner)

Cause possible : L'erreur se produit en raison du paramètre DEP (Data Execution Prevention, Prévention de l'exécution des données) qui est en conflit avec le programme.
Opération : Vérifiez le paramètre DEP sur le serveur en accédant à Panneau de configuration > Système > Paramètres système avancés. Dans la fenêtre Propriétés système, cliquez sur Avancé, sous Performances, cliquez sur Paramètres. Dans la fenêtre Options de performances, cliquez sur Prévention de l'exécution des données.

Notez le paramètre actuel. Sélectionnez l'option Activer la prévention d'exécution des données pour les programmes et les services Windows uniquement si elle n'est pas cochée. Redémarrez le serveur Windows et réessayez de mettre à niveau le serveur ZENworks primaire. Si l'erreur persiste, contactez le support Micro Focus.

Important : si le paramètre a été modifié avant la mise à niveau, rétablissez la valeur et redémarrez le serveur Windows.