En ePO, es posible que tenga una situación en la que tenga varias entradas para un sistema determinado en el árbol de sistemas de ePO. Estas entradas suelen denominarse sistemas duplicados . En este artículo se describen los distintos tipos de sistemas duplicados, cómo se crean en el árbol de sistemas y cómo solucionar el problema.


Gestionado frente a no gestionado (primer tipo)
Cuando se trata de sistemas duplicados en ePO, la primera pregunta que se debe realizar es: ¿todas las entradas duplicadas se muestran como gestionados o se muestran como no gestionadas?

• Administración
  Un sistema solo aparece como gestionado en ePO, si tiene un agente instalado y se ha comunicado al menos una vez con ePO.
  
• No gestionado
  Estos sistemas son entradas creadas en el árbol de sistemas mediante otro método. Por ejemplo, si se trata de una tarea de sincronización de Active Directory, o bien se agrega de forma manual mediante la nueva función sistemas.
  Cuando un sistema se comunica con ePO por primera vez, ePO intenta hacerlo coincidiendo con una entrada no gestionada existente en el árbol. Cuando existe una entrada no gestionada, pero ePO no puede coincidir con ella, crea una nueva entrada en el árbol de sistemas. Ahora tiene un sistema duplicado con dos entradas, una de las cuales no está gestionada.

Varias filas para una única entrada del árbol de sistemas (tipo de segundo)
El segundo tipo de sistema duplicado no está estrictamente hablando de un duplicado. Es una situación en la que el árbol de sistemas muestra varias filas para el mismo sistema, aunque solo haya un sistema real en ePO.

Los síntomas para este escenario son:

• El GUID del agente y las últimas columnas de hora de comunicación de todas las entradas son iguales.
• Si selecciona la casilla de verificación de uno de los sistemas, también se seleccionarán automáticamente los demás sistemas.

Este problema se produce cuando ePO considera que un sistema tiene instaladas varias versiones del mismo producto o familia de productos. En el árbol de sistemas, hay una columna presente para mostrar qué versiones de producto están instaladas:



En el caso anterior, ePO considera que el sistema tiene tanto VirusScan Enterprise 8.8.0.2232 como 8.8.0.2233 instalado, lo cual es imposible. Para solucionar este problema, elimine la columna pertinente de la vista árbol de sistemas. En el caso, la columna "versión del producto (VirusScan Enterprise)".
NOTA: Lo anterior es solo una corrección cosmética y no soluciona el problema subyacente: para resolver la causa raíz correctamente, consulte KB93129-duplicar entradas de productos gestionados mostradas para un solo sistema.


Nuevas entradas del árbol de sistemas creadas cuando no deben ser (tercer tipo)
El tercer tipo de sistema duplicado es el más complejo de diagnosticar. Este problema se produce cuando un sistema gestionado ya tiene una entrada en el árbol de sistemas. Que se comunica a continuación con ePO, en lugar de actualizar la entrada existente. En esta situación, ePO considera que es un sistema nuevo y crea una entrada para él.

Los síntomas de regalo para este escenario son los siguientes:

• El GUID de Agent y la hora de la última comunicación son distintos para cada entrada.
• Si selecciona la casilla de verificación de uno de los sistemas, los demás sistemas no se seleccionan automáticamente.
• Solo se encuentra activa una de las entradas. Por ejemplo, cuando el sistema cliente se comunica, la última hora de comunicación solo se actualiza en uno de los sistemas duplicados.

Un ejemplo de este caso sería el siguiente:



Nota: La imagen anterior muestra la última comunicación y Agent valores de GUID distintos.

Para solucionar correctamente los duplicados de sistemas en este caso, debe comprender cómo determina ePO cuando necesita crear una nueva entrada para un sistema.

Cada vez que un sistema se comunica con ePO, ePO tiene dos cursos de acción:

• El sistema ya es conocido por ePO. En este caso, ePO necesita actualizar sus propiedades y ver si existen nuevas directivas o tareas.
  
• El sistema no conoce ePO. En este caso, ePO debe crear una nueva entrada para él en el árbol de sistemas.

ePO formula varias preguntas para determinar si el sistema es conocido:

• La primera pregunta es "¿este sistema es un cliente de modo VDI? "
  • Si la respuesta es afirmativa, ePO trata el sistema de forma distinta. Este tema se describe con más detalle más adelante en este artículo.
    
• Si el sistema no es un cliente de VDI, la siguiente pregunta más importante es "es el GUID de Agent ya existente en la base de datos . "
  • Si el GUID se encuentra en la base de datos, el sistema ya se conoce como ePO y sigue el procedimiento de acción "Actualizar propiedades".
  • Si el GUID no está en la base de datos, es posible que sea un sistema nuevo, por lo que ePO empieza a seguir la create a new entry ruta de acceso.

Es posible que un sistema cambie su GUID. Las causas más comunes son:

• El agente se desinstalará y reinstalará, o se reinstalará con la opción /forceinstall de comando.
• El sistema se ha reconstruido a partir de una imagen.
• El sistema tenía un cambio de hardware. Por ejemplo, la unidad de disco duro se tomó de un equipo portátil y se colocó en otro chasis. Esta acción podría provocar que la SMBiosUUID siguiente vez que se iniciara el agente. Como resultado, el agente crea un nuevo GUID de Agent.

Si ePO solo verificaba que se conocía el GUID, cada vez que un sistema tenía un GUID nuevo de forma legítima, ePO crearía una nueva entrada para él.
NOTA: Este hecho es la forma en que las versiones anteriores de ePO solían funcionar. En los entornos en los que los sistemas se reconstruyen con frecuencia, este comportamiento provocaba que se crearan números inaceptables de entradas duplicadas. Por lo tanto, se ha cambiado el comportamiento de ePO.

Se ha agregado otra comprobación como primer paso en la create a new entry' ruta de acceso. Cuando un sistema se comunica con ePO, el primer mensaje que envía contiene (entre otras cosas):

• El GUID de Agent.
• Dirección MAC detectados por el Agent.

Si ePO no conoce el GUID de Agent, comprueba si existe una entrada en la base de datos con el mismo dirección MAC. Si la respuesta es afirmativa, ePO supone que se trata de un sistema que ya se ha comunicado con ePO y que ha cambiado su Agent GUID. Por lo tanto, vuelve a la ruta de actualización de propiedades y actualiza la entrada existente con el mismo dirección Mac con el nuevo GUID de Agent.

Lo anterior es un punto importante. La comprobación de dirección MAC solo comprueba si la dirección MAC específica comunicada por el cliente existe en otra parte de la base de datos. ePO solo almacena una dirección MAC para un sistema determinado y la actualiza cada vez que se comunica el sistema. La dirección MAC almacenada por ePO es la dirección que informa el cliente la última vez que se comunicó.

Existen ciertos escenarios en los que varios sistemas pueden tener el mismo dirección MAC. Ajustes generales ejemplos son:

• Sistemas que se conectan a través de un concentrador de red privada virtual (VPN)
• Sistemas que presentan un dirección MAC virtual, como clústeres de servidor, con tarjetas de interfaz de red (NIC) en equipo.

En el caso anterior, la comprobación de dirección MAC adicional provoca problemas. En concreto, el opuesto exacto de los sistemas duplicados. En su lugar, acabará con una única entrada en ePO, que se actualiza continuamente con los detalles del último sistema que se debe comunicar. Lo que hace que parezca que los sistemas aparecen y que desaparezcan del árbol. Para solucionar este problema, puede omitir los dirección MAC y comprobarlo de varias formas.

• En primer lugar, puede desactivar temporalmente la comprobación de MAC en ePO, mediante la configuración de una clave de registro y el reinicio de los servicios de ePO. Este método se utiliza con más frecuencia en el escenario de NIC en equipo. La comprobación de dirección MAC está desactivada y ambos nodos del clúster de NIC en equipo tienen permiso para comunicarse con ePO. Dado que tienen distintos GUID, cada nodo tiene una entrada creada en el árbol de sistemas. A continuación, la comprobación de dirección MAC se vuelve a activar para que otros sistemas que cambien el GUID no creen entradas duplicadas.
  Para desactivar la comprobación de dirección MAC, consulte KB57886-no es posible ver ambos nodos de un clúster en el directorio de EPolicy Orchestrator cuando comparten un dirección Mac.
  
• En el caso de los sistemas que se conectan mediante VPN, puede configurar ePO para omitir de forma selectiva la comprobación de MAC basada en el identificador exclusivo de la organización (OUI).
  NOTA: El OUI es el puño seis caracteres del dirección MAC, que se utiliza para identificar el proveedor del dispositivo de red.
  
  Puede agregar varios OUI a ePO, cuando un sistema con un GUID desconocido se comunica con ePO, la OUI del sistema se compara con la lista de la base de datos. Si se encuentra una coincidencia, ePO omite la comprobación de MAC y crea una nueva entrada para el sistema. Para obtener más detalles, consulte la guía de adición de un proveedor de Mac virtual en ePO Product Guide.

Supongamos que la comprobación de dirección MAC no se ha desactivado. Que el OUI del sistema no se encuentra en la lista de ePO conocida. A continuación, si la respuesta a la comprobación de dirección MAC es no, ePO decide que el equipo es un sistema nuevo y completa la ruta de create a new entry acceso. Si el sistema tiene realmente una entrada en el árbol de sistemas, es el punto en el que se crea el duplicado.

Un ejemplo para mostrar la situación anterior:

• Imaginemos que tenemos un portátil con un agente instalado. El agente se está comunicando con ePO sin problemas.
• Tiene un GUID de agente de 1111111111.
• Está conectado a la red mediante Wi-Fi, con una dirección MAC de 11:11:11:11:11:11. En este punto, en la base de datos de ePO, este sistema tiene un GUID de 1111111111. Dado que la última vez que se comunicó, estaba utilizando la tarjeta de red inalámbrica ePO ha registrado el dirección MAC para este sistema como 11:11:11:11:11:11.
• Repentinamente, sufre un error grave de software y el Departamento de TI debe volver a crear la imagen.
• El ingeniero de ti conecta el portátil a la red mediante el NIC con cable del portátil. La tarjeta de red tiene un dirección MAC de 22:22:22:22:22:22. El ingeniero reinstala el sistema operativo y el agente.
• La primera vez que se inicia el agente, ya que es una nueva instalación de marca, genera un GUID de agente nuevo de 2222222222 y se comunica con ePO.
• ePO busca primero en la base de datos una entrada con el GUID 2222222222. No encuentra ninguno, por lo que continúa con la comprobación de MAC.
• a continuación, ePO busca en la base de datos una entrada con un dirección MAC de 22:22:22:22:22:22. Además, no encuentra ninguno, por lo que ePO crea una nueva entrada con GUID 2222222222 y dirección MAC 22:22:22:22:22:22. Ahora tenemos una entrada duplicada. Dos entradas para el mismo sistema, solo una de las cuales está activa.

NOTA: Si el ingeniero de ti estuviera conectado a la red mediante Wi-Fi, no se crearía una entrada duplicada. La primera comprobación de GUID fallará, ya que el nuevo GUID no existe en la base de datos. No obstante, la comprobación de dirección MAC se realizaría correctamente. Por tanto, ePO volverá a la ruta de actualización de propiedades y actualizará la entrada existente con el nuevo GUID.
Lo anterior es el punto importante que se debe tener en cuenta. Para que se cree un duplicado, el sistema no tiene que informar de un nuevo dirección MAC. Solo uno distinto a partir de la última vez que se comunicó con ePO.

Caso especial con clientes en modo VDI
En el caso de entornos VDI no persistentes, el agente puede funcionar en un modo especial conocido como modo VDI. Este modo permite que ePO se asegure de que el cliente VDI siempre utiliza el mismo GUID. Que permite a ePO rastrear el cliente específico a través del ciclo de deaprovisionamiento y aprovisionamiento.

Para obtener información sobre el modo de VDI, consulte KB87654-McAfee Agent aprovisionamiento y despliegue en sistemas de infraestructura de escritorio virtual.

Sumario

• Cuando se apaga un cliente de VDI, el agente envía un mensaje específico a ePO.
• a continuación, ePO etiqueta el sistema como desaprovisionado en la base de datos.
• Cuando los agentes en modo VDI se comunican con ePO, informan a ePO de que están en modo VDI al inicio de la comunicación.
• ePO Comprueba si existe una entrada en la base de datos que tenga el mismo nombre de dominio completo. a continuación, ePO lo etiqueta como desaprovisionado.
• Si no encuentra ninguno, ePO crea una nueva entrada para el sistema.
• ePO no comprueba si el GUID o dirección MAC existe. En un entorno de VDI no persistente, ambos no son relevantes.

El significado de lo anterior es que en un entorno VDI:

• Cualquier elemento que impida que ePO reciba el mensaje de desaprovisionamiento, la próxima vez que se aprovisione el cliente, ePO creará una entrada duplicada.
• La causa más común es que el cliente VDI no se cierre correctamente. Por ejemplo, si se bloquea o la host fuerza la cierre del sistema.

El siguiente diagrama de flujo muestra el árbol de decisiones que ePO sigue cada vez que un sistema se comunica con él:



Solución de problemas
Ahora sabemos cómo ePO decide cuándo crear una nueva entrada. Ahora podemos solucionar los motivos por los que se crean.

Como sabemos, para que ePO decida crear una nueva entrada, no debe conocer el GUID. Por lo tanto, la primera pregunta es "¿por qué ha cambiado el GUID del cliente?"

A continuación se indican las formas más comunes de que un cliente cree un nuevo GUID:

• Agent se ha desinstalado y reinstalado.
• Se ha ampliado Agent mediante el /forceinstall conmutador o se ha desplegado desde ePO con la Force installation over existing version opción seleccionada.
• Agent detectado un nuevo SMBiosUUID , lo que indica un cambio de hardware. Por ejemplo, el disco duro se ha movido de un portátil a otro.
• Error de comprobación de estado de Agent. Que provocaba que regenerara sus archivos de base de datos y crear un nuevo GUID de Agent.

La primera pregunta de solución de problemas es "¿se espera el cambio de GUID? ".
Por ejemplo: sabemos que se crea un nuevo GUID en los siguientes casos:

• El sistema se ha reconstruido.
  O
• El agente se ha desinstalado y reinstalado.

Si no se esperaba el nuevo GUID, el primer paso es investigar por qué ha cambiado.

• Busque en los registros de instalación del agente ( frminst.log ).
  • ¿Se ha instalado el agente recientemente con la /forceinstall opción?
  • Si es así, McAfee no recomienda el uso general de esta opción. Solo se debe utilizar en determinadas circunstancias. Por ejemplo, si está intentando ampliar el agente a una nueva ubicación con el /instdir conmutador.
• Busque en el mascvc log archivo.
  • Busque pruebas del GUID que cambie.
  • Por ejemplo, si el MA healthcheck fallara. Aparecerá un mensaje de error que indica maconfig.Error: MA databases integrity check failed .

El siguiente paso de solución de problemas es identificar por qué ePO no ha podido hacer coincidir la dirección MAC con la entrada anterior.

Lo primero que se debe hacer es asegurarse de que ePO no está configurado para omitir la comprobación de MAC:

1. Asegúrese de que el agente no se haya instalado en modo VDI por error.
2. Ver las propiedades del sistema del sistema en ePO. Observe la parte inferior de la lista de propiedades, donde se encuentra la propiedad VDI. Debe ser sí si el agente se ha instalado en modo VDI.
3. Si el agente no se debe estar en modo VDI, desinstálelo y vuelva a instalarlo sin utilizar el /EnableVDIMode conmutador.
4. Asegúrese de que la búsqueda de MAC no se haya desactivado globalmente. Consulte KB57886-no es posible ver ambos nodos de un clúster en el directorio de EPolicy Orchestrator cuando comparten un dirección Mac.
   Nota: La configuración anterior se aplica a cada controlador de agentes. Por lo tanto, si tiene varias Controladores de agentes, mire todas y asegúrese de que la búsqueda de MAC no esté desactivada.
5. Si el sistema no se conecta mediante VPN, verifique que la OUI del dirección MAC del agente se agregue a la lista de proveedores de MAC virtual de ePO por error. Si es así, elimine la OUI correspondiente.

Suponiendo que ninguna de las condiciones anteriores sea verdadera, el dirección MAC proporcionado por el sistema cliente no se pudo encontrar en la base de datos de ePO. Lo que hace que ePO cree una nueva entrada.

1. Examine el registro de auditoría de ePO e introduzca el nombre del sistema cliente en el filtro búsqueda rápida. Verá un ASCI - New System evento cuando ePO haya creado la entrada. Los detalles del evento que se ven son los dirección MAC que el cliente ha registrado.
2. Compare los detalles con el dirección MAC en las propiedades del sistema de la entrada duplicada más reciente. Esta entrada es la dirección MAC utilizada por el sistema antes de que se creara el duplicado.
   
   Lo anterior podría ayudar a explicar por qué ePO no coincidía con la dirección MAC. Por ejemplo, la entrada anterior puede tener el dirección MAC para el adaptador inalámbrico y la entrada del registro de auditoría tiene la dirección del adaptador de la estación de acoplamiento.

Resumen

• Para concluir, por lejos, la causa más común de entradas duplicadas en ePO es la creación innecesaria de un nuevo GUID en los sistemas cliente.
• A su vez, la causa más común de este problema son los elementos como la reinstalación del agente mediante el /forceinstall conmutador. Se muestra como parte de una tarea servidor planificada o script de inicio de sesión.
• La clave para comprender de dónde proceden las entradas duplicadas es en primer lugar descubrir por qué cambia el GUID. Cuando sabe por qué, la identificación del origen del problema se ha simplificado en gran medida.

IMPORTANTE:

• El conmutador McAfee Agent /forceinstall no se debe utilizar a menos que se indique en un artículo de KB para resolver un problema.
• El uso del conmutador /forceinstall como proceso normal puede provocar problemas con el McAfee Agent, lo que conduce a entradas duplicadas en el árbol de sistemas de ePolicy Orchestrator. Esto puede acarrear que los sistemas obtengan una asignación de directiva incorrecta.

El caso de uso estándar que se menciona en la guía del producto de McAfee Agent es utilizar el conmutador /forceinstall únicamente para:

• Cambiar el directorio
  de instalación Bien
• Retroceder la McAfee Agent