WinRM - Not Just for PowerShell


As you are probably aware, Windows PowerShell Remoting is based on the WS-Man protocols which are managed by the WinRM service. The primary advantage of this technology is that a secure, remote connection is made over a single, configurable port. None of the chaos normally associated with RPC and DCOM connections. Plus the command is executing on the remote machine, just as if you were sitting in front of the computer.

But you are not required to use PowerShell to leverage WinRM. Sure a lot of remote management is easier done through PowerShell, but let me show you some tricks you might want to try outside of the PS prompt.

Using WinRM Outside of PowerShell

First, remoting must be enabled on the remote machine if you haven’t already done it via PowerShell. Open a CMD prompt and run this command:

​C:\winrm –quickconfig

Follow any prompts and in moments you’ll be ready to go. To see your configuration try this:

Sponsored Content

Passwords Haven’t Disappeared Yet

123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?

​C:\winrm get winrm/config

You should get something like Figure 1.

Figure 1 - WinRM Configuration

Figure 1 – WinRM Configuration

If you haven’t guessed by now, we’ll be using the WinRM command line tool. Run it with –help or /? parameter at any time to see help.

The first thing I’m going to do is check on the status of WinRM on a remote computer.

​C:\winrm id -remote:quark


ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd

ProductVendor = Microsoft Corporation

ProductVersion = OS: 6.2.8400 SP: 0.0 Stack: 3.0


SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/spnego-kerberos

I got a response, so that looks good. How about getting some management information? The primary resource you will use is WMI {See my article on Command Line WMI Part 1}. The advantage of using WinRM is that network communication is over that single port instead of RPC which makes this much more firewall friendly.

For WMI classes that are singletons, that is only a single instance, you can run a command like this:

​C:\winrm enum wmicimv2/win32_bios -remote:quark

I have the results in Figure 2.

Figure 2 - A WMI query via WinRM

Figure 2 – A WMI query via WinRM

For other classes, you can specify a single instance. Here are some example commands you can try. You should be able to use your computer name in place of the remote name.

​C:\winrm get wmicimv2/win32_computersystem?Name=quark -remote:quark

C:\winrm get wmicimv2/win32_service?Name=Wuauserv -remote:quark

C:\winrm get wmicimv2/win32_logicaldisk?DeviceId=C: -remote:quark

It is possible to also get all instances of a specific class:

​C:\winrm enum wmicimv2/win32_service –remote:quark

Creating a WMI query takes a little extra work but you should be able to use this command as a model.

​C:\>winrm enum wmicimv2/* -dialect:wql -filter:"Select Name,Displayname from win32_service where state='Running'" -remote:quark


You need to enumerate all classes under the namespace, specifying a WQL query. The results aren’t necessarily that pretty to look at but they are functional.

You can also use this technology to execute commands remotely but we’ll cover that another day.

Related Topics: