Move to PowerShell for WinRM Management

As most people are aware, PowerShell provides two ways of managing the Windows Remote Management (WinRM) infrastructure: the WSMan Provider and the WS-Management Cmdlets. (As you are no doubt aware, WinRM is the Windows implementation of the WS-Management standard, which is why these cmdlets are named Ws-Management.) Together, the WSMan Provider and WS-Management cmdlets give administrators the ability to enable, configure, manage, and test WinRM easily from within PowerShell, and are the best way for building scripts to manage WinRM.

Prior to the release of the WS-Management cmdlets, the only way to perform some WinRM management tasks was to use the WinRM.VBS scripting interface and WinRM.CMD. However, with the proven success of the PowerShell cmdlets, it is time to move away from those older tools. No development is planned for either WinRM.CMD or WinRM.VBS, and while they are still a part of Windows (to support backwards compatibility), no new scripts or development should be based on them.  

This is a small part of the long-established strategy to move to PowerShell for management of the Windows platforms. PowerShell has become the Windows scripting choice for IT Professionals, and is being more broadly adopted by developers with the addition of Desired State Configuration.

The WS-Management Cmdlets and WSMan Provider give PowerShell a complete mechanism for both local and remote management of WinRM, CredSSP, and PowerShell Sessions that is unavailable from VBScript. For more information on these, you will find links to both the WS-Management cmdlets and the WS-Man provider here on TechNet. There is also a very good article titled “Understanding PowerShell Remote Management” that covers these topics quite well.

To reiterate the key point: while WinRM.VBS and WinRM.CMD will ship in Windows to support backwards compatibility, new scripts developed to manage WinRM should be created using the WSMan Provider and the PowerShell WS-Management cmdlets.