How PowerShell Orchestrator works:

The server manages all aspects of the platform — scripts, jobs, schedules, syslog targets, and connected agents. Agents are deployed on the Windows machines where scripts need to run. Each agent polls the server for queued jobs, executes the assigned PowerShell script locally, and forwards script output to the configured syslog destination.

Data flow:

1. Administrator uploads PowerShell scripts to the server and configures syslog targets
2. Administrator creates a job or schedule, selecting a script, agent, and target
3. The agent polls the server and claims the queued job
4. The agent downloads and executes the PowerShell script locally
5. Script output is forwarded to the configured syslog target in real time
6. The agent reports job completion, exit code, and execution logs back to the server
7. Results are available for review in the Jobs page and in LT Auditor-MP

Core components:

PowerShell Orchestrator Server An ASP.NET Core web application that hosts the administrative interface and REST API. It manages script storage, job queuing, schedules, syslog targets, and agent registrations. The server runs as a Windows service named PowerShellOrchestrator and uses a SQLite database for persistence. The web interface is accessible via browser on port 52866 (HTTPS) or 52865 (HTTP).

PowerShell Orchestrator Agent A .NET background service deployed on each Windows machine where scripts need to run. The agent polls the server for available jobs at a configurable interval (default: every 20 seconds), downloads and executes assigned PowerShell scripts, forwards output to the configured syslog target, and sends regular heartbeats to the server (default: every 60 seconds). The agent runs as a Windows service named PowerShellOrchestrator.Agent.

Key capabilities include:

• Centralized storage and management of PowerShell scripts
• Remote script execution across distributed Windows agents
• On-demand and scheduled recurring job execution using cron expressions
• Real-time job status monitoring and execution history
• Script output forwarding to syslog targets for centralized logging in LT Auditor-MP
• Secure HTTPS/TLS communication between server and agents
• Role-based access control with forced password changes
• Support for both Windows PowerShell 5 and PowerShell Core 7
• Runs as a Windows service on Windows or Linux systemd service on Linux

Common use cases:

• Automated assessment of Active Directory configuration and security posture
• Scheduled execution of compliance and security audit scripts across the environment
• Remote PowerShell script execution without requiring direct access to individual machines
• Centralized collection and forwarding of PowerShell script output to LT Auditor-MP
• Automating routine administrative tasks across distributed Windows infrastructure

How PowerShell Orchestrator fits into LT Auditor-MP:

PowerShell Orchestrator extends LT Auditor-MP’s capabilities into active script-based assessment and automation. Where other modules collect events passively as they occur, PowerShell Orchestrator actively executes scripts on demand or on a schedule — querying the state of your Windows environment and forwarding structured results to LT Auditor-MP for analysis, alerting, and compliance reporting.

[Your administrator should confirm which Windows machines are in scope for PowerShell Orchestrator agent deployment and which scripts will be used in 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.]

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