Closed chelnak closed 2 years ago
I'm not having much success with the repro for this issue.
The following image shows some basic info from my test rig.. You can see that applying test.pp
works with no issue:
Also Protected Event Logging is enabled and encrypting events as expected:
The main thing that perplexes me right now is how the encryption of the logs is correlated with the output of the PowerShell provider.
Attaching docs and further info from customer...
Also, this is coupled with the GPO "Turn on PowerShell Script Block Logging" set to "Enabled". In testing I've found that the errors don't occur if "Protected Event Logging" is enabled, but that policy is not.
Great news! That extra info helped me replicate the issue 😄
Fixed in #189
For each run we reset the session environment to a last known good state. We did this by removing all environment variables, then re-setting them from a cached set we took at the start of the run.
It appears that when ScriptBlock Logging and Protected Event Logging are both enabled, removing the SystemRoot
environment variable from the current session causes PowerShell to crash.
I'm unclear at this time what the dependency is but suspect that there is a process that is consuming $env:\SystemRoot when building a path to an executable.
I was able to replicate by manually invoking init.ps1
with a custom name and redirecting pwshlib
to the new pipe. Once you do this you can see the whole error message. It talks about a missing environment variable...
A bit of trial and error narrowed it down to SystemRoot
.
SystemRoot
from the list and only removing the remainder.The questions remaining for me are:
SystemRoot
?
Both DSC resources and anything with a
provider => powershell
is immediately erroring out with errors as follows:See Slack thread for more discussion and a link to the ZenDesk ticket.