Unlike EventLogCentral, which passively collects events as they occur, PowerShell Orchestrator actively queries your directory environment on a schedule — producing structured assessment reports that capture the current state of your AD and Entra ID configuration at a point in time.

Key capabilities include:

• Automated assessment of Active Directory configuration and security posture
• Automated assessment of Microsoft Entra ID (Azure AD) configuration
• Scheduled execution of PowerShell scripts across managed endpoints
• Forwarding of assessment results to LT Auditor ^MP via syslog
• Linking of scripts to alert rules for automated remediation responses
• Centralized execution history and script output logging

Common use cases:

• Regular vulnerability assessments of Active Directory user and group configurations
• Identifying accounts with excessive privileges or stale access
• Detecting misconfigured or dormant accounts across your directory
• Monitoring Entra ID role assignments and conditional access policies
• Producing assessment reports for NIST, HIPAA, GDPR, and other compliance frameworks
• Automating remediation actions in response to security alerts

How PowerShell Orchestrator fits into LT Auditor ^MP:

PowerShell Orchestrator acts as the active assessment layer for directory environments. While other modules like EventLogCentral and EntraConnector capture events as they happen, PowerShell Orchestrator periodically queries the state of your directory and reports what it finds. This gives LT Auditor ^MP a more complete picture — not just what happened, but what the current configuration looks like at any given time.

Assessment results flow into the LT Auditor ^MP server where they are available in the dashboard, View module, alerts, and compliance reports alongside event data from other modules.

Prerequisites for PowerShell Orchestrator:

• PowerShell 5.1 or PowerShell 7+
• WinRM enabled on target endpoints
• A service account with appropriate read permissions across Active Directory and Entra ID
• LT Auditor ^MP server installed and running

[Your administrator should confirm which Active Directory domains and Entra ID tenants are in scope for PowerShell Orchestrator assessments in your environment.]

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

Understanding scripts in PowerShell Orchestrator:

A script in PowerShell Orchestrator consists of:

• The PowerShell code to execute on the target endpoint or against Entra ID
• The target endpoint or cloud target the script runs against
• A schedule defining when and how often the script runs
• Optional alert linkage that triggers the script automatically in response to a security event

Scripts are stored centrally in LT Auditor ^MP and pushed to the relevant endpoint at execution time. Output from each script run is captured and forwarded to the LT Auditor ^MP server as structured assessment data.

Accessing the script library:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure → PowerShell Orchestrator → Scripts
3. The script library displays all saved scripts with their name, target, schedule status, and last run time

Creating a new script:

1. Click Add New Script
2. Configure the script details:
   • Script Name — a clear, descriptive name (e.g., “AD Privileged Group Membership Assessment”)
   • Description — the purpose of the script and what it assesses
   • Target Type — select either a managed endpoint or an Entra ID cloud target
   • Target — select the specific endpoint or cloud target from the configured list
3. Enter or paste your PowerShell script code in the script editor:

# Example: List all members of the Domain Admins group

Get-ADGroupMember -Identity “Domain Admins” -Recursive |

Select-Object Name, SamAccountName, DistinguishedName |

ConvertTo-Json

4. Configure output settings:
   • Output Format — JSON is recommended for structured data forwarding to LT Auditor ^MP
   • Max Output Size — set a limit to prevent excessively large outputs
5. Click Save

[Your administrator should populate the script library with assessment scripts relevant to your environment. Blue Lance may provide a default set of assessment scripts — refer to the Blue Lance documentation at https://www.bluelance.com/docs for details.]

Recommended assessment scripts to create:

[Your administrator should adjust this list based on your organization’s specific assessment requirements and compliance frameworks.]

Scheduling a script:

1. Open the script configuration
2. Navigate to the Schedule tab
3. Click Add Schedule
4. Configure the schedule:
   • Frequency — Daily, Weekly, Monthly, or a custom interval
   • Day and Time — when the script should run
   • Time Zone — the timezone for schedule execution
5. Click Save

The script will run automatically at the configured time and forward its output to the LT Auditor ^MP server.

Stagger script schedules to avoid running multiple assessment scripts simultaneously, particularly against the same domain controller. Concurrent assessments can impact domain controller performance.

Running a script on demand:

To run a script immediately without waiting for the scheduled time:

1. Open the script from the script library
2. Click Run Now
3. Monitor the execution progress in Configure → PowerShell Orchestrator → Execution Log
4. When complete, navigate to View in the Web UI to see the assessment results

Editing an existing script:

1. Open the script from the script library
2. Click the Edit icon
3. Make the necessary changes to the script code, target, or schedule
4. Click Save

Changes to a script take effect on the next scheduled run or the next time the script is run manually. Any currently running execution of the script will complete using the previous version.

Duplicating a script:

To create a similar script quickly without starting from scratch:

1. Select the script from the script library
2. Click Duplicate
3. Modify the name, target, or code as needed
4. Click Save

This is useful when you need to run the same assessment against multiple different endpoints.

Enabling and disabling scripts:

To temporarily suspend a script without deleting it:

1. Open the script configuration
2. Toggle the Active switch to off
3. The script will not run on its schedule until re-enabled

Deleting a script:

1. Select the script from the script library
2. Click the Delete icon
3. Confirm the deletion

Deleting a script removes it and its schedule permanently. Historical execution results and assessment data already forwarded to LT Auditor ^MP are retained and are not affected.

Best practices:

• Use descriptive script names and descriptions so other administrators understand the purpose of each assessment without needing to read the code
• Always test new scripts with Run Now before activating their schedule to confirm they produce the expected output
• Use JSON output format wherever possible for clean, structured data forwarding to LT Auditor ^MP
• Stagger schedules across scripts and endpoints to avoid performance impacts during peak hours
• Store scripts in source control outside of LT Auditor ^MP as a backup, especially for complex assessments
• Review the script library regularly and remove or update scripts that are no longer relevant
• Use the least privilege principle for the service account — scripts should only have the read access they need

[Your administrator should document the purpose and expected output of each script in the library so the team can interpret assessment results correctly.]

Understanding alert-linked scripts:

When a script is linked to an alert rule, the following happens automatically:

1. An incoming event matches the alert rule’s conditions
2. LT Auditor ^MP generates an alert
3. PowerShell Orchestrator immediately executes the linked script against the configured target
4. The script output is forwarded to LT Auditor ^MP and associated with the alert for investigation

This creates a closed-loop response — the alert fires, evidence is automatically collected, and the results are immediately available in the platform for review.

Common alert-linked script use cases:

[Your administrator should define the automated response workflows most relevant to your environment and configure them accordingly.]

Prerequisites:

Before linking a script to an alert rule, confirm the following:

• The alert rule is already created and active in LT Auditor ^MP (see Configuring Alert Rules)
• The script is already created and tested in the PowerShell Orchestrator script library (see Creating and Scheduling Scripts)
• The script’s target endpoint or cloud target is reachable and connected

Linking a script to an alert rule:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Manage
3. Select the Environment and Category containing the alert rule
4. Locate the alert rule you want to link a script to and click the Edit icon
5. In the filter configuration, navigate to the Actions tab
6. Click Add Action
7. Select Run PowerShell Script as the action type
8. Configure the action:
   • Script — select the script from your PowerShell Orchestrator library
   • Target Override (optional) — if the script should run against the machine that generated the alert rather than a fixed target, enable dynamic targeting
   • Execution Delay (optional) — set a delay in seconds before the script runs, if needed
9. Click Save Action
10. Click Save to update the alert rule

The script will now run automatically every time this alert rule fires.

Using dynamic targeting:

By default, a linked script runs against the fixed target configured in the script definition. Dynamic targeting allows the script to instead run against the machine or user that generated the alert — making the response more relevant to the specific incident.

To enable dynamic targeting:

1. In the Run PowerShell Script action configuration, enable Dynamic Target
2. Select the field from the alert event that identifies the target:
   • Host — runs the script against the machine that generated the event
   • User — passes the affected username as a parameter to the script
3. Click Save

Dynamic targeting requires that the identified machine is already a registered managed endpoint in PowerShell Orchestrator. If the machine is not registered, the script will fail to execute.

Viewing alert-linked script execution results:

When an alert fires and triggers a linked script, the execution results are available in two places:

In the alert record:

1. Navigate to Alerts → Active Alerts or Alerts → Alert History
2. Open the alert that triggered the script
3. Scroll to the Automated Response section
4. View the script execution status and output directly within the alert record

In the execution log:

1. Navigate to Configure → PowerShell Orchestrator → Execution Log
2. Filter by Trigger Type — Alert to see all alert-triggered executions
3. Click any execution entry to view full output and status details

Managing alert-linked scripts:

Removing a script link from an alert rule:

1. Open the alert rule in Manage
2. Navigate to the Actions tab
3. Locate the Run PowerShell Script action
4. Click the Delete icon next to it
5. Click Save

Temporarily suspending automated responses: If you need to stop automated script execution without modifying the alert rule itself, disable the script in the script library:

1. Navigate to Configure → PowerShell Orchestrator → Scripts
2. Open the linked script
3. Toggle the Active switch to off
4. The alert rule will continue to fire alerts, but the script will not execute until re-enabled

Best practices:

• Start with read-only assessment scripts for automated responses before implementing any scripts that make changes to your environment — collect evidence first, remediate manually until you are confident in the automation
• Always test linked scripts manually using Run Now before activating the alert rule to confirm the output is as expected
• Use dynamic targeting where possible so automated responses are relevant to the specific machine or user involved in the alert
• Monitor the execution log regularly to confirm automated responses are firing correctly and producing useful output
• Set an appropriate execution delay for scripts that need the triggering event to fully complete before the assessment runs
• Document all alert-linked scripts and their intended purpose so the team understands what automated actions may occur in response to alerts
• Review linked scripts periodically to ensure they are still appropriate as your environment evolves

[Your administrator should establish a review process for automated response workflows, particularly any scripts that make changes to directory objects or account configurations.]

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

Accessing the execution log:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure → PowerShell Orchestrator → Execution Log
3. The execution log displays all script runs with the following information:

Filtering the execution log:

To narrow down the execution log to specific runs:

1. Use the filter bar at the top of the execution log
2. Filter by any combination of:
   • Script Name — view runs for a specific script
   • Target — view runs against a specific endpoint or cloud target
   • Trigger Type — filter by Scheduled, Manual, or Alert
   • Status — filter by Success, Failed, or Running
   • Date Range — limit results to a specific time period
3. Click Apply Filters

Viewing execution details and output:

To view the full details and output of a specific script run:

1. Locate the execution entry in the log
2. Click the entry to open the detail panel
3. The detail panel displays:
   • Execution Status — Success, Failed, or Running
   • Start and End Time — exact timestamps for the run
   • Target — the endpoint or cloud target the script ran against
   • Trigger — what initiated the execution (schedule name, user, or alert rule)
   • Script Output — the full output returned by the script
   • Error Messages — any errors encountered during execution
   • Exit Code — the PowerShell exit code returned by the script

Understanding execution statuses:

Investigating failed executions:

If a script shows a status of Failed, use the following steps to diagnose the issue:

1. Open the failed execution entry in the log
2. Review the Error Messages section for details on what went wrong
3. Check the Exit Code — a non-zero exit code indicates a PowerShell error

Common failure causes:

Viewing assessment results in LT Auditor ^MP:

Script output forwarded to LT Auditor ^MP is available in the View module alongside event data from other modules:

1. Navigate to View in the Web UI
2. Select the environment and category relevant to your assessment (e.g., Active Directory, Entra ID)
3. Set the date range to cover the time of the script execution
4. Filter by:
   • Source — select PowerShell Orchestrator
   • Script Name — filter by the specific script if needed
5. Review the structured assessment data returned by the script

Exporting execution history:

To export the execution log for reporting or audit purposes:

1. Apply your desired filters and date range
2. Click the Export button
3. Choose your format:
   • CSV — for Excel or data analysis
   • Excel — native Excel format
   • PDF — for audit documentation
4. Click Download

Monitoring scheduled script health:

Use the execution log to confirm that scheduled scripts are running as expected:

1. Filter the execution log by Trigger Type — Scheduled
2. Review the most recent run for each scheduled script
3. Confirm:
   • The last run time matches the expected schedule
   • The status shows as Success
   • The output contains the expected assessment data
4. If a scheduled script has not run at its expected time, check:
   • The script is set to Active in the script library
   • The PowerShell Orchestrator service is running
   • The target endpoint is reachable

Best practices:

• Review the execution log at least weekly to confirm all scheduled assessments are running successfully
• Investigate any failed executions promptly — a failing assessment script means a gap in your security posture visibility
• Use the execution log as part of incident response to confirm that alert-linked scripts fired correctly and produced useful output
• Retain execution history exports as supporting evidence for compliance audits
• Set up an alert rule in LT Auditor ^MP to notify your team when a critical assessment script fails so issues are caught quickly rather than discovered during a log review

[Your administrator should define which assessment scripts are considered critical and ensure alert notifications are configured for any failures in those scripts.]

1. Change the default admin password Log in to the Web UI and immediately change the default administrator password to a strong, unique password.

1. Navigate to Admin → User Management
2. Select the admin account
3. Click Change Password
4. Enter and confirm a new password
5. Click Save

2. Configure SMTP for email alerts Set up email delivery so that alerts and scheduled reports can be sent to your team.

1. Navigate to Admin → SMTP Settings
2. Enter your mail server details:
   • SMTP Host
   • Port
   • Authentication credentials
   • From address
3. Send a test email to confirm delivery
4. Click Save

[Your administrator should fill in the specific SMTP server details for your environment.]

3. Install and connect modules Install the relevant modules for your environment and confirm they are sending data to the LT Auditor ^MP server. Refer to each module’s dedicated documentation section for full instructions.

4. Configure monitored scopes Define which servers, directories, and systems LT Auditor ^MP should monitor.

1. Navigate to Configure → Environments
2. Add each environment relevant to your deployment (Windows, Linux, eDirectory, etc.)
3. Define log categories and operations to capture within each environment
4. Save your configuration

5. Set up alert rules Configure at minimum a basic set of alert rules to notify your team of critical events. See the Configuring Alert Rules article for full instructions.

Recommended starting alerts:

• Failed login threshold exceeded
• Privileged account changes
• File deletion on sensitive directories
• New admin account created

6. Configure data retention policy Set how long audit data is retained in the database to manage storage and meet compliance requirements.

1. Navigate to Admin → Retention Settings
2. Set the retention period in days
3. Click Save

7. Set up user roles and access Create user accounts and assign appropriate roles for your team before sharing access to the platform.

1. Navigate to Admin → User Management
2. Add user accounts for each team member
3. Assign roles based on responsibilities (admin, analyst, report viewer, etc.)
4. Save all changes

8. Test an alert end-to-end Before going live, confirm that the full alert pipeline is working correctly.

1. Trigger a test event that matches one of your alert rules
2. Confirm the alert appears in Alerts → Active Alerts
3. Confirm the alert notification email is received
4. Resolve the test alert

Modules are installed separately on the relevant servers or systems in your environment. Refer to each module’s dedicated documentation section in this knowledge base for full installation and configuration instructions.

Available modules:

For additional documentation and resources, visit: https://www.bluelance.com/docs

[Your administrator should note here any internal processes for requesting or obtaining module packages in your environment.]

LT Auditor ^MP NSS Module Collects and forwards NSS file activity from OES servers.

LT Auditor ^MP EventLogCentral Collects and forwards Windows Event Logs and NTFS file activity.

LT Auditor ^MP PII Scanner Scans and forwards PII scan results from Windows and Linux systems.

LT Auditor ^MP PowerShell Orchestrator Runs and forwards Active Directory and Entra ID assessment reports.

LT Auditor ^MP EntraConnector Collects and forwards Azure sign-in logs and Entra ID audit events.

Always verify you are downloading the latest version of each module. Contact your administrator or refer to https://www.bluelance.com/docs for version information.

Core components:

LT Auditor ^MP Server: The central hub of the platform. It receives incoming audit data, processes and normalizes it, stores it in the database, and serves the web-based dashboard and reporting interface. The server can be hosted on Windows or Linux.

PostgreSQL Database: The backend database that stores all collected audit events, configuration, and report data.

Web UI: A browser-based interface used by administrators to view dashboards, search events, configure the platform, manage alerts, and generate reports. Accessible via any modern browser (Chrome, Edge, or Firefox).

Modules: LT Auditor ^MP extends its collection capabilities through installable modules, each targeting a specific data source. Modules are installed separately on the relevant servers or systems and stream data back to the LT Auditor ^MP server.

Current modules include:

Data flow (simplified):

1. Modules collect activity data from monitored systems
2. Data is forwarded to the LT Auditor ^MP server via syslog or agent-based streaming.
3. The server normalizes and stores the data in the database.
4. Administrators view, alert on, and report from the data via the Web UI.

**[add a network or architecture diagram here]**