Cet article fournit des informations générales sur le fonctionnement d’ePO Data Channel (DC). Elle fournit également des procédures de dépannage utiles à suivre pour diagnostiquer les problèmes liés au canal de données.
Présentation de haut niveau d’un canal de données workflow :
- Le serveur d’applications ePO (Tomcat) écrit la demande DC dans la EPOAgentHandlerDataChannelWQ (DC WQ) table de la base de données ePO.
- Les gestionnaires de l'agent interrogent régulièrement la table DC WQ à la recherche de tâches.
- Les gestionnaires de l'agent récupèrent toutes les demandes de DC en suspens dans le contrôleur de réseau WQ et les traitent sur celles-ci. La demande sortante initiale est essentiellement un appel de réactivation du McAfee Agent sur le client, ce qui lui demande de communiquer avec ePO, car le fonctionnement du contrôleur de poste est disponible.
- Le gestionnaire d'agents communique avec Tomcat et met à jour l’état de la demande de contrôleur de périphérique sortant, qu’il s’agisse d’un succès ou d’un échec.
- Le agent communique avec ePO de l’une des façons suivantes :
- Lors de son intervalle de communication agent-serveur (ASCI)
normal
Or
- Lorsqu’il est contacté par le gestionnaire d'agents à l’étape 3 ci-dessus, et découvre que le poste de CC attend dans la file d’attente des travaux DC. Le agent sélectionne cette opération et complète la demande.
- Une tâche de maintenance de base de données interne est exécutée toutes les minutes. La tâche recherche les demandes de contrôleur de travail dans la base de données qui ont été terminées ou qui ont expiré. Il continue ensuite de les supprimer de la WQ DC.
Requêtes SQL :
Utilisez les requêtes suivantes pour obtenir des informations sur les demandes de canal de données :
- Pour afficher le gestionnaire d'agents qui traite une demande de canal de données pour un client particulier, utilisez la requête SQL suivante :
Select
ELN.NodeName as ClientName,
ELN.AgentGUID,
AH.ComputerName as HandlerName,
AH.LastKnownTCPIP as HandlerIP,
DCWQ.Source as DCRequest,
DCWQAttempts.LastDeliveryAttempt as DCLastAttemptTime,
DCWQ.RetryDelay as RetryDelaySeconds,
DCWQAttempts.RetriesRemaining,
DCWQ.ExpireTime as DCExpireTime
From
EPOLeafNode as ELN, EPOAgentHandlerDataChannelWQMT as DCWQ,
EPOAgentHandlerDataChannelWQAttemptsMT as DCWQAttempts, EPORegisteredApacheServers as AH
Where
DCWQ.AutoID = DCWQAttempts.ParentID
And DCWQ.Target = ELN.AutoID
And DCWQAttempts.AgentHandlerId = AH.AutoID
And ELN.NodeName = '<system name>'
Où
se trouve le système sur lequel vous effectuez une requête. Par exemple, pour interroger un système nommé TEST, vous devez mettre à jour la dernière ligne de la requête en procédant comme suit :
ELN.NodeName = 'TEST'
- Pour afficher le nombre de tous les types de demandes de canal de données dans la file d’attente, utilisez la requête SQL suivante :
Select Source as DCRequest, count (*) as 'Number of Occurrences'
From EPOAgentHandlerDataChannelWQ
Group By Source Order by Source asc
Entrées de fichier journal :
Le canal de données utilise le protocole de canal sécurisé (SPIPe) pour générer des demandes. Il existe quatre types de requête SPIPe principale, que vous pouvez voir référencées dans les fichiers journaux ci-dessous :
- Type de demande : MsgUpload
Objectif : la demande est utilisée pour envoyer des éléments DC à partir du nœud client vers le gestionnaire d'agents.
Exemple (Journal du serveur sur un gestionnaire d'agents) :
NAIMSERV Received [MsgUpload] from <system name="">:{<GUID>}
- Type de demande : MsgAvailable
Objectif : le agent reçu la demande d’ePO lorsqu’il existe des éléments qu’ePO doit remettre en main sur le agent.
Exemple (journalisation agent sur un client) :
- Agent type de package est MsgAvailable
- LstnSvr StartResponse-POST-PKG - MsgAvailable
- Type de demande : MsgRequest
Objectif : cette demande est envoyée au gestionnaire d'agents par le agent après réception d’une MsgAvailable demande d’un gestionnaire d'agents. Cette demande déclenche le gestionnaire d'agents à l’origine de la réponse MsgResponse .
Exemple de #1 (Journal agent sur un client) :
Agent type de package est MsgRequest
Exemple de #2 (Journal du serveur sur un gestionnaire d'agents) :
Received [MsgRequest] from <system name="">:{<GUID>}
- Type de demande : MsgResponse
Objectif : ePO envoie cette demande en réponse à la MsgRequest package SPIPE.
Exemple (journalisation agent sur un client) :
- 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
Partagés des exemples de condition d’erreur :
Cette section fournit des solutions aux problèmes courants de canal de données qui peuvent se produire.
- Exemple 1 : les demandes de canal de données telles qu’un appel de réactivation agent réussissent, mais le journal des tâches serveur de la console ePO signale toujours qu’ils ont expiré.
Le server_<system name>.log fichier sur le gestionnaire d'agents peut contenir les erreurs suivantes :
- 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 n’est pas en mesure de communiquer avec le service serveur d’applications (Tomcat) qui s’exécute sur le serveur ePO. Etant donné qu’il ne peut pas communiquer, l’état de la tâche n’est jamais défini sur réussite ou échec. Finalement, une tâche de maintenance s’exécute et identifie que la tâche a dépassé son heure d’expiration et fait expirer la tâche.
Solutions possibles :
- Examinez le server.ini fichier ( <ePO installation directory>\DB\server.ini ). Il vous indique l’adresse IP et le nom DNS que le gestionnaire d'agents utilise pour Tomcat. Vérifiez qu’ils sont corrects.
- Assurez-vous que DNS résout l’adresse IP correcte pour le serveur ePO sur le gestionnaire d'agents.
- Assurez-vous qu’il existe un itinéraire entre le gestionnaire d'agents et le serveur ePO sur le port 8444 (port par défaut).
- Exemple 2 : le journal des tâches serveur comporte des tâches liées au canal de données qui sont définitivement bloquées "en cours" une fois le délai d’expiration atteint. La taille de la EPODataChannelData table augmente.
Cause :
Une tâche de maintenance interne est censée s’exécuter toutes les minutes pour rechercher les objets de canal de données arrivés à expiration et les supprimer. Toutefois, la tâche n’est pas en cours d’exécution.
Solutions possibles :
Cette entrée dans indique si la tâche interne qui nettoie les tables de canal de données ( dbcleanup tâche) est en cours d' orion.log exécution :
INFO [scheduler-TaskQueueEngine-thread-4] Internal.DbCleanupTask - Running DataChannel DbCleanupTask
Cette requête vous fournit la prochaine mise en file d’attente de la dbcleanup tâche :
Select RunTime from OrionTaskQueueMT where TaskDescription like '%dbclean%'
Procédez comme suit en fonction de l’état de la dbcleanup tâche :
