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

  • Article

Ce guide vous aide à résoudre les problèmes de connexion des agents Operations Manager 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 sur la façon dont ils communiquent avec les serveurs d’administration, consultez Agents et communication entre les agents et les serveurs d’administration.

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

Vérifier le service 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 erreur 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 .

    Remarque

    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 Démarré est affiché dans service status. Dans le cas contraire, cliquez sur Démarrer.

Vérifier les exclusions antivirus

Si le service d’intégrité est opérationnel, l’étape suivante consiste à vérifier que les exclusions antivirus sont correctement configurées. Pour obtenir les dernières informations sur les exclusions antivirus recommandées pour Operations Manager, consultez Recommandations pour les exclusions d’antivirus liées à Operations Manager).

Vérifier les problèmes réseau

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

En plus du 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 dns (Domain Name Service)

En outre, vous devez vous assurer que les communications RPC s’effectuent 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 à la suivante :

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 des 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 à plage élevée non standard ont été configurés, une trace réseau indique une connexion réussie au port RPC 135 suivie d’une tentative de connexion à l’aide d’un port RPC non standard tel que 15595. Voici un 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 TCP :[SynReTransmit #18748] Flags=CE.... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0,
18751 MS Agent TCP 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 les versions ultérieures, les ports haute plage RPC 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 RPC élevée est configurée :

netsh int ipv4 show dynamicportrange tcp

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

Plage de ports dynamiques tcp de protocole
---------------------------------
Port de début : 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 à nouveau les valeurs par défaut des ports à plage élevée :

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 Guide pratique pour configurer l’allocation de ports dynamiques RPC pour utiliser 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 àPropriétés du>poste de travail>Protocoles par défaut, vérifiez qu’il n’existe aucun paramètre personnalisé.

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

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

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

Remarque

La résolution des problèmes réseau étant un problème extrêmement important, il est préférable de consulter un ingénieur réseau si vous pensez qu’un problème réseau sous-jacent est à l’origine de problèmes de connectivité de votre agent dans Operations Manager. Nous avons également des informations de base et généralisées sur la résolution des problèmes de réseau disponibles auprès de notre équipe de support technique des services d’annuaire Windows, disponibles dans Résolution des problèmes de réseaux 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 des 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 doivent être utilisés pour répondre à 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. En outre, 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 gérés dans les règles de pare-feu pour permettre la communication entre eux.

Pour réduire la surcharge administrative, Operations Manager dispose d’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 ensuite uniquement avec les serveurs de passerelle dont il a connaissance.

Les serveurs de passerelle communiquent ensuite avec les serveurs d’administration au nom 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 la passerelle et les serveurs d’administration. Cela réduit le nombre de certificats requis. Dans le cas d’un pare-feu intervenant, 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 à retenir 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 à case activée :

  • Vérifiez que le certificat de passerelle existe dansOrdinateurlocal>Certificats personnels> sur le serveur d’administration auquel la passerelle ou l’agent se connecte.

  • Vérifiez que le certificat racine existe dans Ordinateur> local Certificatsdes autorités> de certification racines approuvéessur le serveur d’administration auquel la passerelle ou l’agent se connecte.

  • Vérifiez que le certificat racine existe dans Ordinateur> localCertificats des autorités> de certification racines approuvéessur le serveur de passerelle.

  • Vérifiez que le certificat de passerelle existe dans l’ordinateur> localCertificats personnels> sur le serveur de passerelle. Vérifiez que le certificat de passerelle existe dans Lescertificats OperationsManager> de l’ordinateur >localsur 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 que la valeur du certificat (à partir du dossier Ordinateur local/Personnel/Certificats dans les détails du champ Numéro de série ) est inversée 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 que la valeur du certificat (à partir du dossier Ordinateur local/Personnel/Certificats dans les détails du champ Numéro de série ) est 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énements suivants dans le journal des événements Operations Manager en cas de problème avec les certificats :

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

Pour plus d’informations sur le fonctionnement de l’authentification basée sur les certificats dans Operations Manager, ainsi que pour obtenir et configurer les 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 a un espace de noms disjoint, l’authentification Kerberos peut échouer. Bien qu’il s’agisse d’un problème Active Directory et non d’Operations Manager, il affecte la connectivité de l’agent.

Pour plus d’informations, consultez Disjoint Namespace.

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 (SPN) appropriés pour les comptes d’ordinateur affectés et incluez le SPN hôte pour le nom de domaine complet (FQDN) avec 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 affecté 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 à votre environnement. Pour plus d’informations, consultez Transition d’un espace de noms disjoint à 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 Correctif cumulatif 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.

Remarque

Ce problème peut également se produire en cas de problèmes de synchronisation de l’heure entre l’agent client et le serveur d’administration.

Rechercher les problèmes liés au connecteur OpsMgr

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

Les ID d’événement 21006 et 21016 apparaissent sur l’agent client

Exemples de ces événements :

Source : Connecteur OpsMgr
Date : Heure
ID d’événement : 21006
Catégorie de la tâche : Aucun
Niveau : Erreur
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 le tiers connecté n’a pas répondu correctement après un certain temps, 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 qu’il a inscrit son port d’écoute, et qu’aucun pare-feu ne bloque le trafic vers la destination.

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
Date : Heure
ID d’événement : 21016
Catégorie de la tâche : Aucun
Niveau : Erreur
Mots clés : classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description : OpsMgr n’a pas pu configurer un canal de communication vers <ManagementServer> et il n’y a pas d’hôtes de basculement. 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 la configuration. Après l’ajout d’un nouvel agent 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 une fois la communication établie.

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

  1. Si l’approbation automatique des 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, assurez-vous 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 provoquer 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 s’affiche 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 la tâche : Aucun
Niveau : Erreur
Mots clés : classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :Échec de l’initialisation du contexte de sécurité pour le 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, case activée les pare-feu entre l’agent client et le serveur d’administration. Les ports suivants doivent être ouverts pour permettre une authentification et une communication correctes :

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

Les ID d’événement 2010 et 2003 apparaissent 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 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 :
<Événement xmlns="http://schemas.microsoft.com/win/2004/08/events/event »>
<Système>
<Provider Name="HealthService » />
<EventID Qualifiers="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>
<Computer>ComputerName</Computer>
<Sécurité/>
</Système>
<EventData>
<Erreur non spécifiée/Données de< données>>
<0x80004005</Données de 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 d’intégrité
Niveau : Informations
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 pour s’exécuter.
Xml d’événement :
<Événement xmlns="http://schemas.microsoft.com/win/2004/08/events/event »>
<Système>
<Provider Name="HealthService » />
<EventID Qualifiers="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>
<Computer>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é avec l’ID d’événement 21016

Exemples de ces événements :

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
Date : 13/06/2014 10 :13 :39 PM
ID d’événement : 21016
Catégorie de la tâche : Aucun
Niveau : Erreur
Mots clés : classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
OpsMgr n’a pas pu configurer un canal de communication sur <ComputerName> et il n’y a pas d’hôtes de basculement. 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/06/2014 10 :13 :37 PM
ID d’événement : 20070
Catégorie de la tâche : Aucun
Niveau : Erreur
Mots clés : classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le connecteur OpsMgr s’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. Vérifiez la présence de 20 000 événements dans le journal des événements sur le serveur, indiquant que les agents qui ne sont pas 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, case activée 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 status en attente et ne sont pas visibles dans la console.

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

Get-SCOMPendingManagement

Si c’est le 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 les ID d’événement 29120, 29181 et 21024 apparaissent sur le serveur d’administration

Vous trouverez ci-dessous quelques exemples de ces événements.

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
ID d’événement : 21023
Catégorie de la tâche : Aucun
Niveau : Informations
Mots clés : classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
OpsMgr n’a aucune configuration pour le groupe <d’administration GroupName> et demande une nouvelle configuration au service de configuration.

Nom du journal : Operations Manager
Source : Configuration de la gestion OpsMgr
ID d’événement : 29120
Catégorie de la tâche : Aucun
Niveau : Avertissement
Mots clés : classique
Utilisateur : N/A
Ordinateur : <ComputerName>
Description :
Le service de configuration de gestion OpsMgr 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 OpsMgr
ID d’événement : 29181
Catégorie de la tâche : Aucun
Niveau : Erreur
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 OpsMgr
ID d’événement : 29181
Catégorie de la tâche : Aucun
Niveau : Erreur
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 « LocalHealthServiceDirtyNotification » en raison de l’exception suivante

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

Nom du journal : Operations Manager
Source : Connecteur OpsMgr
ID d’événement : 29181
Catégorie de la tâche : Aucun
Niveau : Erreur
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 y a un grand espace instance.

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 dans ConfigService.config avec 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 qui exécute 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

    Remarque

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

Autres ID d’événement du connecteur OpsMgr

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

Événement Description Plus d’informations
20050 Impossible de charger le certificat spécifié, 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. Recherchez les noms de principal du service dupliqués ou incorrects.
20066 Un certificat à utiliser avec l’authentification mutuelle a été spécifié. Toutefois, ce certificat est introuvable. La capacité de ce service d’intégrité à 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 nouveau 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 de l’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. Vérifiez la présence de 20 000 événements dans le journal des événements sur le serveur. Ils 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 case activée agent en attente d’approbation.
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 dans le journal des événements sur le serveur et sur l’agent 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 agent doit être en mesure d’atteindre le port 5723 sur le serveur d’administration. Vérifiez également que TCP & le port UDP 389 pour LDAP, le port 88 pour Kerberos et le port 53 pour DNS sont disponibles.
20072 Le certificat distant %1 n’était pas 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 obtenir des 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. Double-case activée pour vous assurer que le certificat contient une clé privée. Une clé privée est manquante ou non associée. Examinez le certificat. Réimportez le certificat ou créez un nouveau 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 de confiance 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 LE 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 qu’il a inscrit son port d’écoute, et qu’aucun pare-feu ne bloque 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 qu’il est correctement configuré.
21016 OpsMgr n’a pas pu configurer un canal de communication sur %1, et il n’y a pas d’hôtes de basculement. 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é. Pour plus d’informations, recherchez les événements précédents dans le journal des événements. 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 avec l’inscription du 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 un certificat et importez-le.