Winrm default authentication error - Исправление ошибок и поиск оптимальных решений проблем

I have disabled negotiate authentication for the winrm service on my server by executing:

winrm put winrm/config/service/Auth @{Negotiate="false"}

And now I can perform any operation with winrm. I get the error:

    Message = The WinRM client cannot process the request. The WinRM client trie
d to use Negotiate authentication mechanism, but the destination computer (local
host:47001) returned an 'access denied' error. Change the configuration to allow
 Negotiate authentication mechanism to be used or specify one of the authenticat
ion mechanisms supported by the server. To use Kerberos, specify the local compu
ter name as the remote destination. Also verify that the client computer and the
 destination computer are joined to a domain. To use Basic, specify the local co
mputer name as the remote destination, specify Basic authentication and provide
user name and password. Possible authentication mechanisms reported by server:

I understand the error, but the problem is that the only way I find on the web to enable Negotiate authentication is by executing:

winrm put winrm/config/service/Auth @{Negotiate="true"}

Which of course gives the error above. Is there another way to enable Negotiate authentication?

asked Nov 1, 2013 at 10:24

Use Group Policy:

Computer > Policies > Administrative Templates > Windows Components > Windows Remote Management > WinRM Service:
Disallow Negotiate Authentication: Disabled.

answered Nov 1, 2013 at 11:36

Greg AskewGreg Askew

34.7k4 gold badges52 silver badges82 bronze badges

Edit the registry key
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWSMANClient.

Set auth_kerberos and auth_negotiate to 1.

Restart the service.

answered Jan 1, 2015 at 9:48

IvanIvan

1711 silver badge3 bronze badges

As suggested in this answer, but Service, not Client:

Edit the registry key HKLMSOFTWAREMicrosoftWindowsCurrentVersionWSMANService.
Set auth_kerberos and auth_negotiate to 1.
Restart the Windows Remote Management (WS-Management) Service.

answered May 18, 2017 at 23:43

On our server 2012 / exchange 2010 machine we had this error when trying to use AVG backup software.

I found removing both maxenvelopesize and trusted_hosts under this key did the trick

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWSMANClient]
"maxEnvelopeSize"=dword:000007d0
"trusted_hosts"="*"

sebix

4,2632 gold badges26 silver badges45 bronze badges

answered Jun 24, 2015 at 10:36

I had one server working, yet another would not. I could not find the problem. Finally I figured it out.

On the sending server:
set the local policy Computer ConfigurationAdministrative TemplatesSystemCredentials DelegationAllow Delegating Fresh Credentials. In there, set WSMAN* in the Add servers to the list (also check the box to Concatenate OS defaults)

On the receiving server (Create a .reg file with the following:):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWSMANClient] 
"auth_credssp"=dword:00000000

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWSMANService]
"auth_credssp"=dword:00000001

works for me

HBruijn

73.5k23 gold badges132 silver badges194 bronze badges

answered Aug 2, 2016 at 21:56

Please note that if the computer (server) is a member of domain, or itself is a domain controller (in my case Windows Server 2019), the Group Policy can be applied from domain group policy.
So I suggest (in these cases) use below command and check the «Disallow Negotiate authentication» policy winning value.

C:Tempgpresult /h rep.htm

It may be applied from «Default Domain Controllers Policy» !!

answered Nov 15, 2019 at 22:43

Источник

Locate manageability status errors
Troubleshoot manageability status errors
Additional resources

This topic is Part II of the Server Manager Troubleshooting Guide.

Windows Server 2012 — Server Manager Troubleshooting Guide, Part I: Overview
Windows Server 2012 — Server Manager Troubleshooting Guide, Part
III: Common Events and Errors in Server Manager

In Server Manager in Windows Server® 2012, manageability is defined as the readiness or ability of a remote computer to be managed by using Server Manager. The following factors are measured as part of evaluating the manageability of a remote computer.

Whether the computer can communicate with Server Manager, and transmit data about the computer’s operational state, and installed roles and features.
Whether the computer is running the right software, or software is configured in a way that allows Server Manager to query and update the computer.
Whether the user of Server Manager has adequate user rights to query the computer or make changes to its configuration.

Locate manageability status errors

Manageability status is displayed in the following locations in the Server Manager console.

On the Server Manager dashboard, the Manageability row in role and server group thumbnails displays alerts (red-highlighted numbers) if there are manageability problems with servers associated with those roles or groups, and a custom filter
created in the Manageability Detail View dialog box is not suppressing those alerts.
The Manageability Detail View dialog box, opened from the
Manageability row in thumbnails on the dashboard, displays the manageability status errors that are the source of alerts.
In the Servers tile on any role or server group home page (including the page for the
All Servers group) the Manageability column displays manageability status.

Troubleshoot manageability status errors

The following table can help you interpret the brief manageability status messages, and resolve problems that are preventing you from managing remote servers by using Server Manager. Many manageability status errors have underlying error messages that are
generated by Windows Remote Management (WinRM); these can be the result of security or authentication problems (such as attempting to manage a remote server in an untrusted domain, for example; or attempting to manage a server by using credentials that are
not recognized as those of an administrator on the remote server), or configuration problems (missing Windows PowerShell, remote management not enabled on the target server, etc.).

Note: In Server Manager practical terms, Negotiate authentication means that Server Manager falls back to NTLM authentication (1) if you attempt to use Server Manager to manage a server that is in an untrusted domain, or
that is in a workgroup, and (2) you provide explicit credentials to manage the target server. If you are using Server Manager to manage servers on which you must authenticate by using
Negotiate authentication, you cannot disable NTLM in your server environment.

In this context, the client is defined as the computer from which you are managing by using Server Manager; this computer can be a server that is running Windows Server 2012, or a computer that is running Windows 8 with
Remote Server Administration Tools installed.

To use the table, match the manageability status for a managed server with an underlying source WinRM or provider message displayed in the
Task Details dialog box, opened from the Notifications area in Server Manager. Find the row in the table where the combination of manageability status message and underlying error message match what is displayed in your Server
Manager console. Read the Possible Causes and Suggested Resolutions column in the matching row to find resolution steps that might help, or causes that are easy to eliminate (such as typographical errors in account credentials).

Manageability Status Message	Issue Category	Underlying Source Message from WinRM or Providers (shown in Task Details pane)	Possible Causes and Suggested Resolutions	Severity Level
Kerberos security error	Client-side authentication error: KerbUnknownSecurityError	Error <computer name> : Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config.	Client and target server are in the same domain; the target server is added to Server Manager, but later, the target server’s domain is changed to a trusted but different domain. Try removing the target server from the Server Manager server pool, and then adding the server again by using the Active Directory tab in the Add Servers dialog box. If you do not want to remove the server from Server Manager, try following instructions in Add Servers to Server Manager to add the target server to the client’s trusted hosts list.	Error
Kerberos target resolution error	Client-side authentication error: KerbResolutionError	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer <computer name>. Verify that the computer exists on the network and that the name provided is spelled correctly.	Client is in a domain, and the target server is in a workgroup (using the NetBIOS name of the server): A Kerberos error occurs if explicit credentials are not specified for managing the target server, because the Kerberos ticket granting service (TGS) cannot find the workgroup server, and the Default authentication mechanism does not attempt to use Negotiate authentication unless explicit credentials are specified for the target server. For information about how to add servers in workgroups to Server Manager, see Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer <computer name>. Verify that the computer exists on the network and that the name provided is spelled correctly. Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter.	Client is in Domain1 and the target server is in an untrusted Domain2. A Kerberos error occurs because the Kerberos TGS cannot find the target server. Explicit credentials must be used to manage the target server. Right-click the target server in the Servers tile of the All Servers page, and then click Manage As to provide explicit credentials.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer <computer name>. Verify that the computer exists on the network and that the name provided is spelled correctly. Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter.	Client is in a domain and the target server is in the same domain, but the domain name provided for the target server is incorrect or misspelled.	Error
Kerberos authentication error	Client-side authentication error: Kerb0x80090311Error	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config.	Client is in a domain, but the domain controller for the client computer is not accessible. Try adding the target server to the client computer’s trusted host list. For information about how to add a managed server to the trusted host list, see Add Servers to Server Manager.	Error
Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains.After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config.	Client is in a domain, and the target server is in the same domain (using the NetBIOS name or FQDN, and explicit but local-only administrator credentials for the target, or other non-domain credentials): A Kerberos error occurs because the credentials are unknown on the domain. The user must add the target server to the trusted host list on the client computer to allow the Default authentication mechanism to use Negotiate authentication instead of Kerberos. For information about how to add a managed server to the trusted host list, see Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config.	Client is in a domain and the target server is in a workgroup (using the NetBIOS name of the server): User has specified explicit credentials. An error occurs if the user has not added the server to the trusted host list of the client, because the Default authentication mechanism will not attempt Negotiate authentication unless explicit credentials are specified. For information about how to add a workgroup server to Server Manager, see Add Servers to Server Manager.	Error
Client-side authentication error: Kerb0x8009030eError	Error : Refresh failed with the following error (WSMAN): The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x8009030e occurred while using Kerberos authentication: A specified logon session does not exist. It may already have been terminated. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains.After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config.	Client is in a domain: Attempting to connect to a remote server by using implicit credentials that are the local administrator’s credentials on the client. Instead, use domain credentials that are recognized by the domain of the target server, or right-click the server entry in the Servers tile, click Manage As, and then specify credentials of an administrator on the target server.	Error
WinRM Default authentication error	Client-side authentication error: DefaultAuthReqsError	Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set TrustedHosts run the following command: winrm help config.	Client and target server are both in the same domain. The target server was added to Server Manager by using the IP address of the server, such as by using the Import tab of the Add Servers dialog box. An authentication error occurs because if a client is in a domain, and attempting to connect to a target server by referencing an IP address, the user must provide explicit server to the client computer’s trusted host list. This is required for the Default authentication mechanism to use Negotiate instead of Kerberos authentication. To avoid this problem, if target servers that you want to manage are in the same domain as the client computer, add them by using the Active Directory tab of the Add Servers dialog box.	Error
Client is in a domain and the target server is in a workgroup. The target server was added to Server Manager by using its IP address. An authentication error occurs because if a client is in a domain, and attempting to connect to a target server by referencing an IP address, the user must provide explicit credentials and add the target server to the client computer’s trusted host list. This is required for the Default authentication mechanism to use Negotiate instead of Kerberos authentication. For information about how to add a workgroup server to Server Manager, see Add Servers to Server Manager.	Error
WinRM Negotiate authentication error	Client-side authentication error: NegoAuthReqsError	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.	Client is in a workgroup, and the target server is in a workgroup (using the NetBIOS name of the server): The network can resolve the name of the server. An authentication error occurs because the target server has not been added to the trusted host list of the client computer, which permits Negotiate authentication. For information about how to add a workgroup server to Server Manager, see Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.	Client computer is in a workgroup, and the target server is also in a workgroup (using the IP address of the server): An authentication error occurs because the target server has not been added to the trusted host list of the client, which permits Negotiate authentication. For information about how to add a workgroup server to Server Manager, see Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.	Client computer is in a workgroup, and the target server is in a domain (using the NetBIOS name of the server): User’s network can resolve the name of the server. An authentication error occurs because the target server has not been added to the trusted host list of the client computer to allow Negotiate authentication. For information about how to add a domain server to Server Manager when the client is in a workgroup, see Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.	Client is in a workgroup and the target server is in a domain (using the IP address of the server): An authentication error occurs because the target server has not been added to the trusted host list of the client computer to allow Negotiate authentication. For information about how to add a domain server to Server Manager when the client is in a workgroup, see Add Servers to Server Manager.	Error
Target name resolution error	Name resolution error	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request because the server name cannot be resolved. Error <computer name>: Refresh failed with the following error: The RPC server is unavailable.	Client is in a workgroup, and the target server is in a workgroup (using the NetBIOS name of the server): A name resolution error occurs if the DNS server that is used by the client cannot resolve the target server name. This can occur when the client and target server are in two different workgroups, and each has a different DNS server. Add the target server to the client computer’s trusted host list. For information about how to add a workgroup server to Server Manager, see Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request because the server name cannot be resolved. Error <computer name>: Refresh failed with the following error: The RPC server is unavailable.	Client is in a workgroup and the target server is in a domain (using the NetBIOS name of the server): A name resolution error occurs if the DNS server that is used by the client cannot resolve the target server name. Add the target server to the client computer’s trusted host list. For information about how to add remote servers to a workgroup client that is running Server Manager, see Add Servers to Server Manager.	Error
Name resolution error: SpecialCasedError	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WS-Management could not connect to the specified destination: (<computer name>:5985).	The target server name includes an unsupported character or string, such as . This error can occur when a cluster logical node is offline. For more information about characters that cannot be used in server names, see Naming conventions in Active Directory for computers, domains, sites, and OUs.	Error
Error — Cannot manage the operating system of the target computer	Non-Windows target computer error	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: «winrm quickconfig». Error <computer name>: Refresh failed with the following error: The RPC server is unavailable.	The target computer is not running a Windows-based operating system. You cannot use Server Manager to manage this computer.	Error
Target computer not accessible	Network connection-related errors	Configuration Refresh failed with the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. [#1]Refresh failed with the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. [#1]	The network connecting the client and server is offline, or there is a problem with the target server’s connection to the network. Try verifying that Windows Firewall exceptions have been enabled on the target server for Windows Remote Management (WinRM) inbound rules. The netsh trace command-line utility can help troubleshoot network connectivity problems, if you do not immediately find the cause of network connectivity failures.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter.	The target computer is offline; either it is turned off, or not responding because of other hardware or software failures.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. Error <computer name>: Refresh failed with the following error: The RPC server is unavailable.	Client computer is in a domain and the target server is in a workgroup (using the NetBIOS name of the server): User has specified explicit credentials for the target server, and added the target server to the trusted host list of the client. However, a subnet timeout error occurs if the user has not changed the default subnet restrictions for computers in workgroups. See step 2 of “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager.	Error
Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. Error <computer IP address>: Refresh failed with the following error: The RPC server is unavailable.	Client is in a domain, and the target server is in a workgroup (using the IP address of the server): User has specified explicit credentials for the target server, and added the target server to the trusted host list of the client. However, a subnet timeout error occurs if the user has not changed the default subnet restrictions for computers in workgroups. See step 2 of “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. Error <computer name>: Refresh failed with the following error: The RPC server is unavailable.	The client is in a workgroup, and the target server is in a workgroup (using the NetBIOS name of the server): The user’s network can resolve the name of the server, and the user has added the target server to the trusted host list of the client. However, a subnet timeout error occurs if the user has not changed the default subnet restrictions for computers in workgroups. See step 2 of “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager.	Error
Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. Error <computer IP address>: Refresh failed with the following error: The RPC server is unavailable.	The client is in a workgroup, and the target server is in a workgroup (using the IP address of the target server): The user has added the server to the trusted host list of the client. However, a subnet timeout error occurs if the user has not changed the default subnet restrictions for computers in workgroups. See step 2 of “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter.	WinRM 3.0, WinRM 2.0, and DCOM are unavailable or not enabled on the target. On a server that is running Windows Server 2012, the user might have disabled both WinRM 3.0 or DCOM. On a server that is running an older Windows Server operating system, WinRM 2.0 and DCOM are not enabled by default, while WinRM 3.0 is not available. Follow instructions in Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012 to resolve this error.	Error
The metadata failed to be retrieved from the server, due to the following error: WS-Management cannot process the request. The operation failed because of an HTTP error. The HTTP error (50) is: The request is not supported.	User is attempting to connect to the target server by using an IPv4 address, but on the client computer, only IPv6, not IPv4, is enabled. Either connect to the target server by using its IPv6 address, or change settings on the client computer network adapters to support IPv4 addresses. These settings are found in Control PanelNetwork and Sharing CenterChange Adapter Settings. Right-click the network connection, click Properties, select Internet Protocol Version 4, and save your changes.	Error
Online — Verify WinRM 3.0 service is installed, running, and required firewall ports are open	Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the Windows Remote Management service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet.	WinRM 2.0 and 3.0 are either not available or not enabled, but DCOM is enabled on the target server. Note: DCOM is enabled by default for domain-joined servers that are running Windows Server 2012 and Windows Server 2008 R2, but not for Windows Server 2008. This error can occur on a server that is running an older Windows Server operating system (Windows Server 2008 R2 or Windows Server 2008) where the Windows Management Framework 3.0 download package has not been installed (so WinRM 3.0 is not available) and WinRM 2.0 is not enabled but DCOM is enabled. It can also occur on servers that are running Windows Server 2012 and older Windows Server operating systems where Windows Management Framework 3.0 is installed and DCOM is still enabled, but the user has disabled WinRM 3.0 (either stopped the service or closed required firewall ports). Follow instructions in Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012 to resolve this error.	Error
Network connection related errors: WinRM 2.0 and DCOM	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WS-Management service cannot process the request. The resource URI (<URI>) was not found in the WS-Management catalog. The catalog contains the metadata that describes resources, or logical endpoints.	WinRM 3.0 is not available or enabled, but WinRM 2.0 and DCOM are both enabled on the target server. This can occur on servers that are running older Windows Server operating systems (Windows Server 2008 R2 or Windows Server 2008 where the Windows Management Framework 3.0 download package has not been installed (so WinRM 3.0 is not available), but WinRM 2.0 and DCOM are both enabled. Follow instructions in Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012 to resolve this error.	Error
Network connection related errors: WinRM 2.0	Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WS-Management service cannot process the request. The resource URI (http://schemas.dmtf.org/wbem/cim-xml/2/cim-schema/2/*) was not found in the WS-Management catalog. The catalog contains the metadata that describes resources, or logical endpoints. Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter.	WinRM 3.0 and DCOM are either not available or not enabled, but WinRM 2.0 is enabled on the target server. Note: DCOM is enabled by default for domain-joined servers that are running Windows Server 2012 and Windows Server 2008 R2, but not for Windows Server 2008. A user might have enabled WinRM 2.0, but not DCOM, on a target server that is running an older Windows Server operating system, and not yet installed the Windows Management Framework 3.0 download package to get WinRM 3.0. Follow instructions in Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012 to resolve this error.	Error
Online — Access denied	Access denied error	Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Client is in a domain and the target server is in a workgroup (using the IP address of the server): The user has provided explicit credentials and added the server to the trusted host list of the client. However, an “access denied” error occurs if the user specifies credentials for the target server other than the built-in Administrator account, and if the account token filter policy is not configured. See “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Client is in a workgroup and the target server is in a workgroup (using the NetBIOS name of the server): The user’s network can resolve the name of the server, the user has added the target server to the trusted hosts list on the client, and the user has already removed subnet restrictions on the server. However, an “access denied” error can occur if the user is managing the target server by using the same credentials that were provided to log on to the client computer, but that are not valid or recognized on the target server.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Client is in a workgroup and the target server is in a workgroup (using the IP address of the server): The user has added the server to the trusted hosts list of the client, and removed subnet restrictions on the server. However, an “access denied” error can occur if the user is managing the target server by using the same credentials that were provided to log on to the client computer, but that are not valid or recognized on the target server.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Client is in a workgroup and the target server is in a domain (using the NetBIOS name of the server): The user’s network can resolve the name of the server, and the user has added the server to the trusted hosts list of the client. However, an “access denied” error can occur if the user is managing the target server by using the same credentials that were provided to log on to the client computer, but that are not valid or recognized on the target server.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	The client is in a workgroup, and the target server is in a domain (using the IP address of the server): The user has added the server to the trusted hosts list on the client. However, an “access denied” error can occur if the user is managing the target server by using the same credentials that were provided to log on to the client computer, but that are not valid or recognized on the target server.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	The user is attempting to manage the remote server with a credential that has only standard user (not a member of the Administrators group) access rights on the target server, and the user has not enabled standard user remote management of the target server. By default, an account with standard user access rights is not a part of the WinRM remote WMI user’s group, and can perform limited management tasks on a remote server in Server Manager. To allow standard users more management access rights on a target server, run the `Enable-ServerManagerStandardUserRemoting` cmdlet on the target server, in a Windows PowerShell session that has been opened with elevated user rights (Run as Administrator). For more information about how to use this cmdlet (and disable standard user management access when it is no longer needed), see the cmdlet Help topic for Enable-ServerManagerStandardUserRemoting.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	An incorrect or misspelled user name was provided to log on to the target server.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	The correct user name for the account used to manage the target server was provided, but the password was incorrect.	Error
MessageID: 1326. Message: The metadata failed to be retrieved from the server, due to the following error: The user name or password is incorrect.	The correct user name for the account used to manage the target server was provided, but the password was incorrect.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Client is in a domain, and the server is in a workgroup (using the NetBIOS name of the server): The user has specified explicit credentials, added the target server to the trusted hosts list of the client, and removed the subnet restrictions on the target server. However, an access denied error occurs if the user specified an account to manage the target server other than the built-in Administrator account, and the local account token filter policy is not configured correctly. See “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager to resolve this issue.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Both the client and the target server are in workgroups (using the NetBIOS name of the server): The user’s network can resolve the name of the server, the user has added the server to the trusted hosts list of the client, the user has removed the subnet restrictions on the server, and specified explicit credentials that are valid on the target server, but is not using the built-in Administrator account for the target server. An access denied error occurs because the specified account is not the built-in Administrator account, and the local account token filter policy is not set. See “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager to resolve this issue.	Error
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied.	Both the client and target server are in workgroups (using the IP address of the server): User has added the server to the trusted host list of the client, and removed the subnet restrictions on the server. The user attempts to manage the target server by using the credentials with which they logged on to the client computer. An access denied error occurs because the specified account is not the built-in Administrator account on the target server, and the local account token filter policy is not set. See “To add remote workgroup servers to Server Manager” in Add Servers to Server Manager to resolve this issue.	Error
Online – Cannot manage a client-based operating system	Server Manager WMI providers are not available on the target computer	Message: The metadata failed to be retrieved from the server, due to the following error: The WS-Management service cannot process the request. The CIM namespace root/microsoft/windows/servermanager is not valid.	This is typical of Windows 8, on which Server Manager providers are not available and DCOM is not enabled by default. You cannot manage this computer by using Server Manager.	Error
Inventory discovery-based errors	None	Server Manager inventory collection finds that the target computer is running a Windows client-based operating system. You cannot manage this computer by using Server Manager, so you must contact them. h	Error
Online — Server Manager WMI providers not loading on the target server	Server Manager WMI provider cannot load error	Error <computer name>: Configuration refresh failed with the following error: HRESULT = 0x80041013	The Server Manager provider is available, but cannot load. This error can occur when WMI namespace access rights do not grant access to the user, and is most commonly seen when standard users (those who are not members of the Administrators group on the target server) are managing a server by using Server Manager. To grant WMI namespace access rights to standard users, administrators should run the `Enable-ServerManagerStandardUserRemoting` cmdlet on the target server. For more information about how to use this cmdlet (and disable standard user management access when it is no longer needed), see the cmdlet Help topic for Enable-ServerManagerStandardUserRemoting.	Error
Online – Cannot manage operating systems older than Windows Server 2003	Inventory discovery-based errors	None	Server Manager inventory collection finds that the target computer is running a release of Windows Server that is older than Windows Server 2003. You cannot manage this computer by using Server Manager.	Error
Online – Limited data – Windows Server 2003	Inventory discovery-based errors	None	Server Manager inventory collection finds that the target computer is running Windows Server 2003.	Informational
Online – Restart pending	Inventory discovery-based errors	None	Server Manager inventory collection finds that the target server requires a restart. Restart the target server.	Informational
Online – Windows PowerShell not installed	Inventory discovery-based errors	None	Server Manager inventory collection finds that Windows PowerShell is not installed on the target server. On a target server that is running Windows Server 2012, run the following cmdlet on the computer that is running Server Manager to install Windows PowerShell: `Install-WindowsFeature -Name PowerShell –ComputerName <target server name>`. On Windows Server 2008 R2 and Windows Server 2008, install the Windows Management Framework 3.0 download package to get Windows PowerShell 3.0. Install prerequisites for Windows Management Framework 3.0 by following instructions in Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012 to resolve this error.	Informational
Online – Performance counters not started	Inventory discovery-based errors	None	Server Manager inventory collection finds that performance counter data collection is turned off on the target server.	Informational
Online — Cannot get event data	Data retrieval errors	Any errors from the Server Manager provider that are related to event data retrieval. This error can also occur if specific roles and features have been installed, but not yet configured. The following underlying error messages are examples of known cases where a role, role service, or feature requires post-installation configuration to clear the error. Events from ‘Virtualization.Events.xml’ could not be enumerated. (This error is cleared after required post-installation configuration for Hyper-V is completed.) Events from ‘PrintServices.Events.xml’ could not be enumerated. (This error is cleared after required post-installation configuration for Print and Document Services is completed.) Events from ‘ADAM.Events.xml’ could not be enumerated. (This error might be cleared after required post-installation configuration for Active Directory Lightweight Directory Services is completed.) The following underlying error message can occur for Active Directory Federation Services when the only role services that are installed are web agents. Configuring the installed role services does not resolve the error. Events from ‘IdentityServer.Events.xml’ could not be enumerated.	Server Manager cannot get event data from the target server. The user might not have access rights to the target server event log, or event log files might not contain valid data. For some roles and features (Hyper-V, Print and Document Services, AD LDS), this error can occur after installation, but before required post-installation configuration has been completed. The error is resolved after post-installation configuration is complete. For AD FS, this error can occur if web agents are the only role services installed, but there is currently no known resolution for this case of the error.	Error
Online — Cannot get service data	Any errors from the Server Manager provider that are related to service data retrieval	Server Manager cannot get services data from the target server. The user might not have access rights to service data on the target server, or service data files might not contain valid data. To grant service data access rights to standard (non-Administrator) users, administrators should run the `Enable-ServerManagerStandardUserRemoting` cmdlet on the target server. For more information about how to use this cmdlet (and disable standard user management access when it is no longer needed), see the cmdlet Help topic for Enable-ServerManagerStandardUserRemoting.	Error
Online — Cannot get BPA results	Any errors from the Server Manager provider related to BPA result retrieval (excluding Windows PowerShell not enabled errors which are covered by other manageability status messages)	Server Manager cannot get Best Practices Analyzer result data from the target server. The user might not have access rights to BPA data on the target server, or BPA result data might not be readable. Standard users cannot get access to BPA data, even after an administrator runs the `Enable-ServerManagerStandardUserRemoting` cmdlet.	Error
Online — Cannot get performance counter data	Any errors from the Server Manager provider related to performance data retrieval (excluding performance counters off errors, which are covered by other manageability status messages)	Server Manager cannot get performance counter data from the target server. The user might not have access rights to performance data on the target server, or the data might not be readable. To grant performance data access rights to standard (non-Administrator) users, administrators should run the `Enable-ServerManagerStandardUserRemoting` cmdlet on the target server. For more information about how to use this cmdlet (and disable standard user management access when it is no longer needed), see the cmdlet Help topic for Enable-ServerManagerStandardUserRemoting.	Error
Online — Cannot get role and feature data	Any errors from the Server Manager provider related to role and feature data retrieval	Server Manager cannot get role and feature inventory data from the target server. The user might not have access rights to role and feature data on the target server, or the data might not be readable. To grant role and feature inventory data access rights to standard (non-Administrator) users, administrators should run the `Enable-ServerManagerStandardUserRemoting` cmdlet on the target server. For more information about how to use this cmdlet (and disable standard user management access when it is no longer needed), see the cmdlet Help topic for Enable-ServerManagerStandardUserRemoting.	Error
Online — Data retrieval failures occurred	(If two or more types of data cannot be retrieved) The WS-Management service cannot process the request. WS-Management cannot identify the enumeration context ID in the SOAP packet. The packet may not be valid, or the operation may have timed out. The WinRM client cannot process the request because the metadata failed to be retrieved from the server. Non terminating error during inventory method; for example, an access error to cluster resource data This error can also occur if specific roles and features have been installed, but not yet configured. The following underlying error messages are examples of known cases where a role, role service, or feature requires post-installation configuration to clear the error. Events from ‘Virtualization.Events.xml’ could not be enumerated. (This error is cleared after required post-installation configuration for Hyper-V is completed.) Events from ‘PrintServices.Events.xml’ could not be enumerated. (This error is cleared after required post-installation configuration for Print and Document Services is completed.) Events from ‘ADAM.Events.xml’ could not be enumerated. (This error might be cleared after required post-installation configuration for Active Directory Lightweight Directory Services is completed.) The following underlying error message can occur for Active Directory Federation Services when the only role services that are installed are web agents. Configuring the installed role services does not resolve the error. Events from ‘IdentityServer.Events.xml’ could not be enumerated.	Server Manager cannot get a combination of data types: events, BPA results, performance counters, or services. This can be caused by insufficient user access rights, data that is not valid, or WinRM time-outs. To grant event, performance, role and feature inventory, and service data access rights to standard (non-Administrator) users, administrators should run the `Enable-ServerManagerStandardUserRemoting` cmdlet on the target server. For more information about how to use this cmdlet (and disable standard user management access when it is no longer needed), see the cmdlet Help topic for Enable-ServerManagerStandardUserRemoting. The `Enable-ServerManagerStandardUserRemoting` cmdlet does not provide standard users access to BPA result data. For some roles and features (Hyper-V™, Print and Document Services, AD LDS), this error can occur after installation, but before required post-installation configuration has been completed. The error is resolved after post-installation configuration is complete. For AD FS, this error can occur if web agents are the only role services installed, but there is currently no known resolution for this case of the error.	Error
An unknown error occurred	Unknown errors	None	If the error persists, contact Customer Support Services.	Error

Additional resources

Server Manager Troubleshooting Guide, Part I: Overview
Add Servers to Server Manager
Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012
Enable-ServerManagerStandardUserRemoting

Источник

Connecting to a remote windows machine is often far more difficult than one would have expected. This was my experience years ago when I made my first attempt to use powershell remoting to connect to an Azure VM. At the time, powershell 2 was the hotness and many were talking up its remoting capabilities. I had been using powershell for about a year at the time and thought I’d give it a go. It wasn’t simple at all and took a few hours to finally succeed.

Now armed with 2012R2 and more knowledge its simpler but lets say you are trying to connect from a linux box using one of the open source WinRM ports, there are several gotchas.

I started working for Chef about six weeks ago and it is not at all uncommon to find customers and fellow employees struggling with failure to talk to a remote windows node. I’d like to lay out in this post some of the fundamental moving parts as well as the troubleshooting decision tree I often use to figure out where things are wrong and how to get connected.

I’ll address cross platform scenarios using plain WinRM, powershell remoting from windows and some Chef specific tooling using the knife-windows gem.

Connecting and Authenticating

In my experience these are the primary hurdles to WinRM sweet success. First is connecting. Can I successfully establish a connection on a WinRM port to the remote machine? There are several things to get in the way here. Then a yak shave or two later you get past connectivity but are not granted access. What’s that you say? You are signing in with admin credentials to the box?…I’m sorry say that again?…huh?…I just can’t hear you.

TL;DR — A WinRM WTF checklist:

I am going to go into detail in this post on the different gotchas and their accompanying settings needed to successfully connect and execute commands on a remote windows machine using WinRM. However, if you are stuck right now and don’t want to sift through all of this, here is a cheat sheet list of things to set to get you out of trouble:

On the remote windows machine:

Run Enable-PSRemoting
Open the firewall with: netsh advfirewall firewall add rule name=»WinRM-HTTP» dir=in localport=5985 protocol=TCP action=allow
Accessing via cross platform tools like chef, vagrant, packer, ruby or go? Run these commands:

winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

Note: DO NOT use the above winrm settings on production nodes. This should be used for tets instances only for troubleshooting WinRM connectivity.

This checklist is likely to address most trouble scenarios when accessing winrm over HTTP. If you are still stuck or want to understand this domain more, please read on.

Barriers to entry

Lets talk about connectivity first. Here are the key issues that can prevent connection attempts to a WinRM endpoint:

The Winrm service is not running on the remote machine
The firewall on the remote machine is refusing connections
A proxy server stands in the way
Improper SSL configuration for HTTPS connections

We’ll address each of these scenarios but first…

How can I know if I can connect?

It can often be unclear whether we are fighting a connection or authentication problem. So I’ll point out how you can determine if you can eliminate connectivity as a potential issue.

On Mac/Linux:

$ nc -z -w1 <IP or host name> 5985;echo $?

This uses netcat available on the mac and most linux distros. Assuming you are using the default HTTP based WinRM port 5985 (more on determining the correct port in just a bit), if the above returns 0, you know you are getting through to a listening WinRM endpoint on the other side.

On Windows:

Test-WSMan -ComputerName <IP or host name>

Again this assumes you are trying to connect over the default HTTP WinRM port (5985), if not add -UseSSL. This should return some non-error response that looks something like:

wsmid         : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

WinRM Ports

The above commands used the default WinRM HTTP port to attempt to connect to the remote WinRM endpoint — 5985. WinRM is a SOAP based HTTP protocol.

Side Note: In 2002, I used to car pool to my job in Sherman Oaks California with my friend Jimmy Bizzaro and would kill time by reading «Programming Web Services with SOAP» an O’Reilly publication. This was cutting edge, cool stuff. Java talking to .net, Java talking to Java but from different machines. This was the future. REST was done in a bed or on a toilet. So always remember, today’s GO and Rust could be tomorrow’s soap.

Anyhoo…WinRM can talk HTTP and HTTPS. The default ports are 5985 and 5986 respectfully. However the default ports can be changed. Now usually the change is driven by network address translation. Sure these ports can be changed locally too, but in my experience if you need to access WinRM on ports other than 5985 or 5986 its usually to accommodate NAT. So check your Virtualbox NAT config or your Azure or EC2 port mappings to see if there is a port forwarding to 5985/6 on the VM. Those would be the ports you need to use. The Test-WSMan cmdlet also takes a -port parameter where you can provide a non standard WinRM port.

So now you know the port to test but you are getting a non 0 netcat response or an error thrown from Test-WSMan. Now What?

Is WinRM turned on?

This is the first question I ask. If winrm is not listening for requests, then there is nothing to connect to. There are a couple ways to do this. What you usually do NOT want to do is simply start the winrm service. Not that that is a bad thing, its just not likely going to be enough. The two best ways to «turn on» WinRM are:

or the powershell approach:

For default windows 2012R2 installs (not altered by group policy), this should be on by default. However windows 2008R2 and client SKUs will be turned off until enabled.

Foiled by Public Network Location

You may get the following error when enabling winrm:

Set-WSManQuickConfig : <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859113"
Machine="localhost"><f:Message><f:ProviderFault provider="Config provider"
path="%systemroot%system32WsmSvc.dll"><f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault"
Code="2150859113" Machine="win81"><f:Message>WinRM firewall exception will not work since one of the network
connection types on this machine is set to Public. Change the network connection type to either Domain or Private and
try again. </f:Message></f:WSManFault></f:ProviderFault></f:Message></f:WSManFault>
At line:1 char:1
+ Set-WSManQuickConfig -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Set-WSManQuickConfig], InvalidOperationException
    + FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand

You need to set the Network Location to Private. I have written a post devoted to Internet Connection Type. There are different ways to set the location on different windows versions. You can view the details in the above post but the one that is the most obscure but universally works across all versions is:

$networkListManager = [Activator]::CreateInstance([Type]::GetTypeFromCLSID([Guid]"{DCB00C01-570F-4A9B-8D69-199FDBA5723B}")) 
$connections = $networkListManager.GetNetworkConnections() 

# Set network location to Private for all networks 
$connections | % {$_.GetNetwork().SetCategory(1)}

Wall of fire

In some circles called a firewall. This can often be a blocker. For instance, while winrm is on by default on 2012R2, its firewall rules will block public traffic from outside its own subnet. So if you are trying to connect to a server in EC2 or Azure for example, opening this firewall restriction is important and can be done with:

HTTP:

netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow

netsh advfirewall firewall add rule name="WinRM-HTTPS" dir=in localport=5986 protocol=TCP action=allow

This also affects client SKUs which by default do not open the firewall to any public traffic. If you are on a client version of windows 8 or higher, you can also use the -SkipNetworkProfileCheck switch when enabling winrm via Enable-PSRemoting which will at least open public traffic to the local subnet and may be enough if connecting to a machine on a local hypervisor.

Proxy Servers

As already stated, WinRM runs over http. Therefore if you have a proxy server sitting between you and the remote machine you are trying to connect to, you need to make sure that the request goes through that proxy server. This is usually not an issue if you are on a windows machine and using a native windows API like powershell remoting or winrs to connect. They will simply use the proxy settings in your internet settings.

Ruby tooling like Chef, Vagrant, or others uses a different mechanism. If the tool is using the WinRM ruby gem, like chef and vagrant do, they rely on the HTTP_PROXY environment variable instead of the local system’s internet settings. As of knife-windows 1.1.0, the http_proxy settings in your knife.rb config file will make its way to the HTTP_PROXY environment variable. You can manually set this as follows:

Mac/Linux:

$ export HTTP_PROXY="http://<proxy server>:<proxy port>/"

$env:HTTP_PROXY="http://<proxy server>:<proxy port>/"

Friends don’t let friends use cmd.exe and you are my friend.

SSL

I’m saving SSL for the last connection issue because it is more involved (why folks often opt for HTTP over the more secure HTTPS). There is extra configuration required both on both the remote and local side and that can vary by local platform. Lets first discuss what must be done on the remote WinRM endpoint.

Create a self signed certificate

Assuming you have not purchased a SSL certificate from a valid certificate authority, you will need to generate a self signed certificate. If your are on a 2012R2 windows os version or later, this is trivial:

$c = New-SelfSignedCertificate -DnsName "<IP or host name>" -CertStoreLocation cert:LocalMachineMy

Read ahead for issues with New-SelfSignedCertificate and certificate verification with openssl libraries.

Creating a HTTPS WinRM listener

Now WinRM needs to be configured to respond to https requests. This is done by adding an https listener and associating it with the thumbprint of the self signed cert you just created.

winrm create winrm/config/Listener?Address=*+Transport=HTTPS "@{Hostname=`"<IP or host name>`";CertificateThumbprint=`"$($c.ThumbPrint)`"}"

Adding firewall rule

Finally enable winrm https requests through the firewall:

netsh advfirewall firewall add rule name="WinRM-HTTPS" dir=in localport=5986 protocol=TCP action=allow

SSL client configuration

At this point you should be able to reach a listening WinRM endpoint on the remote server. On a mac or linux box, a netcat check on the https winrm port should be successful:

$ nc -z -w1 <IP or host name> 5986;echo $?

C:> Test-netConnection <IP> -Port 5986

ComputerName           : <IP>
RemoteAddress          : <IP>
RemotePort             : 5986
InterfaceAlias         : vEthernet (External Virtual Switch)
SourceAddress          : <local IP>
PingSucceeded          : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded       : True

However, trying to establish a WinRM connection will likely fail with a certificate validation error unless you install that same self signed cert you created on the remote endpoint.

If you try to test the connection on windows using Test-WSMan as we saw before, you would receive this error:

Test-WSMan -ComputerName 192.168.1.153 -UseSSL
Test-WSMan : <f:WSManFault
xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="12175"
Machine="ultrawrock"><f:Message>The server certificate on the destination
computer (192.168.1.153:5986) has the following errors:
The SSL certificate is signed by an unknown certificate authority.
The SSL certificate contains a common name (CN) that does not match the
hostname.     </f:Message></f:WSManFault>
At line:1 char:1
+ Test-WSMan -ComputerName 192.168.1.153 -UseSSL
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (192.168.1.153:String) [Test-W
   SMan], InvalidOperationException
    + FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.TestWSManC
   ommand

Now you have a few options depending on your platform and needs:

Do not install the certificate and disable certificate verification (not recommended)
Install to the windows certificate store if you are on windows and need to use native windows APIs like powershell remoting
Export the certificate to a .pem file for use with ruby based tools like chef

Ignoring certificate validation errors

This is equivalent to when you are browsing the internet in a standard browser and try to view a https based site with an invalid cert and the browser gives you a scary warning that you are about to go somewhere potentially dangerous but gives you the option to go there anyway even though that’s probably a really bad idea.

If you are testing, especially using a local hypervisor, the risk of a man in the middle attack is pretty small, but you didn’t hear that from me. If you do not want to go through the trouble of installing the certificate (we’ll go through those steps shortly), here is what you need to do:

Powershell Remoting:

$options=New-PSSessionOption -SkipCACheck -SkipCNCheck
Enter-PSSession -ComputerName <IP or host name> -Credential <user name> -UseSSL -SessionOption $options

irb
require 'winrm'
w=WinRM::WinRMWebService.new('https://<ip or host>:5986/wsman', :ssl, :user => '<user>', :pass => '<password>', :no_ssl_peer_verification => true)

knife winrm -m <ip> ipconfig -x <user> -P <password> -t ssl --winrm-ssl-verify-mode verify_none

Installing to the Windows Certificate store

This is the more secure route and will allow you to interact with the machine via powershell remoting without being nagged that your certificate is not valid.

The first thing to do is download the certificate installed on the remote machine:

$webRequest = [Net.WebRequest]::Create("https://<ip or host>:5986/wsman")
try { $webRequest.GetResponse() } catch {}
$cert = $webRequest.ServicePoint.Certificate

Now we have an X509Certificate instance of the certificate used by the remote winrm HTTPS listener. So we install it in our local machine certificate store along with the other root certificates:

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store `
  -ArgumentList  "Root", "LocalMachine"
$store.Open('ReadWrite')
$store.Add($cert)
$store.Close()

Having done this, we can now validate the SSL connection with Test-WSMan:

C:> Test-WSMan -ComputerName 192.168.43.166 -UseSSL
wsmid        : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

Now we can use tools like powershell remoting or winrs to talk to the remote machine.

Exporting the certificate to a .pem/.cer file

The above certificate store solution works great on windows for windows tools, but it won’t help for many cross platform scenarios like connecting from non-windows or using chef tools like knife-windows. The WinRM gem used by tools like Chef and Vagrant take a certificate file which is expected to be a base 64 encoded public key only certificate file. It commonly has a .pem, .cer, or .crt extension.

On windows you can export the X509Certificate we downloaded above to such a file by using the following lines of powershell:

"-----BEGIN CERTIFICATE-----" | Out-File cert.pem -Encoding ascii
[Convert]::ToBase64String($cert.Export('cert'), 'InsertLineBreaks') |
  Out-File .cert.pem -Append -Encoding ascii
"-----END CERTIFICATE-----" | Out-File cert.pem -Encoding ascii -Append

With this file you could use Chef’s knife winrm command from the knife-windows gem to run commands on a windows node:

knife winrm -m 192.168.1.153 ipconfig -x administrator -P Pass@word1 -t ssl -f cert.pem

Problems with New-SelfSignedCertificate and openssl

If the certificate on the server was generated using New-SelfSignedCertificate, cross platform tools that use openssl libraries may fail to verify the certificate unless New-SelfSignedCertificate was used with the -CloneCert argument and passed a certificate that includes a BasicConstraint property identifying it as a CA. Viewing the certificate’s properties in the certificate manager GUI, the certificate should contain this:

There are are several alternatives to the convenient New-SelfSignedCertificate cmdlet if you need a cert that must be verified with openssl libraries:

Disable peer verification (not recommended) as shown earlier
Create a private/public key certificate using openssl’s req command and then use openssl pkcs12 to combine those 2 files to a pfx file that can be imported to the winrm listener’s certificate store. Note: Make sure to include the «Server Authentication» Extended Key Usage (EKU) not added by default
Use the handy New-SelfSignedCertificateEx available from the Technet Script Center and provides finer grained control of the certificate properties and make sure to use the -IsCA argument:

. .New-SelfSignedCertificateEx.ps1
New-SelfsignedCertificateEx -Subject "CN=$env:computername" `
 -EKU "Server Authentication" -StoreLocation LocalMachine `
 -StoreName My -IsCA $true

Exporting the self signed certificate on non-windows

If you are not on a windows machine, all this powershell is going to produce far different output than what is desirable. However, its actually even simpler to do this with the openssl s_client command:

openssl s_client -connect <ip or host name>:5986 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM >mycertfile.pem

The output mycertfile.pem can now be passed to the -f argument of knife-windows commands to execute commands via winrm:

mwrock@ubuwrock:~$ openssl s_client -connect 192.168.1.155:5986 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM >mycertfile.pem
mwrock@ubuwrock:~$ knife winrm -m 192.168.1.155 ipconfig -x administrator -P Pass@word1 -t ssl -f ~/mycertfile.pem
WARNING: No knife configuration file found
192.168.1.155
192.168.1.155 Windows IP Configuration
192.168.1.155
192.168.1.155
192.168.1.155 Ethernet adapter Ethernet:
192.168.1.155
192.168.1.155    Connection-specific DNS Suffix  . :
192.168.1.155    Link-local IPv6 Address . . . . . : fe80::6c3f:586a:bdc0:5b4c%12
192.168.1.155    IPv4 Address. . . . . . . . . . . : 192.168.1.155
192.168.1.155    Subnet Mask . . . . . . . . . . . : 255.255.255.0

Authentication

As you can probably tell so far, alot can go wrong and there are several moving parts to establishing a successful connection with a remote windows machine over WinRM. However, we are not there yet. Most of the gotchas here are when you are using HTTP instead of HTTPS and you are not domain joined. This tends to describe 95% of the dev/test scenarios I come in contact with.

As we saw above, there is quite a bit of ceremony involved in getting SSL just right and running WinRM over HTTPS. Lets be clear: its the right thing to do especially in production. However, you can avoid the ceremony but that just means there is other ceremonial sacrifices to be made. At this point, if you are connecting over HTTPS, authentication is pretty straight forward. If not, there are often additional steps to take. However these additional steps tend to be less friction laden, but more security heinous, than the SSL setup.

HTTP, Basic Authentication and cross-platform

Both the Ruby WinRM gem and the Go winrm package do not interact with the native windows APIs needed to make Negotiate authentication possible and therefore must use Basic Authentication when using the HTTP transport. So unless you are either using native windows WinRM via winrs or powershell remoting or using knife-windows on a windows client (more on this in a bit), you must tweak some of the WinRM settings on the remote windows server to allow plain text basic authentication over HTTP.

Here are the commands to run:

winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

One bit of easy guidance here is that if you can’t use Negotiate authentication, you really really should be using HTTPS with verifiable certificates. However if you are just trying to get off the ground with local Vagrant boxes and you find yourself in a situation getting WinRM Authentication errors but know you are passing the correct credentials, please try running these on the remote machine before inflicting personal bodily harm.

I always include these commands in windows packer test images because that’s what packer and vagrant need to talk to a windows box since they always use HTTP and are cross platform without access to the Negotiate APIs.

This is quite the security hole indeed but usually tempered by the fact that it is on a test box in a NATed network on the local host. Perhaps we are due for a vagrant PR allowing one to pass SSL options in the Vagrantfile. That would be simple to add.

Chef’s winrm-s gem using windows negotiate on windows

Chef uses a separate gem that mostly monkey patches the WinRM gem if it sees that winrm is authenticating from windows to windows. In this case it leverages win32 APIs to use Negotiate authentication instead of Basic Authentication and therefore the above winrm settings can be avoided. However, if accessing from a linux client, it will drop to Basic Authentication and the settings shown above must then be present.

Local user accounts

Windows remote communication tends to be easier when you are using domain accounts. This is because domains create implicit trust boundaries so windows adds restrictions when using local accounts. Unfortunately the error messages you can sometimes get do not at all make it clear what you need to do to get past these restrictions. There are two issues with local accounts that I will mention:

Qualifying user names with the «local domain»

One thing that has previously tripped me up and I have seen others struggle with is related to authenticating local users. You may have a local user (not a domain user) and it is getting access denied errors trying to login. However if you prefix the user name with ‘./’, then the error is resolved. The ‘./’ prefix is equivelent to ‘<local host or ip><user>’. Note that the ‘./’ prefix may not work in a windows login dialog box. In that case use the host name or IP address of the remote machine instead of ‘.’.

Setting the LocalAccountTokenFilterPolicy registry setting

This does not apply to the built in administrator account. So if you only logon as administrator, you will not run into this. However lets say I create a local mwrock account and even add this account to the local Administrators security group. If I try to connect remotely with this account using the default remoting settings on the server, I will get an Access Denied error if using powershell remoting or a WinRMAuthentication error if using the winrm gem. This is typically only visible on 2012R2. By default, the winrm service is running on a newly installed 2012R2 machine with an HTTP listener but without the LocalAccountTokenFilterPolicy enabled, while 2008R2 and client SKUs have no winrm service running at all. Running winrm quickconfig or Enable-PSRemoting on any OS will enable the LocalAccountTokenFilterPolicy, which will allow local accounts to logon. This simply sets the LocalAccountTokenFilterPolicy subkey of HKLMsoftwareMicrosoftWindowsCurrentVersionPoliciessystem to 1.

Trusted Hosts with HTTP, non domain joined powershell remoting

There is an additional security restriction imposed by powershell remoting when connected over HTTP on a non domain joined (work group) environment. You need to add the host name of the machine you are connecting to the list of trusted hosts. This is a white list of hosts you consider ok to talk to. If there are many, you can comma delimit the list. You can also include wildcards for domains and subdomains:

Set-Item "wsman:localhostclienttrustedhosts" -Value 'mymachine,*.mydomain.com' -Force

Setting your trusted hosts list a single wildcard would allow all hosts:

Set-Item "wsman:localhostclienttrustedhosts" -Value '*' -Force

You would only do this if you simply interact with local test instances and even that is suspect.

Double-Hop Authentication

Lets say you want to access a UNC share on the box you have connected to or in any other way use your current credentials to access another machine. This will typically fail with the ever informative Access Denied error. You can enable whats called credential delegation by using a different type of authentication mechanism called CredSSP. This is only available using Powershell remoting and requires extra configuration on both the client and remote machines.

On the remote machine, run:

Enable-WSManCredSSP -Role Server

On the client there are a few things to set up. First, similar to the server, you need to enable it but also specify a white list of endpoints. This is formatted similar to the trusted hosts discussed above:

Enable-WSManCredSSP -Role Client -DelegateComputer 'my_trusted_host.me.org'

Next you need to edit the local security policy on the machine to allow delegation to specific endpoints. In the gpedit GUI, navigate to Computer Configuration > Administrative Templates > System > Credential Delegation and enable «Allow Delegating Fresh Credentials». Further, you need to add the endpoints you authorize delegation to. You can add WSMAN*.my_domain.com to allow all endpoints in the my_domain.com domain. You can add as many entries as you need.

Certificate based authentication

Even more secure than usernames and passwords is using a x509 certificate signed by a trusted certificate authority. Many use this techniue when using SSH with SSH keys. Well, the same is possible with WinRM. I won’t get into the details here since I have blogged separately on this topic here.

Windows Nano TP 3

As of the date of this post, Microsoft has released technical preview 3 of its new Windows Nano flavored server OS. I have previously blogged about this super light weight os but here is a winrm related bit of info that is unique to nano as of this version at least: there are no tools to tweak the winrm settings. Neither the winrm command or the winrm powershell provider are present.

In order to make changes, you must edit the registry directly. These settings are located at:

HKLMSoftwareMicrosoftWindowsCurrentVersionWSMAN

Other Caveats

I’ve written an entire post on this topic and will not go into the same detail here. Basically I have found that once winrm is correctly configured, there is still a small subset of operations that will fail in a remote context. Any interaction with wsus is an example but please read my previous post for more. When you hit one of these road blocks, you typically have two options:

Use a Scheduled Task to execute the command in a local context
Install an SSH server and use that

The second option appears to be imminent and in the end will make all of this easier and perhaps render this post irrelevant.

Источник

I have disabled negotiate authentication for the winrm service on my server by executing:

winrm put winrm/config/service/Auth @{Negotiate="false"}

And now I can perform any operation with winrm. I get the error:

    Message = The WinRM client cannot process the request. The WinRM client trie
d to use Negotiate authentication mechanism, but the destination computer (local
host:47001) returned an 'access denied' error. Change the configuration to allow
 Negotiate authentication mechanism to be used or specify one of the authenticat
ion mechanisms supported by the server. To use Kerberos, specify the local compu
ter name as the remote destination. Also verify that the client computer and the
 destination computer are joined to a domain. To use Basic, specify the local co
mputer name as the remote destination, specify Basic authentication and provide
user name and password. Possible authentication mechanisms reported by server:

I understand the error, but the problem is that the only way I find on the web to enable Negotiate authentication is by executing:

winrm put winrm/config/service/Auth @{Negotiate="true"}

Which of course gives the error above. Is there another way to enable Negotiate authentication?

asked Nov 1, 2013 at 10:24

Use Group Policy:

Computer > Policies > Administrative Templates > Windows Components > Windows Remote Management > WinRM Service:
Disallow Negotiate Authentication: Disabled.

answered Nov 1, 2013 at 11:36

Greg AskewGreg Askew

34.7k4 gold badges52 silver badges82 bronze badges

Edit the registry key
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWSMANClient.

Set auth_kerberos and auth_negotiate to 1.

Restart the service.

answered Jan 1, 2015 at 9:48

IvanIvan

1711 silver badge3 bronze badges

As suggested in this answer, but Service, not Client:

Edit the registry key HKLMSOFTWAREMicrosoftWindowsCurrentVersionWSMANService.
Set auth_kerberos and auth_negotiate to 1.
Restart the Windows Remote Management (WS-Management) Service.

answered May 18, 2017 at 23:43

On our server 2012 / exchange 2010 machine we had this error when trying to use AVG backup software.

I found removing both maxenvelopesize and trusted_hosts under this key did the trick

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWSMANClient]
"maxEnvelopeSize"=dword:000007d0
"trusted_hosts"="*"

sebix

4,2632 gold badges26 silver badges45 bronze badges

answered Jun 24, 2015 at 10:36

I had one server working, yet another would not. I could not find the problem. Finally I figured it out.

On the receiving server (Create a .reg file with the following:):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWSMANClient] 
"auth_credssp"=dword:00000000

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWSMANService]
"auth_credssp"=dword:00000001

works for me

HBruijn

73.5k23 gold badges132 silver badges194 bronze badges

answered Aug 2, 2016 at 21:56

C:Tempgpresult /h rep.htm

It may be applied from «Default Domain Controllers Policy» !!

answered Nov 15, 2019 at 22:43

Источник

При попытке проадминить работающий вне домена Windows Server Core 20H2 в Server Manager вылезла ошибка:

Winrm negotiate authentication error

Это означает, что клиентский сервер (с которого выполняем управление) не смог согласовать параметры сессии WinRM с управляемым сервером. Причин может быть несколько:

Посмотрим параметры WinRM. По дефолту всё должно быть корректно и сервер не включенный в домен должен дать себя проадминить с учеткой локального админа:

winrm get winrm/config/service
winrm enumerate winrm/config/listener

В выводе этих двух команд должно быть:

Service
  ...
  Auth
    ...
    Negotiate = true
 ...
 AllowRemoteAccess = true

ну и Listener должен слушать на адресе, котоый доступен клиенту.

На управляющем сервере важно убедиться, что не введенный в домен сервер прописан в Trusted Hosts:

Get-Item WSMan:localhostClientTrustedHosts | select name,value | format-list

Очень важно, что в списке Trusted Hosts сервер должен быть прописан с DNS-суффиксом. В моем случае DHCP сервер выдавал управляемому серверу суффикс .lan и до тех пор, пока я не прописал сервер в Trusted Hosts с этим суффиксом подключиться не удавалось.

Это актуально, если серверы не входят в один домен. В пределах домена, как правило, серверы доверяют друг другу.

На управляющем сервере запускаем powershell с правами администратора и добавляем хост в доверенные:

Set-Item wsman:localhostClientTrustedHosts "computer_name" -Concatenate -Force

И теперь прописываем учетные данные для доступа к этому хосту:

cmdkey /add:computer_name /user:Administrator /pass:SUPERPASSWORD

Если в консоли Server Manager хост Online, но Computer Management не работает, то скорее всего виноват Firewall.

Из консоли Server Manager запускаем на удаленном хосте сессию powershell и отключаем Firewall:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

Разрешим подключение по RDP (хотя там будет доступен только cmd и powershell):

Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal Server' -name "fDenyTSConnections" -value 0

Ну и дадим разрешение на firewall (если он еще не отклбчен):

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Источник

Table of Contents

Locate manageability status errors

Troubleshoot manageability status errors

Additional resources

Connecting and Authenticating

TL;DR — A WinRM WTF checklist:

Barriers to entry

How can I know if I can connect?

WinRM Ports

Is WinRM turned on?

Foiled by Public Network Location

Wall of fire

Proxy Servers

SSL

Create a self signed certificate

Creating a HTTPS WinRM listener

Adding firewall rule

SSL client configuration

Ignoring certificate validation errors

Installing to the Windows Certificate store

Exporting the certificate to a .pem/.cer file

Problems with New-SelfSignedCertificate and openssl

Exporting the self signed certificate on non-windows

Authentication

HTTP, Basic Authentication and cross-platform

Chef’s winrm-s gem using windows negotiate on windows

Local user accounts

Trusted Hosts with HTTP, non domain joined powershell remoting

Double-Hop Authentication

Certificate based authentication

Windows Nano TP 3

Other Caveats