Troubleshooting
Event IDs 4103 and 4104 are not logged
Symptom: You run PowerShell commands, but the PowerShell Operational log does not show event IDs 4103 or 4104.
Resolution:
- Confirm that Turn on Module Logging and Turn on PowerShell Script Block Logging are both enabled in the correct GPO.
- Verify that the correct GPO applies to the target computer:
- Default Domain Controllers Policy for Domain Controllers
- ADAuditPlusMSPolicy for Windows member servers
- <DomainName>_ADAuditPlusWSPolicy for Windows workstations
- Force Group Policy update on the target computer.
- Run a new PowerShell command after policy refresh.
- Reopen Event Viewer and check the PowerShell Operational log again.
Only one of the expected event types is logged
Symptom: You see 4103 events but not 4104, or 4104 events but not 4103.
Resolution:
- Open the applicable GPO and check each PowerShell setting separately.
- Confirm that Turn on Module Logging is enabled with Module Names set to *.
- Confirm that Turn on PowerShell Script Block Logging is enabled.
- Run a new test that includes both cmdlet execution and a script block.
- Recheck the PowerShell Operational log.
GPO changes do not apply to the target computer
Symptom: The GPO looks correct in GPMC, but the target computer does not show the PowerShell settings.
Resolution:
- Confirm that you edited the correct GPO for the target computer type.
- Check GPO linking, inheritance, and security filtering.
- Use Group Policy Results to confirm the winning policy.
- Allow time for AD replication if you recently changed the GPO.
- Run Group Policy refresh on the target computer and verify again.
Automatic configuration fails in ADAudit Plus
Symptom: ADAudit Plus reports that automatic audit policy configuration failed or did not complete.
Resolution:
- Confirm that the account used for automatic configuration has permission to create, edit, or apply the required GPO settings.
- Check whether the environment blocks automatic GPO changes through delegation or change-control restrictions.
- Re-run the automatic configuration action from the ADAudit Plus web console.
- If the failure persists, switch to the manual configuration workflow in this Section.
- Verify the result on the target computer after configuration.
Events exist in Event Viewer but not in ADAudit Plus
Symptom: Event Viewer shows 4103 and 4104, but ADAudit Plus reports do not show the same activity.
Resolution:
- Confirm that the correct Domain Controller, Windows Server, or Windows Workstation is onboarded in ADAudit Plus.
- Verify that the required license is present for the monitored object type.
- Allow enough time for collection and processing.
- Check connectivity between the monitored system and the ADAudit Plus server or ADAudit Plus agent path.
- Filter the ADAudit Plus report using the exact test time window, computer name, and user account.
The PowerShell Operational log fills too quickly
Symptom: PowerShell events roll over quickly, or investigation windows are too short.
Resolution:
- Confirm that the MaxSize value is set to 153616384 decimal.
- If the environment has high PowerShell volume, increase the log size beyond 150 MB.
- Review whether scripts or automation jobs are generating unusually high PowerShell event volume.
- Recheck the log size after Group Policy refresh.
- Verify that ADAudit Plus is collecting events as expected so you do not rely only on local retention.
PowerShell 7 activity is missing or incomplete
Symptom: Activity from PowerShell 7.x does not appear the same way as Windows PowerShell activity.
Resolution:
- Confirm whether the tested activity ran in Windows PowerShell or PowerShell 7.x.
- ADAudit Plus collects from the Windows PowerShell Operational log; PowerShell 7.x uses a separate event channel.
- Validate PowerShell 7.x behavior in a non-production test before treating it as fully covered.
- Keep Windows PowerShell logging enabled even if PowerShell 7.x is present in the environment.
- Document the observed behavior for your internal security operations team.
Frequently Asked Questions (FAQ)
Q1. What is the difference between Module Logging and Script Block Logging?
Module Logging records cmdlet and pipeline activity in event ID 4103. Script Block Logging records executed script content in event ID 4104. Use both for complete visibility.
Q2. Do I need both Module Logging and Script Block Logging?
Yes, if you want complete PowerShell audit coverage. If you enable only one, your command or script visibility is incomplete.
Q3. Why is the recommended PowerShell Operational log size 150 MB?
150 MB reduces the chance that important PowerShell events are overwritten before ADAudit Plus collects them. Increase it further in high-volume environments.
Q4. Which PowerShell versions does ADAudit Plus audit?
ADAudit Plus supports Windows PowerShell 4.0, 5.0, and 5.1. Windows PowerShell 5.1 is the standard inbox version on Windows Server 2016, 2019, 2022, and Windows 10/11. Validate PowerShell 7.x separately in your environment.
Q5. How do I know that PowerShell auditing is working?
Confirm that the target computer writes event IDs 4103 and 4104 to Event Viewer → Application and Services Logs → Microsoft → Windows → PowerShell → Operational, then verify the same activity in ADAudit Plus under Server → PowerShell Activity (or Endpoint → PowerShell Activity for workstations).
Q6. What license do I need for PowerShell auditing?
Use the Domain Controllers license for Domain Controller auditing, the Member Servers add-on for Windows Server PowerShell auditing, and the Workstations add-on for Windows Workstation PowerShell auditing.
Q7. Can ADAudit Plus alert on suspicious PowerShell behavior?
Yes. Create alert profiles for encoded commands, suspicious keywords, logging disable attempts, unusual execution times, or high-volume script activity.
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