Partager via

Résoudre les problèmes de découverte d’agent UNIX/Linux dans Operations Manager

  • Article

Cet article vous aide à résoudre les erreurs courantes qui peuvent se produire pendant le processus de découverte d’ordinateurs UNIX ou Linux.

Version d’origine du produit : System Center Operations Manager
Numéro de la base de connaissances d’origine : 4490426

Pour surveiller les ordinateurs UNIX ou Linux dans System Center Operations Manager (OpsMgr), les ordinateurs doivent d’abord être découverts et l’agent OpsMgr doit être installé. L’Assistant Ordinateur et Gestion des appareils permet de découvrir et d’installer des agents sur des ordinateurs UNIX et Linux. Toutefois, le processus de découverte peut échouer en raison de problèmes de configuration, d’informations d’identification ou de privilèges, ou de problèmes de réseau et de résolution de noms.

Erreurs de certificat ou erreurs de signature de certificat

Échec de l’opération de vérification du certificat signé

En cas d’échec de la vérification du certificat, vous recevez généralement une erreur qui ressemble à ce qui suit :

Échec de la vérification de l’agent. Détails de l’erreur : le certificat de serveur sur l’ordinateur de destination (lx1.contoso.com:1270) présente les erreurs suivantes :
Impossible de vérifier la révocation du certificat SSL. Le serveur utilisé pour case activée pour la révocation peut être inaccessible.
Le certificat SSL contient un nom commun (CN) qui ne correspond pas au nom d’hôte.
Il est possible que :

  1. Le certificat de destination est signé par une autre autorité de certification non approuvée par le serveur d’administration.
  2. La destination a un certificat non valide, par exemple, son nom commun (CN) ne correspond pas au nom de domaine complet (FQDN) utilisé pour la connexion. Le nom de domaine complet utilisé pour la connexion est : lx1.contoso.com.
  3. Les serveurs du pool de ressources n’ont pas été configurés pour approuver les certificats signés par d’autres serveurs du pool.

  • L’une des causes courantes est que la valeur de nom commun (CN) du certificat d’agent ne correspond pas au nom de domaine complet (FQDN) fourni ou résolu.

    Pour vérifier cela, vérifiez que le nom d’hôte et le nom de domaine de l’hôte de l’agent correspondent au nom de domaine complet résolu via DNS.

    Vous pouvez afficher les détails de base du certificat sur l’ordinateur UNIX ou Linux en exécutant la commande suivante :

    openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates

    Dans ce cas, vous verrez une sortie similaire à ce qui suit :

    subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
    issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
    notBefore=Mar 25 05 :21 :18 2008 GMT
    notAfter=Mar 20 05 :21 :18 2029 GMT

    Utilisez ces informations pour valider les noms d’hôtes et les dates, assurez-vous qu’ils correspondent au nom en cours de résolution par le serveur d’administration Operations Manager.

    Si les noms d’hôte ne correspondent pas, utilisez l’une des actions suivantes pour résoudre le problème :

    • Si le nom d’hôte UNIX ou Linux est correct, mais que le serveur d’administration Operations Manager le résout de manière incorrecte, modifiez l’entrée DNS pour qu’elle corresponde au nom de domaine complet correct ou ajoutez une entrée au fichier hosts sur le serveur Operations Manager.
    • Si le nom d’hôte UNIX ou Linux est incorrect, effectuez l’une des opérations suivantes :
      • Remplacez le nom d’hôte sur l’hôte UNIX ou Linux par le nom correct et créez un certificat.
      • Créez un certificat avec le nom d’hôte souhaité.

    Pour modifier le nom du certificat :

    Si le certificat a été créé avec un nom incorrect, vous pouvez modifier le nom d’hôte et recréer le certificat et la clé privée. Pour ce faire, exécutez la commande suivante sur l’ordinateur UNIX ou Linux :

    /opt/microsoft/scx/bin/tools/scxsslconfig -f -v

    L’option -f force le remplacement des fichiers dans /etc/opt/microsoft/scx/ssl.

    Vous pouvez également modifier le nom d’hôte et le nom de domaine sur le certificat à l’aide des -h commutateurs et -d , comme dans l’exemple suivant :

    /opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>

    Redémarrez l’agent en exécutant la commande suivante :

    /opt/microsoft/scx/bin/tools/scxadmin -restart

    Pour ajouter une entrée au fichier hosts :

    Si le nom de domaine complet n’est pas dans le DNS inverse, vous pouvez ajouter une entrée au fichier hosts situé sur le serveur d’administration pour fournir la résolution de noms. Le fichier hosts se trouve dans le \Windows\System32\Drivers\etc dossier . Une entrée dans le fichier hosts est une combinaison de l’adresse IP et du nom de domaine complet.

    Par exemple, pour ajouter une entrée pour l’hôte nommé newhostname.newdomain.name avec l’adresse IP 192.168.1.1, ajoutez ce qui suit à la fin du fichier hosts :

    192.168.1.1 newhostname.newdomain.name

  • Une autre cause courante de cette erreur est que le certificat a été signé par une autorité non approuvée, par exemple lorsque plusieurs serveurs d’administration sont membres du pool de ressources utilisé pour la découverte, mais que l’approbation de certificat n’a pas été configurée entre les serveurs d’administration.

    Pour vérifier cela, vérifiez que tous les serveurs d’administration du pool de ressources utilisé pour la découverte approuvent le certificat d’un autre serveur.

    Pour plus d’informations sur la gestion des pools de ressources pour les ordinateurs UNIX et Linux, consultez Gestion des pools de ressources pour les ordinateurs UNIX et Linux.

Le nom d’utilisateur ou le mot de passe est incorrect

L’erreur peut s’afficher lorsque vous essayez de découvrir des agents UNIX/Linux. L’échec peut se produire pendant l’étape de vérification du certificat lors de la découverte d’une machine UNIX/Linux.

Causes possibles

  • L’authentification de base est définie sur un ou plusieurs serveurs d’administration dans le pool de ressources UNIX/Linux lorsque l’agent UNIX/Linux n’est pas joint à false un domaine et ne peut pas utiliser l’authentification Kerberos. Vous pouvez vérifier les paramètres WinRM actuels en exécutant la commande suivante : winrm get winrm/config/client.
  • Le nom d’utilisateur ou le mot de passe est incorrect.

Solution

Vous pouvez mettre à jour la configuration WinRM sur les serveurs d’administration dans le pool de ressources UNIX/Linux pour autoriser l’authentification de base en exécutant la commande suivante, ou vous pouvez définir la configuration via stratégie de groupe :

winrm set winrm/config/client/auth @{Basic="true"}

Remarque

La commande ci-dessus définit une valeur de Registre DWORD (32 bits) (AllowBasic) dans la clé de Registre suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WinRM\Client

AllowBasic autorise les 1 valeurs décimales (Activé) ou 0 (Désactivé).

Échec de l’opération de signature de certificat

Causes possibles

  • Le compte d’utilisateur spécifié pour la découverte ne dispose pas des privilèges suffisants pour effectuer des opérations de fichier impliquées dans la signature.
  • Les privilèges d’élévation Sudo pour le compte d’utilisateur spécifié pour la découverte n’ont pas été correctement configurés.

Solution

Pour résoudre le problème, vérifiez le compte d’utilisateur en inspectant la sortie StdErr dans les détails de l’erreur afin d’identifier la cause de l’échec. Vérifiez également la configuration des privilèges sudo pour le compte utilisé pour la signature de certificat.

Erreurs de résolution de noms réseau

L’adresse cible n’est pas résolvable

Ces problèmes appartiennent généralement à l’une des catégories suivantes :

  • Description de l’erreur

    Échec de la résolution de l’adresse <IP adresse> IP en nom

    Cause

    Cette erreur se produit lorsqu’une adresse IP de l’hôte a été entrée pour la découverte, mais que l’adresse IP n’est pas résolvable en nom dans DNS (recherche inversée).

    Solution

    Pour résoudre ce problème, corrigez la configuration de la résolution de noms (DNS) pour la zone de recherche inversée, assurez-vous qu’il existe un mappage d’adresse IP à nom pour l’hôte affecté.

  • Description de l’erreur

    Échec de la résolution du nom server.contoso.com en adresse IP

    Cause

    Cette erreur se produit si un nom de domaine complet pour l’hôte a été entré pour la découverte, mais que le nom n’est pas résolvable en adresse IP dans DNS (recherche directe).

    Solution

    Pour résoudre ce problème, corrigez la configuration de la résolution de noms (DNS) pour la recherche directe, assurez-vous qu’un mappage de nom d’hôte à adresse IP existe pour l’hôte.

Configuration DNS : la résolution DNS de transfert ne correspond pas à la résolution DNS inversée

Description de l’erreur

Dans ce cas, vous recevez généralement une erreur qui ressemble à ce qui suit :

Nom d’hôte serverName fourni résolu en adresse IP 10.137.216.x. Le nom d’hôte ServerName.contoso.com retourné par recherche inversée de l’adresse IP 192.168.x.x ne correspondait pas au nom d’hôte fourni. Vérifiez la configuration DNS et réessayez la requête.

Cause

La cause la plus courante est que les enregistrements de l’hôte dans les zones de recherche DNS directe et inversée ne correspondent pas.

Solution

Pour résoudre ce problème, corrigez les enregistrements dans les zones de recherche directe et inversée dans DNS afin que les noms d’hôte et l’adresse IP correspondent.

L’adresse cible est inaccessible

Description de l’erreur

Dans ce cas, vous recevez généralement une erreur qui ressemble à ce qui suit :

Le client WinRM ne peut pas terminer l’opération dans le délai spécifié. Vérifiez si le nom de l’ordinateur est valide et accessible sur le réseau et que l’exception de pare-feu pour le service gestion à distance Windows est activée.

Causes possibles

  • L’hôte est inaccessible en raison d’une résolution de noms incorrecte, d’une panne réseau ou d’une panne de l’hôte.
  • Un pare-feu réseau ou basé sur l’hôte bloque la connectivité du port TCP 1270 à l’hôte cible.

Solution

Pour résoudre ce problème, vérifiez que le serveur d’administration peut effectuer un test ping sur l’hôte de l’agent à l’aide de son nom de domaine complet. Vérifiez également qu’aucun pare-feu réseau ou pare-feu hôte ne bloque le port TCP 1270.

Type discoveryResult.ErrorData inattendu. Fichier du rapport de bogue - Nom du paramètre : s

Description de l’erreur

Type DiscoveryResult.ErrorData inattendu. Veuillez créer un rapport de bogue.
ErrorData : System.ArgumentNullException
La valeur ne peut pas être nulle.
Nom du paramètre : s
sur System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
sur System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
sur Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Cause

Cette erreur se produit parce que les paramètres du proxy WinHTTP ont été configurés sur les serveurs d’administration dans le pool de ressources UNIX ou Linux, et que le nom de domaine complet de l’agent UNIX ou Linux que vous essayez de découvrir n’est pas inclus dans la liste de contournement du proxy WinHTTP.

Solution

Pour résoudre ce problème, ajoutez le nom de domaine complet UNIX ou Linux à la liste de contournement du proxy WinHTTP.

Sur les serveurs d’administration dans le pool de ressources UNIX ou Linux, exécutez la commande suivante à une invite de commandes avec élévation de privilèges pour vérifier la configuration actuelle du proxy :

netsh winhttp show proxy

Si un serveur proxy WinHTTP est configuré, ajoutez le nom de domaine complet du serveur que vous essayez de découvrir à la liste de contournement en exécutant la commande suivante :

netsh winhttp set proxy proxy-server="<proxyserver:port>" bypass-list="*.ourdomain.com;*.yourdomain.com*;<serverFQDN>"

Une fois la liste de contournement configurée, case activée si la découverte de l’agent réussit.

Remarque

Vous pouvez exécuter la netsh winhttp reset proxy commande pour désactiver le proxy WinHTTP. Cette commande supprime le serveur proxy et configure l’accès direct.

Type discoveryResult.ErrorData inattendu. Fichier du rapport de bogue - Nom du paramètre : lhs

Description de l’erreur

La découverte échoue
Message : Échec non spécifié
Détails : type DiscoveryResult.ErrorData inattendu. Veuillez créer un rapport de bogue.
ErrorData : System.ArgumentNullException
La valeur ne peut pas être nulle.
Nom du paramètre : lhs
sur System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
sur System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
sur Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Cause

Cette erreur se produit en raison des fichiers de l’interpréteur de commandes omsagent dans le dossier des kits installé.

Solution

Accédez au répertoire suivant dans Explorateur de fichiers :

C :\Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits

Si des fichiers omsagent sont répertoriés, déplacez-les vers un répertoire temporaire en dehors des fichiers SCOM (System Center Operations Manager).

Pour obtenir un exemple, consultez la capture d’écran suivante :

Capture d’écran montrant les fichiers omsagent dans le dossier DownloadedKits.

Une fois qu’ils ont été déplacés à partir du dossier DownloadedKits , réessayez la découverte. La découverte doit maintenant réussir.

Remarque

La découverte peut échouer avec une autre erreur. L’erreur indique qu’un dépannage supplémentaire est nécessaire, comme les sudoers, la connectivité, etc.

Erreurs de connectivité SSH

Échec lors de la découverte SSH. Code de sortie : -1073479162

Description de l’erreur

Sortie standard :
Erreur standard :
Message d’exception : une exception (-1073479162) a provoqué l’échec de la commande SSH . Aucune connexion n’a pu être établie, car l’ordinateur cible l’a activement refusée.

Causes possibles

  • Le démon SSH n’est pas en cours d’exécution sur le système cible.
  • Un pare-feu réseau ou basé sur un hôte empêche les connexions SSH sur le port TCP 22.

Résolutions

  • Vérifiez que le démon SSH est en cours d’exécution.
  • Vérifiez qu’aucun pare-feu réseau ou pare-feu hôte ne bloque le port TCP 22.

Échec lors de la découverte SSH. Code de sortie : -1073479118

Description de l’erreur

Échec lors de la découverte SSH. Code de sortie : -1073479118
Sortie standard :
Erreur standard :
Message d’exception : une exception (-1073479118) a provoqué l’échec de la commande SSH - Message de déconnexion envoyé par le serveur : type 2 (erreur de protocole : Échecs d’authentification trop nombreux pour la racine)

Causes possibles

  • Le compte d’utilisateur spécifié pour la découverte n’est pas autorisé à se connecter via SSH.
  • Le compte d’utilisateur spécifié pour la découverte a été entré avec un nom d’utilisateur ou un mot de passe non valide

Résolutions

  • Vérifiez que l’utilisateur est autorisé à se connecter via SSH.
  • Vérifiez les informations d’identification d’entrée et que l’utilisateur est défini sur l’hôte cible.

Échec lors de la découverte SSH. Code de sortie : 1

Description de l’erreur

Échec lors de la découverte SSH. Code de sortie : 1
Sortie standard : Chemin Sudo : /usr/bin/
Erreur standard : sudo : désolé, vous devez avoir un tty pour exécuter sudo
Message d’exception :

Cause

L’élévation Sudo a été sélectionnée dans l’entrée des informations d’identification de l’utilisateur, mais l’option requiretty n’a pas été désactivée pour l’utilisateur dans sudoers.

Solution

Modifiez le fichier sudoers sur l’hôte cible à l’aide de la visudo commande et ajoutez la ligne suivante :

Valeurs par défaut : <username> !requiretty

Pour plus d’informations, consultez Guide pratique pour configurer l’élévation sudo et les clés SSH.

Mot de passe su non valide

Description de l’erreur

. [ ?1034hopsuser@lx1 :~> su - root -c 'sh /tmp/scx-opsuser/GetOSVersion.sh ; EC=$ ?; rm -rf /tmp/scx-opsuser ; quitter $EC'
Mot de passe:
Sortie
su : mot de passe incorrect
opsuser@lx1 :~> quitter
Déconnexion

Cause possible

L’élévation su a été sélectionnée dans l’entrée des informations d’identification de l’utilisateur, mais un mot de passe racine non valide a été fourni pour l’élévation su.

Solution

Vérifiez l’entrée de mot de passe pour la racine dans la boîte de dialogue Configuration de l’élévation.

Échec lors de la découverte SSH. Code de sortie : -2147221248

  • Description de l’erreur

    Échec lors de la découverte SSH. Code de sortie : -2147221248
    Sortie standard :
    Erreur standard : Impossible de chdir dans le répertoire de base /home/username : aucun fichier ou répertoire de ce type

    Cause

    Le compte d’utilisateur spécifié pour la découverte n’a pas de répertoire de base.

    Solution

    Vérifiez que l’utilisateur dispose d’un répertoire de base à l’adresse : /home/ et que l’utilisateur est en mesure d’écrire dans ce répertoire.

  • Description de l’erreur

    Échec lors de la découverte SSH. Code de sortie : -2147221248
    Sortie standard :
    Erreur standard : mot de passe de la racine :
    Message d’exception : L’opération a expiré

    Cause

    L’élévation Sudo a été sélectionnée dans l’entrée des informations d’identification de l’utilisateur. Toutefois, le compte d’utilisateur spécifié pour la découverte n’est pas correctement configuré pour utiliser l’élévation sudo sans mot de passe, ou les privilèges d’élévation sudo requis n’ont pas été accordés pour le compte d’utilisateur utilisé dans la découverte.

    Solution

    Consultez la documentation sur la configuration de l’élévation sudo et vérifiez la configuration utilisateur pour sudo. Notez que sudo sans mot de passe doit être configuré.

Erreurs de connectivité WSMan

L’agent a répondu à la demande, mais la connexion WSMan a échoué en raison de : Accès refusé

Causes possibles

  • L’agent est installé et le certificat de l’agent a été signé. Toutefois, les informations d’identification de l’utilisateur fournies pour la vérification de l’agent ne sont pas valides.
  • Le compte d’utilisateur spécifié pour la découverte a été configuré pour s’authentifier avec une clé SSH, mais les informations d’identification de l’utilisateur fournies pour la vérification de l’agent ne sont pas valides.
  • Il existe un problème d’autorisation ou une configuration PAM incorrecte côté UNIX.

Solution

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez que le nom d’utilisateur et le mot de passe pour la vérification de l’agent ont été entrés correctement et que l’utilisateur est un utilisateur valide sur l’hôte cible.

  2. Si le problème persiste, vérifiez que l’élévation sudo a été configurée correctement.

  3. Case activée également le journal des messages sur l’ordinateur UNIX/Linux. Par exemple, dans AIX, vous pouvez trouver le journal sous /var/adm/messages. Dans d’autres systèmes d’exploitation, l’emplacement peut varier.

    Recherchez des lignes telles que les suivantes :

    3 sep 14 :49 :07 server auth|security :debug /opt/microsoft/scx/bin/omiserver PAM : pam_authenticate : erreur Échec de l’authentification.

    Si vous voyez des lignes similaires dans le journal des messages, cela signifie que le fichier de configuration PAM ne contient pas d’informations sur OMIServer. Le fichier de configuration PAM se trouve dans le /etc/pam.d/ répertoire ou le /etc/pam.conf fichier .

    Le moyen le plus simple d’ajouter les informations sur OMIServer au fichier de configuration PAM consiste à réinstaller l’agent SCX à partir de zéro sur cet ordinateur. Si cela n’est pas facilement possible, vous pouvez copier les lignes relatives à OMI d’un ordinateur de travail vers l’ordinateur non opérationnel.

Échec de la découverte WSMan uniquement pour 192.168.x.x

Causes possibles

  • L’option Type de découverte a été définie sur Uniquement les ordinateurs avec un agent installé et un certificat signé , et l’agent est installé sur l’hôte cible. Toutefois, le certificat d’hôte cible n’a pas été signé. Pour utiliser l’option de découverte WSMan uniquement, l’agent doit être installé et le certificat doit être signé manuellement.
  • L’option Type de découverte a été définie sur Uniquement les ordinateurs avec un agent installé et un certificat signé, mais l’hôte cible n’a pas l’agent UNIX/Linux actuellement installé.
  • L’option Type de découverte a été définie sur Uniquement les ordinateurs avec un agent installé et un certificat signé, mais l’agent UNIX/Linux n’est pas en cours d’exécution.
  • L’option Type de découverte a été définie sur Uniquement les ordinateurs avec un agent installé et un certificat signé, mais l’hôte cible est inaccessible, un réseau ou un pare-feu basé sur l’hôte empêche la connectivité ou l’agent UNIX/Linux est actuellement arrêté.

Résolutions

  • Signez manuellement le certificat.
  • Vérifiez que l’agent UNIX/Linux a été installé.
  • Remplacez l’option par Découvrir tous les ordinateurs pour permettre à l’Assistant Découverte d’effectuer la signature du certificat.
  • Vérifiez que l’agent UNIX/Linux est en cours d’exécution et que l’hôte cible est accessible.
  • Vérifiez qu’aucun pare-feu réseau ou pare-feu hôte n’empêche l’accès sur le port TCP 1270.

Autres erreurs

La tâche ne peut pas être exécutée sur le ou les objets, car la cible de la tâche ne correspond à aucune des classes de l’objet

Cause

Dans un groupe d’administration System Center 2012 Operations Manager, cela peut se produire si les packs d’administration UNIX/Linux importés sont des versions d’Operations Manager 2007 R2.

Solution

Importez les versions System Center 2012 des packs d’administration du système d’exploitation UNIX/Linux.

L’agent est installé et l’ordinateur est déjà surveillé par Operations Manager

Cause

L’hôte cible a déjà été découvert dans ce groupe d’administration.

Solution

Aucune action n’est requise. La mise à niveau ou la migration de l’agent vers un autre pool de ressources peut être effectuée à partir de la vue Serveurs UNIX/Linux dans le volet Administration de la console Opérateur.

Impossible de trouver une instance d’agent prise en charge correspondante dans les packs d’administration importés

Description de l’erreur

Impossible de trouver un agent pris en charge correspondant instance dans les packs d’administration importés. Importez le ou les packs d’administration pour cette plateforme afin de découvrir cet ordinateur.

Causes possibles

  • L’hôte cible exécute un système d’exploitation non pris en charge.
  • Le pack d’administration approprié pour le système d’exploitation de l’hôte cible n’a pas été importé.
  • Le pack d’administration approprié pour le système d’exploitation a récemment été importé, mais n’a pas encore été entièrement chargé.

Résolutions

  • Vérifiez que l’hôte cible exécute un système d’exploitation pris en charge.
  • Importez le pack d’administration pour le système d’exploitation et la version de l’hôte cible.
  • Si le pack d’administration a été importé, il est possible qu’il soit toujours en cours de chargement. Patientez quelques minutes et réexécutez la découverte.

Impossible d’énumérer les types d’agents installables. Le pool de ressources associé est peut-être encore en cours d’initialisation

Description de l’erreur

Impossible d’énumérer les types d’agents installables. Le pool de ressources associé est peut-être encore en cours d’initialisation. Si vous avez sélectionné un pool de ressources nouvellement créé, patientez quelques minutes avant de l’utiliser.

Causes possibles

  • Le pool de ressources utilisé dans la découverte n’est pas sain, par exemple, la majorité des serveurs membres sont hors connexion.
  • Le pool de ressources utilisé dans la découverte a été créé récemment, mais il n’a pas été entièrement initialisé.

Solution

Si le pool de ressources utilisé dans la découverte a été créé récemment, recommencez la découverte après plusieurs minutes pour permettre l’initialisation du pool. Sinon, case activée le journal des événements Operations Manager sur les serveurs membres du pool de ressources utilisé pour la découverte pour obtenir des indications sur la source du problème.

Impossible de copier le nouvel agent sur cet ordinateur

Description de l’erreur

Message : Impossible de copier le nouvel agent sur cet ordinateur
Détails:
Échec de la copie du kit. Code de sortie : -1073479144
Sortie standard :
Erreur standard :
Message d’exception : une exception (-1073479144) a provoqué l’échec de la commande SSH

Cause

Incompatibilité des versions de l’agent de fichier entre la base de données et le référentiel de l’agent.

Résolutions

  • Vérifiez que les agents ayant échoué échouent tous en raison d’une incompatibilité de version. Sinon, appliquez d’autres étapes de résolution des problèmes.
  • Réessayez de mettre à jour les agents ayant échoué. En règle générale, la liste des agents ayant échoué est de plus en plus courte à chaque itération de mise à jour.
  • Redémarrez le service d’intégrité sur tous les membres de votre pool de ressources Linux ou d’un autre pool pour la gestion des machines Unix ou Linux. Vérifiez si les noms de fichiers sont corrects dans le %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits dossier. N’oubliez pas de fermer et de rouvrir l’Assistant Découverte.

Plus d’informations

Pour obtenir de l’aide, consultez notre forum de support TechNet ou contactez Support Microsoft.