I'm trying to connect to a Windows Machine via PowerShell in a Linux Machine to get some system's info, but I need to achieve it without use the WinRm.

Firstly, I installed the PowerShell following the instructions here. Starting the PowerShell with pwsh worked fine.

Then I tried to get some info through WMI using the following command:

Get-WmiObject -Class Win32_Process -Impersonation 3 -ComputerName IP_ADDRESS

The return is Get-WmiObject : The term 'Get-WmiObject' is not recognized as the name of a cmdlet, function, script file, or operable program..

Following the changelog for the version 6.0 of PowerShell's core, I found that the Get-Wmi* functions should be replaced for Get-Cmi* equivalents. Let's try:

Get-CimInstance -Class Win32_Process -Impersonation 3 -ComputerName IP_ADDRESS

The return is: Get-CimInstance : The term 'Get-CimInstance' is not recognized as the name of a cmdlet, function, script file, or operable program.

Looking for the list of commands, typing Get- and then Tab, the return indeed does not show any Wmi or Cim function.

I'm able to connect to the same computer using the cmdlet Invoke-Command, but as I said, I need to achieve it without the use of WinRm, and, apparently, this is not the case of Invoke-Comand

After a lot of Google search, I found only one similar question here in SO, but it user the cmdlet Enter-PSSession, that's also use WinRM if I understood correctly.

Finally, I found this blog post with fits like a glove with my needs. However, It suggest the use of the cmdlets Invoke-WmiMethod and Invoke-CimMethod that, for surprise of nobody, aren't recognized commands.

My question is: Are there anyway to run a WMI query to get some Windows info through PowerShell in a linux machine without the use of WinRm?

Note1: I'm able to run the Get-Wmi* and Get-Cim* cmdlets in Windows machine PowerShell (connected via RPC, for example);

Note2: I know a workaround to deal with it in linux without PowerShell and it should work for someone with similar problem, but it didn't work for me due to an unsolvable (for now, at least) encoding problem;


  • OS: Debian 8.10

  • $PSVersionTable.PSVersion: 6.0.1

  • Remote Windows: W10 Pro


Look to PoSH over SSH instead.

See the step thru here:

PowerShell Remoting Over SSH


PowerShell remoting normally uses WinRM for connection negotiation and data transport. SSH was chosen for this remoting implementation since it is now available for both Linux and Windows platforms and allows true multiplatform PowerShell remoting. However, WinRM also provides a robust hosting model for PowerShell remote sessions which this implementation does not yet do. And this means that PowerShell remote endpoint configuration and JEA (Just Enough Administration) is not yet supported in this implementation.

PowerShell SSH remoting lets you do basic PowerShell session remoting between Windows and Linux machines. This is done by creating a PowerShell hosting process on the target machine as an SSH subsystem. Eventually this will be changed to a more general hosting model similar to how WinRM works in order to support endpoint configuration and JEA.

The New-PSSession, Enter-PSSession and Invoke-Command cmdlets now have a new parameter set to facilitate this new remoting connection


  • Thanks for your help. It really worked. Just a side note, this SSH approach will work only with recent versions of Windows. – James Mar 1 '18 at 12:46
  • I marked this answer as correct since it is the only one, but it would be good to know some alternative that works with old versions of Windows, it means, a solution to connect to any windows' version through the PowerShell in linux. – James Mar 13 '18 at 16:58
  • 1
    No worries. But understand that this will not happen anytime soon. The statement 'any version of Windows' is far to broad. There is little reason to target legacy unsupported Windows. If you had said, all supported business windows version, I'd be inclined to agree. Yet, know, the even today, not all of PoSH tools are available on all versions of Windows. v5 on Win7 is not the same a v5 on Win10 for example and v6 is a far cry from v5x on Windows. So, as an OSS offering now, it's really up to the community. – postanote Mar 14 '18 at 0:30
  • You are right. All versions of windows is something too broad, but a solution that works in some of the old versions would be good. – James Mar 15 '18 at 1:46

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.