LassoUserGuide 4.0.5

Project Lasso 4.0.
LogLogic Windows Event

Collector Guide
Software Release: 4.0.2

Document release: February 2008
Part No: LL41002-00E04020000
This manual supports Project Lasso 4.0.2 and later releases until
replaced by a newer edition.
© 2005 - 2008 LogLogic, Inc. All rights reserved.
LogLogic is a trademark of LogLogic, Inc. All other products or services mentioned are the
trademarks, service marks, registered trademarks or registered service marks of their
respective owners.
LogLogic, Inc.
110 Rose Orchard Way Ste200
San Jose, CA 95134
Tel: +1 408 215 5900
Fax: +1 408 774 1752
U.S. Toll Free: 888 347 3883
Email: info@loglogic.com
www.loglogic.com
Contents
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Chapter 1 Installing Project Lasso

Prerequisites for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Installing Project Lasso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Scripted Installation of Project Lasso on Multiple Systems . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 2 Configuring Project Lasso

Setting Hosts and Event Logs to Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
hostlist.ini File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Setting Run-Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Lasso.ini Configurable Run-Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Basic Project Lasso Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
LogAppliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
CheckRemHostAvail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
CheckHostListInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
MaxNumWorkerThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Control Event Collection and Spooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
HighWaterMarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
NewHostSkipHistorical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
WatermarkWriteInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
EventPollInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
SpoolPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
SpoolFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Control DLL Collection and Project Lasso Shares. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
DllLoadInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
SkipInitDLLScan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
RepositoryPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
EnableShareDlls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
EnableAdminSharesIfDisabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
DefaultLassoShare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Error Logging, Tracing, and Access Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
DebugLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
LogLevel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
MaxTraceFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
AccessReport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
AccessReportFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring Project Lasso as a Windows Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Windows Event Collector (Project Lasso) Guide 3

CONTENTS
Configuring Site-Specific Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 3 Running Project Lasso

Running Project Lasso as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Chapter 4 How Project Lasso Works

Agent and Collector Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Windows Services Control Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Configuration Parameters in the Lasso.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Target Hosts Monitored Using the hostlist.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Using Multi-Threading for Parallel Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Accessing Registry Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Locating String Resource DLL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Building the Project Lasso Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Event Messages from Monitored EventLogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Expanding EventLog Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Traceability and Field Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Scalability and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A Permissions and Security Considerations for Project Lasso

Authentication and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Privileges Required for the Project Lasso User Account . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Collecting DLLs in the Project Lasso Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B TCP/IP and UDP/IP Ports Used by Lasso

Lasso Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Testing Project Lasso Communication with Monitored Hosts through a Firewall . . . . . . . 44
4 Windows Event Collector (Project Lasso) Guide

About This Guide
Preface
About This Guide
The LogLogic Windows Event Collector Users Guide describes how to install, configure, and
manage security for the LogLogic Windows Event Collector (also called Project Lasso).
The LogLogic Windows Event Collector (Project Lasso) converts Windows Event Logs
into a syslog stream that a LogLogic appliance can collect. You can configure Project Lasso
to monitor multiple machines across your network from a single Windows host machine.
Project Lasso can monitor the following servers and workstations:

Servers - Windows 2000 and Windows 2003
Workstations - Windows XP Professional and Windows 2000 Professional
Project Lasso:
monitors specified Windows hosts from a central Log Collection Server
collects all EventLog records and other related data from specified Windows hosts
can monitor and collect from System, Security, Application, DNS Server, ADServer,
File Replication Service, and custom logs
generates complete, easy-to-read EventLog messages
sends EventLog messages to Log Management appliances
Related Documents
In addition to this LogLogic Windows Event Collector Users Guide, you might want to refer to
the following documentation provided with the LogLogic appliance software:
LogLogic Windows Event Collector Release Notes: This document contains any
late-breaking information specific to the Project Lasso release.
LogLogic Quick Start Guide: This guide gives you short, simple instructions for getting
started quickly with a new appliance.
LogLogic Administration Guide: This guide explains administrative tasks in more
complete detail.
LogLogic Upgrade Guide: This guide provides information relevant to upgrading an
existing appliance.
LogLogic Help: This online help system is integrated into the appliance. It provides
information about fields within the user interface. To access complete online help
system, click on the Help link in the upper right of the screen. For context-sensitive
help, use the ? button below the Help link.

Conventions
Conventions
LogLogic documentation uses the following conventions to highlight code and
command-line elements:
Monospace is used for programming elements (such as code fragments, objects,
methods, parameters, and HTML tags) and system elements (such as file names,
directories, paths, and URLs).
Monospace bold is used to distinguish system prompts or screen output from user
responses.
username: root
home directory: home\test
Monospace italic is used for placeholders, which are general names that you
replace with names specific to your site.
LogLogic_home_directory\upgrade\
Straight brackets signal options in command-line syntax.
ls [-AabCcdFfgiLlmnopqRrstux1] [-X attr] [path ...]
A straight vertical line separates option choices when only two choices exist.
HighWaterMarks,ON|OFF

CHAPTER 1 Installing Project Lasso
C HAPTER 1
Installing Project Lasso
Prerequisites for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Installing Project Lasso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Scripted Installation of Project Lasso on Multiple Systems . . . . . . . . . . . . . . . . . . . . . 10
Prerequisites for Installation

To install Project Lasso, you need the following hardware, software, and environment:
1 gigabyte RAM, 20 gigabytes of free disk space, 1 2.0 Ghz CPU (2 or more is
recommended), 1000 Mbps network interface. If you have more than 50 log-intensive
hosts to monitor, consider additional RAM.
The free disk space amount on the Project Lasso host server depends on the data
rate of log events expected, in aggregate, from the monitored hosts. This disk
space is not used as long as the Project Lasso host maintains contact with the
LogLogic Appliance. Up to 10% of the disk, or more if you configure it, is used for
spooling storage if the LogLogic appliance connection is lost.
LogLogic version 4.0.2 or later installed on your LogLogic appliance.
Note: To run Project Lasso with an earlier LogLogic release, you must register all Windows
servers with the LogLogic Appliance prior to starting Project Lasso for the first time. Earlier
releases do not auto-discover syslog-ng data. LogLogic recommends upgrading to 4.0.2 or
later.
Windows 2003 Server to host Project Lasso, in the same Windows Domain as the
Windows hosts to monitor. (Non-Domain hosts can be monitored, but it takes effort.)
Domain User ID under which Project Lasso runs on the host Windows server. The
Project Lasso User ID must have certain permissions in the Domain and/or on each
monitored host, to have remote access to protected resouces such as the Windows
Security Event Log.
Note: Log Administrators do not need to know the Project Lasso user password. Your Security
Administrator can keep the password secure so long as this installation can be completed.
Note: To run Project Lasso in a non-Domain environment, you must work within the constraints
of Windows user authentication. For details, see Appendix A, Permissions and Security
Considerations for Project Lasso.

A text editor, such as NotePad or WordPad, to edit the .csv configuration files.

You can install Project Lasso from a CD or from a network install image, downloadable
from http://sourceforge.net/projects/lassolog/. You install (and uninstall) Project Lasso
using the InstallShield installer program.
To install Project Lasso on a large number of machines (for instance, if you are using agent
mode), you can use InstallShield's scripted install capability to automate the process. See
Scripted Installation of Project Lasso on Multiple Systems on page 10.
Project Lasso also installs as a Windows Service, and must be configured to auto-start on
boot and auto-restart upon process failure.
Installing Project Lasso:

1. (Collector mode only) Create a Project Lasso User ID (as a Domain User ID) for the
host Windows Server machine. The Project Lasso User ID must have permissions
equivalent to the Domain Administrator or the Local machine Administration on each
monitored server. For more information, see Prerequisites for Installation on page 7.
Project Lasso running in agent mode can run as the local system, so this is required
only for collector mode.
2. Log in to the Project Lasso host machine using an account with privileges to install
services.
3. Run the ProjectLasso_4.0.2_Installer.exe file.
a. Accept the License Agreement; click Next.
b. Read the Project Lasso Release Notes; click Next.
c. Select a destination folder to install Project Lasso in; click Next.
InstallShield asks whether to use a custom Lasso.ini file.
d. Indicate whether to use a custom file. If so, indicate the file location (whether on this
system or on a network file server share).
Using a custom Lasso.ini file lets you perform scripted install with options not
included in this Installer interface. Typically, it is used for installing the same
custom settings on a large number of machines.
e. Select the Project Lasso Repository location to create; click Next.
The Repository contains all resource string .dll files necessary for text expansion
of log messages. Each EventLog on each host can have up to three .dll files that
must be copied. The .dll files can be several megabytes each.

CHAPTER 1 Installing Project Lasso
f. Select the spooling directory location to create; click Next.

The spooling directory contains:
Log messages, if the connection to the LogLogic appliance is lost. LogLogic

recommends providing at least the same percentage of disk space that you specify
later in the Lasso.ini file.
Other data files written by Project Lasso, including

LassoHighWatermarks.log and LassoTrace.log.
g. Complete the installation program as prompted, providing:
LogLogic appliance information - the appliance IP address and port number
Monitoring parameters - certain Project Lasso performance defaults.

For guidance, see Control Event Collection and Spooling on page 18. These settings
can be changed during Project Lasso configuration in the Lasso.ini file.
Host and event log identification - the primary host name and which logs to
monitor.
For guidance, see Setting Hosts and Event Logs to Monitor on page 11. These
settings can be changed during Project Lasso configuration in the hostlist.ini
file.
h. Confirm the settings as displayed; click Next.
InstallShield displays that it is ready to install Project Lasso.
i. Click Next.
InstallShield installs Project Lasso, and notifies you upon completion.
4. Optionally, limit access privileges to the install, Repository, and spool directories
created during installation.
Log data can temporarily reside in these directories, so you might want to limit access
to them. If you limit access, make sure you give the Project Lasso UserID full and
unrestricted access to these directories and all their subdirectories.
Make sure that appropriate Log Administrators, who will maintain the list of hosts
monitored by Project Lasso, have at least read/write access to the installation
directory.
IMPORTANT! The Project Lasso Windows Event Collector service is installed with the Startup type
in the “Manual” state. You must configure Project Lasso, then use the Windows Services Manager to
start the service. See Chapter 2, Configuring Project Lasso.

Scripted Installation of Project Lasso on Multiple Systems
Scripted Installation of Project Lasso on Multiple Systems

To simplify the installation of Project Lasso on a large number of machines (for example, if
you are using agent mode), you can use InstallShield's scripted install capability.
1. Create a recording file.
This option records all the user input and options for future playback. The f1 option
can use any filename but it should be an absolute path to an existing folder.
run: Loglogic_Installer.exe /r /f1"c:\temp\setup.iss"
2. Copy the recorded install file and the installer program for access to use on other
machines. You can:
Copy them directly to each machine on which you will install Project Lasso.
Copy them to a shared network file server, accessible from each machine you will
install Project Lasso on.
3. If you are using a custom Lasso.ini file for these machines, copy it to the same
system as the recorded install file and installer program.
4. Play back the recording file on each additional machine:
To run the installer if it is on the machine:
run: Loglogic_Installer.exe /s /f1"c:\temp\setup.iss"
To run the installer if it is on a network server:
run: Loglogic_Installer.exe /s /f1"\\server\share\setup.iss"
During interactive installation, if you try to install Project Lasso on an Operating System
other than Windows 2003 Server, it opens a warning dialogue box, but lets you continue.
Scripted install suppresses this warning dialogue.
During interactive installation, Project Lasso is installed as a service, but with Startup
type set to Manual. You are expected to set Startup type to Automatic after
configuring all the items specified in Chapter 2. However, if you are performing a
hands-free scripted install in agent mode (using your Lasso.ini file provided with the
install script, the default hostlist.ini consisting of only localhost, and a User ID of
Local System), you might want to install Project Lasso with Startup type already
set to Automatic. To do this, add the /autostart flag to the command line invocation of
Loglogic_Installer.exe.

CHAPTER 2 Configuring Project Lasso
C HAPTER 2
Configuring Project Lasso
Before you can start Project Lasso, you must configure it:
1. Setting Hosts and Event Logs to Monitor, by editing the hostlist.ini file (page 11)
2. Setting Run-Time Parameters, by editing the Lasso.ini file (page 14)
3. Configuring Project Lasso as a Windows Service (page 26)
4. Configuring Site-Specific Network Details, if necessary, to enable the Project Lasso host
machine to communicate with target machines in your network (page 27)
Setting Hosts and Event Logs to Monitor

At service startup, Project Lasso loads a list of hosts (by NetBIOS name, fully qualified
domain name, or IP address) and EventLogs to monitor from a hostlist.ini
configuration file.
hostlist.ini is a comma-separated file that lists each host ID, followed by the names
of logs to monitor on that host.
Project Lasso can monitor System, Security, Application, DNS Server, AD Server, and File
Replication Service logs, and any custom logs for which the EventLog name is known (for
example, OracleLog).
Also at service start-up, Project Lasso loads the target LogLogic Appliance (by IP address
or DNS name) from the Lasso.ini file. See Setting Run-Time Parameters on page 14.
Note: The hostlist.ini file is loaded at start-up and re-read periodically, according to the
configuration parameter CheckHostListInterval. You can edit the list of monitored hosts while
Project Lasso is running. New hosts are added at the next CheckHostListInterval. Removed
hosts continue to be collected until the Project Lasso service is restarted.
To modify the hostlist.ini file:

1. On the Project Lasso host machine, navigate to SYSTEM\Program Files\Lasso.
2. Open the hostlist.ini file using a program that can read .csv files such as
Microsoft Excel.
3. Add, remove, or update lines in hostlist.ini so it contains all the hosts and
EventLogs for Project Lasso to monitor. Every line follows the form:
hostname,lognames,[sharename=sharepath\]

Setting Hosts and Event Logs to Monitor
a. hostname identifies the system to monitor:
Use the IP Address or Server name for the machine to monitor. For example,
dc-server1 or 192.168.22.14.
To monitor the Project Lasso Host, use the reserved word localhost, the local IP
address,or the machine name.
If there are multiple IP addresses on the machine to monitor, specify the IP

address to monitor; do not specify localhost.
b. lognames identifies one or more (comma-separated) logs, or groups of standard
Windows logs, to monitor on the system:
Enter one or more (comma-separated) EventLog names, specifying particular

standard Windows logs and/or other EventLogs.
*3 specifies three standard Windows 2000/2003/XP logs: Security, Application,

System.
*6 specifies six standard Windows 2000/2003 logs: System, Security, Application,

DNS Server, ADServer, and File Replication Service.
Generally, only Domain Controllers have all six of these logs. For hosts that do not
have all of these logs, the unavailable ones are ignored without error.
You can include specific EventLog names and a *3 or *6 group entry in the same
host entry line.
c. sharename=sharepath (optional) defines a Windows Share on each target
specifically for Project Lasso use.
This makes the use of Administrative Shares no longer necessary for DLL collection.
The DefaultLassoShare parameter on page 23 allows creation of a generic Lasso
Share with the same name and a common path on all monitored hosts. However, in
hostlist.ini you can specify a unique name and path per host. If both are
present, the per-host value in hostlist.ini overrides the general
DefaultLassoShare value in Lasso.ini.
sharename and sharepath cannot include a comma or equal sign.
sharepath must be terminated by a back-slash character.
IMPORTANT! Do not insert spaces or blank characters, unless they are part of field values
such as an EventLog name. Values must be delimited with commas only, though leading and
trailing blank spaces are ignored. Blank spaces can create errors when Project Lasso is reading
the file during startup.
4. Enter comments as needed, by starting a line with the # character.

The # character is only allowed at the beginning of a line; you cannot add comments at
the end of a keyword line.
5. Save the hostlist.ini file.
New hosts are added at the next CheckHostListInterval as specified in
Lasso.ini.
Removed hosts continue to be collected until the Project Lasso service is restarted.

hostlist.ini File Example

The following is an example of valid entries in the hostlist.ini file:
localhost,*3
dc-server1,*6
192.168.22.14,Security,System
192.168.22.53,*3,OracleLog
192.168.1.1,*6,LassoShare=C:\LassoShare\
Table 1 hostlist.ini File Example Details

hostlist.ini Entry Monitored Event Logs Monitored Machine
localhost,*3 Security, Application, System local Project Lasso host
dc-server1,*6 System, Security, Application, DNS dc-server1
Server, ADServer, File Replication Service
192.168.22.14,Security, Security, System 192.168.22.14
System
192.168.22.53,*3,Oracle Security, Application, System, OracleLog 192.168.22.53
Log
192.168.1.1,*6,LassoSha System, Security, Application, DNS 192.168.1.1 (with a
re=C:\LassoShare\ Server, ADServer, File Replication Service Project Lasso Share
created at the specified
path)

Setting Run-Time Parameters

At service startup, Project Lasso loads application parameters for your site from the
Lasso.ini file. Lasso.ini is also read at the beginning of each event poll cycle. It is a
.csv file that can be viewed using any spreadsheet program or text editor.
Note: Although the Lasso.ini file is read at the beginning of each poll cycle, some keyword values
are only read at startup. If you need to make changes to the file, determine if your changes require
the Project Lasso Windows Event Collector service to be restarted. For more information on running
Project Lasso, see Running Project Lasso as a Service on page 29.
To modify the Lasso.ini file:

1. On the Project Lasso host machine, navigate to SYSTEM\Program Files\Lasso.
2. Open the Lasso.ini file using a program that can read .csv files such as Microsoft
Excel.
3. Add, remove, or update lines in Lasso.ini so it contains the configuration parameter
values needed for your site. Every line follows the form:
keyword,variable[,variable...]
a. keyword is a configurable run-time parameter, as listed in Table 2 on page 15.
b. variable is an option for the entry’s keyword. Some parameters allow multiple
options.
IMPORTANT! Do not insert spaces or blank characters. Values must be delimited with commas
only, though leading and trailing blank spaces on field values are ignored. Keywords are not
case-sensitive.
4. Enter comments as needed, by starting a line with the # character.

The # character is only allowed at the beginning of a line; you cannot add comments at
the end of a keyword line.
5. Save the Lasso.ini file.
New run-time parameter settings are available either immediately or upon restart of
Project Lasso. The parameter descriptions in this chapter identify when each setting is
available.

Lasso.ini Configurable Run-Time Parameters

Table 2 describes the Project Lasso run-time parameters you can configure in the
Lasso.ini file.
Table 2 Lasso.ini Configurable Run-Time Parameters

Keyword Required Description Page
Basic Project Lasso Configuration
LogAppliance Y The target appliance page 16
CheckRemHostAvail N Checks whether target hosts are available on page 16
the network
CheckHostListInterval N How often hostlist.ini is reloaded page 17
MaxNumWorkerThreads N Maximum number of worker threads for page 17
event collection from remote hosts
Control Event Collection and Spooling
HighWaterMarks N Restarts collecting all available logs page 18
NewHostSkipHistorical N Skips collecting historical event data on new page 18
host
WatermarkWriteInterval N Interval for writing progress cursors page 19
EventPollInterval N Minimum time interval between pollings of page 19
hosts and logs for additional events
Spoolpath N Where Lasso spools log messages if page 19
connection is lost
SpoolFileSize N Maximum size of all spool files page 20
Control DLL Collection and Project Lasso Shares
DllLoadInterval N Time between collecting String Resource DLL page 21
files
SkipInitDLLScan N Skips startup check of DLLs page 21
RepositoryPath N Where Lasso stores resource string .dll files page 21
for text epansion of log messages
EnableShareDlls N Identifies and shares identical DLLs page 22
EnableAdminSharesDisabled N Temporarily enables Admin Shares for DLL page 22
collection
DefaultLassoShare N Allows a Windows Share on each target host page 23
Error Logging, Tracing, and Access Reporting
DebugLevel N Writes messages into a trace file page 24
LogLevel N Writes eventlog entries page 24
MaxTraceFileSize N Maximum size of LassoTrace.log page 24
AccessReport N Writes summary resource access reports page 25
AccessReportFileSize N Maximum size of page 25
LassoAccessReport.log

Basic Project Lasso Configuration

The following parameters control basic Project Lasso confirmation settings.
LogAppliance
(Required) Specifies the target appliance.
LogAppliance,appliance-ID[,port-number[,udp]]
appliance ID (required) - IP address or DNS name of the appliance
port-number (optional) - port number for syslog-ng communication (default is 514)
udp (optional) - causes Project Lasso to use UDP instead of TCP to communicate with
the LogLogic Appliance. If udp is specified, port-number must also be specified.
Caution: UDP communication is intended for use only with Project Lasso in “agent” mode. If you
specify udp, the hostlist.ini file should contain only “localhost” as a monitored host. If you
accidentally set udp while monitoring remote hosts, the LogLogic Appliance interprets all Project
Lasso logs as coming from the Project Lasso Host rather than from the various remote hosts.
Examples
To specify an appliance with IP address 192.168.22.199, using standard syslog-ng port 514:
LogAppliance,192.168.22.199
To specify appliance 192.168.22.199 using port number 1514:
LogAppliance,192.168.22.199,1514
To specify appliance LLAUSTIN using port number 1514:
LogAppliance,LLAUSTIN,1514
To use UDP communications for appliance 192.168.22.199 using port 514:
LogAppliance,192.168.22.199,514,udp
CheckRemHostAvail
(Optional) Enables Project Lasso to check whether target hosts are available for
communication over the network by sending it an Echo message using TCP port 7.
CheckRemHostAvail,0|1
If a target host is running Windows Firewall, port 7 is blocked by default. In this case, you
can turn off the Echo test by adding CheckRemHostAvail,0 to Lasso.ini. See Testing
Project Lasso Communication with Monitored Hosts through a Firewall on page 44.
Default is 0.
If an expected host is not available on the network, Windows networking APIs can take
between 30 seconds and 2 minutes to time out. During this time, one of the Project Lasso
threads is blocked and unavailable for other work. Non-response to the Echo test takes
only a few seconds. Therefore, if you turn off the Echo test it is important to have a clean
hostlist.ini file, without large numbers of unavailable target hosts.

Tip: If Project Lasso is collecting logs from the localhost normally, but is collecting no logs from
remote hosts and the manual tests in Testing Project Lasso Communication with Monitored Hosts
through a Firewall on page 44 all work, try turning off CheckRemHostAvail.
CheckHostListInterval
(Optional) Specifies how often Project Lasso reloads the hostlist.ini file.
CheckHostListInterval,value
value is the reload interval, in seconds. (default is 3600)
To disable the reload of hostlist.ini and make it read only at startup, use 0.
Example
To check the hostlist.ini file for changes once per hour:
CheckHostListInterval,3600
MaxNumWorkerThreads
(Optional) Sets the maximum number of worker threads for event message collection
from remote hosts. The actual number of threads is defined by this value and the number
of hosts in hostlist.ini .
MaxNumWorkerThreads,value
Valid values: = 1 to 99 (default is 4)
Usage Notes
LogLogic recommends setting this parameter to 4 times the number of CPU cores in the
Project Lasso Host server.
The number of worker threads actually used by the system never exceeds the number of
hosts defined in hostlist.ini at the time the Project Lasso service is started.
Example
MaxNumWorkerThreads,8

Control Event Collection and Spooling

The following parameters control event collection and spooling settings.
HighWaterMarks
(Optional) HighWaterMarks affects how Project Lasso collects new EventLog messages.
It is dependent on the concept of “progress cursors” or “high-water marks”, as mentioned
in Chapter 4, How Project Lasso Works.
HighWaterMarks,ON|OFF
As Project Lasso collects events, it maintains a record of the last event successfully
collected from each monitored EventLog on each target host. It periodically records these
progress cursor values in the LassoHighWatermarks.log file in the Project Lasso Spool
directory.
At startup, Project Lasso reads the LassoHighWatermarks.log file to find out how far
it got on each monitored EventLog during its last run. To discard this information and
restart collecting all available logs, set HighWaterMarks,OFF. This one-time setting is
automatically reset to HighWaterMarks,ON immediately after Project Lasso startup.
Usage Notes
The value of HighWaterMarks is effective only at startup, and is therefore not
reloadable.
If the value is invalid, the default value (ON) is used.
Example
HighWaterMarks,ON
NewHostSkipHistorical
(Optional) NewHostSkipHistorical affects how Project Lasso collects new EventLog
messages. It is dependent on the concept of “progress cursors” or “high-water marks”, as
mentioned in Chapter 4, How Project Lasso Works.
NewHostSkipHistorical,0|1
As Project Lasso collects events, it maintains a record of the last event successfully
collected from each monitored EventLog on each target host. It periodically records these
progress cursor values in the LassoHighWatermarks.log file in the Project Lasso
Spool directory.
When you add a new host to hostlist.ini, or if Project Lasso starts up and there is no
LassoHighWatermarks.log file, Project Lasso normally collects all logs from the
monitored EventLogs, no matter how old. This can result in thousands of old event
messages being collected and transmitted to the LogLogic Appliance.
Usage Notes
If the value is invalid, the default value (0) is used.
Example
To skip collecting historical event data:

NewHostSkipHistorical,1
WatermarkWriteInterval
(Optional) Identifies the interval, in milliseconds, for when progress cursors are written.
WatermarkWriteInterval,value
Usage Notes
Range: 100 milliseconds (0.1 seconds) through 10000 milliseconds (10 seconds)
If the value is invalid, the default value (1000 milliseconds; 1 second) is used.
The value is reloadable and is effective starting at the next event poll cycle.
Example
WatermarkWriteInterval,1000
EventPollInterval
(Optional) Identifies the minimum time interval, in seconds, since the last data collection
completed after which Project Lasso polls the identified hosts and logs again for data.
EventPollInterval,value
Note: The EventPollInterval is not a guarantee of performance. It is the minimum time between
event collections. If a large number of busy servers are monitored, the overall polling cycle time
might be much longer than the requested EventPollInterval. The actual polling interval depends on
the number of hosts, number of threads, and how busy the collection server is.
Usage Notes
Range: 1 through 86400 seconds (1 day)
If the value is invalid, the default value (300 seconds; 5 minutes) is used.
Setting value to 1 allows near real-time log collection.
Example
To set the time between polling occurrences to 5 minutes (300 seconds):
EventPollInterval,300
SpoolPath
(Optional) Controls the directory where Project Lasso spools log messages if the
connection to the appliance is temporarily lost. This configuration line is normally written
by the Project Lasso installation program, but can be modified manually. You must have
enough available disk space on your host machine. LogLogic recommends at least 5
gigabytes of free disk space.
SpoolPath,path
The default path is .\.

Usage Notes
If the value is invalid, the default value of RepositoryPath\Spool\, which resides
under the same directory as the .dll file repository, is used.
The value is not reloadable. The value is read only during Project Lasso startup.
Example
SpoolPath,C:\Program Files\Lasso\LassoRepository\Spool\
SpoolFileSize
(Optional) Identifies the maximum size of the spool files. If there are multiple spool files,
this value defines the maximum combined size of all the spool files.
SpoolFileSize,value
value is the percentage of disk space of the volume specified in the SpoolPath
parameter.
The default is 1.0 (one percent of volume).
Usage Notes
Range: 0.1 (one tenth percent) through 10.0 (ten percent).
If the value is out of bound, it is matched to the appropriate boundary. That is, if the value
is greater than 10.0, the value is set to 10.0.
If the value is invalid, the default value (1.0) is used.
Example
SpoolFileSize,10.0

Control DLL Collection and Project Lasso Shares

The following parameters control DLL collection and Project Lasso shares.
DllLoadInterval
(Optional) Identifies the amount of time, in seconds, between when Project Lasso attempts
to collect String Resource DLL files into the Project Lasso Repository.
DllLoadInterval,value
Usage Notes
Range: 900 (15 min) through 2592000 (1 month).
If the value is invalid, the default value (3600; hourly) is used.
Example
DllLoadInterval,86400
SkipInitDLLScan
(Optional) Skips Project Lasso’s normal startup check of all String Resource DLLs
required by all monitored hosts. The check collects any DLLs that are not already in the
Repository. Depending on the number of monitored hosts in hostlist.ini, this check
can delay log collection.
SkipInitDLLScan,0|1
If you are certain the Repository exists and contains all required DLLs, skip the check:
SkipInitDLLScan,1
Allowed values:
0 (initial DLL scan occurs; default)
1 (initial DLL scan is skipped)
If needed DLLs are not already in the Repository, event messages collected before the next
periodic DLL collection do not expand or parse correctly on the Appliance.
RepositoryPath
(Optional) RepositoryPath controls the directory where Project Lasso stores all resource
string .dll files necessary for text expansion of log messages. It is normally written by the
Project Lasso installation program, but can be modified manually. You must have enough
disk space available on your host machine. LogLogic recommends at least 20 GB free disk
space, unless Project Lasso is being used in agent mode to monitor only the local host.
RepositoryPath,path
Usage Notes
If the value is invalid, the default value of .\ (the current working directory where Project
Lasso is installed) is used.

Example
RepositoryPath,C:\Program Files\Lasso\LassoRepository\
EnableShareDlls
(Optional) Where possible, Project Lasso identifies and “shares” identical String Resource
DLLs. This frees up a lot of disk space on a Project Lasso Host monitoring many remote
systems. If all hosts are kept at the same level of Microsoft service packs and patch level,
they have mostly identical DLLs.
EnableShareDlls,0|1
DLLs are shared only if they appear identical and are used identically. For example, if the
same DLL is used in two different EventLog contexts, there are still two copies of the DLL.
EnableShareDlls disables this feature, copying every String Resource DLL used by every
monitored host to the Project Lasso host. Because this typically requires 100 to 300 MB of
disk space per remote host, LogLogic recommends keeping EnableShareDlls enabled.
Usage Notes
Allowed values: 0 (disable) or 1 (enable)
If the value is invalid, the default value (1) is used.
Example
To enable the identifying and sharing of DLLs:
EnableShareDlls,1
Note: The sharing of DLL files is done via an NTFS file system feature called “hard links.” If the
RepositoryPath is on a non-NTFS volume, shared DLLs are disabled.
The behavior of hard links can be confusing, because the sharing of physical files by
multiple hard link instances cannot be perceived in the Windows File Browser. Each
instance of a hard link looks like a complete instance of the physical file. If you examine its
properties in the Windows File Browser, each instance states the full size of the file. If you
add up the file sizes, the Project Lasso Repository seems to take the same amount of space
it did in 3.x or more, due to additional directory structures added for Shared Repository
support. However, if you query the volume free space before and after creating the Project
Lasso Repository, the actual disk usage of the Repository is far less than the sum of the
hard link file sizes.
When you install Project Lasso 4.x over a 3.x installation, it replaces the old Project Lasso
Repository with the new shared repository during the first DLL collection cycle.
EnableAdminSharesIfDisabled
(Optional) Temporarily re-enables Administrative Shares to allow collection of String
Resource DLLs from remote hosts.

Some sites disable Administrative Shares for security reasons, so this option lets Project
Lasso re-enable them long enough to collect DLLs, then disables them again. Project Lasso
must be running with Administrator privileges, and Project Lasso Shares cannot also be in
use (see DefaultLassoShare).
EnableAdminSharesIfDisabled,0|1
0 (disabled Admin Shares are inaccessible; default)
1 (disabled Admin Shares are temporarily enabled during DLL collection)
Example
To allow temporary re-enabling of Administrative Shares for DLL collection:
EnableAdminSharesIfDisabled,1
DefaultLassoShare
(Optional) Allows the configuration of a Windows Share on each target host, specifically
for use by Project Lasso. The use of Administrative Shares is then no longer necessary.
DefaultLassoShare,sharename=sharepath
If absent, there is no Default Lasso Share. If present, it defines a Project Lasso Share name
that is created on each monitored host. This default can be overridden on a per-host basis
in the hostlist.ini file.
If Project Lasso runs as a domain administrator, the default Default Lasso Share is
automatically created. If Project Lasso does not run as a domain administrator, Project
Lasso can automatically create the Default Lasso Share only if it has sufficient access.
Otherwise, it must be created using the lasso.exe -c command.
Usage Notes
sharename and sharepath must not include 'comma' or 'equal sign' characters.
sharepath must be terminated by a '\' character.
sharepath can include special substrings which are interpreted relative to their meaning
on each monitored host:
%SYSTEMDRIVE% - the root drive where Windows is installed, for example: C:
%SYSTEMROOT% - the path where Windows is installed, for example: C:\Windows
These special substrings are not available in hostlist.ini, only with the
DefaultLassoShare keyword in Lasso.ini.
Example
DefaultLassoShare,LassoShare=%SYSTEMDRIVE%\LassoShare\
IMPORTANT! The Project Lasso Share does not have to publish any existing directories on the
host, in particular the directories that contain String Resource DLLs. For example, it should not point
to C:\windows. To improve security, LogLogic recommends using a directory path that points to a
uniquely named subdirectory that does not exist and/or contains no data files, such as
C:\LassoShare\. The Project Lasso Share is used only as an intermediate transfer area, and only
needs a few hundred MB of space on its volume.

Error Logging, Tracing, and Access Reporting

The following parameters control error logging, tracing and access reporting.
DebugLevel
(Optional) Enables Project Lasso to write messages into a trace file (LassoTrace.log, in
the Project Lasso program installation folder).
DebugLevel,value
The value variable controls the types of messages to trace.

Table 3 Trace Output Types
Output Type Value Description
Disable 0 default
Error 1 Project Lasso encountered an unrecoverable situation that results in loss of
functionality.
Warning 2 Project Lasso encountered a situation that might result in loss of
functionality.
Info 4 Project Lasso encountered a situation that the user should notice.
Debug 8 (For LogLogic Customer Support use) Project Lasso notes every minor and
recoverable error.
Trace 16 (For LogLogic Customer Support use) Project Lasso displays step in and
out of various modules of the program.
Examples
To disable Trace:
DebugLevel,0
To enable Trace for Error, Warning, and Info = 1 + 2 + 4 = 7:

DebugLevel,7
To enable Trace for Error, Warning, Info, Debug, Trace = 1 + 2 + 4 + 8 + 16 = 31:

DebugLevel,31
LogLevel
(Optional) Enables Project Lasso to write eventlog entries. If Project Lasso is monitoring
the localhost, the messages are sent to the log appliance.
LogLevel,value
The messages and level setting are identical to the DebugLevel keyword. This keyword
separately controls the type of messages written to the eventlog.
Default is 1.
MaxTraceFileSize
(Optional) Controls the maximum size, in MB, of LassoTrace.log until the output
wraps around to the beginning of the file.

MaxTraceFileSize,size
Default is 20.
AccessReport
(Optional) Enables Project Lasso to write summary resource access reports. The report file
is LassoAccessReport.log located in the Project Lasso program installation folder.
AccessReport,value
These values set the level of detail in the report:

0 - Disable
1 - Resource access result success or failure
2 - Level 1 message plus error code or error message associated with this attempt
3 - Level 2 message plus data result from the access
Default is 0.
IMPORTANT! SkipInitialDLLScan impacts the AccessReport.
AccessReportFileSize
(Optional) Controls the maximum size, in MB, of LassoAccessReport.log until the
output wraps around to the beginning of the file.
AccessReportFileSize,value
Default is 20. Range is 1 through 1000.

Configuring Project Lasso as a Windows Service
Configuring Project Lasso as a Windows Service

When running in collectore mode, Project Lasso runs as a Windows Service, so you must
first configure it as a Service.
1. Set up the Windows Services parameters on the Project Lasso host machine.
a. On the Project Lasso host machine, open the Windows Services control panel:
Start Menu, click Settings > Control Panel and then Administrative Tools >
Services
The Services Window appears.
b. Scroll down to find the Project Lasso Windows Event Collector service.
c. Right-click the Project Lasso Windows Event Collector service, and then select
Properties.
d. On the General tab, set Startup type to Automatic, and then click Apply.
e. On the Log On tab, in the Log on as field, select This Account, enter the Project
Lasso User ID and associated password, and then click OK.
The Project Lasso User ID is you used to log into the Project Lasso host machine. If
you do not have the password for this ID, check with your System Security
Administrator.
f. Click the Recovery tab. Set First failure, Second failure, and Subsequent failures to
Restart the Service. If not, set them to “Restart the Serve”, then click the Apply
button. (In Project Lasso 4.0, these settings are already done by the Installer.)
g. Click OK.
Note: If any of these steps are prevented by the security settings in your Domain, ask your System
Security Administrator for help. Your administrator might need to log in as himself and repeat the
configuration steps.
2. Confirm the changes in Step 1 were made. Do not click in the Log on as or Password
fields again, as this might reset the entries.
Project Lasso is now configured to run as a Windows Service. See Running Project Lasso as
a Service on page 29.

Configuring Site-Specific Network Details

In addition to controlling user privileges, some Windows environments use host names or
IP addresses, or host-based firewall software, to control remote access.
1. Grant remote access authorization to the Project Lasso host machine on every
Windows machine it monitors.
This is separate from the privileges of the Project Lasso User ID with Domain User
permissions. Many host-based firewall software packages limit machine-to-machine
access in Windows 2003. Prior to Windows 2003, this access was unlimited.
2. Ensure each monitored machine is running Windows Management Instrumentation
(WMI).
WMI is required on every monitored system. WMI runs by default on all Windows
operating system versions supported by Project Lasso. However, if WMI is turned off
or network access is restricted, Project Lasso cannot monitor that host.
3. Ensure the services Remote Procedure Call (RPC), Remote Registry, and DCOM, are
running on all monitored machines. These services are typically on by default.
4. Configure access to Shares on all monitored machines, to allow transport of String
Resource DLLs from the remote hosts to the Project Lasso host:
If Project Lasso has Administrator privileges on the Windows hosts, use the
Administrative Shares, which are enabled by default on all Windows hosts.
Otherwise, create Project Lasso Shares. By specifying a default Lasso Share in
Lasso.ini, or Project Lasso Shares for specific hosts in hostlist.ini, you can
enable special shares that are used only by Project Lasso. Creation of these shares
requires Project Lasso to run under the Domain Administrator user ID, but
thereafter the Shares persist unless you deliberately remove them.
If no Project Lasso Shares exist, Project Lasso tries to use Administrative Shares. If
Administrative Shares is turned off or network access is restricted, Project Lasso
periodically attempts to use WMI to enable it briefly for DLL file collection. This is
attempted only if the Lasso.ini parameter EnableAdminSharesIfDisabled is
set to 1. If this succeeds it might generate a Security audit log message. If it fails,
Project Lasso cannot collect message expansion resource files from that machine.
In this final case, if shared DLLs are enabled (EnableShareDlls), Project Lasso
attempts to find a match in the current Repository for the DLLs needed. If it finds a
match, Project Lasso uses it. Otherwise, log messages from that machine are
incorrectly parsed by the LogLogic appliance for report purposes.

Configuring Site-Specific Network Details

CHAPTER 3 Running Project Lasso
C HAPTER 3
Running Project Lasso
Once configured, you can run Project Lasso as a Windows Service.

Running Project Lasso as a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Running Project Lasso as a Service

If you configured Project Lasso as a Windows Service (page 26), you can start the service.
To run Project Lasso as a Windows service, on the Project Lasso host machine:
1. Verify that the hostlist.ini and Lasso.ini files are configured as needed.
2. Open the Windows Services control panel:
Start Menu > Settings > Control Panel and then Administrative Tools > Services
The Services Window appears.
3. Scroll down to find the Project Lasso Windows Event Collector service.
4. Right- click the Project Lasso Windows Event Collector service, and then click Start.
The Status column for the Project Lasso Windows Event Collector service changes to
Started.
Project Lasso runs indefinitely unless otherwise stopped or paused.
Note: To stop the Project Lasso Windows Event Collector, go to the Services control panel,
right-click the Project Lasso Windows Event Collector service, and then click Stop.

Running Project Lasso as a Service

CHAPTER 4 How Project Lasso Works
C HAPTER 4
How Project Lasso Works
Project Lasso converts Windows Event Logs into a syslog stream that a LogLogic
appliance can collect. You can configure Project Lasso to monitor multiple machines
across your network from a single Windows host machine. There is no need to install
additional software on each monitored machine.
All messages are delivered to an appliance through the syslog-ng protocol (TCP).
Syslog-ng lets you specify the original source IP Address, so the LogLogic appliance
recognizes it as having come from the original source host, and not the Project Lasso host.
Agent and Collector Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Windows Services Control Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Configuration Parameters in the lasso.ini File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Target Hosts Monitored Using the hostlist.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Using Multi-Threading for Parallel Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Accessing Registry Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Locating String Resource DLL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Building the Project Lasso Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Event Messages from Monitored EventLogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Expanding EventLog Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Traceability and Field Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Scalability and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 1 How Project Lasso Works
1. Windows Services Control

Module starts
2. Read configuration from 4. Start monitoring (multi-threaded)
lasso.ini 5. Test connectivity
3. Read hosts from hostlist.ini 6. Locate String Resource DLL files
Lasso Monitored
LogLogic
Windows Windows
Appliance 9. Expand EventLogs Host System
into readable form
7. Copy DLLs to Lasso Repository
10. Send expanded EventLogs 8. Collect new events from
to appliance monitored EventLogs

Agent and Collector Modes
Agent and Collector Modes

Project Lasso can be installed in two operational modes:
Agent mode - Project Lasso collects and forwards messages from the system on which
it is installed.
Use agent mode if you only need logs from the system on which Project Lasso is
installed.
Collector mode - Project Lasso collects and forwards messages from systems other
than the system on which it is installed.
Use collector mode if you need one system to gather logs from multiple other systems.
Project Lasso can also run in both agent and collector modes at the same time. This hybrid
mode has the system on which Project Lasso is installed collect and forward messages
both from itself and multiple other systems.
The mode Project Lasso runs in is simply set based on the log sources designated in the
.ini files while configuring Project lasso.
Windows Services Control Module

When running Project Lasso in collector mode, the Windows Services Control Module
starts the Project Lasso service. Project Lasso is usually configured to auto-start when the
system is started and to auto-restart when a process failure occurs.
The Project Lasso Service runs under a Domain User ID on the Windows host and, for
remote access to the Windows Security Event Log and other protected resources, requires
certain permissions in the Domain and/or on each monitored host.
Configuration Parameters in the Lasso.ini File

Project Lasso reads its configuration parameters from the Lasso.ini file. This file, in the
installation directory on the Project Lasso Host, contains about 20 parameters that specify
various Project Lasso behaviors including where it should send collected event logs, the
polling interval for log collection, and various resources, protocols, and time outs.
Many of these parameters are set during installation, using InstallShield. The Lasso.ini
file is a simple CSV (comma-separated values) file, so you can edit the parameter values
after installation with a text editor or Microsoft Excel. Many of the parameters can be
edited during Project Lasso execution; such edits are re-read on each polling cycle.

Target Hosts Monitored Using the hostlist.ini File

The hostlist.ini file, also in the installation directory on the Project Lasso Host,
details which target hosts Project Lasso monitors and which EventLogs to monitor on
each of those hosts. Target hosts can be identified by NetBIOS name, fully qualified
domain name, or IP address. Every host can have a different list of monitored EventLogs.
hostlist.ini initially contains only localhost, for agent-style self-monitoring of the

Project Lasso Host. However, after installation the file can be edited to add other target
hosts. The hostlist.ini file is a simple CSV file, so you can edit long complex lists of
hosts and eventlogs with a text editor or Microsoft Excel. Depending on the resources of
the Project Lasso Host and total rate of EventLog generation by the monitored hosts, one
Project Lasso installation might be able to monitor up to several hundred target hosts.
hostlist.ini can be edited during Project Lasso execution. It is not necessary to stop
and restart Project Lasso to add new target hosts to the list.
Using Multi-Threading for Parallel Processing

Project Lasso starts monitoring hosts using multi-threading for parallel processing. The
number of simultaneously running threads is configured in the Lasso.ini file. The
recommended value is four times the number of CPUs in the Project Lasso Host.
Because Project Lasso is multi-threaded, it is not always predictable which hosts are being
polled at a specific time. Project Lasso typically collects from more than one host at a time.
Testing Connectivity
For each monitored host, Project Lasso tests connectivity. Project Lasso first attempts to
check whether the target host is available for communication over the network, by
sending it an Echo message using TCP port 7.
If the target hosts are running Windows Firewall, port 7 is blocked by default. In this case,
to turn off the Echo test add CheckRemHostAvail,0 to Lasso.ini. For more details,
see Testing Project Lasso Communication with Monitored Hosts through a Firewall on page 44.
Project Lasso performs the Echo test. If an expected host is not available on the network,
Windows networking APIs can take between 30 seconds and 2 minutes to time out.
During this time, one of the Project Lasso threads is blocked and unavailable for other
work. Non-response to the Echo test takes only a few seconds. So if you turn off the Echo
test, it is important to have a clean hostlist.ini file, without large numbers of
unavailable target hosts.
Accessing Registry Entries

For each monitored host, Project Lasso attempts to access the Registry entries for each
monitored EventLog.

Locating String Resource DLL Files
This is the first activity that requires Remote Access network privileges. Using Windows
RPC APIs, Project Lasso reaches out to each monitored host, and reads certain registry
entries associated with each monitored EventLog on those hosts.
If permissions are granted according to Appendix A, Permissions and Security

Considerations for Project Lasso, this step occurs silently. If it fails, error events are written to
the Application EventLog on the Project Lasso Host.
Locating String Resource DLL Files

String Resource DLL files are located for each monitored host.
The Registry entries for each EventLog specify the location of String Resource DLL files.
These are the files needed to convert the original, compressed native form of Windows
EventLog messages into the expanded, human-readable form seen in “Event Viewer” and
in the LogLogic Appliance reports.
Each EventLog can reference up to three String Resource DLL files. For each DLL file,
Project Lasso attempts to transport a copy back to the Project Lasso host. This lets log
message expansion occur on the Project Lasso Host, avoiding computational load on the
target servers, and providing much higher Project Lasso performance.
These String Resource DLL files contain no customer data. Most are simply standard
Microsoft files distributed with the Windows operating system. Application-specific or
custom event logs are files distributed and installed with each application by the
application vendor.
Building the Project Lasso Repository

There are three methods to build the Project Lasso Repository to contain String Resource
DLLs. The method you choose depends on the security requirements of your network
environment. For more details, see Appendix A, Permissions and Security Considerations for
Project Lasso.
IMPORTANT! If you use Project Lasso in “agent” mode, monitoring only the localhost, you install it
using the User ID “Local System”. In this case, you do not need any of these three methods.
Everything is handled without administrative effort.
Unless using “agent” mode, you must use one of these three methods. Otherwise, while
EventLog collection might be successful, the text of the messages is not human-readable
because Project Lasso cannot perform message text expansion from the original
compressed format.
The three methods are:

Allow the Project Lasso User ID to run with Domain Administrator privileges.
If this method is allowed, Project Lasso has all necessary access to target hosts in the
Domain, and the Project Lasso Repository is built and maintained automatically
without further effort by the administrator.

Manually maintain the Project Lasso Repository on the Project Lasso Host, using
periodic Administrator setup.
A Security Administrator can perform a “manual” DLL collection, by logging into the
Project Lasso Host using a Domain Administrator user ID, then running Project Lasso
from the command line with the -c option:
\Lasso-installation-directory-path\lasso.exe -c
This causes a manual build of the Project Lasso Repository, performing a one-time
collection of all DLL files needed for the hostlist.ini file at the time.
This method requires no special privileges for Project Lasso. However, you must
repeat this manual process periodically (LogLogic recommends at least once per
month) to track modifications and updates in the DLL files due to Windows and
application updates.
When new hosts are added to hostlist.ini, their DLL files are not in the
repository until the next manual collection. In the interim, if there are shared DLLs
in the Repository, Project Lasso attempts to use the most current DLL file of the
same name/usage from all other monitored machines. In most circumstances this
lets Project Lasso correctly perform message text expansion for all standard
eventlogs.
If a new server is added to hostlist.ini which hosts a custom application
EventLog not present on any other monitored host, it might be necessary to run a
manual DLL collection immediately to let Project Lasso perform message text
expansion on the new custom logs.
Allow non-administrative remote access for the Project Lasso User ID on each target
host, including DCOM, WMI, and non-admin Shares.
To let Project Lasso collect DLLs without having Domain Admin privileges, configure
a non-administrative “Lasso Share” on each target host. You can configure this:
Globally in Lasso.ini (see Setting Run-Time Parameters on page 14)
Per-host in hostlist.ini (see Setting Hosts and Event Logs to Monitor on page 11)
It is not necessary to manually create the Lasso Share on each target host, although you
can. Instead, a Security Administrator logged in with Domain Administrator
privileges can run Project Lasso once from the command line with the -c option. At
the end of that cycle, Project Lasso has created the Lasso Shares on all target hosts, per
the configuration options in Lasso.ini and hostlist.ini.
Thereafter, Project Lasso can run without Domain Admin privileges and can still use
the non-administrative Lasso Shares for access to the String Resource DLLs. The
Project Lasso Repository is built and maintained automatically without further effort
by the administrator. For more information about Lasso Shares, and how they are used
see Control DLL Collection and Project Lasso Shares on page 21.
To use this option, Windows requires some complex administrative configuration

actions. Some of these actions can be done once via Active Directory Group Policies.
Other actions must be performed on each monitored host. For details, see Collecting
DLLs in the Project Lasso Repository on page 41.

Event Messages from Monitored EventLogs
If the first or third (automated) method is used to build the Project Lasso Repository,
Project Lasso periodically refreshes the Repository contents. It checks the size and
modification date of each referenced DLL, and compares it to the size and modification
date of the corresponding DLL in the Repository. If they differ, the target host was
updated, and the new DLL is copied to the Repository.
If the second (manual) method is used, Project Lasso depends on system administrators to
keep the Project Lasso Repository current.
Event Messages from Monitored EventLogs

For each monitored host, Project Lasso collects new event messages from each monitored
EventLog.
This requires Remote Access network privileges. Microsoft specifies that remote access to
the Security EventLog requires Administrator privileges on the target host. If you run
Project Lasso without Domain Administrator privileges, this requirement can be
overridden by certain Windows configuration choices, either on the target host or in
Active Directory Group Policies. For details, see Appendix A, Permissions and Security
Considerations for Project Lasso.
Project Lasso has two configuration parameters that affect how it collects new EventLog
messages: HighWaterMarks and NewHostSkipHistorical. Project Lasso stores
high-water marks of the last processed events for all monitored EventLogs in a file. Upon
implicit restart, such as a system reboot or if Project Lasso goes down, the restart is from
the high-water marks per monitored EventLog. They can be used to cause Project Lasso to
re-collect all available event messages, or to prevent Project Lasso from collecting old,
historical event messages on newly monitored hosts. For details, see Control Event
Collection and Spooling on page 18.
Expanding EventLog Messages

Collected EventLog messages are expanded to human-readable form and sent to the
LogLogic Appliance.
This is a complex process, but independent of the preceding network security issues. All
event messages collected by all threads are expanded to human-readable form, then
combined into a single syslog-ng stream, and sent to the appliance. There they are
archived, parsed, and reported.

Traceability and Field Debug

Project Lasso has a trace functionality for field debug. Six levels of tracing are supported:
None, Error, Warning, Info, Debug, and full Trace.
Trace messages can be written to a trace file or to the Application EventLog on the Lasso
Host. These options are controlled by the DebugLevel and LogLevel configuration
parameters in Lasso.ini.
Project Lasso can also generate a report of all resource access attempts and results for
monitored hosts. This lets you determine whether remote host Registry, String Resource
DLLs, and EventLogs are available and accessible to Project Lasso. This is a starting point
for fixing Security and Permissions issues. This option is controlled by the
AccessReport configuration parameter in Lasso.ini.
For more details, see Error Logging, Tracing, and Access Reporting on page 24.
Scalability and Performance

For horizontal scalability, use multiple parallel Project Lasso instances. To avoid duplicate
logging, monitor each Windows host with a single Project Lasso instance.
Project Lasso performance can vary widely, depending on several factors:

number of hosts and workstations to monitor
total number of events generated by all hosts, and per host on average
maximum number of events generated by a single host
number and size of event logs Project Lasso is monitoring
available resources (CPUs, amount of RAM) on the server running Project Lasso
effective network bandwidth

Scalability and Performance

APPENDIX A Permissions and Security Considerations for Project Lasso
A PPENDIX A
Permissions and Security Considerations

for Project Lasso
Contents
Authentication and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Privileges Required for the Project Lasso User Account . . . . . . . . . . . . . . . . . . . . . . . 40
Collecting DLLs in the Project Lasso Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authentication and Access

In the Windows Operating System, all access privileges are allowed based on the User
Name. Before accepting that a user or process has the right to access a computer while
using a given User Name, it is authenticated by means of the Password. The
authentication process differs depending on whether:
access to the computer is local or remote
the computer being accessed is a member of a Domain
The three main scenarios are:

1. If Project Lasso is running in agent mode, accessing only the localhost, it should use
the “Local System” user name.
This is the default when Project Lasso is installed. This user name has no password
and, according to Microsoft, cannot be faked or spoofed. It is therefore very secure. It
also has local administrative privileges on the localhost, and so has easy access to all
information required for EventLog collection.
If this is your situation, you do not need this section.
2. If Project Lasso is performing remote collection, where both the Project Lasso Host and
the remote target hosts are all members of a Domain, the remote hosts use Active
Directory to authenticate the Project Lasso User Name and Password.
If a hierarchical forest of Domains is in use, the Project Lasso User Name must be
defined in the Domain hierarchy at a level where it can be authenticated by all target
hosts. Only one Project Lasso User Name can be used per Project Lasso host
installation.
Note: Although Project Lasso accesses all remote hosts using the same Domain User Name,
nevertheless, that User Name might have different privileges on different remote hosts.
Appropriate privileges must be set so that Project Lasso can work properly on each remote

Privileges Required for the Project Lasso User Account
host. These privileges are best set globally using Active Directory Group Policies, but can also
be set via administrative operations on individual target hosts. See Privileges Required for the
Project Lasso User Account.
3. If Project Lasso is performing remote collection from a target host that is not a member
of a Domain, Windows provides a different means to establish remote authentication:
If the Project Lasso Host is on a Domain, Project Lasso should still use a Domain
User Name and password.
If the Project Lasso Host, like the target host, is not on a Domain, Project Lasso can
use a Local User Name and password created directly on the Project Lasso Host.
In either case, a local user account using the SAME User Name and password must be
created on the target host. When Project Lasso tries to access the non-Domain target
host, it passes in its User Name and password from the Project Lasso Host to the target
host. If these match a Local User Name and password on the target host, access is
allowed.
As above, authentication is a separate issue from privileges. Appropriate privileges for
this Local User Name must be set on the target host, so Project Lasso can work
properly on the remote host. Since the remote host is not a member of a Domain, these
privileges must be set locally via administrative operations directly on individual
target hosts.
Privileges Required for the Project Lasso User Account

As noted in Configuring Site-Specific Network Details on page 27, all target hosts must
enable remote access to RPC and DCOM services, and to the Registry, EventLogs, and at
least one Share. Beyond this, however, the Project Lasso User Name must also be
privileged to use these services remotely for each target host.
If your site allows running the Project Lasso service with Domain Administrator
privileges, everything is simple. Add the Project Lasso User Name to the Domain
Administrators Group in Active Directory, and it automatically has all privileges required
on all target hosts in the Domain. You can skip the rest of this section.
By the same logic, for remote target hosts that are not on the Domain, the easiest solution
is to add the Project Lasso User Name to the Local Administrators Group on each target
host.
If you are running Project Lasso in agent mode, collecting logs from only the localhost, it
should run under the user name “Local System”. As observed previously, this secure user
name has local administrative privileges on the localhost.
If remote log collection must be done without administrative privileges, it becomes much
more complex to configure the privileges for the Project Lasso User Name. On each target
host the following privileges must be enabled, either globally via Group Policies, or
locally on each target host via individual administrative operations:
WMI remote access
DCOM remote access
EventLog remote read access to all EventLogs which you want to monitor

APPENDIX A Permissions and Security Considerations for Project Lasso
Registry remote access for read, query, and enumerate, to the following registry
subtrees:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
(“windir” key only - provides “%WINDOWS%” path value)
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion (“SystemRoot” key
only - provides “%SystemRoot%” path value)
HKLM\SYSTEM\CurrentControlSet\Services\EventLog (full sub-tree must be
traversable - holds all DLL path information, per EventLog and per Source)
By default:
Most Windows systems let any authenticated Domain User have remote access to all
the above Registry paths and EventLogs, except those related to the Security
EventLog.
Only administrators are allowed remote access to the Security EventLog and its related
Registry entries.
Because the Security event log contains the events of most interest for log management,
you must provide a non-default configuration to allow remote access to this part of the
Registry and EventLog for the Project Lasso User Name without administrative
privileges. Your Security Administrator might be able to help you do the necessary
configurations.
Access to the Security event log on Windows XP Pro can be controlled via the Local
Security Policy: Local Security Setting > Local Policies > User Rights Assignment >
Manage auditing and security log. You can assign a Lasso user with this privilege.
However, this Lasso user gets full control of the security logs, including deleting,
resetting, and so on, similar to the local administrator. There is no known way to grant just
read-only access.
WMI and DCOM remote access are only used for String Resource DLL collection, so you
need not enable them for non-administrative access if you can do either of:
Allow Project Lasso to run with administrative privileges
Build the DLL Repository manually, using an administrative log-in
Collecting DLLs in the Project Lasso Repository

Project Lasso requires building a Project Lasso Repository of String Resource DLLs on the
Project Lasso Host. It uses these copies of DLLs to perform string expansion of the event
messages into human-readable form. Without these DLLs, event messages are not
expanded, and are not correctly parsed or reported in the Log Appliance.
For information about the three methods for building the Project Lasso Repository, see
Configuring Site-Specific Network Details on page 27 and Building the Project Lasso Repository
on page 34.
Beyond the three methods for building the Repository, there are also three methods for
collecting DLLs into the Repository:

Collecting DLLs in the Project Lasso Repository
Collect all DLLs from every remote host, using Administrative Shares. This is the
default collection method, if no other method is configured. This method can be a
performance burden for some sites.
Shared DLLs in the Repository, so that DLLs common to multiple hosts can be copied
just once, and used by all. With Shared DLLs, DLL collection does not necessarily have
to occur for all hosts, as long as at least one instance of each needed DLL is collected
from a host (such as only the Project Lasso Host).
Shared DLLs makes the system much more forgiving of failure to collect DLLs from
some remote hosts, as long as a comparable DLL is available on the Project Lasso Host
or some other host where Project Lasso has privileges to collect DLLs.
Application-specific Project Lasso Shares so that collection can take place without
administrator privileges and from systems that have Administrative Shares disabled.
Project Lasso Shares are not a panacea. Using them instead of Administrative Shares is
simple: specify a DefaultLassoShare in Lasso.ini, or a host-specific Lasso Share
name for the hosts you want in hostlist.ini. However, this alone is not sufficient
to guarantee non-administrative access to DLLs on a remote host. You must also
enable the Project Lasso User Name for DCOM and WMI on each remote host, as
specified in Privileges Required for the Project Lasso User Account on page 40.
The easiest way to overcome these limitations is to manually build the Project Lasso
Repository using the lasso.exe -c command. Project Lasso Shares work with this
command or as required when Administrative Shares are explicitly disabled.
To build, rebuild, or delete the Project Lasso Repository, run lasso.exe with the
appropriate option. You can run lasso.exe regardless of whether Project Lasso is
configured as a service, though you should run it in this manner only when manually
maintaining the Project Lasso Repository (the second method in Building the Project Lasso
Repository on page 34).
There are three options when running lasso.exe:

Lasso.exe -c
Creates the Project Lasso Repository.
Initiates a single collection of DLLs from all monitored hosts in hostlist.ini.
Creates all Project Lasso Shares, if any, specified in Lasso.ini or hostlist.ini.
Lasso.exe -cl
Similar to the -c option, but collects DLLs only from the localhost. This is useful to
refresh the Shared Repository after a Windows Update.
Lasso.exe -d
Deletes any previously created Project Lasso Shares for hosts in hostlist.ini.
Caution: Stop the Project Lasso service before you run lasso.exe -d.
When you run lasso.exe manually, Project Lasso is executed with the privileges of the
currently logged-in user account.

APPENDIX B TCP/IP and UDP/IP Ports Used by Lasso
A PPENDIX B
TCP/IP and UDP/IP Ports Used by Lasso
Contents
Lasso Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Testing Project Lasso Communication with Monitored Hosts through a Firewall . . . . . 44
Lasso Ports
Communication between the Lasso host and the LogLogic appliance is via protocol and
default port number:
"syslog-ng protocol -- TCP port 514 (default)
The TCP syslog port number is not configurable on the Appliance.
For agent use, when monitoring only the localhost, Project Lasso can be configured in
Lasso.ini to communicate with the LogLogic appliance via:
"syslog protocol -- UDP port 514 (default)
The default UDP port number can be modified by configuring it on both the appliance
and in Lasso.ini.
All communications between the Lasso host and monitored Windows servers is via
Windows SDK API calls and Windows WMI calls. These calls use the following Windows
protocols and ports:
RPC (for remote registry and eventlog access) -- TCP port 135
SMB (for remote DLL and File System access) -- TCP port 445
Echo (checking TCP/IP connection availability) -- TCP port 7
These services also use dynamically assigned ports numbered above 1024.
The use of Echo on port 7improves performance when servers listed in hostlist.ini
become unavailable. Project Lasso fails to download DLLs if port 7 is blocked, and
Windows Firewall, among others, blocks Port 7 by default. Echo can be turned off by the
Lasso.ini parameter CheckRemHostAvail,0.
The TCP syslog port is not configurable on the Appliance

Testing Project Lasso Communication with Monitored Hosts through a Firewall
Testing Project Lasso Communication with Monitored Hosts

through a Firewall
To test whether Lasso works through a firewall:
1. Log in to the Lasso Host using the Lasso User ID and password.
2. Open the Event Viewer.
3. Attempt to connect to the remote host that you intend to monitor, and view its logs.
If you can successfully view the remote logs using Event Viewer, it is highly probable
that Lasso event collection will work fine.
To check DLL file collection, try to open the remote host's Admin Shares or, if
configured, the DefaultLassoShare or other LassoShare path configured for the
particular target host in hostlist.ini, using the following steps.
First, discover the Admin Shares available on the target host. (If you are using
non-Administrative Shares, skip these three steps.)
4. Open the “Computer Management” MMC.
5. Connect to the remote host, and view its shares.
6. Confirm that you can view the Admin Shares (C$, E$, etc.), and which ones exist on
that host.
Now see if you can mount and browse the shares.
7. Open the “Start : Run…” window on the Lasso host.
8. In the “Run…” window, type \\remotehostname\AdminShareName\ or
\\remotehostname\LassoShareName\
and confirm that you can mount and browse the specified share from that host.
If both Step 3 and Step 8 work, Lasso should have no difficulty. If either fails, you have an
easier environment than Lasso for tracking down the networking and/or permissions
issues and changing them. The port numbers mentioned above will be helpful if you need
to drill a hole in the firewall, but start with the high-level tools.
This procedure does not test Echo on port 7. If the target hosts are running Windows
Firewall, port 7 is blocked by default. If the above works but DLL collection is not taking
place for any host except localhost, try turning off Echo on port 7 by adding
CheckRemHostAvail,0 to Lasso.ini. For more information, see CheckRemHostAvail
on page 16.

LassoUserGuide 4.0.5

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LassoUserGuide 4.0.5

Transféré par

Droits d'auteur :

Formats disponibles

Project Lasso 4.0.

LogLogic Windows Event

Software Release: 4.0.2

Chapter 1 Installing Project Lasso

Chapter 2 Configuring Project Lasso

Windows Event Collector (Project Lasso) Guide 3

Configuring Site-Specific Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 3 Running Project Lasso

Chapter 4 How Project Lasso Works

Appendix A Permissions and Security Considerations for Project Lasso

Appendix B TCP/IP and UDP/IP Ports Used by Lasso

4 Windows Event Collector (Project Lasso) Guide

About This Guide

Project Lasso can monitor the following servers and workstations:

Windows Event Collector (Project Lasso) Guide 5

6 Windows Event Collector (Project Lasso) Guide

Installing Project Lasso

Prerequisites for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Installing Project Lasso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Scripted Installation of Project Lasso on Multiple Systems . . . . . . . . . . . . . . . . . . . . . 10

Prerequisites for Installation

Windows Event Collector (Project Lasso) Guide 7

Installing Project Lasso

Installing Project Lasso:

8 Windows Event Collector (Project Lasso) Guide

f. Select the spooling directory location to create; click Next.

Log messages, if the connection to the LogLogic appliance is lost. LogLogic

Other data files written by Project Lasso, including

LogLogic appliance information - the appliance IP address and port number

Monitoring parameters - certain Project Lasso performance defaults.

Windows Event Collector (Project Lasso) Guide 9

Scripted Installation of Project Lasso on Multiple Systems

10 Windows Event Collector (Project Lasso) Guide

Configuring Project Lasso

Setting Hosts and Event Logs to Monitor

To modify the hostlist.ini file:

Windows Event Collector (Project Lasso) Guide 11

a. hostname identifies the system to monitor:

If there are multiple IP addresses on the machine to monitor, specify the IP

Enter one or more (comma-separated) EventLog names, specifying particular

*3 specifies three standard Windows 2000/2003/XP logs: Security, Application,

*6 specifies six standard Windows 2000/2003 logs: System, Security, Application,

sharename and sharepath cannot include a comma or equal sign.

sharepath must be terminated by a back-slash character.

4. Enter comments as needed, by starting a line with the # character.

12 Windows Event Collector (Project Lasso) Guide

hostlist.ini File Example

Table 1 hostlist.ini File Example Details

Windows Event Collector (Project Lasso) Guide 13

Setting Run-Time Parameters

To modify the Lasso.ini file:

4. Enter comments as needed, by starting a line with the # character.

14 Windows Event Collector (Project Lasso) Guide

Lasso.ini Configurable Run-Time Parameters

Table 2 Lasso.ini Configurable Run-Time Parameters

Windows Event Collector (Project Lasso) Guide 15

Basic Project Lasso Configuration

To specify appliance 192.168.22.199 using port number 1514:

To specify appliance LLAUSTIN using port number 1514:

To use UDP communications for appliance 192.168.22.199 using port 514:

16 Windows Event Collector (Project Lasso) Guide

value is the reload interval, in seconds. (default is 3600)

Valid values: = 1 to 99 (default is 4)