Understanding receiver settings:

LT Auditor ^MP uses Transformation Rules to define how incoming syslog data is received and processed. Each transformation rule specifies:

• The IP address the LT Auditor ^MP server listens on for incoming connections
• The port number the rule listens on
• The communication protocol — UDP, TCP, or TLS
• How the incoming log data is parsed and normalized into structured audit records

Two transformation rules are pre-configured for eDirectory and NSS auditing:

If these default ports conflict with other services in your environment, they can be changed in the transformation rule configuration.

Accessing transformation rules:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure in the main navigation menu
3. Locate the relevant transformation rule in the list:
   • The eDirectory rule (default port 5014)
   • The NSS rule (default port 5015)
4. Click the three vertical action buttons to the right of the rule
5. Select Edit to open the transformation rule configuration window

Reviewing and updating receiver settings:

Once the transformation rule configuration window is open:

1. Navigate to the Settings tab
2. Review and update the following fields as needed:

IP Address: The network interface on the LT Auditor ^MP server that will listen for incoming syslog connections from your OpenText systems.

Use a specific IP address if your LT Auditor ^MP server has multiple network interfaces and you want to restrict syslog reception to a specific one. Use 0.0.0.0 to accept connections on any interface.

Port Number: The port the transformation rule listens on for incoming syslog data.

If you change the default port, ensure the new port is:

• Not already in use by another service on the LT Auditor ^MP server
• Open in your firewall between the OpenText servers and the LT Auditor ^MP server
• Updated in the syslog forwarding configuration on your eDirectory and OES servers to match

Communication Protocol: The transport protocol used for the syslog connection between your OpenText servers and LT Auditor ^MP.

TLS configuration (if TLS is selected):

If TLS is selected as the protocol, additional settings are required:

[Your administrator should coordinate with your PKI or security team to obtain the appropriate certificates before enabling TLS.]

3. Click Save to apply your changes

Changes to transformation rule settings take effect immediately. If eDirectory or NSS servers are already forwarding logs to LT Auditor ^MP, updating the port or protocol will interrupt collection until the syslog forwarding configuration on those servers is updated to match.

Confirming the firewall allows the configured ports:

After reviewing or updating the transformation rule settings, confirm that your firewall allows inbound traffic on the configured ports from your OpenText servers to the LT Auditor ^MP server.

Test connectivity from an OES server to the LT Auditor ^MP server:

nc -zv <LT_AuditorMP_Host> <Port>

A successful response confirms the port is open and reachable. If the connection fails, review your firewall rules to ensure the required port is permitted.

[Your administrator should document the configured ports and protocols for both the eDirectory and NSS transformation rules so that OpenText system administrators can configure syslog forwarding to match.]

Duplicating transformation rules:

If your environment has multiple eDirectory servers or OES NSS servers that require different port assignments or protocol configurations, you can duplicate an existing transformation rule and modify the copy:

1. In the Configure page, locate the transformation rule to duplicate
2. Click the three vertical action buttons
3. Select Duplicate
4. Edit the duplicated rule with the new port or protocol settings
5. Click Save

This allows you to maintain separate receiver configurations for different OpenText systems in your environment.

Viewing transformation rule history:

LT Auditor ^MP maintains a version history of transformation rule configurations:

1. Open the transformation rule
2. Click View History
3. Review previous versions with timestamps
4. Revert to a previous version if needed

This is useful if a recent configuration change has caused collection issues and you need to restore a previously working configuration.

Best practices:

• Review transformation rule settings before configuring syslog forwarding on your OpenText systems — the port and protocol must match on both ends
• Use TCP or TLS rather than UDP in production environments for reliable log delivery
• Document the configured ports and protocols for all transformation rules and share them with your OpenText system administrator
• Test firewall connectivity from each OpenText server to the LT Auditor ^MP server before configuring syslog forwarding to catch network issues early
• Change default ports only if necessary — using standard ports simplifies troubleshooting and documentation
• If enabling TLS, coordinate certificate management with your PKI team well in advance of go-live

[Your administrator should include the eDirectory and NSS transformation rule port and protocol settings in your network documentation so firewall administrators can maintain the correct rules over time.]

Every LDAP server in your environment must be configured to forward eDirectory audit logs. Missing even one server will result in gaps in your audit data that may affect compliance reporting and incident investigation.

Understanding CEF audit log forwarding:

eDirectory generates audit log data in CEF format and forwards it via syslog to a configured destination — in this case, the LT Auditor ^MP server. There are two ways to configure this forwarding depending on your environment:

Both methods produce the same result — CEF audit events forwarded to LT Auditor ^MP on port 5014 (or your configured port).

Before you begin:

Confirm the following on each eDirectory server before proceeding:

• The LT Auditor ^MP transformation rule for eDirectory is configured and the server is listening on port 5014 (or your configured port) — see the Modifying Receiver Settings in LT Auditor ^MP article
• The firewall allows outbound syslog traffic from the eDirectory server to the LT Auditor ^MP server on the configured port
• You have administrative access to each eDirectory server — either via iManager or direct server access for configuration file editing

Option A — Configure via iManager (GUI):

Use this method if you prefer a graphical interface or are configuring a small number of eDirectory servers.

1. Open a browser and log in to iManager for the eDirectory server you are configuring
2. Navigate to eDirectory Auditing
3. Select your LDAP NCP server from the server list
4. Select CEF as the audit output format
5. Configure the syslog destination:
   • Host — the IP address or hostname of the LT Auditor ^MP server
   • Port — 5014 (or your configured port)
   • Protocol — TCP, UDP, or TLS to match your LT Auditor ^MP transformation rule setting
6. Enable the following event categories and save:

7. Click Save
8. Verify the configuration is active and eDirectory begins forwarding logs

[Your administrator should add screenshots of each iManager screen here to guide administrators who are less familiar with the iManager interface.]

Option B — Configure via configuration file (SLES LDAP Server):

Use this method for SLES Linux LDAP servers, large deployments, or where iManager access is not available.

Step 1 — Edit the audit log configuration file:

Open the audit configuration file on the eDirectory server:

sudo nano /etc/opt/novell/eDirectory/conf/auditlogconfig.properties

Uncomment and update the following lines. The example below uses TCP — replace TCP with UDP or TLS if required by your environment:

log4j.rootLogger=debug, S

log4j.appender.S=org.apache.log4j.net.SyslogAppender

log4j.appender.S.Host=<IP Address of LT Auditor MP>

log4j.appender.S.Port=5014

log4j.appender.S.Protocol=TCP

log4j.appender.S.Threshold=INFO

log4j.appender.S.CacheEnabled=no

log4j.appender.S.layout=org.apache.log4j.PatternLayout

log4j.appender.S.layout.ConversionPattern=%c: %m%n

Replace <IP Address of LT Auditor MP> with the actual IP address or hostname of your LT Auditor ^MP server.

Protocol options:

Save the file after making your changes.

Step 2 — Update the modules configuration file:

To ensure the CEF audit daemon restarts automatically when eDirectory is restarted or the server reboots, add the following line to the modules configuration file:

Open the file:

sudo nano /etc/opt/novell/eDirectory/conf/ndsmodules.conf

Add the following line:

cefauditds   auto     #cefauditds

Save the file.

Step 3 — Restart the CEF audit daemon:

Apply the configuration changes by restarting the CEF audit daemon:

ndstrace –c “unload cefauditds”

ndstrace –c “load cefauditds”

The daemon will restart and begin forwarding eDirectory CEF audit events to the LT Auditor ^MP server on the configured port.

Verifying eDirectory log forwarding:

After configuring syslog forwarding on the eDirectory server, verify that LT Auditor ^MP is receiving the data:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the eDirectory environment and category
4. Set the date range to Last 15–30 minutes
5. Confirm that eDirectory events are appearing in the event list

If no events appear:

Confirm the CEF audit daemon is running on the eDirectory server:
ndstrace –c “modules” | grep cefauditds

• Confirm no firewall is blocking outbound syslog traffic from the eDirectory server to the LT Auditor ^MP server on port 5014
• Confirm the IP address and port in the configuration file match the LT Auditor ^MP transformation rule settings
• Review the eDirectory server logs for any errors related to the CEF audit module

Repeating configuration across all eDirectory servers:

Repeat the configuration steps above — using either Option A or Option B — for every eDirectory LDAP server in your environment. Each server must be individually configured to forward its audit logs to LT Auditor ^MP.

To confirm all servers are forwarding:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Filter by Source or Host and confirm events are appearing from each eDirectory server
3. If any server is not appearing as a source, revisit the configuration on that server

[Your administrator should maintain a list of all eDirectory servers in the environment and confirm each one has been configured and verified before considering the deployment complete.]

Caching behavior during LT Auditor ^MP outages:

The eDirectory CEF audit configuration supports log caching to prevent data loss during temporary connectivity interruptions:

• When CacheEnabled=no is set (as in the configuration above), events are not cached locally — if the LT Auditor ^MP server is temporarily unavailable, events generated during that period will be lost

To enable caching and ensure no audit events are lost during outages, change the setting:
log4j.appender.S.CacheEnabled=yes

• When caching is enabled, events are stored locally on the eDirectory server and automatically forwarded to LT Auditor ^MP once connectivity is restored

[Your administrator should determine whether caching is required based on your organization’s audit data retention and compliance requirements. For compliance-critical environments, enabling caching is recommended.]

Best practices:

• Configure all eDirectory servers before considering the deployment complete — a single unconfigured server represents a monitoring gap
• Use TCP or TLS in production environments for reliable log delivery
• Enable caching if your compliance requirements mandate that no audit events are lost during connectivity interruptions
• Test log forwarding from each server individually after configuration rather than assuming all servers are working correctly
• Document which eDirectory servers have been configured, the protocol and port used, and the date of configuration
• Coordinate with your network team to confirm firewall rules are in place for all eDirectory servers — not just the first one you configure
• Add screenshots of the iManager configuration screens to the Option A section of this article to assist administrators less familiar with iManager

[Your administrator should revisit this configuration whenever new eDirectory servers are added to the environment, or when the LT Auditor ^MP server IP address or syslog port changes.]

Understanding the NSS Audit Agent:

Unlike eDirectory auditing which is configured directly within eDirectory itself, NSS file activity auditing requires a separate agent component — the LT Auditor ^MP OES module — to be installed on each OES server hosting NSS volumes. The agent:

• Monitors file system activity on NSS volumes in real time
• Captures file reads, writes, deletions, renames, and permission changes
• Forwards collected activity to LT Auditor ^MP via syslog
• Caches audit streams locally if the LT Auditor ^MP server is temporarily unavailable and automatically resends once connectivity is restored — no audit data is lost during outages

The agent must be installed individually on each OES server you want to monitor. Missing even one server results in a gap in your NSS file activity audit data.

Prerequisites:

Before installing the NSS Audit Agent, confirm the following on each target OES server:

[Your administrator should confirm the current version of the agent package and where to obtain it for your environment.]

Step 1 — Copy the agent package to the OES server:

Copy the agent RPM package to the target OES server. The package filename follows the format:

LTAuditorMP-OES-25.0.0.0-0.x86_64.rpm

[Your administrator should note the current package filename and version used in your environment here.]

Step 2 — Switch to root:

Open a terminal on the OES server and switch to root:

su

Enter the root password when prompted.

Step 3 — Install the agent package:

Install the RPM package using the following command:

rpm -ivh LTAuditorMP-OES-25.0.0.0-0.x86_64.rpm

The agent installs to:

/opt/bluelance/

The installation process:

• Installs the agent binaries and configuration files to /opt/bluelance/
• Registers the ltaudit service with systemd
• Does not start the service automatically — configuration must be completed first

Step 4 — Configure syslog forwarding:

Navigate to the agent bin directory and run the configuration script:

cd /opt/bluelance/bin

./update_syslog_config.sh

The script will prompt you for the following information:

Host/IP of the LT Auditor ^MP server: Enter the IP address or hostname of your LT Auditor ^MP server:

Enter LT Auditor ^MP host: <LT_AuditorMP_IP_or_Hostname>

Port: Enter the port configured in the LT Auditor ^MP NSS transformation rule (default: 5015):

Enter port [default: 5015]: 5015

Protocol: Select the communication protocol to match your LT Auditor ^MP NSS transformation rule:

Enter protocol [UDP/TCP/TLS, default: TCP]: TCP

If TLS is selected, you will be prompted for additional settings:

[Your administrator should update the TLS defaults above with the actual values used in your environment if TLS is selected.]

Once all prompts are completed, the configuration script automatically saves the settings and starts the required daemons.

Step 5 — Configure the firewall:

Ensure no firewall is blocking outbound traffic from the OES server to the LT Auditor ^MP server on the configured syslog port.

Test connectivity from the OES server:

nc -zv <LT_AuditorMP_Host> <Port>

A successful response confirms the connection is open. If the connection fails, review your firewall rules to permit outbound traffic on the configured port.

Step 6 — Verify the agent service is running:

After the configuration script completes, confirm the ltaudit service is running:

Using systemctl:

systemctl status ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc status

The service should show as active (running). If the service is not running, check the agent logs for errors before proceeding.

Step 7 — Verify audit log collection:

After confirming the service is running, verify that NSS audit data is being collected and forwarded to LT Auditor ^MP:

Check NSS audit status:

cat /opt/bluelance/log/nssstatus.log

Confirm the file contains:

Successfully opened live vigil file

This message confirms the agent has successfully connected to the NSS audit subsystem and is collecting file activity data.

Review general application logs:

ls /opt/bluelance/logs/

Check for forwarding failures:

cat /opt/bluelance/log/syslog_send.log

Review this log for any errors related to forwarding data to the LT Auditor ^MP server.

Step 8 — Verify data in LT Auditor ^MP:

Confirm that NSS file activity data is appearing in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the NSS environment and category
4. Set the date range to Last 15–30 minutes
5. Perform a file operation on an NSS volume on the configured server (e.g., create or modify a file)
6. Confirm the event appears in the LT Auditor ^MP event list within a short period

If no events appear:

• Confirm the ltaudit service is running on the OES server
• Confirm the nssstatus.log shows Successfully opened live vigil file
• Confirm no firewall is blocking traffic on the configured syslog port
• Confirm the port and protocol in the agent configuration match the LT Auditor ^MP NSS transformation rule settings
• Review the syslog_send.log for forwarding errors

Managing the NSS Audit Agent service:

Use the following commands to manage the ltaudit service after installation:

Using systemctl:

# Start the service

systemctl start ltaudit.service

# Stop the service

systemctl stop ltaudit.service

# Restart the service

systemctl restart ltaudit.service

# Check service status

systemctl status ltaudit.service

# Enable the service to start automatically on boot

systemctl enable ltaudit.service

Using the control script:

# Start the service

/opt/bluelance/bin/ltaudit.rc start

# Stop the service

/opt/bluelance/bin/ltaudit.rc stop

# Check service status

/opt/bluelance/bin/ltaudit.rc status

Enable the service to start automatically on boot using systemctl enable ltaudit.service to ensure NSS audit collection resumes automatically after a server reboot without manual intervention.

Caching behavior during LT Auditor ^MP outages:

If the LT Auditor ^MP server is temporarily unavailable, the NSS Audit Agent automatically caches audit streams locally on the OES server. Once connectivity to the LT Auditor ^MP server is restored, the cached data is automatically forwarded — no NSS audit events are lost during outages.

This behavior is built into the agent and requires no additional configuration.

Repeating installation across all OES servers:

Repeat all steps in this article for every OES server in your environment that hosts NSS volumes you want to monitor. Each server must have the agent installed and configured individually.

To confirm all servers are forwarding:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Filter by Source or Host
3. Confirm NSS file activity events are appearing from each OES server
4. If any server is not appearing as a source, revisit the installation and configuration on that server

[Your administrator should maintain a list of all OES servers in the environment, confirm each one has been installed and verified, and document the agent version, configuration date, and protocol used for each server.]

Uninstalling the NSS Audit Agent:

If the agent needs to be removed from an OES server:

1. Stop the service:

systemctl stop ltaudit.service

2. Remove the RPM package:

rpm -e LTAuditorMP-OES

3. Confirm the package has been removed:

rpm -qa | grep LTAuditorMP

No output confirms the package has been successfully removed.

Best practices:

• Install the agent on all OES servers hosting NSS volumes before considering the deployment complete — a single unmonitored server is a gap in your audit coverage
• Always verify the nssstatus.log after installation to confirm the agent has successfully connected to the NSS audit subsystem
• Enable the ltaudit service to start automatically on boot on every OES server to prevent monitoring gaps after reboots
• Use TCP or TLS in production environments for reliable log delivery
• Test firewall connectivity before running the configuration script to catch network issues early
• Document the agent version, configuration date, port, and protocol for each OES server
• Include NSS Audit Agent installation in your OES server provisioning checklist so new servers are automatically configured for monitoring when they are deployed

[Your administrator should revisit agent installations whenever the LT Auditor ^MP server IP address or NSS syslog port changes, as the agent configuration will need to be updated on every OES server to reflect the new values.]

Before installing and configuring Azure Log Connector, several prerequisites must be in place in both your Microsoft Azure environment and your LT Auditor ^MP deployment. This article covers everything that needs to be confirmed or prepared before proceeding with installation.

LT Auditor ^MP prerequisites:

[Your administrator should confirm the exact download location for the Azure Log Connector package in your environment.]

Server requirements:

The machine where Azure Log Connector will be installed must meet the following requirements:

Required outbound network access:

Azure Log Connector requires outbound HTTPS access to the following Microsoft API endpoints. Confirm these are not blocked by your firewall or proxy:

Test connectivity from the Azure Log Connector server to each endpoint:

Test-NetConnection -ComputerName graph.microsoft.com -Port 443

Test-NetConnection -ComputerName manage.office.com -Port 443

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443

All three should return a successful result. If any connection fails, work with your network team to allow outbound HTTPS traffic to those endpoints.

[Your administrator should confirm whether outbound internet access from the installation server requires proxy configuration, and if so, ensure the proxy settings are configured before proceeding.]

Microsoft Entra ID prerequisites:

Required API permissions:

The App Registration used by Azure Log Connector requires the following permissions. All permissions are Application type — not Delegated — as Azure Log Connector runs as a background service without a signed-in user. All permissions require Admin Consent from a Global Administrator.

Microsoft Graph — Application Permissions:

Office 365 Management APIs — Application Permissions:

This is a significantly broader set of permissions than the previous EntraConnector module required, reflecting the expanded scope of Azure Log Connector across both Entra ID and Microsoft 365. All permissions require Admin Consent before they become active.

Microsoft 365 license requirements:

Access to certain log categories requires appropriate Microsoft licensing. Confirm the following with your Microsoft licensing administrator:

[Your administrator should confirm your organization’s current Microsoft 365 and Entra ID license tiers and which log categories are available before configuring Azure Log Connector.]

Roles required for setup:

[Your administrator should coordinate with your Azure or Microsoft 365 administrator to complete the App Registration steps if they do not have access to the Azure Portal.]

Information to gather before installation:

Before proceeding to the App Registration and installation steps, gather the following. You will need all of these values during configuration:

The Client Secret value is only displayed once at the time of creation. Copy it immediately and store it securely. If the secret is lost, a new one must be generated.

Prerequisites checklist:

Before proceeding to the next article, confirm all of the following:

• [ ] Installation server meets Windows Server 2019 or newer requirement
• [ ] Outbound HTTPS access confirmed to all three Microsoft API endpoints
• [ ] LT Auditor ^MP server is installed and running
• [ ] LT Auditor ^MP syslog listener is active on the configured port
• [ ] Azure Portal access with appropriate privileges is available
• [ ] Microsoft 365 and Entra ID license tiers confirmed
• [ ] Tenant ID, Client ID, and Client Secret are ready to hand
• [ ] LT Auditor ^MP syslog port and protocol are confirmed

[Your administrator should complete this checklist before proceeding to the Registering the App in Microsoft Entra ID article to avoid interruptions during setup.]

Understanding managed endpoints:

A managed endpoint is any machine that PowerShell Orchestrator connects to in order to collect assessment data. This includes:

• Active Directory domain controllers
• Windows member servers
• Workstations (if included in your assessment scope)
• Microsoft Entra ID (connected via the configured service account, not a direct machine connection)

PowerShell Orchestrator connects to endpoints using PowerShell Remoting over WinRM. The service account configured during installation is used to authenticate to each endpoint.

Prerequisites:

Before adding managed endpoints, confirm the following on each target machine:

• WinRM is enabled and the WinRM service is running
• The PowerShell Orchestrator service account has read permissions on the target machine
• No firewall is blocking WinRM traffic between the orchestrator machine and the target endpoint

Default WinRM ports:

Anthropic recommends using HTTPS (port 5986) for WinRM connections in production environments to encrypt traffic between the orchestrator and managed endpoints.

[Your administrator should confirm which WinRM protocol and port are used in your environment.]

Enabling WinRM on target endpoints:

If WinRM is not already enabled on a target endpoint, run the following in PowerShell as Administrator on that machine:

Enable-PSRemoting -Force

To enable WinRM across multiple machines simultaneously, use Group Policy:

1. Open Group Policy Management Console
2. Create or edit a GPO linked to the relevant OU
3. Navigate to:

Computer Configuration → Policies → Windows Settings →

Security Settings → System Services → Windows Remote Management

4. Set the service startup mode to Automatic
5. Apply the GPO

[Your administrator should confirm whether WinRM is already managed via Group Policy in your environment before making manual changes.]

Testing connectivity to a target endpoint:

Before adding an endpoint to PowerShell Orchestrator, test that the orchestrator machine can successfully connect to it:

Test-WSMan -ComputerName <hostname or IP> -Credential (Get-Credential)

A successful result returns the WinRM service information for the target machine. If the test fails:

• Confirm WinRM is running on the target machine
• Confirm no firewall is blocking ports 5985 or 5986
• Confirm the service account has permission to connect remotely

Adding managed endpoints in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure → PowerShell Orchestrator
3. Click Add Endpoint
4. Configure the endpoint details:
   • Name — a descriptive name for the endpoint (e.g., DC01 — Primary Domain Controller)
   • Hostname or IP Address — the address of the target machine
   • Connection Protocol — HTTP or HTTPS
   • Port — 5985 (HTTP) or 5986 (HTTPS)
   • Credential — select the configured service account
5. Click Test Connection to verify connectivity before saving
6. Click Save

Repeat this process for each endpoint you want to include in assessments.

[Your administrator should maintain a list of all managed endpoints and their roles in your environment.]

Adding Microsoft Entra ID as a managed target:

Entra ID is connected as a cloud target rather than a direct machine endpoint.

1. Navigate to Configure → PowerShell Orchestrator → Cloud Targets
2. Click Add Entra ID Target
3. Enter the following details from your App Registration in the Azure Portal:
   • Tenant ID
   • Client ID
   • Client Secret
4. Click Test Connection to verify the credentials
5. Click Save

[Your administrator should refer to the EntraConnector Prerequisites article for instructions on creating and configuring the App Registration in the Azure Portal if this has not already been done.]

Verifying endpoint connectivity:

After adding endpoints, confirm they are showing as reachable in LT Auditor ^MP:

1. Navigate to Configure → PowerShell Orchestrator
2. Review the endpoint list — each endpoint should show a status of Reachable
3. If any endpoint shows as Unreachable, check:
   • The WinRM service is running on that machine
   • The hostname or IP address is correct
   • No firewall is blocking the WinRM port
   • The service account credentials are valid and have not expired

Removing a managed endpoint:

If a machine is decommissioned or no longer needs to be included in assessments:

1. Navigate to Configure → PowerShell Orchestrator
2. Locate the endpoint in the list
3. Click the Delete icon next to it
4. Confirm the deletion

Removing an endpoint stops future assessments from running against it. Historical assessment data collected from that endpoint is retained in the LT Auditor ^MP database and is not affected.

Best practices:

• Always test connectivity before saving a new endpoint to catch configuration issues early
• Use HTTPS for WinRM connections in production to encrypt assessment traffic
• Use a dedicated, least-privilege service account — avoid using a domain admin account for orchestrator connections
• Keep the endpoint list current — remove decommissioned machines promptly to avoid failed assessment runs
• Manage WinRM configuration via Group Policy for consistency across large environments
• Document each managed endpoint and its role so other administrators understand the assessment scope

[Your administrator should review the managed endpoint list regularly to ensure it reflects the current state of your environment.]

Login issues:

Client issues:

Client not appearing in the client list:

1. Verify the EventLogAgent service is installed and running on the client machine:

sc query LTA_EventLogAgent

2. Confirm the appsettings.json on the agent machine points to the correct EventLogCentral server address and port
3. Check for network connectivity issues between the client and the EventLogCentral server
4. If using self-signed certificates, confirm the ltaeventlog.cer file has been installed on the client machine via Install-Rootcert.ps1
5. Review the agent logs for errors:

C:\Program Files\Blue Lance 2-0\LTA_EventLogAgent\logs

Client showing as Offline:

1. Confirm the EventLogAgent service is running on the client:

sc query LTA_EventLogAgent

2. Verify the agent configuration points to the correct EventLogCentral server address
3. Check for network connectivity or firewall issues between the agent and the server on port 52966
4. Review agent logs for connectivity or authentication errors

Configuration issues:

Configuration changes not applying to clients:

1. Wait for the next heartbeat cycle — agents retrieve configuration updates every 5 minutes by default
2. Check the client’s Last Heartbeat timestamp in the Clients page to confirm the agent is checking in
3. Use Force Configuration Sync from the client actions menu to trigger an immediate update
4. Restart the EventLogAgent service on the client if Force Configuration Sync does not resolve the issue:

Restart-Service LTA_EventLogAgent

5. Verify the client is assigned to the correct group

Events not being forwarded:

1. Verify the syslog target is configured correctly in the Targets section
2. Confirm a sender is assigned to the client’s group in the Sender configuration
3. Test network connectivity to the syslog target using Test Connection in the Targets page
4. Check if Windows auditing is enabled on the client for the relevant event categories — EventLogAgent can only collect events that Windows is generating
5. Review the Event Log configuration for the group — confirm the relevant log channels and Event IDs are enabled
6. Review audit policies for the group — confirm no DENY policy is suppressing the expected events
7. Review agent logs for forwarding errors:

C:\Program Files\Blue Lance 2-0\LTA_EventLogAgent\logs

File audit not working:

1. Confirm Windows Object Access auditing is enabled on the client machine via Group Policy:

Computer Configuration → Policies → Windows Settings →

Security Settings → Advanced Audit Policy Configuration →

Object Access → Audit File System

2. Confirm the monitored path exists and is accessible on the client machine
3. Confirm the EventLogAgent service account has appropriate permissions to the monitored path
4. Verify include and exclude patterns in the file audit rule are not filtering out the expected files
5. Confirm no audit policy DENY rule is suppressing Windows Security Event IDs 4656 or 4670

Performance issues:

Too many events being forwarded:

1. Add Exclude Event IDs to the group’s Event Log configuration for high-volume, low-value events
2. Create DENY audit policies to suppress routine events such as service account logons
3. Refine file audit rules — add Exclude Patterns to filter out temporary files and use Include Patterns to limit monitoring to relevant file types
4. Review which log channels are enabled for the group and disable any that are not required

Web interface slow to load:

1. Reduce the page size in the client list — use 10 or 25 items per page rather than 100
2. Use the search bar to filter results rather than loading the full client list
3. Check server resource utilization on the EventLogCentral server
4. Review the EventLogCentral server logs for database performance issues:

C:\Program Files\Blue Lance 2-0\LTA_EventLogCentral\logs

Common error messages:

Log file locations:

When contacting support or escalating an issue, include relevant excerpts from both log locations along with a description of the problem and steps already taken to resolve it.

Contacting support:

If the troubleshooting steps above do not resolve the issue, contact Blue Lance support at: support@bluelance.com

When contacting support, provide:

• A detailed description of the problem
• Steps taken to reproduce the issue
• Exact error messages
• Relevant log file excerpts
• System information including OS version and EventLogCentral version

Cannot access from remote machines The server was likely configured using 127.0.0.1 (localhost) as the IP address during installation. This restricts access to the local machine only. Reconfigure the server using its actual IP address or domain name.

SMTP not working Email/alert delivery settings can be reconfigured after installation by editing the configuration files in the installation directory. You do not need to reinstall.

Port conflicts If a required port is already in use by another application, the service will fail to start. Confirm all required ports are free before installation. Use the following to check for port conflicts:

On Linux:

sudo ss -tulnp | grep <port>

On Windows:

netstat -ano | findstr <port>

Service errors on startup Check the application logs for error details:

On Linux:

cd /opt/bluelance/lcollector/logs/general/

cd /opt/bluelance/web/server/logs/

On Windows:

\Program Files\Blue Lance 2-0\Web\Apps\Logs\

\Program Files\Blue Lance 2-0\Collector\Logs\General\

Services not starting automatically on reboot (Linux) If services do not restart after a system reboot, ensure they are enabled:

sudo systemctl enable lta-web

sudo systemctl enable lta-collector

PowerShell execution policy error (Windows) If the installation script fails to run, confirm the execution policy is set correctly before running the installer:

Set-ExecutionPolicy Unrestricted

Remember to reset it after installation completes:

Set-ExecutionPolicy Restricted

For additional support, refer to the Blue Lance documentation at https://www.bluelance.com/docs or contact your system administrator.

Your administrator should confirm exact RAM, disk, and network port requirements for your specific deployment.