Powershell: Foreach-Object Parallel serialization issue

[somescout]

Description

Powershell omits certain fields in foreach-object -parallel code block, for example Get-ADComputer correctly displays computer name in code block, but return empty string for any extra fields requested in Properties argument. When calling without -Parallel argument everything works as expected.

Steps to reproduce

Get-ADComputer w2 -Properties OperatingSystem | % -Parallel { $_.OperatingSystem }

Expected behavior

Windows 10 Pro

Actual behavior

<nothing>

Environment data

PSVersion                      7.1.0-preview.1
PSEdition                      Core
GitCommitId                    7.1.0-preview.1
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[SeeminglyScience]

The Parallel parameter doesn't actually serialize anything since it's thread based instead of process based.

This is due to the ActiveDirectory module defining it's own PSPropertyAdapter and registering it on module import.

@PaulHigin I know RunspaceFactory.CreateRunspace has some overloads that take a TypeTable. I'm guessing no, but is there a publicly accessible way to obtain the current TypeTable? Eh that's probably not feasible anyway without some method of removing things like script members.

[somescout]

So basically I could use something like this, as workaround

Get-ADComputer w2 -Properties OperatingSystem | % -Parallel { $_["OperatingSystem"] }

It is working, but it's inconsistent.

[SeeminglyScience]

@somescout Yeah that should work. You said it's inconsistent, do you have an example that doesn't work? Or can otherwise elaborate? (I may be able to suggest a more consistent alternative if I know what doesn't work)

[PaulHigin]

This is another consequence of the fact that each foreach -parallel loop iteration runspace is intialized (or reset) to its default state, rather than the state of the current runspace running the cmdlet.

I have created an Issue (#12240) to track this, and have linked this issue to that one.
Closing this issue.