get-winevent inside invoke-command can't handle arrays inside filterhashtable

[jszabo98]

Steps to reproduce

# elevated prompt
start-service winrm
invoke-command localhost { get-winevent @{logname = 'application'; level = 1,2,3} }  

Expected behavior

# many events

Actual behavior

Get-WinEvent: No events were found that match the specified selection criteria.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.1
PSEdition                      Core
GitCommitId                    7.0.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

Workaround, define an array variable first inside the scriptblock. Note that passing in an array as a param() to invoke-command is notoriously difficult.

invoke-command localhost { $levels = 1,2,3; get-winevent @{logname = 'application'; level = $levels} }

[iSazonov]

Can you confirm that you use PS7 remote point (not Windows PowerShell remote point)?

[jszabo98]

No, as is likely, the remote endpoint is PS 5. How do you enable a PS 7 endpoint? Running enable-psremote in PS 7 doesn't seem to do anything. Get-PSSessionConfiguration doesn't return anything. (Not working in win10 2004, crashing)

# windows 10 2004
Enable-PSRemoting

WARNING: PowerShell remoting has been enabled only for PowerShell 6+ configurations and does not affect Windows
PowerShell remoting configurations. Run this cmdlet in Windows PowerShell to affect all PowerShell remoting 
configurations.  WinRM is already set up to receive requests on this computer.
Set-WSManQuickConfig:
Line |
 121 |                  Set-WSManQuickConfig -force
     |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859113" 
Machine="localhost"><f:Message><f:ProviderFault provider="Config provider" 
path="%systemroot%\system32\WsmSvc.dll"><f:WSManFault 
xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859113" Machine="mycomputer.com">
<f:Message>WinRM firewall exception will not work since one of the network connection types on this machine is set to
Public. Change the network connection type to either Domain or Private and try again. </f:Message></f:WSManFault>
</f:ProviderFault></f:Message></f:WSManFault>

Get-PSSessionConfiguration # no output

Remote powershell 7 confirmed in windows 10 1809:

Enable-PSRemoting

WARNING: PowerShell remoting has been enabled only for PowerShell 6+ configurations and does not affect Windows 
PowerShell remoting configurations. Run this cmdlet in Windows PowerShell to affect all PowerShell remoting configurations.
WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.


Get-PSSessionConfiguration  # PS 5 remotes not shown

Name          : PowerShell.7
PSVersion     : 7.0
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote
                Management Users AccessAllowed

Name          : PowerShell.7.0.2
PSVersion     : 7.0
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote
                Management Users AccessAllowed


invoke-command localhost { get-winevent @{logname = 'application'; level = 1,2,3} } -ConfigurationName powershell.7

Get-WinEvent: No events were found that match the specified selection criteria.


# array test, only first element still returned
icm localhost { param($levels) $levels } -args 1,2,3 -ConfigurationName powershell.7

1

Windows 10 1903/1909 shrug (works as domain admin not local admin)

invoke-command localhost { get-winevent @{logname = 'application'; level = 1,2,3} } -ConfigurationName powershell.7

OpenError: [localhost] Connecting to remote server localhost failed with the following error message : Access is denied. For
more information, see the about_Remote_Troubleshooting Help topic.

[iSazonov]

@PaulHigin Could you please comment the issue?

[PaulHigin]

This is not a regression since it can be repro'd in WindowsPowerShell 5.1. This looks like another bug in the 'GetPowerShell' method that tries to convert script text into equivalent PowerShell command/parameters. The above workaround works because it causes the conversion to fail and the script text is sent to the target computer as is. A fix for this may involve detecting a hash table parameter argument like this and failing the conversion.

[daxian-dbw]

It looks GetPowerShell method is working as expected, but the problem lies in the serialization/deserialization layer -- the object[] (1,2,3) got deserialized into an ArrayList on the remote side, and hence Get-WinEvent couldn't understand the filter hashtable.

PS> $s = New-PSSession .
PS> Enter-PSSession $s
[localhost]: PS> function bar { param([hashtable] $h) $h; $type = $h['level'].GetType().FullName; "`nType of level's value: $type" }
[localhost]: PS> exit
PS> invoke-command $s { bar @{logname = 'application'; level = 1,2,3} }

Name                           Value
----                           -----
level                          {1, 2, 3}
logname                        application

Type of level's value: System.Collections.ArrayList

If you use ArrayList locally, you will get the same error.

PS> $al = [System.Collections.ArrayList]::new()
PS> $al.Add(1) > $null
PS> $al.Add(2) > $null
PS> $al.Add(3) > $null
PS> Get-WinEvent @{ logname = 'application'; level = $al}
Get-WinEvent: No events were found that match the specified selection criteria.

I'm not sure if this can be fixed at all since it's in the serialization/deserialization layer. @PaulHigin any thoughts?

[PaulHigin]

I would argue that GetPowerShell is not working correctly, if its conversion to command/parameters fails, even if the failure is in the serialization system. I doubt we can safely change serialization behavior so I feel the best fix is to not perform conversion for hashtable argument cases, if they can't be transferred correctly.

[daxian-dbw]

The failure can happen in a different form, where GetPowerShell is not involved:

PS:45> Invoke-Command $s { param($h) $h.GetType(); Get-WinEvent $h } -ArgumentList @{logname = 'application'; level = 1,2,3}

IsPublic IsSerial Name                                     BaseType                                 PSComputerName
-------- -------- ----                                     --------                                 --------------
True     True     Hashtable                                System.Object                            localhost
Get-WinEvent: No events were found that match the specified selection criteria.

[PaulHigin]

Yes, definitely this is broken and we should look at fixing it if possible. But the script version works just fine and is probably much more common. I feel we are compounding the problem by gratuitously converting the working script to a broken command form. We may be able to fix it in the serialization system, but I am a little worried about making changes there. But I agree that if it can be fixed there, that would be ideal.

[SteveL-MSFT]

@PowerShell/powershell-committee discussed this in relation to another issue, we agreed that remoting should not be using GetPowerShell and instead should be passing the scriptblock as text to be handled by the target

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.