Este artículo proporciona información adicional sobre cómo funciona el canal de datos de ePO (CC). También proporciona algunos pasos de solución de problemas útiles que puede seguir para diagnosticar problemas con el canal de datos.
Descripción general de alto nivel de un flujo de trabajo de canales de datos:
- El servidor de aplicaciones de ePO (Tomcat) escribe la solicitud de DC en la EPOAgentHandlerDataChannelWQ (DC WQ) tabla de la base de datos de ePO.
- Controladores de agentes sondear con regularidad la tabla de WQ de DC en busca de trabajo que hacer.
- Controladores de agentes recoger las solicitudes de DC pendientes en el WQ de DC y trabajar en ellas. La solicitud saliente inicial es esencialmente una llamada de activación a la McAfee Agent en el cliente que indica que se comunique de nuevo a ePO porque el trabajo de DC está disponible.
- El Controlador de agentes se comunica con Tomcat y actualiza el estado de la solicitud de DC saliente, ya sea correcto o incorrecto.
- El agente se comunica con ePO, ya sea:
- Durante su intervalo de comunicación agente-servidor normal (ASCI)
O
- Cuando se pone en contacto con el Controlador de agentes en el paso 3 anterior, y descubre que el trabajo de DC está esperándolo en la cola de trabajo de DC. El agente selecciona este trabajo y completa la solicitud.
- Una tarea de mantenimiento de base de datos interna se ejecuta cada minuto. La tarea busca las solicitudes de DC de la base de datos que se hayan completado o hayan caducado. A continuación, continúa con su eliminación de la WQ de DC.
Consultas SQL:
Utilice las siguientes consultas para obtener información sobre las solicitudes de canal de datos:
- Para ver qué Controlador de agentes está procesando una solicitud de canal de datos para un cliente concreto, utilice la siguiente consulta SQL:
Seleccione
ELN. NodeName como nombrecliente,
ELN. AgentGUID
AH. ComputerName como HandlerName,
Ah. LastKnownTCPIP como HandlerIP,
DCWQ. Origen como DCRequest,
DCWQAttempts. LastDeliveryAttempt as DCLastAttemptTime,
DCWQ. RetryDelay como RetryDelaySeconds,
DCWQAttempts.RetriesRemaining,
DCWQ. ExpireTime como DCExpireTime
De
EPOLeafNode as ELN, EPOAgentHandlerDataChannelWQMT como DCWQ,
EPOAgentHandlerDataChannelWQAttemptsMT como DCWQAttempts, EPORegisteredApacheServers como AH
Donde
DCWQ. Valor AutoID = DCWQAttempts. ParentID
Y DCWQ. Destino = ELN. Valor AutoID
Y DCWQAttempts. AgentHandlerId = AH. Valor AutoID
Y ELN. NodeName = ''
Donde
es el sistema que está consultando. Por ejemplo, para consultar un sistema llamado prueba, tendría que actualizar la última línea de la consulta a:
ELN.NodeName = 'TEST'
- Para mostrar un recuento de todos los tipos de solicitudes de canales de datos de la cola, utilice la siguiente consulta SQL:
Select Source as DCRequest, count (*) as 'Number of Occurrences'
From EPOAgentHandlerDataChannelWQ
Group By Source Order by Source asc
Entradas del archivo de registro:
El canal de datos utiliza el protocolo de canalización segura (SPIPe) para generar solicitudes. Tiene cuatro tipos de solicitud de SPIPe principales, de los que se puede hacer referencia en los siguientes archivos de registro:
- Tipo de solicitud: MsgUpload
Propósito: la solicitud se utiliza para enviar elementos de CC desde el nodo cliente a la Controlador de agentes.
Ejemplo (registro del servidor en un Controlador de agentes):
NAIMSERV Received [MsgUpload] from :{}
- Tipo de solicitud: MsgAvailable
Propósito: el agente ha recibido la solicitud de ePO cuando hay elementos que ePO tiene que entregar al agente.
Ejemplo (registro de agente en un cliente):
- Agent tipo de paquete es MsgAvailable
- LstnSvr StartResponse-POST-PKG - MsgAvailable
- Tipo de solicitud: MsgRequest
Propósito: esta solicitud se envía al Controlador de agentes por parte del agente tras la recepción de un MsgAvailable solicitud de un Controlador de agentes. Esta solicitud activa la Controlador de agentes para responder con MsgResponse.
Ejemplo #1 (registro del agente en un cliente):
Agent tipo de paquete es MsgRequest
Ejemplo #2 (registro del servidor en una Controlador de agentes):
Received [MsgRequest] from :{}
- Tipo de solicitud: MsgResponse
Propósito: ePO envía esta solicitud en respuesta a la MsgRequest Paquete de SPIPe.
Ejemplo (registro de agente en un cliente):
- Agent CMsgResponsePackage::ParsePackage() - New MsgResponse-EEADMIN_1000_UserUpdatesAndAcknowledgementRsp was received
- Agent Package type is MsgResponse
- Agent CMsgResponsePackage::ParsePackage() - New MsgResponse-EEADMIN_1000_AddDomainUsersRsp was received
Ajustes generales error ejemplos de condiciones:
En esta sección se proporcionan soluciones a los problemas habituales de los canales de datos que podrían producirse.
- Las solicitudes de canal de datos, como una llamada de activación del agente, se realizan correctamente, pero el registro de tareas servidor de la consola de ePO siempre informa de que han caducado.
Lo server_.log el archivo del Controlador de agentes puede contener los siguientes errores:
- MCUPLOAD SecureHttp.cpp(968): Failed to send HTTP request. Error=12029 (12029)
- NAIMSERV server.cpp(587): Failed to send request, err=0x80004005, HTTP status code=0
Cause
Apache no puede comunicarse con el servicio servidor de aplicaciones (Tomcat) que se ejecuta en el servidor de ePO. Dado que no se puede comunicar, el estado de la tarea nunca se establece como correcto o error. Finalmente, se ejecuta una tarea de mantenimiento y se identifica que la tarea ha superado su hora de caducidad y que caduca la tarea.
Soluciones posibles:
- Consulte la server.ini File\DB\server.ini). Indica qué dirección IP y nombre DNS utiliza el Controlador de agentes para Tomcat. Confirme que son correctos.
- Asegúrese de que DNS resuelva la dirección IP correcta para el servidor de ePO en la Controlador de agentes.
- Asegúrese de que exista una ruta entre el Controlador de agentes y el servidor de ePO en el puerto 8444 (puerto predeterminado).
- El registro de tareas servidor tiene tareas relacionadas con el canal de datos que siempre se bloquean "en curso" después de que se alcance el tiempo de caducidad. Lo EPODataChannelData la tabla aumenta de tamaño.
Cause
Se supone que una tarea de mantenimiento interna se ejecuta cada minuto para buscar objetos de canal de datos caducados y eliminarlos. Sin embargo, la tarea no se está ejecutando.
Soluciones posibles:
Esta entrada en el orion.log muestra si la tarea interna que limpia las tablas del canal de datos (dbcleanup tarea) se está ejecutando:
INFO [scheduler-TaskQueueEngine-thread-4] Internal.DbCleanupTask - Running DataChannel DbCleanupTask
Esta consulta le da el siguiente tiempo en cola de la dbcleanup tarea
Select RunTime from OrionTaskQueueMT where TaskDescription like '%dbclean%'
Realice lo siguiente en función del estado de la dbcleanup tarea
- Si el dbcleanup la tarea no se encuentra en su totalidad (en otras palabras, la consulta anterior no devuelve ningún resultado), consulte KB84114.
- Si no le conviene ninguna de esas opciones, activar registro de depuración para orion.log para obtener más información sobre la tarea. Ve KB52369 para obtener instrucciones.
