Dans ePO, il se peut que vous ayez plusieurs entrées pour un système donné dans l’arborescence des systèmes ePO. Ces entrées sont généralement connues sous le nom de systèmes en double . Cet article décrit les différents types de systèmes dupliqués, la manière dont ils sont créés dans l’arborescence des systèmes et comment résoudre le problème.


Managé et non managé (premier type)
Lorsque vous traitez des systèmes en double dans ePO, la première question à poser est la suivante : toutes les entrées en double sont-elles affichées comme managées ou certaines d’entre elles s’affichent-elles comme non managées ?

• Managé
  Un système s’affiche uniquement comme géré dans ePO, s’il dispose d’un agent installé et qu’il a communiqué au moins une fois avec ePO.
  
• Non managé
  Ces systèmes sont des entrées créées dans l’arborescence des systèmes via une autre méthode. Par exemple, par une tâche de synchronisation Active Directory, ou ajoutée manuellement par l’intermédiaire de la fonctionnalité nouveaux systèmes.
  Lorsqu’un système communique avec ePO pour la première fois, ePO tente de l’associer à une entrée non managée existante dans l’arborescence. Lorsqu’une entrée non managée existe, mais qu’ePO ne parvenait pas à la mettre en correspondance, elle crée une nouvelle entrée dans l’arborescence des systèmes. Vous disposez à présent d’un système dupliqué avec deux entrées, dont l’une n’est pas gérée.

Plusieurs lignes pour une seule entrée de l’arborescence des systèmes (deuxième type)
Le second type de système dupliqué n’est pas strictement identique à un doublon. Il s’agit d’un scénario dans lequel l’arborescence des systèmes affiche plusieurs lignes pour le même système, même s’il n’y a qu’un seul système réel dans ePO.

Les symptômes de ce scénario sont les suivants :

• Le GUID de l'agent et les colonnes date/heure de la dernière communication pour toutes les entrées sont identiques.
• Si vous cochez la case correspondant à l’un des systèmes, les autres systèmes sont également automatiquement sélectionnés.

Ce problème survient lorsqu’ePO pense qu’un système est équipé de plusieurs versions du même produit ou d’une même famille de produits. Dans l’arborescence des systèmes, une colonne est présente pour indiquer les versions de produits installées :



Dans le cas ci-dessus, ePO pense que le système possède à la fois VirusScan Enterprise 8.8.0.2232 et 8.8.0.2233 installé, ce qui est impossible. Vous pouvez contourner ce problème en supprimant la colonne correspondante de la vue arborescence des systèmes. Dans le cas, la colonne'version du produit (VirusScan Enterprise)'.
REMARQUE : L’exemple ci-dessus n’est qu’un correctif cosmétique et ne résout pas le problème sous-jacent : pour résoudre correctement la cause initiale, reportez-vous à la section KB93129-Duplicated Products-duplicate Entries, qui s’affiche pour un seul système. Nouvelles entrées dans l'


arborescence des systèmes créées lorsqu’elles ne doivent pas être (troisième type)
Le troisième type de système dupliqué est le plus complexe à diagnostiquer. Ce problème survient lorsqu’un système managé possède déjà une entrée dans l’arborescence des systèmes. Qui communique ensuite avec ePO, au lieu de mettre à jour l’entrée existante. Dans ce cas, ePO pense qu’il s’agit d’un nouveau système et crée une entrée pour celui-ci.

Les symptômes de cadeaux pour ce scénario sont les suivants :

• Le GUID de l'agent et l’heure de la dernière communication sont différents pour chaque entrée.
• Si vous cochez la case correspondant à l’un des systèmes, les autres systèmes ne sont pas automatiquement sélectionnés.
• Seule l’une des entrées est active. Par exemple, lorsque le système client communique, l’heure de la dernière communication est uniquement mise à jour sur l’un des systèmes en double.

Un exemple de ce scénario peut se présenter comme suit :



Remarque : L’image ci-dessus montre la dernière communication, et Agent valeurs GUID, sont toutes différentes.

Pour résoudre correctement les problèmes liés aux systèmes en double dans ce cas, vous devez comprendre la manière dont ePO décide le moment où il doit créer une nouvelle entrée pour un système.

Chaque fois qu’un système communique avec ePO, ePO dispose de deux actions :

• Le système est déjà connu d’ePO. Dans ce cas, ePO doit mettre à jour ses propriétés et voir s’il existe de nouvelles stratégies ou tâches.
  
• Le système n’est pas connu d’ePO. Dans ce cas, ePO doit créer une nouvelle entrée pour celui-ci dans l’arborescence des systèmes.

ePO pose plusieurs questions pour déterminer si le système est connu :

• La première question est "est-ce que le système est un client en mode VDI ? "
  • Si la réponse est oui, ePO traite le système différemment. Cette section est traitée en détail plus loin dans cet article.
    
• Si le système n’est pas un client VDI, la question la plus importante suivante est "le GUID agent est-il déjà dans la base de données ? "
  • Si le GUID se trouve dans la base de données, le système est déjà connu d’EPO et respecte la mesure d’action'mettre à jour les propriétés'.
  • Si le GUID n’est pas dans la base de données, il s’agit peut-être d’un nouveau système. par conséquent, EPO commence à suivre le chemin d’accès' create a new entry '.

Un système peut modifier son GUID. Les causes les plus courantes sont les suivantes :

• La agent est désinstallée et réinstallée, ou réinstallée avec l’option /forceinstall de commande.
• Le système a été reconstruit à partir d’une image.
• Le système a subi une modification du matériel. Par exemple, le disque dur a été prélevé sur un ordinateur portable et placé dans un autre châssis. Cette action risque SMBiosUUID d’être différente lors du prochain démarrage de la agent. Par conséquent, le agent crée un nouveau GUID Agent.

Si ePO vérifiait uniquement que le GUID était connu, chaque fois qu’un système obtenait un nouveau GUID légitime, ePO créerait une nouvelle entrée pour celui-ci.
REMARQUE : Ce fait est la manière dont les versions antérieures d’ePO sont utilisées. Dans les environnements où les systèmes étaient fréquemment reconstruits, ce comportement entraînait la création de nombres inacceptables d’entrées en double. Par conséquent, le comportement d’ePO a été modifié.

Une autre vérification a été ajoutée en tant que première étape dans le create a new entry' chemin d’accès. Lorsqu’un système communique avec ePO, le premier message que celui-ci envoie contient (entre autres) :

• GUID de l'agent.
• Adresse MAC détectés par l'agent.

Si ePO ne connaît pas le GUID Agent, il cherche à vérifier s’il existe une entrée dans la base de données avec le même adresse MAC. Si la réponse est oui, ePO suppose qu’il s’agit d’un système qui a déjà communiqué avec ePO et qui a modifié son GUID Agent. Il revient donc au chemin des Propriétés de mise à jour et met à jour l’entrée existante avec le même adresse Mac avec le nouveau GUID agent.

Le point ci-dessus est important. La vérification de la adresse MAC recherche uniquement si les adresse MAC spécifiques signalés par le client existent ailleurs dans la base de données. ePO ne stocke qu’un adresse MAC pour un système donné et le met à jour à chaque fois que le système communique. La adresse MAC stockée par ePO est l’adresse signalée par le client lors de sa dernière communication.

Dans certains scénarios, plusieurs systèmes peuvent avoir le même adresse MAC. Partagés exemples sont les suivants :

• Systèmes se connectant via un concentrateur de réseau privé virtuel (VPN)
• Systèmes présentant une adresse MAC virtuelle, tels que les clusters de serveurs, avec des cartes d’interface réseau (NIC) en équipe.

Dans le scénario ci-dessus, la vérification supplémentaire des adresse MAC est à l’origine de problèmes. En particulier, l’inverse exact des systèmes en double. Au lieu de cela, vous vous retrouvez avec une seule entrée dans ePO, qui est continuellement mis à jour avec les détails du dernier système à communiquer. Qui rend les systèmes apparemment visibles et disparaissent de l’arborescence. Pour résoudre ce problème, vous pouvez ignorer le adresse MAC et effectuer une vérification de plusieurs façons.

• Tout d’abord, vous pouvez désactiver temporairement la vérification MAC globalement dans ePO, en définissant une clé de Registre et en redémarrant les services ePO. Cette méthode est le plus souvent utilisée dans le scénario de carte d’interface réseau (NIC) en équipe. La vérification de la adresse MAC est désactivée et les deux nœuds du cluster NIC en équipe sont autorisés à communiquer avec ePO. Etant donné qu’ils ont des GUID différents, chaque nœud comporte une entrée créée dans l’arborescence des systèmes. La vérification de la adresse MAC est alors réactivée de sorte que les autres systèmes qui modifient le GUID ne créent pas d’entrées en double.
  Pour désactiver la vérification de la adresse MAC, voir KB57886-impossible de voir les deux nœuds d’un cluster dans le répertoire ePolicy Orchestrator lorsqu’ils partagent un adresse macOS.
  
• Pour les systèmes se connectant via un réseau privé virtuel (VPN), vous pouvez configurer ePO pour qu’il ignore de manière sélective la vérification MAC en fonction de l’identificateur unique de l’organisation (OUI).
  REMARQUE : La OUI est la première des six caractères de la adresse MAC, qui permet d’identifier le fournisseur de l’équipement réseau.
  
  Vous pouvez ajouter plusieurs Oui à ePO, lorsqu’un système dont le GUID est inconnu communique avec ePO, le OUI du système est comparé à la liste de la base de données. Si une concordance est trouvée, ePO ignore la vérification MAC et crée une nouvelle entrée pour le système. Pour plus d’informations, reportez-vous au fournisseur Add Virtual macOS du Guide produit d’ePO.

Supposons que la vérification de la adresse MAC n’a pas été désactivée. Que le OUI du système ne figure pas dans la liste connue d’ePO. Si la réponse à la vérification de adresse MAC est non, ePO décide que l’ordinateur est un nouveau système et se termine par le chemin d’accès' create a new entry '. Si le système comporte effectivement une entrée dans l’arborescence des systèmes, il s’agit du point auquel la copie est créée.

Voici un exemple d’affichage de la situation ci-dessus :

• Imaginez qu’un agent est installé sur votre ordinateur portable. Le agent communique avec ePO sans aucun problème.
• Il possède un GUID agent de 1111111111.
• Il est connecté au réseau via Wi-Fi, avec un adresse MAC de 11:11:11:11:11:11. A ce stade, dans la base de données ePO, le GUID de ce système est 1111111111. Etant donné qu’il utilisait la carte d’interface réseau sans fil ePO pour la dernière fois, il enregistrait le adresse MAC pour ce système en tant que 11:11:11:11:11:11.
• Il subit soudainement un blocage du logiciel fatal et votre service informatique doit le redéfinir.
• L’ingénieur informatique connecte l’ordinateur portable au réseau à l’aide de la carte d’interface réseau filaire de l’ordinateur portable. La carte d’interface réseau (NIC) a un adresse MAC de 22:22:22:22:22:22. L’ingénieur réinstalle le système d’exploitation et agent.
• La première fois que la agent démarre, puisqu’il s’agit d’une nouvelle installation, elle génère un nouveau GUID agent de 2222222222 et communique avec ePO.
• ePO recherche d’abord une entrée avec le GUID 2222222222 dans la base de données. Il n’en trouve pas, il continue ainsi jusqu’à la vérification MAC.
• ePO recherche ensuite dans la base de données une entrée avec un adresse MAC de 22:22:22:22:22:22. Il n’en trouve pas non plus. par conséquent, ePO crée une nouvelle entrée avec le GUID 2222222222 et adresse MAC 22:22:22:22:22:22. Nous avons maintenant une entrée en double. Deux entrées pour le même système, une seule d’entre elles est active.

REMARQUE : Si le technicien informatique s’est connecté au réseau à l’aide de Wi-Fi, aucune entrée dupliquée n’était créée. La première vérification du GUID échouait, car le nouveau GUID n’existe pas dans la base de données. Toutefois, la vérification de la adresse MAC réussit. Par conséquent, ePO accède au chemin des Propriétés de mise à jour et met à jour l’entrée existante avec le nouveau GUID.
Vous trouverez ci-dessus le point important à noter. Pour qu’un doublon soit créé, le système n’a pas besoin de signaler un nouveau adresse MAC. Il s’agit d’un autre nom de la dernière fois qu’il a communiqué avec ePO.

Cas spécial avec les clients en mode VDI
Pour les environnements VDI non persistants, le agent peut fonctionner dans un mode spécial appelé mode VDI. Ce mode permet à ePO de s’assurer que le client VDI utilise toujours le même GUID. Qui permet à ePO de localiser le client spécifique en passant par le cycle de déconfiguration et de configuration.

Pour plus d’informations sur le mode VDI, voir la section KB87654-McAfee Agent configuration et déploiement sur les systèmes d’infrastructure de postes de travail virtuels.

Synthétique

• Lorsqu’un client VDI s’arrête, le agent envoie un message spécifique à ePO.
• ePO marque alors ce système comme étant mis en service dans la base de données.
• Lorsque les agents en mode VDI communiquent avec ePO, ils informent ePO qu’ils sont en mode VDI au début de la communication.
• ePO vérifie s’il existe une entrée dans la base de données qui possède le même nom de domaine complet. ePO le marque ensuite comme étant mis en service.
• S’il n’en trouve pas, ePO crée une nouvelle entrée pour le système.
• ePO ne recherche pas si le GUID ou le adresse MAC existe. Dans un environnement VDI non persistant, ces deux éléments ne sont pas pertinents.

Ce qui ci-dessus veut dire que dans un environnement VDI :

• Tout ce qui empêche ePO de recevoir le message de déconfiguration, lors de la prochaine mise en service de ce client, ePO crée une entrée en double.
• La cause la plus fréquente est si le client VDI n’est pas correctement arrêté. Par exemple, si elle se bloque ou si l’hôte force l’arrêt du système.

Le diagramme ci-dessous montre l’arborescence de décision qu’ePO suit chaque fois qu’un système communique avec celui-ci :



Résolution des problèmes
Nous sommes désormais conscients de la manière dont ePO décide à quel moment créer une nouvelle entrée. Nous pouvons maintenant résoudre les problèmes de création.

Comme nous le savons, pour qu’ePO décide de créer une nouvelle entrée, il ne doit pas connaître le GUID. La première question est donc, "pourquoi le GUID du client a-t-il été modifié ?"

Voici les façons les plus courantes pour un client de créer un nouveau GUID :

• Agent a été désinstallé et réinstallé.
• Agent a été mis à niveau à l’aide du /forceinstall commutateur ou déployé à partir d’EPO avec l' Force installation over existing version option sélectionnée.
• Agent a détecté un nouveau SMBiosUUID , indiquant une modification du matériel. Par exemple, le disque dur a été déplacé d’un ordinateur portable à un autre.
• Echec de la vérification de l’intégrité de la Agent. Ce qui provoquait la régénération de ses fichiers de base de données et la création d’un nouveau GUID Agent.

La première question de dépannage est "est-ce la modification du GUID est-elle attendue ? ".
Exemple : nous savons qu’un nouveau GUID est créé lorsqu’un de ces éléments :

• Le système a été reconstruit.
  Ou
• La agent a été désinstallée et réinstallée.

Si le nouveau GUID n’était pas attendu, la première étape consiste à rechercher la raison de sa modification.

• Consultez les journaux d’installation de l'agent ( frminst.log ).
  • La agent a-t-elle été installée récemment avec l' /forceinstall option ?
  • Si tel est le cas, McAfee ne recommande pas l’utilisation générale de cette option. Elle ne doit être utilisée que dans certaines circonstances. Par exemple, si vous essayez de mettre à niveau le agent vers un nouvel emplacement avec le /instdir commutateur.
• Recherchez dans le mascvc log fichier.
  • Recherchez les preuves de la modification du GUID.
  • Par exemple, en cas d’échec de MA healthcheck . Vous voyez un message d’erreur indiquant que maconfig.Error: MA databases integrity check failed .

L’étape de dépannage suivante permet d’identifier la raison pour laquelle ePO n’est pas en mesure de faire correspondre les adresse MAC à l’entrée précédente.

La première chose à faire est de s’assurer qu’ePO n’est pas configuré pour ignorer la vérification MAC :

1. Assurez-vous que le agent n’a pas été installé en mode VDI par erreur.
2. Affichez les propriétés du système du système dans ePO. Examinez le bas de la liste des propriétés, c’est-à-dire l’emplacement où se trouve la propriété VDI. Elle doit être définie sur Oui si le agent a été installé en mode VDI.
3. Si le agent n’est pas censé être en mode VDI, désinstallez-le, puis réinstallez-le sans utiliser le /EnableVDIMode commutateur.
4. Assurez-vous que la recherche MAC n’a pas été désactivée de manière globale. Voir KB57886-impossible de voir les deux nœuds d’un cluster dans le répertoire ePolicy Orchestrator lorsqu’ils partagent un adresse macOS.
   Remarque : Le paramètre ci-dessus s’applique pour chaque gestionnaire d'agents. Ainsi, si vous avez plusieurs gestionnaires d’Agent, vérifiez-les tous et assurez-vous que la recherche MAC n’est pas désactivée.
5. Si le système ne se connecte pas via un réseau privé virtuel (VPN), vérifiez que le OUI de la adresse MAC du agent est ajouté à la liste des fournisseurs de MAC virtuels d’ePO par erreur. Si tel est le cas, supprimez les OUI pertinents.

En supposant qu’aucune des informations ci-dessus n’est vraie, les adresse MAC fournies par le système client sont introuvables dans la base de données ePO. Ce qui provoque la création d’une nouvelle entrée par ePO.

1. Examinez le journal des audit ePO, puis entrez le nom du système client dans le filtre recherche rapide. Un ASCI - New System événement s’affiche lors de la création de l’entrée par ePO. Les détails de l’événement affiché sont les adresse MAC que le client a signalés.
2. Comparez les détails avec le adresse MAC dans les propriétés du système pour l’entrée en double la plus récente. Cette entrée est la adresse MAC utilisée par le système avant la création du doublon.
   
   Ce qui précède peut vous expliquer pourquoi ePO n’est pas parvenu à établir la correspondance avec le adresse MAC. Par exemple, l’entrée précédente peut avoir le adresse MAC pour la carte sans fil, et l’entrée de journal audit contient l’adresse de l’adaptateur de station d’accueil.

Synthèse

• Pour conclure, la cause la plus fréquente d’entrées en double dans ePO est la création inutile d’un nouveau GUID sur les systèmes clients.
• La cause la plus fréquente de ce problème est, par exemple, de réinstaller le agent à l’aide du /forceinstall commutateur. Apparaît dans le cadre d’une tâche serveur planifiée ou script de connexion.
• La clé de compréhension de l’origine des entrées en double est d’abord de découvrir pourquoi le GUID est modifié. Lorsque vous savez pourquoi, l’identification de la source du problème est grandement simplifiée.

IMPORTANT :

• Le commutateur McAfee Agent /ForceInstall ne doit pas être utilisé sauf s’il est indiqué dans un article de la base de connaissances (KB) pour résoudre un problème.
• L’utilisation du commutateur /ForceInstall comme processus habituel peut provoquer des problèmes avec le McAfee Agent, ce qui conduit à des entrées en double dans l’arborescence des systèmes ePolicy Orchestrator. Les systèmes peuvent ainsi obtenir une affectation de stratégie incorrecte.

Le cas d’utilisation standard, tel que mentionné dans le Guide produit de McAfee Agent, consiste à utiliser le commutateur /ForceInstall uniquement pour l’une des options suivantes :

• Modification du répertoire
  d’installation Or
• Rétrograder la McAfee Agent