Add a timestamp to transcript

[thekamilpro]

Summary of the new feature / enhancement

As a user, I want to have the ability to enable timestamps with Start-Transcript command,
so that when the transcript is saved it automatically prefixes the output with the date.

There would be a question whether the timestamp should default to current time on the machine, or to UTC.

Proposed technical implementation details (optional)

Start-Transcript ./log.txt -IncludeTimeStamp
Write-Host "This is a test"
Stop-Transcript
gc log.txt
2024-08-23:11:04 This is a test

[iRon7]

Related: #17588 Add callback feature to Start-Transcript.

[SteveL-MSFT]

@thekamilpro just to be clear, you want a timestamp for each line of output?

[thekamilpro]

@SteveL-MSFT yes - expanded example below.

Start-Transcript ./log.txt -IncludeTimeStamp
Write-Host "This is a test"
Start-Sleep -Seconds 180
Write-Host "The end"
Stop-Transcript
gc log.txt
2024-08-23:11:04 This is a test
2024-08-23:14:04 The end

[kilasuit]

A few thoughts - as this is something that I know lots would like to see Transcription be more flexible

This is already sorta available when using the -IncludeInvocationHeader parameter - albeit not in that simple or friendly an output and far too much info for this simple a need.

There is a sample output with the full invocation header in the PowerShell loves the blue team blog post

We could address this ask with update the output from the UseMinimalHeader parameter so that it outputs an inline header with timestamp however this would break any current ingestion mechanisms, so I think we shouldn't do this

However if we added just this ask

Otherwise & what I think makes more sense & be additive and less of an upset would be adding a -InvocationDetails parameter that allows controlling the display of each commands InvocationTime, how we format it, what the duration was & what the completion time was` (exposing some of the info from Get-History)

Doing all of this would have perf impact though

Example with InvocationTimeStamp & completion time with inline/wrapped options (I prefer inline with InvocationTime only btw)

**********************
PowerShell transcript start
Start time: 20240821002046
**********************
Transcript started, output file is C:\ps\i\24135\transcript-min.txt
<<< Inline Invocation Start only>>>
[InvocationTime: 20240821002073] PS C:\> cd C:\ 
<<< Inline Invocation Start & Completion>>>
[InvocationTime: 20240821002073 : InvocationComplete: 20240821002084] PS C:\> cd C:\ 

<<< Wrapped >>>
[InvocationTime: 20240821002073]
PS C:\> cd C:\ 
[InvocationComplete: 20240821002084]

[InvocationTime: 20240821002096] 
PS C:\> ls .\PS\I\24135\

    Directory: C:\PS\I\24135

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          21/08/2024    00:20            174 transcript-min.txt

[InvocationComplete: 20240821002103] 

[InvocationTime: 20240821002124]  PS C:\> exit
**********************
PowerShell transcript end
End time: 20240821002126
**********************

additional longer term thoughts

OR perhaps a longer term thought (but is lots more work)

Provide a way for the logging format to be fully customisable from what we already use within the -IncludeInvocationHeader and provide a -UseCustomHeader switch parameter, along with -CustomHeaderDefinition which takes everything that IncludeInvocationHeader provides today, whilst surfacing any additional per line properties that we may define as being of use

This could be then used to capture a slightly reduced set of entries in a transcription file, but also enables a custom parser of each transcription entry for orgs to use downstream

It could also enable the scenario for each line in a transcription or the full transcription file to be run through Protect-CMSMessage or other similar methods inc PGP so can potentially negate some of the worries behind exposing secrets and follows on from the point made from the Security WG back in 2022.

[SydneyhSmith]

This is something we could consider if we make improvements to transcription logging

[jwyker]

Any update on this? Would be a great improvement to transcript logging.

[iSazonov]

@jwyker As far as I understand, the working group does not have a clear approval, but this can be added as an experimental feature so that we can evaluate this change based on feedback.

[lvde0]

Yes, this definitely seems like a useful feature. Especially for monitoring scripts running in headless environments.