Introduction

The ELM infrastructure must be planned prior to deploying ELM in your environment.

Consider the following questions:

What are my Windows Audit Policy settings?

Your Windows Audit Policy is going to determine which events are being written to your event logs.  Some of these audit policies generate a lot of events, such as Audit process tracking - Success.  Determine what your business needs are and only turn on auditing for the events that you will need to collect.

Which events do you want to collect?

You decide which events are important to you. For example, in order to collect user logon events, you may decide to collect Audit Success and Audit Failure events on your domain controllers, but only Audit Failure events on your member server. You can determine which events are collected based on a number of event filter criteria. Filtering takes place at the Agent level, reducing the workload on the Agent, the ELM Server, and the network.

How many Syslog messages and/or SNMP Traps will you be receiving?

Network devices can be configured to transmit a wide variety of Syslog messages and SNMP traps. This translates into network traffic, ELM Server receiving and processing, and database overhead.

How frequently do you want to collect data?

Data can be collected in real-time (every second), or at periodic intervals. The frequency of data collection is directly related to resource consumption (overhead) and database size. The more frequently you collect data, the higher your resource utilization and the larger your database becomes (unless you use the built-in aggregation/pruning features).

How long do you want to keep data?

If you are planning to keep all event data for years, months, or weeks, the database will become very large and must eventually be archived. Developing a plan to prune unnecessary records and archive preferred data periodically will save time and resources. Keep all current events in the database (from the last two weeks, for example), keep only error and audit events for a longer period of time.

If you anticipate your database growing beyond 10.0 GB, we recommend using Microsoft SQL Server 2008 R2 rather than Microsoft SQL Server 2008 R2 Express Edition since it has a maximum database size of 10 GB.

Which notification methods work best for you?

You might choose to send non-critical events by e-mail, and critical events by network message or pager. You might use custom batch files as a notification method, allowing you to take action when a critical event occurs (such as restarting a failed service).

What Type and Class of Agents do you want to use?

Agent Agents are the fundamental component for identifying the devices to be monitored. is the general term describing a monitored system. There are two classes of Agents that distinguish among operating systems.  For example a Windows Server vs. a Windows Workstation vs. a Linux Server.  These two classes are:

•Class I = Windows Server and Windows Cluster Server Systems.

•Class II = Windows Workstation and non-Windows Systems.

There are two types for Agents monitoring Windows operating systems.  So Cluster, Server and Workstation Agents can be installed as one of the following:

•Service Agents a program that runs as a service on the monitored system

•Virtual Agents provide agent-less monitoring, where the ELM Server performs monitoring/collection.

Note
Non-Windows devices are always monitored by an IP Virtual Agent.

    Agent Types

•Service Agents run in the security context of the LocalSystem, or in a user security context (e.g., using a service account). Service Agents usually consume approximately 30-75MB of physical memory, and less than 3% of the overall CPU time on the monitored system. The resources actually consumed depend on the number of Monitor Items applied to the Agent, the frequency at which those Monitor Items are executed, and the amount of data generated by or being collected from the monitored system. Service Agents are used for monitoring only Windows 2000/2003/2008, Windows XP Pro, Vista Ultimate, and Windows 7 systems; if you do not wish to install software on the monitored system, use a Virtual Agent; to monitor a computer with a different OS or a device that uses TCP/IP, use an IP Virtual Agent.

Note
When setting the user security context (e.g., using a service account), the settings in the ELM console override the user security context settings in the TNT Agent service in Windows services.

•Virtual Agents provide agent-less monitoring of Windows computers without installing a service on the monitored system. The ELM Server monitors and collects data from the Windows system remotely. Because Agent code is not used on the monitored system, Virtual Agents will add overhead to your network and to the ELM Server. In most situations, Service Agents are recommended, however Virtual Agents are useful when you do not want to install software on the monitored system. Virtual Agents require that the ELM Server service account has administrative privileges on the system to be monitored. Virtual Agents require RPC and NetBIOS connectivity between the ELM Server and the monitored system. Because Virtual Agents remotely monitor Windows systems, they cannot monitor in real-time.

•IP Virtual Agents always provide agent-less monitoring. You can monitor, collect data from, or receive data from Unix, Linux, NetWare, Cisco and Apple systems, hubs, switches, routers, gateways, etc. with IP Virtual Agents. The ELM Server can receive SNMP Traps, and TCP-based and UDP-based Syslog messages from IP Virtual Agents, as well as monitor internet services. Windows systems can be monitored by IP Virtual Agents but Inventory Collectors, Event Collectors, Event Monitors or File Monitors cannot be used for these systems.