This article includes a comple guide to logging and data gathering for Symantec Monitor Solution.
ITMS 8.x
Monitor Solution 8.x
Prelude:
For brevity purposes many acronyms are used in this document. The first occurrence of any terminology used in this document will include the complete spelled name of the term accompanied by the acronym in parenthesis. For easy reference below is a list of terminology used in this document and the associated acronyms:
SMA: Symantec Management Agent.
NS: Notification Server.
SMP: Symantec Management Platform.
SMP Server: Notification Server on which the Symantec Management Platform is installed.
Introduction:
This guide covers how to collect all of the available forms of logging for Symantec Monitor Solution, what they are used for, and examples of when they should be collected for troubleshooting purposes. This document covers the following forms of logging:
Monitor Agent Logs:
PPA Logs
Agent Logs
Server Logs
Verbose Agent and Server Logs
Policy Data: exported from servers and client's policies.
NT Event Logs
WMI Diagnostic Data, Testing, and Logging
Process Monitor Logs
SQL Server Error Logs and Trace
Monitor Logs - How to collect:
Please follow the steps below to collect the Monitor Agent Logs:
PPA Logs - Introduction:
PPA stands for pluggable protocol architecture and is used for storing information that is required to communicate with computers and other devices using standard network monitoring protocols. The Pluggable Protocols Architecture unifies the configuration of protocols across the Symantec Management Platform. To capture PPA logs the registry must be edited.
PPA Logs - When to collect:
There can be a number of reasons to collect PPA logs. General reasons include: PPA error referenced in other logs, PPA error in Symantec management console, issue being caused by unknown source and PPA is a good place to look for issues.
PPA Logs - How to collect:
Note: For additional AMT logging, include the following in step 4 above:
Agent Logs - Introduction:
Agent Logs are the written interactions of the Symantec Management Agent (SMA) that is installed on client and server systems. The SMA is the software that establishes communication between the Notification Server (NS) on which the Symantec Management Platform (SMP) is installed and client computers. Please note that the NS on which the SMP is installed (SMP Server) by default also has the SMA installed as well. The reason for mentioning that detail is an attempt to alleviate any confusion when discussing client and server interactions because any server (including the SMP server) can also be a client. For the purposes of this document, client and server interaction will refer to the interaction between the SMP Server and another computer with the agent installed on it regardless of whether or not that client is a server system or a true client endpoint. Any computer with the SMA installed on it is referred to as a Managed Client.
Agent Logs - When to collect:
There are many reasons for collecting the agent logs. All of the solutions (SMP Plugin) available in the SMP use the SMA for communication. One reason for collecting them may be to determine which solution is causing the issue or if there are multiple problems. In general, the agent logs are a good starting point when diagnosing most problems in the SMP. Agent Logs are important to gather when having issues with a particular machine or a few specific machines.
Agent Logs - How to collect:
Client logs are located at C:\ProgramData\Symantec\Symantec Agent\Logs
Mac/Linux:
Server Logs - Introduction:
The Server Logs are essentially the inverse of the Agent Logs. Instead of detailing the interaction between a single client and the SMP, the Server Logs are the written interaction between the SMP and all Managed Clients. The Server Logs could be described as a one to many relationship where the Agent Logs can be described as a one to one relationship.
Server Logs - When to collect:
In most of the same instances that Agent Logs are gathered, it is also a good idea to gather the Server Logs. It is especially important to gather server logs when an issue is widely distributed amongst client computers rather than an issue with an individual computer.
Server Logs - How to collect:
Symantec Management Platform (Notification Server) logs are located at C:\ProgramData\Symantec\SMP\Logs
Verbose Agent Logs - Introduction:
Verbose Agent Logs are actually in the same location and are the same log files as the standard agent files, the only difference being that verbose logging has been enabled on those log files.
Verbose Agent Logs - When to collect:
Verbose Agent Logging is used in many of the same situations that standard agent logging is collected, but sometimes it is helpful to see every interaction between a particular client and the SMP Server. Verbose Agent Logs differ from Agent Logs by the amount of detail provided in the logs. Both the Symantec Management Agent and the server logging are controlled by the registry. To enable Verbose logging the registry will need to be edited.
Verbose Agent Logs - How to collect:
Please follow the steps below to collect the Verbose Agent Logs:
Verbose Server Logs - Introduction:
Verbose Server Logs are actually the same log files as the standard server logs. The only difference being that verbose logging has been enabled on those log files.
Verbose Server Logs - When to collect:
Verbose Server Logging is used in many of the same situations that standard server logging is collected, but sometimes it is helpful to see every interaction between all clients and the SMP Server. Verbose Server Logs differ from Agent Logs by the amount of detail provided within them. Both the Symantec Management Agent and the server logging are controlled by the registry. To enable Verbose logging the registry will need to be edited.
Verbose Server Logs - How to collect:
Please follow the steps below to collect the Verbose Agent Logs:
Monitor Logs - Introduction:
To capture monitor logs a 3rd party tool like Microsoft's dbgview.exe must be used. To start Monitor Logging adjustments to the registry must be made.
Monitor Logs - When to collect:
The monitor logs should be collected when there is a suspected problem with the aexmetricprovider process. When monitor logging is enabled it collects verbose data about how the aexmetricprovider process operates.
Policy Data - Introduction:
The client policy XML files contain monitor and other polices
Policy Data - When to collect:
Any time all policies applied to a particular system need to assessed it is a good idea to collect the client policy xml file.
Policy Data - How to collect:
The Client Policy XMLs are located at C:\Program Files\Altiris\Altiris Agent\Client Policies on all managed clients.
NT Event Logs - Introduction:
NT Event Logs are a component of Microsoft Windows that started with Microsoft Windows NT 4.0. They are a culmination of events from several system components including: Application Event Logs, Security Event Logs, System Events Logs, Registry, and Message Resource files. The interface for viewing all of these logs is through the Event Viewer (eventvwr.exe). The Event Viewer allows you to view, search, and record the NT Event logs. This discussion of NT Event Logs will be a bit truncated here as there are entire books written on this subject matter.
NT Event Logs - When to collect:
NT Event Logs are important to collect when certain issues are occurring such as: monitor agent is crashing, Symantec Management Agent is crashing, Monitor Agent is causing high CPU usage, WMI isn't working correctly, etc. In general if there is any question about what is causing the problem at hand, look through the NT Events to see if there are any outstanding errors or warnings that could be related.
NT Event Logs - How to collect:
WMI Diagnostic Data, Testing, and Logging - Introduction:
WMI (Windows Management Instrumentation) is a core Windows management technology that can be used to gather system data and control system processes and services locally or remotely. There are 3 methods to collecting diagnostic information on WMI. The first portion is the actual diagnostic information that can be gathered by using Microsoft's WMIDiagnosis Tool (WMIDiag). The second part involves testing the WMI database installed on a machine both locally and remotely across the network which can be done using wbemtest. The instructions here on using WMIDiag will be brief as the full instructions on using the tool are included with the download (WMIDiag.doc). The third portion is WMI logging which requires changes to the registry of the computer in question.
WMI Diagnostic Data and Logging - When to collect:
Anytime there is an issue or a suspected issue with WMI these logs should be collected. For instance if WMI metrics are not alerting as expected then WMI diagnostic data and logs should be collected.
WMI Diagnostic Data - How to collect:
WMI Testing - How to test locally and remotely:
How to test WMI locally:
How to test WMI remotely through wbemtest:
How to test WMI remotely through PowerShell:
WMI Logging - How to collect:
How to view WMI Events in Event Viewer:
Process Monitor Logs - Introduction:
Process Monitor (ProcMon) is an advanced monitoring tool for Windows that shows Realtime file system, Registry and process/thread activity. This can be a very useful tool in many situations, especially if the source of problem at hand is hard to track down.
Process Monitor Logs - When to collect:
Process Monitor logs (PM Logs) are a good to collect when there are problems with the monitor agent such as: excessive CPU usage, excessive memory usage, monitor agent crashes, or monitor agent is causing a Blue Screen of Death (BSOD).
Process Monitor Logs - How to collect:
SQL Server Error Logs and Trace - Introduction:
There are two primary methods for diagnosing SQL Server issues: SQL Server Error Logs and SQL Server Profiler Trace. The SQL Server error logs contains user defined events and certain system events that can be used to troubleshoot issues on the SQL Server. The Profiler trace is a built in program to Microsoft SQL Server Management Studio. The Profiler is used for monitoring an instance of the Database Engine or Analysis Services. The Profiler trace can provide information on the following issues: Stepping through problem queries to find the cause of the problem, finding and diagnosing slow-running queries, capturing the series of SQL transactions that can then be used on a test server to recreate the issue and diagnose it, monitor the performance of SQL Server to adjust workloads, correlating performance counters to diagnose problems.
SQL Server Error Logs and Trace - When to collect:
SQL Server error logs and profiler trace are a good first step for any potential database problem. For instance if monitoring reports are working as expected it may be a good idea to check the tables that the report is populated from and you can step through the SQL queries with the profiler or you can scan the error logs for potential problems that may be related.
SQL Server Error Logs - How to collect:
SQL Server Profiler Trace - How to collect: