Partager via

Details on the changes in Windows Remote Management behavior in Windows Server 2008 R2 and Windows 7

  • Article

Applies To: Windows Server 2008 R2

This article details the behavior changes of Windows Remote Management (WinRM) you might encounter when upgrading to Windows 7 and Windows Server 2008 R2 from an existing deployment.

WinRM Behavior changes

  1. Detecting which version of WinRM is installed

  2. Default ports changed

  3. Updates to configuration

  4. Deprecated resource URIs

  5. CredSSP HTTP headers

  6. New SOAP headers

  7. Returned__cimnamespace selector for DMFT URI requests

  8. XPRESS compression used for shell operations

  9. HTTP cookies used

  10. RootDDL used differently

  11. Changed shell resource URI

  12. Different faults returned

  13. Shell schema changed

  14. Non-admin access restricted by default

  15. Local operations require service to be started

  16. CredSSP required for WinRM operations through WinRS

  17. Multiple listeners

  18. Configuring WinRM

Detecting which version of WinRM is installed

If the WinRM service is not currently running, you can determine the version of WinRM installed on your system by checking the version of the file %Windir%\System32\wsmsvc.dll. The table below outlines the WinRM version number that is indicated by the various possible file version numbers of %Windir%\System32\wsmsvc.dll:

Version number for %Windir%\System32\wsmsvc.dll

WinRM version

5.2.3790.2075

0.5

6.0.6000.16386

1.0

5.1.2600.3191

1.1

5.2.3790.2990

1.1

5.2.3790.4131

1.1

6.0.6001.18000

2.0

6.1.7600.16385

2.0

Default ports changed

The values for the default ports have changed from 80/443 to 5985/5986 for HTTP/HTTPS connections. For more detailed information on this change, see Details on the changes in Windows Remote Management behavior in Windows Server 2008 R2 and Windows 7.

Updates to configuration

The following elements in the WS-Management configuration were added in Windows 7.

  • winrm\Config\Client\Auth\CredSSP

  • winrm\Config\Service\Auth\CredSSP

  • winrm\Config\Service\Auth\CbtHardeningLevel

The following elements in the WS-Management configuration have been deprecated and their values are no longer functional.

  • winrm\Config\MaxProviderRequests

  • winrm\Config\Service\MaxConcurrentOperations

  • winrm\Config\Winrs\MaxShellRunTime

Deprecated resource URIs

The following resource URI has been deprecated.

CredSSP HTTP headers

When CredSSP authentication is used, the following HTTP headers are used.

Authorization  = "Authorization" ":" “CredSSP”  1#( gssapi-data )

Protocolvalue: “application/HTTP-CredSSP-session-encrypted”

New SOAP headers

The following SOAP headers are now sent as a part of some WS-Management messages.

  • DataLocale

  • ActivityId

Returned _cimnamespace selector for DMTF URI requests

When a request contains a resource URI that is a DMTF URI, a URI that begins with https://schemas.dmtf.org/, the __cimnamespace selector is returned as a part of the Endpoint Reference (EPR) in the response.

XPRESS compression used for shell operations

The CompressionType SOAP header is sent as a part of the Create message when creating a shell, with the value xpress, to indicate that the XPRESS compression algorithm will be used to compress the contents of the stream data sent to and from that shell.

HTTP cookies used

In order to maintain server affinity in the face of load balancers, HTTP cookies are sometimes used.

RootSDDL used differently

The value stored at winrm\Config\Service\RootSDDL is only used for security access checks if the requested resource URI does not specify its own specific SDDL as a part of the plug-in configuration.

Changed shell resource URI

Shells are addressed using the following URI.

  1. https://schemas.microsoft.com/wbem/wsman/1/windows/shell

The following resource URIs have been deprecated and can no longer be used.

  1. https://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd

  2. https://schemas.microsoft.com/wbem/wsman/1/windows/shell/CustomShell

Different faults returned

A wsman:InvalidValue fault is returned when invalid XML is received by the WS-Manangement service. A wsman:InternalError fault is returned when a quota limit is violated by a request.

Shell schema changed

The following elements in the Shell schema, returned in a GetResponse message directed at a shell resource URI, were added in Windows 7.

  1. ResourceUri

  2. Owner

  3. ClientIP

  4. Environment

  5. WorkingDirectory

  6. ShellIdleTimeout

  7. ShellRunTime

  8. ShellInactivity

Additionally, the Lifetime element in the Shell schema, returned in a GetResponse message directed at a shell resource URI, is no longer returned in Windows 7.

Non-admin access restricted by default

There are some operations that are no longer enabled by default for non-admin users. In order to enable them, the non-admin user needs to either be added to the default SDDL, which is stored at winrm\Config\Service\RootSDDL, or to the SDDL for the resource URI in question. The SDDL for that resource URI is stored as a part of the plugin-specific configuration. The following operations are now restricted by default.

  1. Local operations against winrm/config/client/* resources

  2. Local operations against wmicimv2/* resources

Local operations require service to be started

In order to carry out local operations against wimr/config/* resources, the WinRM service must be started. The service is not started by default on client SKUs of Windows 7.

CredSSP required for WinRM operations through WinRS

In order to carry out a WinRM operations when inside an interactive WinRS session, CredSSP authentication must be used. For example, issuing the winrs –r:<server> cmd or winrm g winrm/config commands now requires CredSSP authentication.

Multiple listeners

In most scenarios, it is not possible for WinRM to listen for requests on the same network interface on more than one port. However it is possible for two such listeners to coexist as long as one of them is on port 80 for HTTP or port 443 for HTTPS. The listener on 80/443 can be created either via Group Policy or through a specific WinRM configuration setting.

Configuring WinRM

The following commands can be used to configure WinRM from the PowerShell command prompt.

  • To enumerate the existing WinRM listeners:

    winrm enumerate winrm/config/listener

  • To enable the "compatibility" HTTP listener on port 80:

    winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

  • To enable the "compatibility" HTTPS listener on port 443:

    winrm set winrm/config/service @{EnableCompatibilityHttpsListener="true"}

  • To disable the "compatibility" HTTP listener on port 80:

    winrm set winrm/config/service @{EnableCompatibilityHttpListener="false"}

  • To disable the "compatibility" HTTPS listener on port 443:

    winrm set winrm/config/service @{EnableCompatibilityHttpsListener="false"}

The following Group Policy settings can be used to enable/disable the "compatibility" listeners:

  • Windows Components > Windows Remote Management (WinRM) > WinRM Service > Turn On Compatibility HTTP Listener

  • Windows Components > Windows Remote Management (WinRM) > WinRM Service > Turn On Compatibility HTTPS Listener