Résoudre les problèmes d'installation client agent d'Operations Manager

Que fait ce guide ?

Permet de résoudre les questions que l'agent du client de System Center 2012 Operations Manager (OpsMgr 2012 et Operations Manager 2012 R2) ne peut pas être installé.

Qui est-il destiné ?

Admins de System Center 2012 Operations Manager qui vous aider résoudre les problèmes d'installation client agent.

Comment ça marche ?

Nous allons commencer par demander si les conditions préalables nécessaires pour une installation réussie sont remplies. S'il n'y a aucun problème avec toutes les conditions préalables de la réunion, nous vous emmenons à travers une série d'étapes qui sont spécifiques à votre situation pour résoudre votre problème.

Temps approximatif d'achèvement :

15-30 minutes.

Première étape : Vérifier que l'ordinateur cible répond à la configuration prise en charge

Il n'est pas rare que des problèmes d'installation de client d'être causé par des clients qui ne possèdent pas les préalables nécessaires. Par conséquent, la première étape de la résolution des problèmes d'installation de l'agent Operations Manager consiste à vérifier que l'ordinateur client "potentiel" disposer des configurations logicielle et matérielle prises charge fr. Les articles suivants répertorie les configurations requises pour un client de System Center Operations Manager 2007 (OpsMgr 2007) et un client de System Center 2012 Operations Manager (OpsMgr 2012 et Operations Manager 2012 R2) :

Configurations prises en charge par Operations Manager 2007 R2

Configurations prises en charge par Operations Manager 2012

Si le système cible est un ordinateur Unix/Linux, vérifier que la distribution et la version sont pris en charge. Notez que la prise en charge de certaines versions vu Manager 2007 nécessite des mises à jour cumulatives postérieures à la version R2. Les articles suivants ont les versions supportées de Unix/Linux :

System Center Operations Manager 2007 R2 Cross plate-forme de surveillance des Packs d'administration

System Center Operations Manager 2012 prise en charge Unix et les Versions de système d'exploitation Linux


Cela résout votre problème ?

Première étape : Vérifier que l'ordinateur cible répond à la configuration prise en charge

Il n'est pas rare que des problèmes d'installation de client d'être causé par des clients qui ne possèdent pas les préalables nécessaires. Par conséquent, la première étape de la résolution des problèmes d'installation de l'agent Operations Manager consiste à vérifier que l'ordinateur client "potentiel" disposer des configurations logicielle et matérielle prises charge fr. Les articles suivants répertorie les configurations requises pour un client de System Center Operations Manager 2007 (OpsMgr 2007) et un client de System Center 2012 Operations Manager (OpsMgr 2012 et Operations Manager 2012 R2) :

Configurations prises en charge par Operations Manager 2007 R2

Configurations prises en charge par Operations Manager 2012

Si le système cible est un ordinateur Unix/Linux, vérifier que la distribution et la version sont pris en charge. Notez que la prise en charge de certaines versions vu Manager 2007 nécessite des mises à jour cumulatives postérieures à la version R2. Les articles suivants ont les versions supportées de Unix/Linux :

System Center Operations Manager 2007 R2 Cross plate-forme de surveillance des Packs d'administration

System Center Operations Manager 2012 prise en charge Unix et les Versions de système d'exploitation Linux


Cela résout votre problème ?

L'Assistant n'affiche pas la liste des agents potentiels à installer

Si l'Assistant n'affiche pas une liste d'agents potentiels à installer, le problème le plus probable est que le compte a des problèmes pour accéder à Active Directory. Les informations d'identification spécifiées dans l'Assistant lors de la découverte initiale devraient avoir la permission pour rechercher dans Active Directory pour potentiels agents Operations Manager, et si ce compte n'est pas capable de se connecter à Active Directory, puis l'Assistant de découverte va échouer.

Les erreurs typiques sont les suivants :

  • Code d'erreur : 800706BA
    Description de l'erreur : Le serveur RPC est indisponible.
  • Code d'erreur : 80070079
    Le serveur MOM n'a pas pu effectuer l'opération spécifiée sur l'ordinateur « nom ». Le délai de temporisation de sémaphore a expiré.
  • Code d'erreur : 800706433
    L'opération de gestion de Agent Agent installer a échoué pour l'ordinateur distant « nom »

Résolutions possibles :

Au cours de la découverte, spécifiez un compte qui a les deux autorisations d'administrateur de domaine et est membre du groupe Admins de gestionnaire des opérations.

En outre, si la requête LDAP arrive à expiration ou n'est pas en mesure de résoudre les éventuels agents dans Active Directory, découverte peut être faite via l'interface de commande de gestionnaire des opérations. Sélectionnez la case d'option « Dépannage Agent déploiement via the Operations Manager commande Shell » pour plus d'informations.


Cela résout votre problème ?

Résolution des problèmes de déploiement de l'agent via l'Assistant Détection de la console Operations Manager

Si l'agent sera déployée par l'intermédiaire de découverte de la console Operations Manager, sachez que l'agent sera installé à partir du serveur d'administration ou serveur de passerelle spécifié dans l'Assistant de découverte de l'agent, pas de gérer le serveur de que la console a été connectée à lors de son inauguration. Par conséquent, tous les tests se fasse à partir du serveur de gestion ou passerelle spécifié lorsque l'Assistant est exécuté ou un serveur de gestion différents/passerelle doit être spécifié au cours de l'Assistant pour voir si la même erreur se produit.


S'il vous plaît sélectionnez le scénario que vous rencontrez :

L'ordinateur cible voulu ne figure pas dans la liste des agents potentiels après l'exécution de la détection initiale

Si l'ordinateur cible n'est pas dans la liste des agents potentiels après que la découverte initiale s'exécute, l'ordinateur peut déjà figurer dans la base de données dans le cadre du groupe de gestion, ou l'ordinateur est répertorié sous «Actions en attente» dans la Console.

Si l'ordinateur cible n'est répertorié dans le nœud "Actions en attente" de l'espace "Administration" dans la Console opérateur, l'action existante doit être approuvée ou rejetée avant une nouvelle action puisse être exécutée. Si les paramètres d'installation existants sont suffisants, approuvez l'installation en attente à partir de la console. Si les paramètres existants sont incorrectes, rejeter l'action en cours, puis réexécutez l'Assistant de découverte.


Cela résout votre problème ?

L'Assistant Détection rencontre une erreur lors de l'installation de l'agent

Les erreurs les plus courantes que l'Assistant de découverte rencontre en essayant d'installer l'agent sont énumérés ci-dessous :

  • Opération : Installation de l'Agent
    Code d'erreur : 800706 9
  • Description de l'erreur : Erreur inconnue 0xC000296E
  • Description de l'erreur : Erreur inconnue 0xC0002976
  • Code d'erreur : 80070643
    Description de l'erreur : Erreur irrécupérable lors de l'installation.

Il peut y avoir plusieurs causes différentes à ces types d'erreurs :

  • Le compte spécifié précédemment pour réaliser l'installation de l'agent dans l'Assistant de découverte n'a pas les autorisations pour se connecter à distance sur l'ordinateur cible et d'installer un service Windows. Cela nécessite des autorisations d'administrateur local en raison de l'obligation d'écrire dans le registre.
  • Restrictions de stratégie de groupe sur le compte d'ordinateur de gestion serveur ou le compte utilisé pour pousser de l'agent, empêchent une installation réussie. Des objets de stratégie de groupe dans Active Directory qui empêchent le compte d'ordinateur serveur d'administration, ou le compte d'utilisateur utilisé par l'Assistant de découverte, d'accéder à distance au dossier Windows, le registre, WMI ou les partages administratifs sur l'ordinateur cible peut empêcher la réussite du déploiement de l'agent Operations Manager.
  • Le pare-feu Windows bloque les ports entre le serveur d'administration et de l'ordinateur cible.
  • Les services requis sur l'ordinateur cible ne s'exécutent pas.
Résolutions possibles :
  • Si la credent EIAA spécifiés dans l'Assistant n'ont pas des autorisations d'administrateur local, ajoutez le compte au groupe de sécurité local Administrateurs sur l'ordinateur cible ou utiliser un compte qui est déjà membre de ce groupe.
  • Bloquer l'héritage de stratégies de groupe sur l'ordinateur cible, ou le compte d'utilisateur effectue l'installation.
  • Si une installation de l'agent échoue lorsque vous utilisez un compte de domaine pour distribuer l'agent à partir d'un serveur de gestion, l'utilisation des outils d'administration Windows peut aider à identifier les problèmes potentiels. Ouvrez une session sur le serveur d'administration avec les informations d'identification en question et tentez effectuer les tâches suivantes. Si le compte n'a pas l'autorisation de se connecter sur le serveur de gestion, les outils peuvent être exécutés sous les informations d'identification seront effectués à une invite de commande.

    "RUNAS/User : compmgmt.msc". Dans l'élément de menu « Action », sélectionnez « se connecter à un autre ordinateur ». Recherchez ou tapez le nom de l'ordinateur distant. Essayez d'ouvrir l'observateur d'événements et de sourcils tout le journal des événements.

    "RUNAS user:services.msc". Dans l'élément de menu « Action », sélectionnez « se connecter à un autre ordinateur ». Recherchez ou tapez le nom de l'ordinateur distant. Essayez de démarrer ou d'arrêter le spouleur d'impression ou tout autre service sur l'ordinateur cible.

    "RUNAS/User : regedt32.exe". Partir du fichier "menu article, sélectionnez « connexion registre réseau ». Recherchez ou tapez le nom de l'ordinateur distant. Essayez d'ouvrir « HKey_Local_Machine » sur l'ordinateur distant.

    "RUNAS user:Explorer.exe". Tapez ce qui suit dans la barre d'adresse : \\admin$.
Si une de ces tâches échoue, essayez d'utiliser un compte différent, connu pour avoir l'administrateur de domaine ou des autorisations d'Administrateur Local (sur l'ordinateur cible). Essayez aussi les mêmes tâches d'un serveur membre ou poste de travail pour voir si les tâches échouent de plusieurs machines.

NOTE Échec de la connexion au partage admin$ peut empêcher le serveur d'administration de copier les fichiers d'installation à la cible. L « échec de la connexion au Registre Windows sur la cible peut adequately l'installation correcte du service de contrôle d » intégrité. Échec de la connexion au Service Control Manager empêche le programme d'installation de démarrer le service.

  • Ce qui suit ports doivent être ouverts entre le serveur d'administration et de l'ordinateur cible :

    Mappeur de point final RPC numéro de Port : 135 protocole : TCP/UDP

    * Ports haute RPC/DCOM (2000/2003 OS) Ports 1024-5000 protocole : TCP/UDP

    * Ports haute RPC/DCOM (OS 2008) Ports 49152-65535 protocole : TCP/UDP

    Numéro de Port de service de noms NetBIOS : 137 protocole : TCP/UDP

    Numéro de Port NetBIOS session service : 139 protocole : TCP/UDP

    SMB sur le numéro de Port IP : 445 protocole : TCP

    Numéro de Port canal MOM : 5723 protocole : TCP/UDP
  • Les services suivants doivent être activé et en cours d'exécution sur l'ordinateur cible :

    Netlogon

    Registre à distance

    Windows Installer

    Mises à jour automatiques
Les articles suivants donner quelques bons renseignements sur le déploiement de l'agent Operations manager à l'aide de découverte du serveur de gestion :


Cela résout votre problème ?

Résolution des problèmes de déploiement de l'agent via l'interface de commande d'Operations Manager

Dans certaines situations, la détection automatique des agents potentiels peut expirer en raison de la très grande taille ou complexes environnements Active Directory. D'autres situations peuvent nécessiter l'exécution de la détection automatique avec une requête LDAP plus limitée que celle disponible dans interface utilisateur. Dans ces cas, la détection automatique d'ordinateurs et d'installation à distance de l'agent Operations Manager sont possibles via l'interface de commande d'Operations Manager.

Par exemple, la commande suivante définit une requête LDAP et le passe à New-WindowsDiscoveryConfiguration, créant ainsi un LDAP basé à WindowsDiscoveryConfiguration :

$query = New-LdapQueryDiscoveryCriteria – LdapQuery: "(sAMAccountType=805306369)(name=srv1.contoso.com*)" –Domain:"contoso.com"$discoConfig = New-WindowsDiscoveryConfiguration – LdapQueryDiscoveryCriteria: $query $query

Voici un autre exemple, la commande suivante définit une WindowsDiscoveryConfiguration basé sur le nom qui sera découverte un ordinateur spécifique ou des ordinateurs. Dans notre exemple, on trouve client1.contoso.com et client2.contoso.com.

$discoConfig = New-WindowsDiscoveryConfiguration - ComputerName: « srv1.contoso.com. », « srv2.contoso.com. »

Il y a aussi beaucoup plus que vous pouvez spécifier lorsque vous définissez une WindowsDiscoveryConfiguration. Les commandes suivantes indiquent au module de détection qu'il doit utiliser des informations d'identification spécifiques, procéder à la vérification de chaque ordinateur Windows détecté et limiteur le type objet détecté à un serveur Windows. Le paramètre ComputerType peut être un poste de travail, un serveur ou les deux. Le commutateur PerformVerification est utilisé pour diriger la découverte afin de vérifier que les ordinateurs uniquement disponibles doivent être retournés.

# Invite d'informations d'identification utilisées pour exécuter la découverte.

$creds = get-Credential

# Définir une WindowsDiscoveryConfiguration

$discoConfig = New-WindowsDiscoveryConfiguration – ComputerName: « srv3.contoso.com. », « srv4.contoso.com. » – PerformVerification : $true – ActionAccount: $creds - ComputerType: "Serveur"

# Sélectionnez le serveur de gestion utilisé pour exécuter la découverte.

$managementServer = get-ManagementServer – racine : $true

# Lancez le processus de découverte.

$discoResult = démarrer-découverte-ManagementServer : $managementServer – WindowsDiscoveryConfiguration : $discoConfig

# Vérifier que le processus de découverte découvert les ordinateurs Windows, que vous avez spécifié.

$discoResult.CustomMonitoringObjects

# Enfin et surtout installer des agents sur les ordinateurs détectés.

Install-Agent – ManagementServer : $managementServer – AgentManagedComputer : $discoResult.CustomMonitoringObjects


Cela résout votre problème ?

Résolution des problèmes de déploiement d'agent via la journalisation détaillée de Windows Installer

Si l'installation de l'agent sur un ordinateur distant échoue pendant l'installation, un journal détaillé de Windows Installer peut être créé sur le serveur d'administration dans l'emplacement par défaut suivant :

C:\Program System Center Operations Manager \AgentManagement\AgentLogs

où <version> est 2007ou 2012

Le journal peut servir à déterminer s'il y avait une erreur spécifique rencontrée et peut-être être utile pour poursuivre le dépannage installation de l'agent Operations Manager sur l'ordinateur cible.

Recherchez la première entrée avec la chaîne de valeur de retour 3 dans le journal. Ce qui précède de quelques lignes indiquera habituellement que Windows Installer a rencontré l'erreur. Le format sera généralement sous forme de fonction / description d'erreur / error code de retour et peut indiquer des problèmes d'autorisation, les fichiers manquants ou d'autres paramètres qui doivent être changés.

Exemples :

  • Message d'erreur : ConvertStringSecurityDescriptorToSecurityDescriptor a échoué : 87
    Cause possible : le compte d'installation n'a pas la permission du journal de sécurité sur l'ordinateur cible.
  • Message d'erreur : ModifyEventLogAccessForNetworkService() : ne pourrait pas accorder un accès en lecture aux SecurityLog : 0x00000057
    Cause possible : le compte d'installation n'a pas la permission du journal de sécurité sur l'ordinateur cible.
  • Message d'erreur : impossible d'ouvrir le fichier de base de données. Erreur système-2147024629
    Cause possible : le compte d'installation n'a pas d'autorisation dans le dossier TEMP de système.

Il y a beaucoup d'erreurs possibles qui peut être enregistrés ici et autres erreurs individuelles que vous trouverez peut être plus documenté sur TechNet ou sur la Base de connaissances Microsoft.


Cela résout votre problème ?

Résolution des problèmes liés à l'installation manuelle de l'agent Operations Manager

Dans les cas où l'agent Operations Manager ne peut pas être déployé à un ordinateur distant via l'Assistant de découverte, l'agent devra être installé manuellement. Cela peut être effectuée via la ligne de commande en utilisant le fichier MomAgent.msi . Les références suivantes décrivent les différents commutateurs et options de configuration disponibles pour effectuer une installation manuelle :

Si l'agent est déployé par l'intermédiaire de manuel d'installation, sachez que le futur Service Pack met à jour ou mises à jour cumulatives devra être déployé manuellement aussi bien. Les ordinateurs qui ont été installés manuellement ne seront pas désignés par le service d'administration de Microsoft System Center Configuration comme étant facile à gérer à distance, et la possibilité de mettre à niveau ne sera pas présentée dans la Console.

D'autres considérations clées pour tenir compte lors de l'installation manuelle des agents incluent :

  • Si l'installation est effectuée par un domaine ou un utilisateur local, le compte doivent être membre du groupe local administrateurs sécurité dans Vista ou des systèmes d'exploitation ultérieurs. Dans les systèmes d'exploitation antérieurs à Vista, les utilisateurs qui sont membres du groupe de sécurité "Power Users" avaient les autorisations requises pour installer les services.
  • Si l'agent est déployé via le gestionnaire de Configuration, le compte de service de Configuration Manager Agent devra soit exécuté en tant que Localsystem (qui est la valeur par défaut) ou sous le contexte d'un administrateur local.

Cela résout votre problème ?

Félicitations !

Votre problème d'installation de client Operations Manager est résolu.

Désolé

Il semble que nous sommes incapables de résoudre votre problème à l'aide de ce guide. Pour plus d'aide pour résoudre cette question s'il vous plaît voir notre TechNet support forum ou contactez le Support technique Microsoft.

Erreur Code 800706BA - le serveur RPC n'est pas disponible

Dans Operations Manager, l'ordinateur de l'agent doit être en mesure d'atteindre avec succès et se connecter au port TCP 5723 sur le serveur d'administration. Si c'est à défaut vous sera probablement recevoir l'ID d'événement 21016 et événement ID 21006 sur l'agent du client.

En plus du port TCP 5723, les ports suivants doivent également être activés :

  • TCP et UDP port 389 pour LDAP
  • Le port TCP et UDP 88 pour l'authentification Kerberos
  • TCP et UDP port 53 pour DNS

Outre ce qui précède, nous devons également garantir que les communications RPC se termine correctement sur le réseau. S'il y a des problèmes avec la communication RPC il va se manifester généralement lorsque vous appuyez sur un agent depuis le serveur d'administration Operations Manager. Problèmes de communication RPC causera habituellement le push client échoue avec une erreur semblable au suivant :

Le serveur Operations Manager n'a pas pu effectuer l'opération spécifiée sur l'ordinateur de agent1.contoso.com.

Opération : Agent Insall

Installer de compte : contoso\Agent_action

Code d'erreur : 800706BA

Description de l'erreur : Le serveur RPC est indisponible

Cela se produit généralement lorsque deux ports éphémères non standard sont utilisés ou lorsque les ports éphémères sont bloqués à un pare-feu. Par exemple, si les ports RPC non standard haut de gamme ont été configurés, une trace réseau tout en poussant l'agent affiche une connexion réussie à port RPC 135 suivie d'une tentative de connexion à l'aide d'un port non standard de la RPC comme 15595 comme indiqué ci-dessous.

18748 MS Agent TCP TCP : Flags = CE... S., SrcPort = 52457, DstPort = 15595, PayloadLen = 0, Seq = 1704157139, Ack = 0, Win = 8192 18750 MS Agent TCP TCP : drapeaux [SynReTransmit #18748] = CE... S., SrcPort = 52457, DstPort = 15595, PayloadLen = 0, Seq = 1704157139, Ack = 0, 18751 MS Agent TCP TCP : drapeaux [SynReTransmit #18748] =... S., SrcPort = 52457, DstPort = 15595, PayloadLen = 0, Seq = 1704157139, Ack = 0, Win = 8192

Dans cet exemple, étant donné que l'exemption de port pour cet intervalle non standard n'a pas été configurée sur le pare-feu, les paquets sont perdus et la connexion échoue.

Dans Windows Vista et supérieur à la fourchette haute de RPC ports sont 49152-65535, c'est ce que nous voulons chercher. Pour vérifier si c'est votre problème, exécutez la commande suivante pour voir quelle plage de haut port RPC est configuré :

Netsh int ipv4 afficher dynamicportrange tcp

Selon les normes de l'IANA, il devrait ressembler à ceci :

Protocole tcp étendue de Port dynamique

---------------------------------

Port de début : 49152

Nombre de Ports : 16384

Si vous voyez un port de départ différentes, alors le problème peut être que le pare-feu n'est pas correctement configuré pour autoriser le trafic sur ces ports. Vous pouvez modifier la configuration du pare-feu, ou vous pouvez exécuter la commande suivante pour définir la gamme haute ports à leurs valeurs par défaut :

Netsh int ipv4 définir dynamicport tcp début = 49152 num = 16383

Notez que vous pouvez également configurer l'étendue de port dynamique RPC via le registre. Consultez l'article suivant pour plus d'informations :

154596 - comment faire pour configurer l'allocation de port dynamique RPC avec un pare-feu

Si tout semble être configuré correctement, mais vous rencontrez toujours l'erreur ci-dessus, il peut être qu'une des conditions suivantes sont vraies :

  1. DCOM a été limité à un certain port. Pour vérifier, ouvrez dcomcnfg.exe et traverse de dcomcnfg -> poste de travail -> Propriétés -> protocoles par défaut et faire en sorte qu'il n'y a pas réglage personnalisé il.
  2. WMI est configuré pour utiliser un point de terminaison personnalisé. Pour vérifier si vous avez un point de terminaison statique configuré pour WMI, dcomcnfg.exe ouvert et traverse de dcomcnfg -> poste de travail -> DCOM Config -> Windows Management et Instrumentation -> Propriétés -> le point de terminaison et veiller à ce qu'il n'y a pas personnalisé ici.
  3. L'ordinateur agent exécute le rôle Exchange 2010 CAS. Le Service d'accès Client Exchange 2010 modifie cette plage de ports à 6005 et 65 535. La gamme a été étendue pour fournir la mise à l'échelle suffisante pour les déploiements à grandes échelle. Ne modifiez pas ces valeurs de port sans comprendre pleinement les conséquences de faire telle.

Plus d'informations

Pour plus d'informations concernant les ports et pare-feu exigences, veuillez consulter la section pare-feu dans le document suivant :

Préparation de votre environnement pour System Center 2012 R2 Operations Manager

Vous pouvez également trouver les vitesses de connectivité de réseau requise minimale dans le même document.

Dernières Notes

Résolution des problèmes de réseau sont une question extrêmement importante en soi, il est donc préférable de consulter un ingénieur réseau, si vous pensez qu'un problème de réseau sous-jacent est cause votre agent des problèmes de connectivité dans Operations Manager. Nous avons aussi quelques base réseau généralisé dépannage informations disponibles auprès de nos Services d'annuaire Windows appuyer équipe disponible ici :

Dépannage réseaux sans NetMon


Cela résout votre problème ?


Propriétés

ID d'article : 10147 - Dernière mise à jour : 13 janv. 2016 - Révision : 2

Commentaires