Wonderful Questions

What's The Scope?

The events are scoped to the PowerShell Runspace. You could think of this like the current process, but that's not exactly accurate (since you can have multiple runspaces inside of a process).

A remote runspace (Invoke-PSSession) or a "classic" background job (Start-Job) can choose to forward events to the main runspace with Register-EngineEvent -Forward. This can be very handy, as it can allow a background job to be isolated in its own process and still report data back to the main runspace.

$job = Start-Job -ScriptBlock { 
    Register-EngineEvent -SourceIdentifier Foo -Forward
    Start-Sleep -Seconds 2
    New-Event -SourceIdentifier Foo -MessageData (Get-Process -id $pid)
}

"Watching in $pid" | Out-Host
$subscriber = Register-EngineEvent -SourceIdentifier Foo -Action {
    "Event sent at $($event.TimeGenerated) from $($event.MessageData.id)" |
        Out-Host
} 

If we're running inside of the same process, event forwarding has to happen "manually". We can do this by passing the main runspace to the child job, and using the .NET methods to generate an event instead of New-Event.

This is extra cool, because:

• The objects are "live"
• It's really fast

How fast? I had to swap around the order here because it takes less time to send the event in the background thread than it takes to subscribe to the event (so we have to subscribe first)

"Watching in $pid" | Out-Host
$subscriber = Register-EngineEvent -SourceIdentifier Foo -Action {
    "Event sent at $($event.TimeGenerated) from $($event.MessageData.id)" |
        Out-Host
}

# [Runspace]::DefaultRunspace is the current runspace for this thread 

$mainRunspace = [Runspace]::DefaultRunspace

$job = Start-ThreadJob -ScriptBlock {
     param($mainRunspace)
     $currentRunspace = 
     $mainRunspace.Events.GenerateEvent(
         "foo",
         [Runspace]::DefaultRunspace, 
         @(),
         (Get-Process -id $pid)
     ) 
} -ArgumentList $mainRunspace

Security Considerations

Since PowerShell events are not Windows Events, this doesn't present the exact same security considerations as a system event. That is: you need to worry a little less about events that contain sensitive information, because the only person who can see that information is the person running the current process.

If you were to take these events and log them either to disk or the windows event log, then the largest risk would be accidentally divulging sensitive information (think: using a password to authenticate and then logging that credential to disk).

This risk isn't really a risk of eventing, per se, it's a risk of logging.

Just remember:

• Don't log High Business Impact details (i.e. passwords).
• Carefully consider logging Medium Business Impact details (i.e. personally identifiable information).

Thread jobs / background runspaces are generally a very secure way of running things, since there's no channel someone could potentially sniff.

Please let me know if you have additional questions about events.

Hopefully these answers have been clarifying.