Как активировать Windows Remote Management с помощью групповой политики

В этой статье, я попытаюсь рассказать, каким образом можно централизованно активировать и настроить службу Windows Remote Management (WinRM) на всех целевых компьютерах с помощью групповой политики. Напомню, что Windows Remote Management – это специальный сервис, позволяющий администраторам получить возможность удаленного доступа и управления клиентскими и серверными ОС Windows (и, думаю, если вы ранее пользовались набором утилит Microsoft Sysinternals PSTools, то WRM должен вам понравиться).
Возьмем обычный ПК с Windows 7, который включен в домен, и на котором не активирована функция Windows Remote Management. В командной строке введем следующую команду:

, должно появиться следующее сообщение об ошибке, свидетельствующее о том, что WRM не установлен:
WSMan Fault. The client cannot connect to the destination specified in the request. Error number: — 2144108526 0x80338012

Если нужно настроить WinRM вручную на отдельной системе, достаточно набрать команду:

В том случае, если нужно настроить WinRM на группе компьютеров, то можно воспользоваться специальными параметрами групповой политики. Интересующая нас политика находится в разделе: Computer Configuration -> Policies -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service. Нужно активировать следующие параметры:
• Allow automatic configuration of listeners
• Allow Basic Authentication

В разделе IPv4 filter укажем *, что означает, что компьютер может принимать подключения (а значит и управляющие команды) откуда угодно, это значит что листенеры на компьютере будет принимать запросы на всех IP интерфейсах.

Затем в разделе Computer Configuration -> Policies -> Windows Components -> Windows Remote Shell активируем пункт:
• Allow Remote Shell Access

И, наконец, нужно задать тип запуска у службы Windows Remote Service в «Автоматический» (Automatically). Напомню, что управлять способом запуска служб можно из следующего раздела групповых политик: Computer Configuration -> Windows Settings -> Security Settings ->System Services.

После активации WinRM с помощью групповой политики, на клиентской системе проверим статус службы с помощью знакомой команды:

Удостоверимся, что тип запуска службы WinRM задан в автоматический . Хотя по факту тип запуска «автоматический с задержкой», т.к. по умолчанию для службы WinRM задана задержка запуска (параметр DelayedAutoStart=1 в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinRM ).

Теперь, после активации WinRM с помощью групповой политики, данной системой можно управлять удаленно с помощью команд WinRS. Следующая команда откроет командную строку, запущенную на удаленной системе:

После появления окна командной строки вы можете выполнять и видеть результат выполнения любых команд на удаленном компьютере, как будто бы вы работаете за ним локально. Отметим, что на вашем управляющем компьютере WinRM также должна быть активирована.

Force a Remote Group Policy Refresh (GPUpdate)

Applies To: Windows Server 2012 R2, Windows Server 2012

Group Policy is a complicated infrastructure that enables you to apply policy settings to remotely configure a computer and user experience within a domain. When the Resultant Set of Policy settings does not conform to your expectations, a best practice is to first verify that the computer or user has received the latest policy settings. In previous versions of Windows, this was accomplished by having the user run GPUpdate.exe on their computer.

With Windows Server 2012 and Windows 8, you can remotely refresh Group Policy settings for all computers in an organizational unit (OU) from one central location by using the Group Policy Management Console (GPMC). Or you can use the Invoke-GPUpdate Windows PowerShell cmdlet to refresh Group Policy for a set of computers, including computers that are not within the OU structure—for example, if the computers are located in the default computers container.

The remote Group Policy refresh updates all Group Policy settings, including security settings that are set on a group of remote computers, by using the functionality that is added to the context menu for an OU in the Group Policy Management Console (GPMC). When you select an OU to remotely refresh the Group Policy settings on all the computers in that OU, the following operations happen:

An Active Directory query returns a list of all computers that belong to that OU.

For each computer that belongs to the selected OU, a WMI call retrieves the list of signed in users.

A remote scheduled task is created to run GPUpdate.exe /force for each signed in user and once for the computer Group Policy refresh. The task is scheduled to run with a random delay of up to 10 minutes to decrease the load on the network traffic. This random delay cannot be configured when you use the GPMC, but you can configure the random delay for the scheduled task or set the scheduled task to run immediately when you use the Invoke-GPUpdate cmdlet.

This document describes a method to force a remote Group Policy refresh to all computers in an OU and all OUs that are contained within the selected OU by using the GPMC. An equivalent Windows PowerShell method is also presented for each procedure.

In this document

This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For more information, see Using Cmdlets.

Prerequisites

You can only schedule to force a remote Group Policy update by using the GPMC from domain-joined computers that are running:

Windows Server 2012 or Windows Server 2012 R2

Windows 8 or Windows 8.1 with Remote Server Administration Tools for Windows 8

You can schedule a remote Group Policy refresh for any computer running:

Windows Server 2012 R2

Windows Server 2012

WindowsВ ServerВ 2008В R2

WindowsВ ServerВ 2008

Step 1: Configure firewall rules on each client that will be managed with remote Group Policy refresh

To schedule a Group Policy refresh for domain-joined computers by using the GPMC or the Invoke-GPUpdate cmdlet, you must have firewall rules that enable inbound network traffic on the ports listed in the following table.

Type of network traffic

TCP RPC dynamic ports, Schedule

(Task Scheduler service)

Remote Scheduled Tasks Management (RPC)

TCP port 135, RPCSS

(Remote Procedure Call service)

Remote Scheduled Tasks Management (RPC-EPMAP)

TCP all ports, Winmgmt

(Windows Management Instrumentation service)

Windows Management Instrumentation (WMI-in)

In Windows Server 2012, Group Policy added a Starter GPO called, Group Policy Remote Update Firewall Ports. This Starter GPO includes policy settings to configure the firewall rules that are specified in the previous table. It is a best practice to create a new GPO from this Starter GPO. Link the GPO to your domain at a higher precedence than the Default Domain GPO, and then use it to configure all the computers in the domain to enable a remote Group Policy refresh.

To create a GPO from the Group Policy Remote Update Firewall Ports Starter GPO and link to the domain

In the GPMC console tree, locate the domain for which you want to configure all the computers to enable a remote Group Policy refresh.

Right-click the selected domain, and click Create a GPO in this domain, and link it here…

In the New GPO dialog box, type the name of the new Group Policy object in the Name box.

In the Source Starter GPO list, select the Group Policy Remote Update Firewall Ports Starter GPO that you want to use to create a new Group Policy object, and click OK.

In the results pane, click the Linked Group Policy Objects tab.

Select the GPO that you just created, and click the Up arrow until the GPO is listed above the Default Domain Policy. The new GPO will have a smaller link order value than the Default Domain Policy.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

Use the New-GPO cmdlet with the –StarterGpoName parameter, and then pipe the output to the New-GPLink cmdlet.

For example, to create a new GPO called Configure firewall rules for remote gpupdate by using the Group Policy Remote Update Firewall Ports Starter GPO, then link the new GPO to the Contoso.com domain, use the following script:

For more information about the New-GPO cmdlet and the New-GPLink cmdlet, see:

Step 2: Schedule a remote Group Policy refresh

You can schedule gpupdate.exe to run on multiple computers from the GPMC or from a Windows PowerShell session using the Invoke-GPUpdate cmdlet.

To schedule a Group Policy refresh to run on all computers in an OU by using the GPMC

In the GPMC console tree, locate the OU for which you want to refresh Group Policy for all computers.

Group Policy will also be refreshed for all computers that are located in the OUs contained in the selected OU.

Right-click the selected OU, and click Group Policy Update…

Click Yes in the Force Group Policy update dialog box. This is the equivalent to running GPUpdate.exe /force from the command line.

The Remote Group Policy update results window displays only the status of scheduling a Group Policy refresh for each computer located in the selected OU and any OUs contained within the selected OU. This display does not show the success or failure of the actual Group Policy refresh for each computer.

Use Resultant Set of Policy to determine the success of the scheduled Group Policy refresh, Determine Resultant Set of Policy.

You should plan a delay of up to 10 minutes to start a Group Policy refresh when you are verifying the results for each computer.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

The Invoke-GPUpdate cmdlet allows you to schedule a remote Group Policy update for a specified computer with all the options that the GPUpdate.exe command-line utility provides. This allows more freedom to determine which set of computers is to be refreshed than if you schedule the refresh through the GPMC. Additionally, you have the freedom to configure the interval of time to wait before a Group Policy refresh is performed by using the –RandomDelayInMinutes parameter. If set to a zero (0) value, the scheduled task for the Group Policy refresh is configured to start immediately. For more information, see Invoke-GPUpdate.

You can refresh the changed Group Policy settings for the computer that you are signed in to by running the Invoke-GPUpdate cmdlet without including any parameters, for example:

You cannot schedule a Group Policy refresh for the Computers container by using the GPMC Group Policy Update… functionality. The Computers container is a default location for computer accounts. It is not implemented as an OU that can be managed by the GPMC. However, by combining the use of the Windows PowerShell cmdlet, Get-ADComputer, with the Invoke-GPUpdate cmdlet, you can schedule a remote refresh for all computers in the Computers container. For more information about available Windows PowerShell cmdlets for Active Directory, see AD DS Administration Cmdlets in Windows PowerShell.

Installation and configuration for Windows Remote Management

For Windows Remote Management (WinRM) scripts to run, and for the Winrm command-line tool to perform data operations, Windows Remote Management (WinRM) has to be both installed and configured.

These elements also depend on WinRM configuration.

• The Windows Remote Shell command-line tool (Winrs).
• Event forwarding.
• Windows PowerShell 2.0 remoting.

Where WinRM is installed

WinRM is automatically installed with all currently-supported versions of the Windows operating system.

Configuration of WinRM and IPMI

These WinRM and Intelligent Platform Management Interface (IPMI) WMI provider components are installed with the operating system.

• The WinRM service starts automatically on Windows ServerВ 2008 and on wards (on WindowsВ Vista, you need to start the service manually).
• By default, no WinRM listener is configured. Even if the WinRM service is running, WS-Management protocol messages that request data can’t be received nor sent.
• Internet Connection Firewall (ICF) blocks access to ports.

Use the Winrm command to locate listeners and the addresses by typing the following command at a command prompt.

To check the state of configuration settings, type the following command.

Quick default configuration

You can enable the WS-Management protocol on the local computer, and set up the default configuration for remote management with the command winrm quickconfig .

The winrm quickconfig command (or the abbreviated version winrm qc ) performs these operations.

• Starts the WinRM service, and sets the service startup type to auto-start.
• Configures a listener for the ports that send and receive WS-Management protocol messages using either HTTP or HTTPS on any IP address.
• Defines ICF exceptions for the WinRM service, and opens the ports for HTTP and HTTPS.

The winrm quickconfig command creates a firewall exception only for the current user profile. If the firewall profile is changed for any reason, you should run winrm quickconfig to enable the firewall exception for the new profile; otherwise, the exception might not be enabled.

To retrieve information about customizing a configuration, type winrm help config at a command prompt.

To configure WinRM with default settings

Type winrm quickconfig at a command prompt.

If you’re not running under the local computer Administrator account, then you must either select Run as Administrator from the Start menu, or use the Runas command at a command prompt.

When the tool displays Make these changes [y/n]?, type y.

If configuration is successful, then the following output is displayed.

Keep the default settings for client and server components of WinRM, or customize them. For example, you might need to add certain remote computers to the client configuration TrustedHosts list.

You should set up a trusted hosts list when mutual authentication can’t be established. Kerberos allows mutual authentication, but it can’t be used in workgroups—only domains. A best practice when setting up trusted hosts for a workgroup is to make the list as restricted as possible.

Create an HTTPS listener by typing the command winrm quickconfig -transport:https . Be aware that you must open port 5986 for HTTPS transport to work.

Listener and WS-Management protocol default settings

To get the listener configuration, type winrm enumerate winrm/config/listener at a command prompt. Listeners are defined by a transport (HTTP or HTTPS) and an IPv4 or IPv6 address.

winrm quickconfig creates the following default settings for a listener. You can create more than one listener. For more information, type winrm help config at a command prompt.

Address

Specifies the address for which this listener was created.

Transport

Specifies the transport to use to send and receive WS-Management protocol requests and responses. The value must be either HTTP or HTTPS. The default is HTTP.

Specifies the TCP port for which this listener is created.

WinRM 2.0: The default HTTP port is 5985.

Hostname

Specifies the host name of the computer on which the WinRM service is running. The value must be a fully-qualified domain name, or an IPv4 or IPv6 literal string, or a wildcard character.

Enabled

Specifies whether the listener is enabled or disabled. The default value is True.

URLPrefix

Specifies a URL prefix on which to accept HTTP or HTTPS requests. This is a string containing only the characters a-z, A-Z, 9-0, underscore (_), and slash (/). The string must not start with or end with a slash (/). For example, if the computer name is SampleMachine, then the WinRM client would specify https://SampleMachine/ in the destination address. The default URL prefix is «wsman».

CertificateThumbprint

Specifies the thumbprint of the service certificate. This value represents a string of two-digit hexadecimal values found in the Thumbprint field of the certificate. This string contains the SHA-1 hash of the certificate. Certificates are used in client certificate-based authentication. Certificates can be mapped only to local user accounts, and they do not work with domain accounts.

ListeningOn

Specifies the IPv4 and IPv6 addresses that the listener uses. For example: «111.0.0.1, 111.222.333.444, ::1, 1000:2000:2c:3:c19:9ec8:a715:5e24, 3ffe:8311:ffff:f70f:0:5efe:111.222.333.444, fe80::5efe:111.222.333.444%8, fe80::c19:9ec8:a715:5e24%6».

Protocol default settings

Many of the configuration settings, such as MaxEnvelopeSizekb or SoapTraceEnabled, determine how the WinRM client and server components interact with the WS-Management protocol. The following list describes the available configuration settings.

MaxEnvelopeSizekb

Specifies the maximum Simple Object Access Protocol (SOAP) data in kilobytes. The default is 150 kilobytes.

The behavior is unsupported if MaxEnvelopeSizekb is set to a value greater than 1039440.

MaxTimeoutms

Specifies the maximum time-out, in milliseconds, that can be used for any request other than Pull requests. The default is 60000.

MaxBatchItems

Specifies the maximum number of elements that can be used in a Pull response. The default is 32000.

MaxProviderRequests

Specifies the maximum number of concurrent requests that are allowed by the service. The default is 25.

WinRM 2.0: This setting is deprecated, and is set to read-only.

WinRM client default configuration settings

The client version of WinRM has the following default configuration settings.

NetworkDelayms

Specifies the extra time in milliseconds that the client computer waits to accommodate for network delay time. The default is 5000 milliseconds.

URLPrefix

Specifies a URL prefix on which to accept HTTP or HTTPS requests. The default URL prefix is «wsman».

AllowUnencrypted

Allows the client computer to request unencrypted traffic. By default, the client computer requires encrypted network traffic and this setting is False.

Basic

Allows the client computer to use Basic authentication. Basic authentication is a scheme in which the user name and password are sent in clear text to the server or proxy. This method is the least secure method of authentication. The default is True.

Digest

Allows the client to use Digest authentication. Digest authentication is a challenge-response scheme that uses a server-specified data string for the challenge. Only the client computer can initiate a Digest authentication request. The client computer sends a request to the server to authenticate, and receives a token string from the server. Then the client computer sends the resource request, including the user name and a cryptographic hash of the password combined with the token string. Digest authentication is supported for HTTP and for HTTPS. WinRM Shell client scripts and applications can specify Digest authentication, but the WinRM service does not accept Digest authentication. The default is True.

Digest authentication over HTTP is not considered secure.

Certificate

Allows the client to use client certificate-based authentication. Certificate-based authentication is a scheme in which the server authenticates a client identified by an X509 certificate. The default is True.

Kerberos

Allows the client to use Kerberos authentication. Kerberos authentication is a scheme in which the client and server mutually authenticate by using Kerberos certificates. The default is True.

Negotiate

Allows the client to use Negotiate authentication. Negotiate authentication is a scheme in which the client sends a request to the server to authenticate. The server determines whether to use the Kerberos protocol or NTLM. The Kerberos protocol is selected to authenticate a domain account, and NTLM is selected for local computer accounts. The user name must be specified in domain\user_name format for a domain user. The user name must be specified in «server_name\user_name» format for a local user on a server computer. The default is True.

CredSSP

Allows the client to use Credential Security Support Provider (CredSSP) authentication. CredSSP enables an application to delegate the user’s credentials from the client computer to the target server. The default is False.

DefaultPorts

Specifies the ports that the client will use for either HTTP or HTTPS.

WinRM 2.0: The default HTTP port is 5985, and the default HTTPS port is 5986.

TrustedHosts

Specifies the list of remote computers that are trusted. Other computers in a workgroup or computers in a different domain should be added to this list.

The computers in the TrustedHosts list are not authenticated. The client may send credential information to these computers.

If an IPv6 address is specified for a TrustedHost, the address must be enclosed in square brackets as demonstrated by the following winrm utility command: winrm set winrm/config/client ‘@‘ .

For more info about how to add computers to the TrustedHosts list, type winrm help config .

WinRM service default configuration settings

The service version of WinRM has the following default configuration settings.

RootSDDL

Specifies the security descriptor that controls remote access to the listener. The default is «O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)».

MaxConcurrentOperations

The maximum number of concurrent operations. The default is 100.

WinRM 2.0: The MaxConcurrentOperations setting is deprecated, and is set to read-only. This setting has been replaced by MaxConcurrentOperationsPerUser.

MaxConcurrentOperationsPerUser

Specifies the maximum number of concurrent operations that any user can remotely open on the same system. The default is 1500.

EnumerationTimeoutms

Specifies the idle time-out in milliseconds between Pull messages. The default is 60000.

MaxConnections

Specifies the maximum number of active requests that the service can process simultaneously. The default is 300.

WinRM 2.0: The default is 25.

MaxPacketRetrievalTimeSeconds

Specifies the maximum length of time, in seconds, the WinRM service takes to retrieve a packet. The default is 120 seconds.

AllowUnencrypted

Allows the client computer to request unencrypted traffic. The default is False.

Basic

Allows the WinRM service to use Basic authentication. The default is False.

Certificate

Allows the WinRM service to use client certificate-based authentication. The default is False.

Kerberos

Allows the WinRM service to use Kerberos authentication. The default is True.

Negotiate

Allows the WinRM service to use Negotiate authentication. The default is True.

CredSSP

Allows the WinRM service to use Credential Security Support Provider (CredSSP) authentication. The default is False.

CbtHardeningLevel

Sets the policy for channel-binding token requirements in authentication requests. The default is Relaxed.

DefaultPorts

Specifies the ports that the WinRM service will use for either HTTP or HTTPS.

WinRM 2.0: The default HTTP port is 5985, and the default HTTPS port is 5986.

IPv4Filter and IPv6Filter

Specifies the IPv4 or IPv6 addresses that listeners can use. The defaults are IPv4Filter = * and IPv6Filter = *.

IPv4: An IPv4 literal string consists of four dotted decimal numbers, each in the range 0 through 255. For example: 192.168.0.0.

IPv6: An IPv6 literal string is enclosed in brackets and contains hexadecimal numbers that are separated by colons. For example: [::1] or [3ffe:ffff::6ECB:0101].

EnableCompatibilityHttpListener

Specifies whether the compatibility HTTP listener is enabled. If this setting is True, then the listener will listen on port 80 in addition to port 5985. The default is False.

EnableCompatibilityHttpsListener

Specifies whether the compatibility HTTPS listener is enabled. If this setting is True, then the listener will listen on port 443 in addition to port 5986. The default is False.

Winrs Default Configuration Settings

winrm quickconfig also configures Winrs default settings.

AllowRemoteShellAccess

Enables access to remote shells. If you set this parameter to False, then new remote shell connections will be rejected by the server. The default is True.

IdleTimeout

Specifies the maximum time, in milliseconds, that the remote shell will remain open when there is no user activity in the remote shell. The remote shell is automatically deleted after the time that is specified.

WinRM 2.0: The default is 180000. The minimum value is 60000. Setting this value lower than 60000 will have no effect on the time-out.

MaxConcurrentUsers

Specifies the maximum number of users who can concurrently perform remote operations on the same computer through a remote shell. New remote shell connections will be rejected if they exceed the specified limit. The default is 5.

MaxShellRunTime

Specifies the maximum time, in milliseconds, that the remote command or script is allowed to execute. The default is 28800000.

WinRM 2.0: The MaxShellRunTime setting is set to read-only. Changing the value for MaxShellRunTime will have no effect on the remote shells.

MaxProcessesPerShell

Specifies the maximum number of processes that any shell operation is allowed to start. A value of 0 allows for an unlimited number of processes. The default is 15.

MaxMemoryPerShellMB

Specifies the maximum amount of memory allocated per shell, including the shell’s child processes. The default is 150 MB.

MaxShellsPerUser

Specifies the maximum number of concurrent shells that any user can remotely open on the same computer. If this policy setting is enabled, then the user won’t be able to open new remote shells if the count exceeds the specified limit. If this policy setting is disabled or is not configured, the limit will be set to 5 remote shells per user by default.

Configuring WinRM with Group Policy

Use the Group Policy editor to configure Windows Remote Shell and WinRM for computers in your enterprise.

To configure with Group Policy

1. Open a Command Prompt window as an administrator.
2. At the Command Prompt, type gpedit.msc . The Group Policy Object Editor window opens.
3. Find the Windows Remote Management and Windows Remote Shell Group Policy Objects (GPO) under Computer Configuration\Administrative Templates\Windows Components.
4. On the Extended tab, select a setting to see a description. Double click a setting to edit it.

Windows Firewall and WinRM 2.0 ports

Starting in WinRM 2.0, the default listener ports configured by Winrm quickconfig are port 5985 for HTTP transport, and port 5986 for HTTPS. WinRM listeners can be configured on any arbitrary port.

If a computer is upgraded to WinRM 2.0, the previously configured listeners are migrated, and still receive traffic.

WinRM installation and configuration notes

WinRM isn’t dependent on any other service except WinHttp. If the IIS Admin Service is installed on the same computer, then you might see messages that indicate that WinRM can’t be loaded before Internet Information Services (IIS). However, WinRM doesn’t actually depend on IIS—those messages occur because the load order ensures that the IIS service starts before the HTTP service. WinRM does require that WinHTTP.dll be registered.

If the ISA2004 firewall client is installed on the computer, then it can cause a Web Services for Management (WS-Management) client to stop responding. To avoid this issue, install ISA2004 Firewall SP1.

If two listener services with different IP addresses are configured with the same port number and computer name, then WinRM listens or receives messages on only one address. This is because the URL prefixes used by the WS-Management protocol are the same.

IPMI driver and provider installation notes

The driver might not detect the existence of IPMI drivers that are not from Microsoft. If the driver fails to start, then you might need to disable it.

If the baseboard management controller (BMC) resources appear in the system BIOS, then ACPI (Plug and Play) detects the BMC hardware, and automatically installs the IPMI driver. Plug and Play support might not be present in all BMCs. If the BMC is detected by Plug and Play, then an Unknown Device appears in Device Manager before the Hardware Management component is installed. When the driver is installed, a new component, the Microsoft ACPI Generic IPMI Compliant Device, appears in Device Manager.

If your system doesn’t automatically detect the BMC and install the driver, but a BMC was detected during the setup process, then you must create the BMC device. To do this, type the following command at a command prompt: Rundll32 ipmisetp.dll, AddTheDevice . After this command is executed, the IPMI device is created, and it appears in Device Manager. If you uninstall the Hardware Management component, then the device is removed.

The IPMI provider places the hardware classes in the root\hardware namespace of WMI. For more information about the hardware classes, see IPMI Provider. For more information about WMI namespaces, see WMI Architecture.

WMI plug-in configuration notes

Beginning with WindowsВ 8 and Windows ServerВ 2012, WMI plug-ins have their own security configurations. For a normal or power (non-administrator) user to be able to use the WMI plug-in, you need to enable access for that user after the listener has been configured. First, you must set up the user for remote access to WMI through one of these steps.

• Run lusrmgr.msc to add the user to the WinRMRemoteWMIUsers__ group in the Local Users and Groups window, or
• use the winrm command-line tool to configure the security descriptor for the namespace of the WMI plug-in, as follows: winrm configSDDL http://schemas.microsoft.com/wbem/wsman/1/wmi/ WmiNamespace .

When the user interface appears, add the user.

After setting up the user for remote access to WMI, you must set up WMI to allow the user to access the plug-in. To do this, run wmimgmt.msc to modify the WMI security for the namespace to be accessed in the WMI Control window.

The majority of the WMI classes for management are in the root\cimv2 namespace.