- Related Products
- AD360
- Log360
- ADManager Plus
- ADSelfService Plus
- EventLog Analyzer
- Exchange Reporter Plus
Click here to expand
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 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.
| Item | Value |
|---|---|
| License required | Domain Controllers license |
| Audit policy reference | AD Auditing Guide — Configure audit policies |
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.
| Item | Value |
|---|---|
| License required | Member Servers add-on |
| Audit policy reference | Windows Server Auditing Guide — Configure audit policies |
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.
| Item | Value |
|---|---|
| License required | Workstations add-on |
| Audit policy reference | Workstation Auditing Guide — Configure audit policies |
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.
Standard Windows audit policy configuration for each machine type is covered in the respective auditing guides:
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.
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 |
Note: Automatic configuration is still GPO-based. If GPO creation, editing, linking, or security filtering is blocked by your environment, use the manual workflow.
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.
Module logging creates PowerShell event ID 4103 records.
Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell
| 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.
Script block logging creates PowerShell event ID 4104 records and related lifecycle events.
Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell
| 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.
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:
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
Add a Group Policy Registry preference to the existing audit policy GPO for the target machine type.
Computer Configuration → Preferences → Windows Settings
| 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.
Verification is the final step. Do not assume the configuration is correct until you confirm event generation and report visibility.
Use Group Policy results or direct policy review to confirm that both PowerShell logging settings are applied.
| Setting | Expected value |
|---|---|
| Turn on Module Logging | Enabled |
| Module Names | * |
| Turn on PowerShell Script Block Logging | Enabled |
Confirm that the target computer writes the required PowerShell events locally.
Get-Process Get-Service | Select-Object -First 5
After local event generation is confirmed, verify that ADAudit Plus shows the same activity.
Copyright © 2020, ZOHO Corp. All Rights Reserved.