{"id":800,"date":"2026-09-27T02:02:30","date_gmt":"2026-09-27T02:02:30","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=800"},"modified":"2026-10-17T22:08:46","modified_gmt":"2026-10-17T22:08:46","slug":"powershell-transcription-script-block-logging-audit","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/powershell-transcription-script-block-logging-audit\/","title":{"rendered":"PowerShell Transcription and Script Block Logging for Server Audit Trails"},"content":{"rendered":"

PowerShell transcription and Script Block Logging are the two audit controls that most Windows Server incidents are eventually reconstructed from. They do different jobs: transcript files record what appeared on the console and in the pipeline for a whole session, while event 4104 records the parsed script block itself, which is what you need when a script was run from memory with -EncodedCommand<\/code> and never touched disk. Getting both into a tamper-resistant location on a VPS takes about twenty minutes and a clear decision about where the data goes.<\/p>\n\n

What transcription records and what it misses<\/h2>\n\n

Transcription writes a text file per host, per user, with a header naming the machine, the user, the runas account, and the time zone, then every command and its output in order. It captures output from Start-Transcript<\/code> in interactive sessions, from the Windows PowerShell ISE, and \u2014 with the policy set \u2014 from every PowerShell host on the machine.<\/p>\n\n

What it does not capture is equally important. Output of commands run in a nested job or runspace started by Start-Job<\/code> can land in a separate transcript. Native executables that write directly to the console (most installers, robocopy<\/code>, sqlcmd<\/code>) are recorded only as far as PowerShell can observe the stream. And a script that reads a password from a secure string and passes it to an external tool will record the argument, so keep credentials in Get-Credential<\/code> objects or Windows.Data.Protection<\/code> rather than typed inline.<\/p>\n\n

Transcription gives you readability, not integrity \u2014 that distinction drives the storage design below.<\/p>\n\n

If you have not yet chosen the host that will hold the transcript share, the Windows VPS platform overview<\/a> lists which plans include a dedicated data disk and private networking between instances.<\/p>\n\n

Enable both controls system-wide with Group Policy<\/h2>\n\n

The settings live under Computer Configuration\\Administrative Templates\\Windows Components\\Windows PowerShell<\/code>, and applying them by GPO rather than by registry edit means a local administrator cannot quietly switch them off through the registry without the next policy refresh reverting the change.<\/p>\n\n

Policy setting<\/th>Registry value<\/th>Recommended for a VPS<\/th><\/tr><\/thead>
Turn on PowerShell Transcription<\/td>HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\Transcription\\EnableTranscripting = 1 (DWORD)<\/td>Enabled<\/td><\/tr>
Transcript output directory<\/td>…\\Transcription\\OutputDirectory (REG_SZ)<\/td>\\\\fs01\\ps-logs\\%COMPUTERNAME%<\/td><\/tr>
Include invocation headers<\/td>…\\Transcription\\IncludeInvocationHeader = 1 (DWORD)<\/td>Enabled \u2014 adds timestamps<\/td><\/tr>
Turn on PowerShell Script Block Logging<\/td>HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\\EnableScriptBlockLogging = 1<\/td>Enabled<\/td><\/tr>
Log script block invocation start\/stop<\/td>…\\ScriptBlockLogging\\EnableScriptBlockInvocationLogging = 1<\/td>Disabled \u2014 doubles 4104 volume<\/td><\/tr>
Event log size, PowerShell\/Operational<\/td>HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WINEVT\\Channels\\Microsoft-Windows-PowerShell\/Operational\\MaxSize<\/td>1 048 576 KB (1 GB)<\/td><\/tr><\/tbody><\/table>
Policy registry values under HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell<\/figcaption><\/figure>\n\n

The same result can be written directly with registry commands for a single server, which is useful when you are testing before rolling out the GPO:<\/p>\n\n

$base = 'HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell'\nNew-Item -Path \"$base\\Transcription\" -Force | Out-Null\nSet-ItemProperty \"$base\\Transcription\" EnableTranscripting -Type DWord -Value 1\nSet-ItemProperty \"$base\\Transcription\" EnableInvocationHeader -Type DWord -Value 1\nSet-ItemProperty \"$base\\Transcription\" OutputDirectory -Value '\\\\fs01\\ps-logs\\%COMPUTERNAME%'\nNew-Item -Path \"$base\\ScriptBlockLogging\" -Force | Out-Null\nSet-ItemProperty \"$base\\ScriptBlockLogging\" EnableScriptBlockLogging -Type DWord -Value 1\n\n# Verify without logging off\ngpupdate \/target:computer \/force\nGet-ItemProperty \"$base\\Transcription\" | Select-Object EnableTranscripting, OutputDirectory<\/code><\/pre>\n\n
Be aware that the policy path is under HKLM\\SOFTWARE\\Policies<\/code>, not HKLM\\SOFTWARE\\Microsoft\\Windows\\PowerShell<\/code>. Values written to the non-Policies key are honoured by the engine in some builds but are ignored the moment a domain GPO sets the policy value, which produces the classic “it worked on the test box” failure.<\/p>\n\n
Send transcripts somewhere the admin cannot alter<\/h2>\n\n
The default transcript location is %USERPROFILE%\\Documents\\PowerShell_transcript.*.txt<\/code>. On a VPS anyone with local admin can delete that directory, edit the files, or stop the service, so the control has no evidentiary value unless the output leaves the machine immediately. Point OutputDirectory<\/code> at a UNC path on a file server or a log collector with append-only permissions.<\/p>\n\n
If the share is temporarily unavailable, PowerShell does not buffer \u2014 it writes a warning to the console and the transcript for that session is lost. Keep a fourteen-day local fallback that your backup agent picks up, and forward the contents off-box, so a network blip during an incident does not erase the record of that incident.<\/p>\n\n
Script Block Logging fills the gaps transcription leaves<\/h2>\n\n
Every time PowerShell parses a script block it writes event ID 4104<\/b> to Microsoft-Windows-PowerShell\/Operational<\/code>. The event contains the raw text of the block, the script path, and a ScriptBlockId<\/code> that groups all parts of a large script \u2014 blocks above 20 KB are split across events 4104 with matching IDs, and you must reassemble them in the correct order to read the code.<\/p>\n\n
That is what catches the common VPS intrusion pattern: the attacker runs a Base64-encoded one-liner through powershell -EncodedCommand<\/code>, nothing is written to disk, and the only trace is a 4104 event containing the decoded script. Reading recent blocks with filter and shaping is quick from Get-WinEvent<\/code>:<\/p>\n\n
$since = (Get-Date).AddHours(-24)\nGet-WinEvent -FilterHashtable @{\n  LogName   = 'Microsoft-Windows-PowerShell\/Operational'\n  Id        = 4104\n  StartTime = $since\n} | ForEach-Object {\n  $x = [xml]$_.ToXml()\n  [pscustomobject]@{\n    Time     = $_.TimeCreated\n    BlockId  = ($x.Event.EventData.Data | Where-Object Name -eq 'ScriptBlockId').'#text'\n    Path     = ($x.Event.EventData.Data | Where-Object Name -eq 'Path').'#text'\n    Script   = ($x.Event.EventData.Data | Where-Object Name -eq 'ScriptBlockText').'#text'\n  }\n} | Where-Object { $_.Script -match 'DownloadString|FromBase64String|IEX|Invoke-Expression|Net\\.WebClient' } |\n  Format-List Time, BlockId, Path, Script<\/code><\/pre>\n\n
Event 4103 is the Invocation Logging counterpart \u2014 it records the parameters a block was called with, not just its text, and is the only way to see what arguments a signed, unmodified module function received. It generates roughly one event per pipeline element, so enable it only on specific hosts or specific modules, never globally on a busy application server.<\/p>\n\n
Rotate and protect the audit trail<\/h2>\n\n
Both logs end up on disk, and a local administrator can clear the PowerShell log with wevtutil cl Microsoft-Windows-PowerShell\/Operational<\/code>. Event ID 1100 in the System log records log-service shutdown, and 104 proves a log was cleared \u2014 those two are the canary events you should alert on, ideally in an external SIEM rather than on the same host.<\/p>\n\n