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

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

Version du produit d’origine : System Center Operations Manager
Numéro de 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 est utilisé pour découvrir et installer des agents sur des ordinateurs UNIX et Linux. Toutefois, le processus de découverte peut échouer en raison de problèmes de configuration, de problèmes d'identifiants 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

L’opération de vérification de certificat signée n’a pas réussi

En cas d’échec de la vérification du certificat, vous recevez généralement une erreur semblable à 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 :
Le certificat SSL n’a pas pu être vérifié pour la révocation. Le serveur utilisé pour vérifier 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 du certificat de l’agent ne correspond pas au nom de domaine complet fourni ou résolu.

  Pour vérifier cela, vérifiez que le nom d’hôte de l’agent et le nom de domaine 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
  

  Lorsque vous effectuez cette opération, 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ôte et les dates, assurez-vous qu’elles correspondent au nom résolu 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 correctement, 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 bon 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 les fichiers dans /etc/opt/microsoft/scx/ssl à remplacer.

  Vous pouvez également modifier le nom d’hôte et le nom de domaine sur le certificat à l’aide des -h commutateurs et -d des commutateurs, 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 DNS inverse, vous pouvez ajouter une entrée au fichier d'hôte qui se trouve sur le serveur d'administration pour fournir la résolution de nom. 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 (FQDN).

  Par exemple, pour ajouter une entrée pour l’hôte nommé newhostname.newdomain.name avec une adresse IP de 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és pour la découverte approuvent le certificat du 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

Vous pouvez voir l’erreur lors de la tentative de découverte d’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 false sur un ou plusieurs serveurs d’administration dans le pool de ressources UNIX/Linux lorsque l’agent UNIX/Linux n’est pas joint à 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 mot de passe est incorrect.

Solution

Vous pouvez mettre à jour la configuration WinRM sur les serveurs d’administration du 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 la stratégie de groupe :

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

L'opération de signature du certificat a échoué

Causes possibles

• Le compte d’utilisateur spécifié pour la découverte dispose de privilèges insuffisants 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 pour 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 nom 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

  Impossible de résoudre l’adresse IP de l’adresse <> IP en nom

  Cause

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

  Solution

  Pour résoudre ce problème, corrigez la configuration DNS pour la zone de recherche inverse, vérifiez qu’une adresse IP à mappage de noms existe pour l’hôte concerné.

• Description de l’erreur

  Échec de la résolution du nom server.contoso.com à l’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 à l’adresse IP dans DNS (recherche vers l’avant).

  Solution

  Pour résoudre ce problème, corrigez la configuration DNS pour la recherche vers l’avant, vérifiez qu’un nom d’hôte au mappage d’adresses IP existe pour l’hôte.

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

Description de l’erreur

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

Nom d’hôte fourni résolu en adresse IP 10.137.216.x. Le nom d’hôte ServerName.contoso.com retourné par la recherche inverse de l’adresse IP 192.168.x.x ne correspond 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 vers l’avant et inverse ne correspondent pas.

Solution

Pour résoudre ce problème, corrigez les enregistrements dans les zones de recherche vers l’avant et inverse 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 semblable à 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 via le réseau et que l’exception de pare-feu pour le service Windows Remote Management 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 d’hôte.
• Un pare-feu basé sur un réseau ou un 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. Rapport de bogue de fichier - Nom du paramètre : s

Description de l’erreur

Type DiscoveryResult.ErrorData inattendu. Veuillez créer un rapport de bogue.
ErrorData : System.ArgumentNullException
Value cannot be null.
Nom de paramètre : s
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
sur Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, Critères DiscoveryTargetEndpoint, IInstallableAgents installableAgents)

Cause

Cette erreur se produit parce que les paramètres de 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 du pool de ressources UNIX ou Linux, exécutez la commande suivante à l’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, vérifiez si la découverte de l’agent réussit.

Type discoveryResult.ErrorData inattendu. Rapport de bogue de fichier - Nom du paramètre : lhs

Description de l’erreur

La découverte n’a pas réussi
Message : Échec non spécifié
Détails : Type DiscoveryResult.ErrorData inattendu. Veuillez créer un rapport de bogue.
ErrorData : System.ArgumentNullException
Value cannot be null.
Nom de paramètre : lhs
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
sur Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, Critères DiscoveryTargetEndpoint, IInstallableAgents installableAgents)

Cause

Cette erreur se produit en raison de fichiers shell omsagent dans le dossier des kits installés.

Solution

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

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

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

Consultez la capture d’écran suivante pour obtenir un exemple :

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

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 refusé activement.

Causes possibles

• Le démon SSH n’est pas en cours d’exécution sur le système cible.
• Un pare-feu basé sur un réseau ou 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 : trop d’échecs d’authentification 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 une tty pour exécuter sudo
Message d’exception :

Cause

L’élévation sudo a été sélectionnée dans l’entrée d’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 Comment 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 :
exit
su : mot de passe incorrect
opsuser@lx1 :~> sortie
logout

Cause possible

L’élévation de su a été sélectionnée dans l’entrée d’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 sur : /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 :Expiration de l’opération

  Cause

  L’élévation sudo a été sélectionnée dans l’entrée d’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

  Passez en revue la documentation de 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 : l’accès est 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 de la vérification de l’agent ont été correctement entrés 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. Vérifiez é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 septembre 14:49:07 auth du serveur|security :debug /opt/microsoft/scx/bin/omiserver PAM : pam_authenticate : error Authentication failed.

   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 fonctionnel.

Échec de la découverte WSMan 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 le certificat signé et l’hôte cible a installé l’agent. Toutefois, le certificat 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 pare-feu basé sur un réseau ou un hôte empêche la connectivité ou l’agent UNIX/Linux est actuellement arrêté.

Résolutions

• Signer manuellement le certificat.
• Vérifiez que l’agent UNIX/Linux a été installé.
• Modifiez l’option Pour découvrir tous les ordinateurs , autorisez l’Assistant Découverte à effectuer la signature de 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

Impossible d’exécuter la tâche 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 de 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.

Échec de la recherche d’une instance d’agent prise en charge correspondante dans les packs d’administration importés

Description de l’erreur

Impossible de trouver une instance d'agent prise en charge correspondante dans les packs d'administration importés. Importez le ou les packs d'administration liés à cette plate-forme pour détecter cet ordinateur.

Causes possibles

• L’hôte cible exécute un système d’exploitation non pris en charge.
• Le pack d’administration correct pour le système d’exploitation de l’hôte cible n’a pas été importé.
• Le pack d’administration correct 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 peut toujours être chargé. Patientez quelques minutes et réexécutez la découverte.

Impossible d’énumérer les types d’agents installables. Le pool de ressources associé peut toujours initialiser

Description de l’erreur

Impossible d’énumérer les types d’agents installables. Le pool de ressources associé peut toujours être initialisé. 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é récemment créé, mais il n’a pas entièrement initialisé.

Solution

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

Impossible de copier un nouvel agent sur cet ordinateur

Description de l’erreur

Message : Impossible de copier un 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

Les versions de l’agent de fichiers ne correspondent pas entre la base de données et le référentiel d’agents.

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 plus courte et plus courte pendant 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 le %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits dossier si les noms de fichiers sont corrects. N’oubliez pas de fermer et de rouvrir l’Assistant Découverte.

Plus d’informations

Pour plus d’aide, consultez notre forum de support TechniqueNet ou contactez Support Microsoft.