Understanding the ltaudit service:

The ltaudit service is the NSS Audit Agent daemon that runs continuously on each OES server, collecting NSS file activity and forwarding it to the LT Auditor ^MP server via syslog. It is registered with systemd during installation and can be managed using standard systemctl commands or the agent’s built-in control script located at /opt/bluelance/bin/ltaudit.rc.

Both management methods produce the same result — use whichever is more familiar or appropriate for your environment.

When you need to manage the service:

Checking service status:

Always check the service status first before taking any other management action — it tells you whether the service is running, stopped, or in an error state.

Using systemctl:

systemctl status ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc status

Interpreting the status output:

Starting the service:

If the service is stopped and needs to be started:

Using systemctl:

systemctl start ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc start

After starting, confirm the service is running:

systemctl status ltaudit.service

Stopping the service:

If the service needs to be stopped for maintenance, configuration changes, or troubleshooting:

Using systemctl:

systemctl stop ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc stop

Stopping the service suspends NSS file activity collection on that server. Any events that occur while the service is stopped will not be captured. Stop the service only when necessary and restart it as soon as possible to minimize monitoring gaps.

Restarting the service:

Restart the service to apply configuration changes or reset connections to the LT Auditor ^MP server:

Using systemctl:

systemctl restart ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc stop

/opt/bluelance/bin/ltaudit.rc start

After restarting, confirm the service returns to an active (running) state:

systemctl status ltaudit.service

Enabling automatic startup on boot:

To ensure the ltaudit service starts automatically when the OES server reboots, enable it with systemctl:

systemctl enable ltaudit.service

Confirm the service is enabled:

systemctl is-enabled ltaudit.service

The output should return enabled. If it returns disabled, run the enable command again.

Enabling automatic startup is strongly recommended for all production OES servers. Without it, NSS audit collection will not resume after a server reboot until an administrator manually starts the service — potentially leaving a significant monitoring gap.

Disabling automatic startup on boot:

If automatic startup needs to be disabled (e.g., for a server being decommissioned):

systemctl disable ltaudit.service

Reviewing service logs:

If the service fails to start or is behaving unexpectedly, review the agent logs for error details:

General application logs:

ls /opt/bluelance/logs/

NSS audit status log:

cat /opt/bluelance/log/nssstatus.log

Syslog forwarding log:

cat /opt/bluelance/log/syslog_send.log

systemd journal (for service startup errors):

journalctl -u ltaudit.service -n 50

The -n 50 flag returns the last 50 log entries. Increase this number if you need to look further back.

Common errors to look for:

• Connection refused — firewall blocking syslog port
• Certificate errors — TLS configuration issue
• Permission denied — agent lacks required access to NSS volumes
• Failed to open live vigil file — NSS audit subsystem not available

Service management after a configuration change:

Whenever the syslog forwarding configuration is updated using update_syslog_config.sh, restart the service to apply the new settings:

systemctl restart ltaudit.service

Confirm the service is running after the restart, then verify that events are appearing in LT Auditor ^MP to confirm the new configuration is working correctly.

Best practices:

• Always check the service status before investigating log collection issues — a stopped service is the most common cause of missing NSS audit data
• Enable automatic startup on boot on every production OES server to prevent monitoring gaps after reboots
• Restart rather than stop-and-start when applying configuration changes — it is faster and reduces the monitoring gap
• Review the nssstatus.log and syslog_send.log as the first step when troubleshooting collection or forwarding issues
• Include systemctl status ltaudit.service in your regular OES server health check routine alongside other service checks
• Document any planned service interruptions (maintenance windows, upgrades) so the security team is aware of expected monitoring gaps

[Your administrator should include ltaudit service status in any OES server monitoring dashboards or health check scripts used in your environment.]

When to run a verification check:

Step 1 — Verify the LT Auditor ^MP transformation rules are active:

Before checking the OpenText systems, confirm that LT Auditor ^MP is ready to receive data on the correct ports.

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure
3. Locate the eDirectory transformation rule (default port 5014) and the NSS transformation rule (default port 5015)
4. Confirm both rules show a status of Active
5. If either rule is inactive, click the three vertical action buttons and select Enable

Step 2 — Verify firewall connectivity from OpenText servers:

Confirm that each eDirectory and OES server can reach the LT Auditor ^MP server on the configured syslog ports.

Run the following from each OpenText server:

For eDirectory servers (port 5014):

nc -zv <LT_AuditorMP_Host> 5014

For OES NSS servers (port 5015):

nc -zv <LT_AuditorMP_Host> 5015

A successful response confirms connectivity is open. If the connection fails:

• Review firewall rules between the OpenText server and the LT Auditor ^MP server
• Confirm the LT Auditor ^MP server is running and the transformation rules are active
• Confirm the correct IP address is being used

Step 3 — Verify the eDirectory CEF audit daemon is running:

On each eDirectory server, confirm the CEF audit daemon is loaded and active:

ndstrace –c “modules” | grep cefauditds

The output should show cefauditds as a loaded module. If it does not appear:

Manually load the daemon:

ndstrace –c “load cefauditds”

Confirm it loads successfully, then check again:

ndstrace –c “modules” | grep cefauditds

Also confirm the audit configuration file is correctly set up:

cat /etc/opt/novell/eDirectory/conf/auditlogconfig.properties

Verify the host, port, and protocol values match your LT Auditor ^MP transformation rule settings.

Step 4 — Verify the NSS Audit Agent service is running:

On each OES server, confirm the ltaudit service is running:

systemctl status ltaudit.service

The service should show as active (running). If it is stopped or failed:

systemctl start ltaudit.service

systemctl status ltaudit.service

Confirm the service returns to active (running) before proceeding.

Step 5 — Check the NSS audit status log:

On each OES server, confirm the NSS Audit Agent has successfully connected to the NSS audit subsystem:

cat /opt/bluelance/log/nssstatus.log

Confirm the log contains:

Successfully opened live vigil file

If this message is not present:

• The agent may not have access to the NSS audit subsystem
• NSS may not be running or volumes may not be mounted

Review the general application logs for more detail:
ls /opt/bluelance/logs/

Step 6 — Check the syslog forwarding log:

On each OES server, confirm that events are being successfully forwarded to LT Auditor ^MP:

cat /opt/bluelance/log/syslog_send.log

Look for:

• Successful forwarding messages confirming events are reaching the LT Auditor ^MP server
• Any connection errors, timeout messages, or TLS certificate errors that may indicate a forwarding problem

If forwarding errors are present:

• Confirm network connectivity using the nc test in Step 2
• Confirm the port and protocol in the agent configuration match the LT Auditor ^MP transformation rule
• If using TLS, confirm certificate configuration is correct on both ends

Step 7 — Generate test events on OpenText systems:

To confirm the full end-to-end pipeline is working, generate known test events on your OpenText systems and verify they appear in LT Auditor ^MP.

Generating a test eDirectory event:

Perform a simple directory operation that eDirectory auditing is configured to capture — for example, modify an attribute on a test user object in iManager or via an LDAP command:

ldapmodify -H ldap://<eDirectory_Host> -D “<admin_DN>” -W <<EOF

dn: cn=testuser,ou=users,o=yourorg

changetype: modify

replace: description

description: Audit verification test

EOF

Generating a test NSS file event:

Perform a simple file operation on an NSS volume on the OES server — for example, create and then delete a test file:

touch /media/nss/<VolumeName>/audit_verification_test.txt

rm /media/nss/<VolumeName>/audit_verification_test.txt

Replace <VolumeName> with the name of an NSS volume on the server.

[Your administrator should confirm the correct NSS volume mount path used in your environment.]

Step 8 — Verify test events appear in LT Auditor ^MP:

After generating test events, confirm they appear in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the relevant environment and category:
   • For eDirectory events: eDirectory environment → Object Events or Attribute Events category
   • For NSS events: NSS environment → File Activity category
4. Set the date range to Last 15 minutes
5. Look for the test events you just generated
6. Click on a test event row to view full details and confirm the event data is correctly structured and normalized

If test events do not appear within a few minutes:

• Confirm the relevant daemon or service is running (Steps 3 and 4)
  
• Confirm firewall connectivity is open (Step 2)
  
• Confirm the transformation rule is active (Step 1)
  
• Review the syslog forwarding log for errors (Step 6)
  

Check the LT Auditor ^MP server logs for any ingestion errors:

On Linux:

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

 On Windows:

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

Step 9 — Confirm all servers are represented as sources:

After verifying individual servers, confirm that all configured eDirectory and OES servers are appearing as active sources in LT Auditor ^MP:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Select the eDirectory or NSS environment
3. Set the date range to cover the last 24 hours
4. Filter by Source or Host and review the list of servers generating events
5. Cross-reference against your list of configured servers
6. If any server is missing from the source list:
   • Confirm the CEF audit daemon or ltaudit service is running on that server
   • Confirm syslog forwarding is configured correctly on that server
   • Revisit the relevant configuration article for that server type

[Your administrator should maintain a reference list of all eDirectory and OES servers that should be appearing as sources in LT Auditor ^MP, and use it during routine verification checks to quickly identify any gaps.]

Routine verification schedule:

Rather than verifying collection only after problems occur, incorporate collection verification into your regular operational routine:

[Your administrator should assign ownership of routine verification checks to a specific team member and document the results so the verification history is available for compliance audits.]

Common issues and resolutions:

Best practices:

• Run the full end-to-end verification workflow immediately after initial installation — do not assume the deployment is working without confirming test events appear in LT Auditor ^MP
• Incorporate routine verification checks into your regular operational schedule rather than waiting for problems to be reported
• Maintain a reference list of all configured eDirectory and OES servers and use it during verification to quickly identify any gaps
• Generate and retain verification records as evidence of your audit program’s ongoing effectiveness for compliance audits
• Address any identified collection gaps promptly — unmonitored servers represent both a security monitoring gap and a potential compliance violation
• Include collection verification in your change management process for any changes to OpenText systems, network infrastructure, or the LT Auditor ^MP server

[Your administrator should document the results of each verification cycle and retain them as part of your organization’s compliance evidence library.]

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.]

Prerequisites:

Before installing, confirm the following:

Download the PowerShell Orchestrator package:

[Your administrator should confirm whether packages are distributed internally or downloaded directly from the portal in your environment.]

Enabling WinRM on the installation machine:

If WinRM is not already enabled, run the following in PowerShell as Administrator:

Enable-PSRemoting -Force

Confirm WinRM is running:

Get-Service WinRM

The service should show as Running.

[Your administrator should confirm whether WinRM is managed via Group Policy in your environment before enabling it manually.]

Installation steps:

1. Copy the lta-mp-orchestrator.zip package to the target Windows machine
   
2. Extract the zip file to a working directory
   
3. Open PowerShell as Administrator and navigate to the extracted directory:
   

cd C:\path\to\extracted\orchestrator

4. If not already done, allow PowerShell scripts to run:

Set-ExecutionPolicy Unrestricted

5. Run the installation script:

.\Install.ps1

6. Follow any on-screen prompts during installation, including:
   
   • Entering the LT Auditor ^MP server IP address or hostname
   • Confirming the syslog port (default: 514)
   • Selecting the communication protocol (UDP, TCP, or TLS)
   • Entering the service account credentials to be used for Active Directory and Entra ID assessments
7. Once installation is complete, reset the PowerShell execution policy:
   

Set-ExecutionPolicy Restricted

[Your administrator should fill in the exact installer prompts and any environment-specific options that appear during installation.]

Post-installation verification:

After installation completes, confirm that PowerShell Orchestrator is running and communicating with the LT Auditor ^MP server.

1. Check the service status:

sc query PowerShellOrchestrator

The service should show as Running.

2. In the LT Auditor ^MP Web UI, navigate to Admin → Modules and confirm the PowerShell Orchestrator instance appears with a status of Connected
   
3. Check the PowerShell Orchestrator logs for any errors:
   

\Program Files\Blue Lance 2-0\PowerShellOrchestrator\Logs\

4. Verify that assessment data is appearing in the LT Auditor ^MP View module by navigating to View and selecting the Active Directory environment

If the module does not appear as connected in the Web UI, confirm that no firewall is blocking communication between the installation machine and the LT Auditor ^MP server on the configured syslog port.

[Your administrator should note the specific port, protocol, and service account used in your environment, and document which machine PowerShell Orchestrator is installed on.]

Verifying service account permissions:

The service account used by PowerShell Orchestrator requires the following minimum permissions:

Active Directory:

• Read access to all user, group, and computer objects in the monitored domains
• Read access to Group Policy Objects (GPOs)
• Read access to Active Directory Sites and Services

Microsoft Entra ID:

• Directory.Read.All — read access to directory objects
• AuditLog.Read.All — read access to audit logs
• Policy.Read.All — read access to conditional access and other policies

[Your administrator should confirm the exact permissions required in your environment and ensure the service account is configured accordingly before running the first assessment.]

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.

Check service status:

sc query LTA_Web

sc query LTA_Server

sc query LTA_DataCollector

All three services should show as running. If any service is not running, check the logs for errors before continuing.

Check logs for errors or warnings:

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

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

[Your administrator should note any expected output or common first-run messages specific to your environment.]

Start a service:

sudo systemctl start lta-web

sudo systemctl start lta-collector

Restart a service:

sudo systemctl restart lta-web

sudo systemctl restart lta-collector

Stop a service:

sudo systemctl stop lta-web

sudo systemctl stop lta-collector

Check service status:

sudo systemctl status lta-web

sudo systemctl status lta-collector

Enable services to start automatically on boot:

sudo systemctl enable lta-web

sudo systemctl enable lta-collector

Check service status:

systemctl status lta-web

systemctl status lta-collector

Both services should show as active and running. If either service is not running, check the logs for errors before continuing.

Check logs for errors or warnings:

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

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

[Your administrator should note any expected output or common first-run messages specific to your environment.]