Partager via

Résoudre les problèmes de connectivité de l’agent dans Operations Manager

  • Article

Ce guide vous aide à résoudre les problèmes que les agents Operations Manager rencontrent des problèmes au niveau de la connexion au serveur d’administration dans System Center 2012 Operations Manager (OpsMgr 2012) et versions ultérieures.

Pour en savoir plus sur l’agent Operations Manager et leur communication avec les serveurs d’administration, consultez Agents et communication entre les agents et les serveurs d’administration.

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

Vérifier le service de contrôle d’intégrité

Chaque fois que vous rencontrez des problèmes de connectivité dans Operations Manager, vérifiez d’abord que le service d’intégrité s’exécute sans erreurs sur l’agent client et le serveur d’administration. Pour déterminer si le service est en cours d’exécution, procédez comme suit :

  1. Appuyez sur la touche Windows+R.

  2. Dans la zone Exécuter , tapez services.msc et appuyez sur Entrée.

  3. Recherchez le service Microsoft Monitoring Agent , puis double-cliquez dessus pour ouvrir la page Propriétés .

    Note

    Dans System Center 2012 Operations Manager, le nom du service est System Center Management.

  4. Vérifiez que le type de démarrage est défini sur Automatique.

  5. Vérifiez si le démarrage s’affiche dans l’état du service. Sinon, cliquez sur Démarrer.

Vérifier les exclusions d’antivirus

Si le service d’intégrité est opérationnel, la prochaine chose consiste à confirmer que les exclusions antivirus sont correctement configurées. Pour obtenir les informations les plus récentes sur les exclusions d’antivirus recommandées pour Operations Manager, consultez Recommandations relatives aux exclusions antivirus liées à Operations Manager.

Vérifier les problèmes réseau.

Dans Operations Manager, l’ordinateur de l’agent doit être en mesure de se connecter au port TCP 5723 sur le serveur d’administration. Si cela échoue, vous recevrez probablement l’ID d’événement 21016 et 21006 sur l’agent client.

Outre le port TCP 5723, les ports suivants doivent être activés :

  • Port TCP et UDP 389 pour LDAP
  • Port TCP et UDP 88 pour l’authentification Kerberos
  • Port TCP et UDP 53 pour le service DNS (Domain Name Service)

En outre, vous devez vous assurer que les communications RPC se terminent correctement sur le réseau. Les problèmes de communication RPC se manifestent généralement lors de l’envoi (push) d’un agent à partir du serveur d’administration. Les problèmes de communication RPC entraînent généralement l’échec de l’envoi push du client avec une erreur similaire à ce qui suit :

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

Opération : Installation de l’agent
Compte d’installation : contoso\Agent_action
Code d’erreur : 800706BA
Description de l’erreur : le serveur RPC n’est pas disponible

Cette erreur se produit généralement lorsque les ports éphémères non standard sont utilisés ou lorsque les ports éphémères sont bloqués par un pare-feu. Par exemple, si des ports RPC non standard ont été configurés, une trace réseau affiche une connexion réussie au port RPC 135 suivi d’une tentative de connexion à l’aide d’un port RPC non standard tel que 15595. Par exemple :

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

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

Dans Windows Vista et versions ultérieures, les ports rpc haute plage sont 49152-65535, c’est ce que nous voulons rechercher. Pour vérifier s’il s’agit de votre problème, exécutez la commande suivante pour voir quelle plage de ports haute RPC est configurée :

netsh int ipv4 show dynamicportrange tcp

Selon les normes IANA, la sortie doit ressembler à ceci :

Plage de ports tcp dynamiques de protocole
---------------------------------
Port de démarrage : 49152
Nombre de ports : 16384

Si vous voyez un autre port de démarrage, le problème peut être que le pare-feu n’est pas configuré correctement pour autoriser le trafic via ces ports. Vous pouvez modifier la configuration sur le pare-feu ou exécuter la commande suivante pour définir les ports de plage élevée sur leurs valeurs par défaut :

netsh int ipv4 set dynamicport tcp start=49152 num=16384

Vous pouvez également configurer la plage de ports dynamiques RPC via le Registre. Pour plus d’informations, consultez Comment configurer l’allocation de port dynamique RPC avec des pare-feu.

Si tout semble être configuré correctement et que vous rencontrez toujours l’erreur, cela peut être dû à l’une des conditions suivantes :

  1. DCOM a été limité à un certain port. Pour vérifier, exécutez dcomcnfg.exe, accédez aux protocoles par défaut des propriétés>de mon ordinateur>, vérifiez qu’il n’existe aucun paramètre personnalisé.

  2. WMI est configuré pour utiliser un point de terminaison personnalisé. Pour vérifier si un point de terminaison statique est configuré pour WMI, exécutez , accédez à My Computer>DCOM Config>Windows Management and Instrumentation>Properties>Endpoints, vérifiez qu’il n’existe aucun paramètre personnalisé.dcomcnfg.exe

  3. L’ordinateur agent exécute le rôle serveur d’accès client Exchange Server 2010. Le service d’accès client Exchange Server 2010 remplace la plage de ports par 6005 à 65535. La plage a été développée pour fournir une mise à l’échelle suffisante pour les déploiements volumineux. Ne modifiez pas ces valeurs de port sans comprendre pleinement les conséquences.

Pour plus d’informations sur les exigences relatives au port et au pare-feu, consultez Pare-feu. Vous trouverez également les vitesses minimales de connectivité réseau requises dans le même article.

Note

La résolution des problèmes réseau est un problème extrêmement important. Il est donc préférable de consulter un ingénieur réseau si vous pensez qu’un problème réseau sous-jacent provoque des problèmes de connectivité de votre agent dans Operations Manager. Nous disposons également d’informations de dépannage réseau généralisées de base disponibles à partir de notre équipe du support technique des services d’annuaire Windows disponibles sur les réseaux de résolution des problèmes sans NetMon.

Vérifier les problèmes de certificat sur le serveur de passerelle

Operations Manager exige que l’authentification mutuelle soit effectuée entre les agents clients et les serveurs d’administration avant l’échange d’informations entre eux. Pour sécuriser le processus d’authentification, le processus est chiffré. Lorsque l’agent et le serveur d’administration résident dans le même domaine Active Directory ou dans les domaines Active Directory qui ont établi des relations d’approbation, ils utilisent les mécanismes d’authentification Kerberos v5 fournis par Active Directory. Lorsque les agents et les serveurs d'administration ne se trouvent pas dans la même limite d'approbation, d'autres mécanismes sont nécessaires pour satisfaire l'exigence d'authentification mutuelle sécurisée.

Dans Operations Manager, cela s’effectue via l’utilisation de certificats X.509 émis pour chaque ordinateur. S’il existe de nombreux ordinateurs surveillés par agent, cela peut entraîner une surcharge administrative élevée pour la gestion de tous ces certificats. De plus, s'il existe un pare-feu entre les agents et les serveurs d'administration, plusieurs points de terminaison autorisés doivent être définis et maintenus dans les règles de pare-feu pour autoriser la communication entre eux.

Pour réduire la surcharge administrative, Operations Manager a un rôle serveur facultatif appelé serveur de passerelle. Les serveurs de passerelle se trouvent dans la limite d’approbation des agents clients et peuvent participer à l’authentification mutuelle obligatoire. Étant donné que les passerelles se trouvent dans la même limite d’approbation que les agents, le protocole Kerberos v5 pour Active Directory est utilisé entre les agents et le serveur de passerelle, et chaque agent communique uniquement avec les serveurs de passerelle dont il a connaissance.

Les serveurs de passerelle communiquent ensuite avec les serveurs d’administration pour le compte des clients. Pour prendre en charge l’authentification mutuelle sécurisée obligatoire entre le serveur de passerelle et les serveurs d’administration, les certificats doivent être émis et installés, mais uniquement pour les serveurs de passerelle et d’administration. Cela réduit le nombre de certificats requis. Dans le cas d’un pare-feu intermédiaire, il réduit également le nombre de points de terminaison autorisés qui doivent être définis dans les règles de pare-feu.

Le point de départ ici est que si les agents clients et les serveurs d’administration ne se trouvent pas dans la même limite d’approbation, ou si un serveur de passerelle est utilisé, les certificats nécessaires doivent être installés et configurés correctement pour que la connectivité de l’agent fonctionne correctement. Voici quelques éléments clés à vérifier :

  • Vérifiez que le certificat de passerelle existe dans les certificats personnels>de l’ordinateur>local sur le serveur d’administration auquel la passerelle ou l’agent se connecte.

  • Vérifiez que le certificat racine existe dans les certificats autorités>de certification racines approuvées par l’ordinateur>local sur le serveur d’administration auquel la passerelle ou l’agent se connecte.

  • Vérifiez que le certificat racine existe dans les certificats autorités>de certification racines approuvées par l’ordinateur>local sur le serveur de passerelle.

  • Vérifiez que le certificat de passerelle existe dans les certificats personnels>de l’ordinateur>local sur le serveur de passerelle. Vérifiez que le certificat de passerelle existe dans les certificats Operations Manager>de l’ordinateur>local sur le serveur de passerelle.

  • Vérifiez que la valeur HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber de Registre existe et a la valeur du certificat (à partir du dossier Ordinateur local/Personnel/Certificats dans les détails du champ Numéro de série) inversée dans celui-ci sur le serveur de passerelle.

  • Vérifiez que la valeur HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber de Registre existe et a la valeur du certificat (à partir du dossier Ordinateur local/Personnel/Certificats dans les détails du champ Numéro de série) inversée dans celui-ci sur le serveur d’administration auquel la passerelle ou l’agent se connecte.

Vous pouvez recevoir les ID d’événement suivants dans le journal des événements Operations Manager lorsqu’il existe un problème avec des certificats :

  • 20050
  • 20057
  • 20066
  • 20068
  • 20069
  • 20072
  • 20077
  • 21007
  • 21021
  • 21002
  • 21036

Pour plus d’informations sur la façon dont les fonctions d’authentification basées sur des certificats dans Operations Manager, ainsi que des instructions sur l’obtention et la configuration des certificats appropriés, consultez Authentification et chiffrement des données pour les ordinateurs Windows.

Rechercher un espace de noms disjoint sur l’agent client

Un espace de noms disjoint se produit lorsque l’ordinateur client a un suffixe DNS principal qui ne correspond pas au nom DNS du domaine Active Directory auquel appartient le client. Par exemple, un client qui utilise un suffixe DNS principal de corp.contoso.com dans un domaine Active Directory nommé na.corp.contoso.com utilise un espace de noms disjoint.

Lorsque l’agent client ou le serveur d’administration dispose d’un espace de noms disjoint, l’authentification Kerberos peut échouer. Bien qu’il s’agisse d’un problème Active Directory et non d’un problème Operations Manager, il affecte la connectivité de l’agent.

Pour plus d’informations, consultez Espace de noms dissocié.

Pour résoudre le problème, utilisez l’une des méthodes suivantes :

Méthode 1

Créez manuellement les noms de principal de service appropriés pour les comptes d’ordinateur affectés et incluez le SPN hôte pour le nom de domaine complet (FQDN) ainsi que le suffixe de nom disjoint (HOST/machine.disjointed_name_suffix.local). Mettez également à jour l’attribut DnsHostName de l’ordinateur pour refléter le nom disjoint (machine.disjointed_name_suffix.local) et activez l’inscription de l’attribut dans une zone DNS valide sur les serveurs DNS qu’Active Directory utilise.

Méthode 2

Corrigez l’espace de noms disjoint. Pour ce faire, modifiez l’espace de noms dans les propriétés de l’ordinateur concerné pour refléter le nom de domaine complet du domaine auquel appartient l’ordinateur. Assurez-vous que vous êtes pleinement conscient des conséquences de cette opération avant d’apporter des modifications dans votre environnement. Pour plus d’informations, consultez Transition d’un espace de noms disjoint vers un espace de noms contigu.

Rechercher une connexion réseau lente

Si l’agent client s’exécute sur une connexion réseau lente, il peut rencontrer des problèmes de connectivité en raison du fait qu’il existe un délai d’expiration codé en dur pour l’authentification. Pour résoudre ce problème, installez System Center 2012 Operations Manager SP1 Update Rollup 8 (en supposant que vous n’êtes pas déjà sur System Center 2012 R2 Operations Manager), puis modifiez manuellement la valeur du délai d’expiration.

La mise à jour UR8 augmente le délai d’expiration du serveur à 20 secondes et le délai d’expiration du client à 5 minutes.

Pour plus d’informations, consultez Correctif cumulatif 8 pour System Center 2012 Operations Manager Service Pack 1.

Note

Ce problème peut également se produire lorsqu’il existe des problèmes de synchronisation de temps entre l’agent client et le serveur d’administration.

Rechercher les problèmes de connecteur OpsMgr

Si tout le reste est extrait, consultez le journal des événements Operations Manager pour tous les événements d’erreur générés par le connecteur OpsMgr. Les causes et résolutions courantes des différents événements de connecteur OpsMgr sont répertoriées ci-dessous.

L’ID d’événement 21006 et 21016 apparaît sur l’agent client

Exemples de ces événements :

Source : Connecteur OpsMgr
Date : heure
ID d’événement : 21006
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description : Le connecteur OpsMgr n’a pas pu se connecter à <ManagementServer> :5723. Le code d’erreur est 10060L (une tentative de connexion a échoué, car la partie connectée n’a pas répondu correctement après une période donnée, ou la connexion établie a échoué, car l’hôte connecté n’a pas pu répondre.). Vérifiez qu’il existe une connectivité réseau, que le serveur est en cours d’exécution et a inscrit son port d’écoute et qu’il n’existe aucun pare-feu bloquant le trafic vers la destination.

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
Date : heure
ID d’événement : 21016
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description : OpsMgr n’a pas pu configurer un canal de communication vers <ManagementServer> et aucun hôte de basculement n’est présent. La communication reprend lorsque <ManagementServer> est disponible et que la communication à partir de cet ordinateur est autorisée.

En règle générale, ces ID d’événement sont générés, car l’agent n’a pas reçu de configuration. Une fois qu’un nouvel agent est ajouté et avant sa configuration, cet événement est courant. L’événement 1210 dans le journal des événements Operations Manager de l’agent indique que l’agent a reçu et appliqué la configuration. Vous recevez cet événement après l’établissement de la communication.

Vous pouvez utiliser les étapes suivantes pour résoudre ce problème :

  1. Si l’approbation automatique pour les agents installés manuellement n’est pas activée, vérifiez que l’agent est approuvé.

  2. Vérifiez que les ports suivants sont activés pour la communication :

    • 5723 et port TCP et UDP 389 pour LDAP.
    • Port TCP et UDP 88 pour l’authentification Kerberos.
    • Port TCP et UDP 53 pour le serveur DNS.

  3. Cet événement peut potentiellement indiquer que l’authentification Kerberos échoue. Recherchez les erreurs Kerberos dans les journaux des événements et résolvez les problèmes.

  4. Vérifiez si le suffixe DNS a un domaine incorrect. Par exemple, l’ordinateur est joint à contoso1.com , mais le suffixe DNS principal est défini sur contoso2.com.

  5. Vérifiez que les clés de Registre de noms de domaine par défaut sont correctes. Pour vérifier, vérifiez que les clés de Registre suivantes correspondent à votre nom de domaine :

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain

  6. Un SPN dupliqué pour le service d’intégrité peut également entraîner l’ID d’événement 21016. Pour rechercher le SPN dupliqué, exécutez la commande suivante :

    setspn -F -Q MSOMHSvc/<fully qualified name of the management server in the event>

    Si des spN en double sont inscrits, vous devez supprimer le SPN du compte qui n’est pas utilisé pour le service d’intégrité du serveur d’administration.

L’ID d’événement 20057 apparaît sur le serveur d’administration

Exemple de cet événement :

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
Date : heure
ID d’événement : 20057
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :Échec de l’initialisation du contexte de sécurité pour MSOMHSvc/****** L’erreur retournée est 0x80090311(Aucune autorité n’a pu être contactée pour l’authentification.). Cette erreur peut s’appliquer au package Kerberos ou SChannel.

Les ID d’événement 21006, 21016 et 20057 sont généralement causés par des pare-feu ou des problèmes réseau qui empêchent la communication sur les ports requis. Pour résoudre ce problème, vérifiez les pare-feu entre l’agent client et le serveur d’administration. Les ports suivants doivent être ouverts pour activer l’authentification et la communication correctes :

  • Port TCP et UDP 389 pour LDAP.
  • Port TCP et UDP 88 pour l’authentification Kerberos.

L’ID d’événement 2010 et 2003 apparaît sur l’agent client

Exemples de ces événements :

Nom du journal : Operations Manager
Source : HealthService
Date : données
ID d’événement : 2010
Catégorie de tâche : Service de contrôle d’intégrité
Niveau : Erreur
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description : Le service d’intégrité ne peut pas se connecter à Active Directory pour récupérer la stratégie de groupe d’administration. L’erreur est une erreur non spécifiée (0x80004005)
Xml d’événement :
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event »>
<Système>
<Nom du fournisseur="HealthService » />
<Qualificateurs EventID="49152">2010/<EventID>
<Niveau 2</Niveau>>
<Tâche 1</Tâche>>
<Mots clés 0x80000000000000</mots>clés>
<TimeCreated SystemTime="2015-02-21T21:06:04.000000000Z » />
<EventRecordID>84143</EventRecordID>
<Channel>Operations Manager</Channel>
<ComputerName</Computer>>
<Sécurité/>
</Système>
<EventData>
<Erreur></données non spécifiées>
<Données>0x80004005</données>
</EventData>
</Événement>

Nom du journal : Operations Manager
Source : HealthService
Date : heure
ID d’événement : 2003
Catégorie de tâche : Service de contrôle d’intégrité
Niveau : Information
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description : Aucun groupe d’administration n’a été démarré. Cela peut être dû au fait qu’aucun groupe d’administration n’est actuellement configuré ou qu’un groupe d’administration configuré n’a pas pu démarrer. Le service d’intégrité attend que la stratégie d’Active Directory configure un groupe d’administration à exécuter.
Xml d’événement :
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event »>
<Système>
<Nom du fournisseur="HealthService » />
<Qualificateurs EventID="16384">2003/<EventID>
<Niveau 4</Niveau>>
<Tâche 1</Tâche>>
<Mots clés 0x80000000000000</mots>clés>
<TimeCreated SystemTime="2015-02-21T21:06:04.000000000Z » />
<EventRecordID>84156</EventRecordID>
<Channel>Operations Manager</Channel>
<ComputerName</Computer>>
<Sécurité/>
</Système>
<EventData>
</EventData>
</Événement>

Si l’agent utilise l’affectation Active Directory, les journaux des événements indiquent également un problème de communication avec Active Directory.

Si vous voyez ces journaux d’événements, vérifiez que l’agent client peut accéder à Active Directory. Vérifiez les pare-feu, la résolution de noms et la connectivité réseau générale.

ID d’événement 20070 combiné à l’ID d’événement 21016

Exemples de ces événements :

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
Date : 13/6/2014 10:13:39 PM
ID d’événement : 21016
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
OpsMgr n’a pas pu configurer un canal de communication vers <ComputerName> et aucun hôte de basculement n’est présent. La communication reprend lorsque <ComputerName> est disponible et que la communication à partir de cet ordinateur est autorisée.

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
Date : 13/6/2014 10:13:37 PM
ID d’événement : 20070
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le connecteur OpsMgr est connecté à <ComputerName>, mais la connexion a été fermée immédiatement après l’authentification. La cause la plus probable de cette erreur est que l'agent n'est pas autorisé à communiquer avec le serveur ou que le serveur n'a pas reçu de configuration. Consultez le journal des événements sur le serveur pour la présence de 20 000 événements, qui indique que les agents non approuvés tentent de se connecter.

Lorsque vous voyez ces événements, cela indique que l’authentification s’est produite, mais que la connexion a été fermée. Cela se produit généralement parce que l’agent n’a pas été configuré. Pour vérifier cela, vérifiez si l’ID d’événement 20000 Un appareil qui ne fait pas partie de ce groupe d’administration a tenté d’accéder à ce service d’intégrité est reçu sur le serveur d’administration.

Ces journaux d’événements peuvent également se produire si les agents clients sont bloqués dans un état en attente et non visibles dans la console.

Pour vérifier, exécutez la commande suivante pour vérifier si les agents sont répertoriés pour approbation manuelle :

Get-SCOMPendingManagement

Dans ce cas, vous pouvez résoudre ce problème en exécutant la commande suivante pour approuver manuellement les agents :

Get-SCOMPendingManagement| Approve-SCOMPendingManagement

L’ID d’événement 21023 apparaît sur l’agent client, tandis que l’ID d’événement 29120, 29181 et 21024 apparaît sur le serveur d’administration

Voici quelques exemples de ces événements.

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
ID d’événement : 21023
Catégorie de tâche : None
Niveau : Information
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
OpsMgr n’a aucune configuration pour groupName> de groupe <d’administration et demande une nouvelle configuration auprès du service de configuration.

Nom du journal : Operations Manager
Source : Configuration de la gestion d’OpsMgr
ID d’événement : 29120
Catégorie de tâche : None
Niveau : Avertissement
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le service de configuration d’administration Operations Manager n’a pas pu traiter la demande de configuration (fichier de configuration XML ou demande de pack d’administration) en raison de l’exception suivante

Nom du journal : Operations Manager
Source : Configuration de la gestion d’OpsMgr
ID d’événement : 29181
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le service de configuration de gestion OpsMgr n’a pas pu exécuter l’élément de travail du moteur « GetNextWorkItem » en raison de l’exception suivante

Nom du journal : Operations Manager
Source : Configuration de la gestion d’OpsMgr
ID d’événement : 29181
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Échec du service de configuration de gestion OpsMgr pour exécuter l’élément de travail du moteur « LocalHealthServiceDirtyNotification » en raison de l’exception suivante

Nom du journal : Operations Manager
Source : Configuration de la gestion d’OpsMgr
ID d’événement 21024 :
Catégorie de tâche : None
Niveau : Information
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
La configuration d’OpsMgr peut être obsolète pour groupName> du groupe <d’administration et a demandé la configuration mise à jour à partir du service de configuration. Le cookie d’état actuel (obsolète) est « 5dae4442500c9d3f8f7a83e8383851994 906af60d48ed417fb1860b23ed67dd71:001662A3 »

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
ID d’événement : 29181
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le service de configuration de gestion OpsMgr n’a pas pu exécuter l’élément de travail du moteur DeltaSynchronization en raison de l’exception suivante

Ces événements peuvent se produire lorsque le processus de synchronisation delta ne peut pas générer la configuration dans sa fenêtre de délai d’expiration configurée de 30 secondes. Cela peut se produire lorsqu’il existe un espace d’instance volumineux.

Pour résoudre ce problème, augmentez le délai d’expiration sur tous les serveurs d’administration. Pour ce faire, utilisez l’une des méthodes suivantes :

Méthode 1

  1. Effectuez une copie de sauvegarde du fichier suivant :

    Lecteur :\Program Files\System Center 2012\Operations Manager\Server\ConfigService.Config

  2. Augmentez les valeurs de délai d’expiration avec ConfigService.config les modifications suivantes :

    Recherchez , remplacez <OperationTimeout DefaultTimeoutSeconds="30">30 par 300.
    Recherchez , remplacez <Operation Name="GetEntityChangeDeltaList" TimeoutSeconds="180" />180 par 300.

  3. Redémarrez le service de configuration.

Dans la plupart des cas, cela doit laisser suffisamment de temps pour que le processus de synchronisation se termine.

Méthode 2

  1. Installez le correctif cumulatif 3 ou version ultérieure pour System Center 2012 R2 Operations Manager.

  2. Ajoutez la valeur de Registre suivante sur le serveur exécutant System Center 2012 R2 Operations Manager pour configurer le délai d’expiration :

    • Sous-clé de Registre : HKEY_LOCAL_MACHINE\Software\Microsoft Operations Manager\3.0\Config Service
    • Nom DWORD : CommandTimeoutSeconds
    • Valeur DWORD : nn

    Note

    La valeur par défaut de l’espace réservé nn est de 30 secondes. Vous pouvez modifier cette valeur pour contrôler le délai d’expiration de la synchronisation delta.

Autres ID d’événement de connecteur OpsMgr

D’autres événements d’erreur du connecteur OpsMgr et les suggestions de résolution des problèmes correspondantes sont répertoriées ci-dessous :

Événement Description Informations complémentaires
20050 Le certificat spécifié n’a pas pu être chargé, car l’utilisation améliorée de la clé spécifiée ne répond pas aux exigences d’OpsMgr. Le certificat doit avoir les types d’utilisation suivants : %n %n Authentification du serveur (1.3.6.1.5.5.7.3.1)%n Authentification du client (1.3.6.1.5.5.7.3.2)%n Confirmez l’identificateur d’objet sur le certificat.
20057 Échec de l’initialisation du contexte de sécurité pour la cible %1 L’erreur retournée est %2(%3). Cette erreur peut s’appliquer au package Kerberos ou au package SChannel. Vérifiez les noms de principal dupliqués ou incorrects.
20066 Un certificat à utiliser avec l’authentification mutuelle a été spécifié. Toutefois, ce certificat n’a pas pu être trouvé. La possibilité pour ce service d’intégrité de communiquer sera probablement affectée. Vérifiez le certificat.
20068 Le certificat spécifié dans le Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings ne peut pas être utilisé pour l’authentification, car le certificat ne contient pas de clé privée utilisable ou parce que la clé privée n’est pas présente. L’erreur est %1(%2). Recherchez une clé privée manquante ou non associée. Examinez le certificat. Réimportez le certificat ou créez un certificat et importez-le.
20069 Impossible de charger le certificat spécifié, car keySpec doit être AT_KEYEXCHANGE Vérifiez le certificat. Vérifiez l’identificateur d’objet sur le certificat.
20070 Connecteur OpsMgr connecté à %1. Toutefois, la connexion a été fermée immédiatement après l’authentification. La cause la plus probable de cette erreur est que l’agent n’est pas autorisé à communiquer avec le serveur ou que le serveur n’a pas reçu de configuration. Consultez le journal des événements sur le serveur pour connaître la présence d’événements 20000. Ceux-ci indiquent que les agents qui ne sont pas approuvés tentent de se connecter. L’authentification s’est produite, mais la connexion a été fermée. Vérifiez que les ports sont ouverts et vérifiez l’approbation de l’agent en attente.
20071 Connecteur OpsMgr connecté à %1. Toutefois, la connexion a été fermée immédiatement sans authentification. La cause la plus probable de cette erreur est l’échec de l’authentification de cet agent ou du serveur. Vérifiez le journal des événements sur le serveur et sur l’agent pour les événements qui indiquent un échec de l’authentification. L’authentification a échoué. Vérifiez les pare-feu et le port 5723. L’ordinateur de l’agent doit être en mesure d’atteindre le port 5723 sur le serveur d’administration. Vérifiez également que le port TCP &UDP 389 pour LDAP, le port 88 pour Kerberos et le port 53 pour DNS sont disponibles.
20072 Le certificat distant %1 n’a pas été approuvé. L’erreur est %2(%3). Vérifiez si le certificat se trouve dans le magasin approuvé.
20077 Le certificat spécifié dans le Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings ne peut pas être utilisé pour l’authentification, car le certificat ne peut pas être interrogé pour les informations de propriété. L’erreur spécifique est %2(%3).%n %n. Cela signifie généralement qu’aucune clé privée n’a été incluse dans le certificat. Vérifiez deux fois que le certificat contient une clé privée. Il existe une clé privée manquante ou non associée. Examinez le certificat. Réimportez le certificat ou créez un certificat et importez-le.
21001 Le connecteur OpsMgr n’a pas pu se connecter à %1, car l’authentification mutuelle a échoué. Vérifiez que le SPN est inscrit correctement sur le serveur et que, si le serveur se trouve dans un domaine distinct, il existe une relation d’approbation totale entre les deux domaines. Vérifiez l’inscription du spn.
21005 Le connecteur OpsMgr n’a pas pu résoudre l’adresse IP pour %1. Le code d’erreur est %2(%3). Vérifiez que DNS fonctionne correctement dans votre environnement. Il s’agit généralement d’un problème de résolution de noms. Vérifiez DNS.
21006 Le connecteur OpsMgr n’a pas pu se connecter à %1 :%2. Le code d’erreur est %3(%4). Vérifiez qu’il existe une connectivité réseau, que le serveur est en cours d’exécution et a inscrit son port d’écoute et qu’il n’existe aucun pare-feu bloquant le trafic vers la destination. Il s’agit probablement d’un problème de connectivité général. Vérifiez les pare-feu et vérifiez que le port 5723 est ouvert.
21007 Le connecteur OpsMgr ne peut pas créer une connexion mutuellement authentifiée à %1, car il n’est pas dans un domaine approuvé. Une approbation n’est pas établie. Vérifiez que le certificat est en place et est configuré correctement.
21016 OpsMgr n’a pas pu configurer un canal de communication vers %1 et aucun hôte de basculement n’est présent. La communication reprend lorsque %1 est disponible et que la communication à partir de cet ordinateur est activée. Cela indique généralement un échec d’authentification. Vérifiez que l’agent a été approuvé pour la surveillance et que tous les ports sont ouverts.
21021 Aucun certificat n’a pu être chargé ou créé. Ce service d’intégrité ne pourra pas communiquer avec d’autres services d’intégrité. Recherchez les événements précédents dans le journal des événements pour plus de détails. Vérifiez le certificat.
21022 Aucun certificat n’a été spécifié. Ce service d’intégrité ne pourra pas communiquer avec d’autres services d’intégrité, sauf si ces services d’intégrité se trouvent dans un domaine qui a une relation d’approbation avec ce domaine. Si ce service d’intégrité doit communiquer avec les services d’intégrité dans des domaines non approuvés, configurez un certificat. Vérifiez le certificat.
21035 L’inscription d’un SPN pour cet ordinateur avec la classe de service « %1 » a échoué avec l’erreur « %2 ». Cela peut entraîner l’échec de l’authentification Kerberos vers ou depuis ce service d’intégrité. Cela indique un problème lié à l’inscription spN. Examinez les SPN pour l’authentification Kerberos.
21036 Le certificat spécifié dans le Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings ne peut pas être utilisé pour l’authentification. L’erreur est %1(%2). Il s’agit généralement d’une clé privée manquante ou non associée. Examinez le certificat. Réimportez le certificat ou créez-le et importez-le.