Click here to shrink
Click here to expand Click here to expand

Configuration

Configure PowerShell auditing in ADAudit Plus

ADAudit Plus collects PowerShell audit data from machines that are already configured as data sources. The PowerShell Operational log is read alongside the Security log from the same configured machine — no separate ADAudit Plus configuration is needed specifically for PowerShell.

The steps below confirm whether each machine type is already in scope. If a machine is not yet configured, follow the respective auditing guide to add it first, then return to enable the PowerShell-specific audit settings in Configure audit policies.

Domain Controllers

Domain Controllers are configured in ADAudit Plus as part of Active Directory auditing. Once a Domain Controller is in scope, ADAudit Plus reads its PowerShell Operational log automatically alongside the Security log.

  • Already configured: Confirm the Domain Controller is in the monitored scope under Configuration → Data Sources → Domains and Controllers, then proceed to Configure audit policies.
  • Not yet configured: Follow Configure PowerShell auditing in ADAudit Plus of the Active Directory Auditing Guide to add the domain and Domain Controllers, then return to Configure audit policies.
Item Value
License required Domain Controllers license
Audit policy reference AD Auditing Guide — Configure audit policies

Windows Servers

Windows Servers are configured in ADAudit Plus as part of Windows Server auditing. Once a server is in scope, ADAudit Plus reads its PowerShell Operational log automatically alongside the Security log.

  • Already configured: Confirm the server is listed under Configuration → Data Sources → Member Servers, then proceed to Configure audit policies.
  • Not yet configured: Follow Configure PowerShell auditing in ADAudit Plus of the Windows Server Auditing Guide to add it, then return to Configure audit policies.
Item Value
License required Member Servers add-on
Audit policy reference Windows Server Auditing Guide — Configure audit policies

Windows Workstations

Windows Workstations are configured in ADAudit Plus as part of Workstation auditing. Once a workstation is in scope, ADAudit Plus reads its PowerShell Operational log automatically alongside the Security log.

  • Already configured: Confirm the workstation is listed under Configuration → Data Sources → Endpoints, then proceed to Configure audit policies.
  • Not yet configured: Follow Configure PowerShell auditing in ADAudit Plus of the Workstation Auditing Guide to add it, then return to Configure audit policies.
Item Value
License required Workstations add-on
Audit policy reference Workstation Auditing Guide — Configure audit policies

Choose automatic or manual audit policy configuration

The choice between automatic and manual audit policy configuration is made during the data source setup in the respective auditing guide. For PowerShell auditing, the same choice determines how the PowerShell-specific settings (Module Logging and Script Block Logging) are applied:

Method What ADAudit Plus does for PowerShell What you must do
Automatic Applies both the standard audit policies and the PowerShell-specific settings (Module Logging + Script Block Logging) in a single workflow. Confirm permissions, wait for GPO replication, and verify. See this Section
Manual Monitors only — does not modify any GPO settings. Complete standard audit policy steps from the respective guide, then additionally configure Module Logging and Script Block Logging as described in this Section

⚠️ Important: Automatic configuration reduces setup time, but it does not remove the need to verify the applied GPO results on the target computer.

Configure audit policies

Standard Windows audit policy configuration for each machine type is covered in the respective auditing guides:

  • Domain Controllers — Active Directory Auditing Guide
  • Windows Servers — Windows Server Auditing Guide
  • Windows Workstations — Workstation Auditing Guide

PowerShell auditing requires two additional Group Policy settings beyond the standard audit policies: Module Logging and Script Block Logging. These are the settings that tell Windows to write event IDs 4103 and 4104 to the PowerShell Operational log. This section covers only those additions.

Automatic configuration

When you choose automatic configuration in ADAudit Plus, the product applies both the standard audit policies and the PowerShell-specific settings in a single workflow. No additional manual steps are required.

In addition to the standard audit policy settings covered in the respective guide, ADAudit Plus applies the following PowerShell-specific Group Policy settings:

Setting Policy name Event IDs generated
Module Logging Turn on Module Logging 4103 — cmdlet and pipeline activity
Script Block Logging Turn on PowerShell Script Block Logging 4104, 4105, 4106 — script content and lifecycle
Scope Where to start
Domain Controller Configuration → Data Sources → Domains and Controllers
Windows member server Configuration → Data Sources → Member Servers → Audit Policy: Configure
Windows workstation Configuration → Data Sources → Endpoints
  1. Open the relevant ADAudit Plus onboarding page for the target machine type.
  2. Choose the option to configure audit policy automatically.
  3. Allow ADAudit Plus to complete the configuration.
  4. Wait for Group Policy replication and refresh.
  5. Verify the results using the steps in Verify the configuration.

Note: Automatic configuration is still GPO-based. If GPO creation, editing, linking, or security filtering is blocked by your environment, use the manual workflow.

Manual configuration overview

Complete the standard audit policy steps in the respective guide for your machine type first, then add the PowerShell-specific settings to the same GPO.

Target system GPO to edit
Domain Controllers Default Domain Controllers Policy
Windows member servers ADAuditPlusMSPolicy
Windows workstations <DomainName>_ADAuditPlusWSPolicy

Tip: If you audit Domain Controllers, Windows member servers, and workstations, configure each GPO separately so the correct settings apply to the correct scope.

Configure module logging

Module logging creates PowerShell event ID 4103 records.

  • Log in to a computer that has the Group Policy Management Console (GPMC) using Domain Admin or equivalent delegated credentials.
  • Open Group Policy Management.
  • Edit the correct GPO:
  • Default Domain Controllers Policy for Domain Controllers
  • ADAuditPlusMSPolicy for Windows member servers
  • <DomainName>_ADAuditPlusWSPolicy for Windows workstations
  • Navigate to:

    Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell

  • In the right pane, open Turn on Module Logging.
  • Select Enabled.
  • In Options, click Show.
  • In Module Names, enter *.
  • Click OK.
  • Click Apply and OK.
Field Value
Policy Turn on Module Logging
Setting Enabled
Module Names *
Resulting event ID 4103

Note: Using * captures all modules. If you restrict the list, you also restrict audit coverage.

Configure script block logging

Script block logging creates PowerShell event ID 4104 records and related lifecycle events.

  • Log in to a computer that has the Group Policy Management Console (GPMC) using Domain Admin or equivalent delegated credentials.
  • Open Group Policy Management.
  • Edit the correct GPO:
  • Default Domain Controllers Policy for Domain Controllers
  • ADAuditPlusMSPolicy for Windows member servers
  • <DomainName>_ADAuditPlusWSPolicy for Windows workstations
  • Navigate to:

    Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell

  • In the right pane, open Turn on PowerShell Script Block Logging.
  • Select Enabled.
  • Click Apply and OK.
Field Value
Policy Turn on PowerShell Script Block Logging
Setting Enabled
Primary event ID 4104
Related event IDs 4105, 4106

⚠️ Important: Script block logging is the setting that gives you script content visibility. Without it, you may know that PowerShell ran, but you may not have enough context to investigate what the script actually did.

Configure the PowerShell log size

ADAudit Plus does not configure the PowerShell Operational log size — this step is always performed manually. Apply the log size setting to the same GPO used or created during audit policy configuration in Configure audit policies:

  • Automatic audit policy: ADAudit Plus created or modified a GPO for the machine type. Edit that same GPO to add the registry preference below.
  • Manual audit policy: You edited the GPO. Add the registry preference to that same GPO.

Set the maximum PowerShell Operational log size to 150 MB.

Setting Value
Recommended size 150 MB
Registry value data (decimal) 153616384
Reason Reduces the risk of event overwrite during high command volume or delayed collection

The log channel affected is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PowerShell\Operational

Configure the registry preference

Add a Group Policy Registry preference to the existing audit policy GPO for the target machine type.

  • Log in to a computer that has the Group Policy Management Console (GPMC) using Domain Admin or equivalent delegated credentials.
  • Open Group Policy Management.
  • Edit the same GPO used for audit policy configuration in Configure audit policies.
  • Navigate to:

    Computer Configuration → Preferences → Windows Settings

  • Right-click Registry and click New → Registry Item.
  • In the New Registry Properties window, enter the following values.
  • Click Apply and OK.
Field Value
Action Update
Hive HKEY_LOCAL_MACHINE
Key Path SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PowerShell\Operational
Value name MaxSize
Value type REG_DWORD
Value data 153616384
Base Decimal

Tip: 150 MB is a starting point. Increase the size further if your environment generates a high volume of PowerShell activity or if collection can be delayed.

Verify the configuration

Verification is the final step. Do not assume the configuration is correct until you confirm event generation and report visibility.

Verify module logging and script block logging are enabled

Use Group Policy results or direct policy review to confirm that both PowerShell logging settings are applied.

  1. Open Group Policy Management Console (GPMC).
  2. Run Group Policy Results for a target Domain Controller, Windows Server, or Windows Workstation.
  3. Verify that the following settings are present.
    Setting Expected value
    Turn on Module Logging Enabled
    Module Names *
    Turn on PowerShell Script Block Logging Enabled
  4. If the settings are missing, force a Group Policy refresh on the target computer and verify again.

Verify PowerShell events in Event Viewer

Confirm that the target computer writes the required PowerShell events locally.

  1. Log in to a target Domain Controller, Windows Server, or Windows Workstation.
  2. Open Event Viewer.
  3. Navigate to Application and Services Logs → Microsoft → Windows → PowerShell → Operational.
  4. Run a simple test command from a PowerShell console.

    Get-Process Get-Service | Select-Object -First 5

  5. Refresh the Operational log.
  6. Confirm that event IDs 4103 and 4104 appear.
  7. If available, also note 4105 and 4106 around script block activity.

Verify data in ADAudit Plus reports

After local event generation is confirmed, verify that ADAudit Plus shows the same activity.

  1. Wait for ADAudit Plus to collect the new events.
  2. Navigate to Server → PowerShell Activity (or Endpoint → PowerShell Activity for workstations).
  3. Open Process Tracking, Script Block Logging, or Module Logging as appropriate for your test.
  4. Filter by:
    • The target computer
    • The time range of the test
    • The user account used for the test
  5. Confirm that the process, command, or script block activity appears.
  6. If the event exists in Event Viewer but not in ADAudit Plus, use the troubleshooting steps in this Section.

Don't see what you're looking for?

  •  

    Visit our community

    Post your questions in the forum.

     
  •  

    Request additional resources

    Send us your requirements.

     
  •  

    Need implementation assistance?

    Try OnboardPro

     

On this page

Copyright © 2020, ZOHO Corp. All Rights Reserved.

Get download link