PowerShell Remote execution command failed

Connecting to remote server failed with the following error message:the WinRM client cannot process the
Request. If the authentication scheme is different from Kerberos, or if the client computer are not joined to a domain,
Then HTTPS transport must is used or the destination machine must is added to the Trustedhosts configuration setting.
Use Winrm.cmd to configure Trustedhosts. Note that computers in the Trustedhosts list might is not being authenticated. You c
An get more information on that is running the following Command:winrm help CONFIG. For more information, see the
About_remote_troubleshooting Help topic.
+ Categoryinfo:openerror: (:) [], Psremotingtransportexception
+ Fullyqualifiederrorid:pssessionstatebroken

Open the Gpedit.msc, the original is here

Http://dustinhatch.tumblr.com/post/24589312635/enable-powershell-remoting-with-credssp-using-group

Enable PowerShell Remoting with CredSSP using Group Policy

Windows PowerShell 2.0 have significantly improved the command-line experience for Windows administration, both for servers and clients. What makes it even better, though, was PowerShell Remoting, which uses Windows Remote Management (WinRM) to send commands B Etween PowerShell sessions on different computers. WinRM is a implementation of ws-management, an open, standardized soap-based Web services protocol. In many ways, PowerShell Remoting are similar to SSH, although arguably less mature. Manual Configuration Enable PowerShell Remoting manually

Enabling PowerShell 2.0 Remoting is simple, just run the following command from the elevated PowerShell session:

Enable-psremoting-force

Once that's done, you can start using it to execute PowerShell commands from a remote host:

Invoke-command-computername $remotehost-command {write-host "Hello, world!"}

Or, you can open a interactive session on the remote computer:

Enter-pssession-computername $remotehost

Enable CredSSP Manually

CredSSP is a Security support Provider introduced with Windows Vista that enables credential delegation. In other words, it allows the remote host to access the credentials that were used to authenticate the user, and pass them On to a third host. For example, when using either Basic or Kerberos authentication (the default) when connecting to a remote PowerShell Sessi On, the user would not has access to a separate file server. When using CredSSP, however, the session credentials can is passed through to the file server.

To enable CredSSP, both the client and the server must is configured to allow CredSSP. To enable CredSSP in the client side, run the following PowerShell command from an elevated session:

Enable-wsmancredssp-role Client-delegatecomputer $remotehost

Note: The Delegatecomputer parameter specifies a list of remote hosts to which the client should being allowed to co Nnect. It can accept wildcards, such as * for all hosts, or *.mydomain.local for any host on the mydomain.local DNS domain. If you specify a domain, however, you must always use the server's FQDN when connecting to it.

To enable CredSSP in the server side, run the following PowerShell 2.0 command from an elevated session:

Enable-wsmancredssp-role Server

To connect to a remote host with PowerShell Remoting using CredSSP authentication, you need to specify the credential and Authentication parameters:

Enter-pssession-computername $remotehost-credential (get-credential)-authentication CredSSP

Note: You must specify a fully-qualified username (such as username@domain.tld or domain\username) when prompted For credentials.

The unfortunate drawback of using CredSSP is, the current implementation of the CredSSP provider for WinRM does not su Pport Delegating Default credentials (i.e. the current user ' s credentials). Go vote for Microsoft Connect suggestion #498377 if this bothers you; Hopefully Microsoft would fix it in a future release. As such, it is the best-get-a Pscredential object once and store it in a variable for reuse:

$cred = get-credential $env: username@ $env: Userdnsdomain

Group Policy Configuration

Enabling PowerShell Remoting and CredSSP manually is fine for only one or both hosts, but what if it needs to be do for E Very machine on a network? Luckily, Group Policy is able to make all the same configuration changes the enable-psremoting and ENABLE-WSMANCREDSSP cmd Lets do.

There is several configuration pieces that must being set in order for everything to work correctly:the Windows Remote Mana Gement Service Windows Firewall Exceptions Credential delegation winrm Client parameters WinRM service Parameters

In addition, some Active Directory objects could need to has permissions changed.

It is probably best to group these settings into one or both separate GPOs, one for servers and one for clients, to keep th EM separate from the rest of the Group Policy settings, may already exist on the network. Server Settings

To enable PowerShell Remoting on the server side, create a new GPO and link it an organizational unit containing the Compu ter objects for the server machines. Open the GPO with the Group Policy editor and set the following options:Windows Remote Management ServiceNavigate to Computer Configuration > Windows Settings > Security Settings > System Services Locate the Windows Re Mote Management (ws-management) service and double-click it Tick the check box nexte to Define this policy setting and SEL ECT Automatic. Click "OK"Windows Firewall ExceptionsNavigate to Computer Configuration > Windows Settings > Security settings> Windows Firewall with Advanced Securit Y > Windows Firewall with Advanced security-ldap://{gpo-distinguishedname} > Inbound Rules Right-click the pane at The right and choose New Rule ... Select predefined and choose Windows Remote Management from the Drop-down list. Click "Next" Remove the Tick next to Windows Remote management-compatibility Mode (http-in), but leave the one for Windo WS Remote Management (http-in). The "Compatibility Mode" rule provides an upgrade path in systems using WinRM prior to version 2.0 and should not being Enab Led unless there is a specific need for it. Click "Next" select Allow the connection and click "Finish"WinRM Service ParametersNavigate to Computer Settings > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service Double-click allow automatic configuration of listeners Select Enabled in the box labeled IPV4 Filter, Enter a comma-separated list of IP address ranges to specify to which IP addresses the WinRM service should bind on the S Erver. For example,192.168.1.0-192.168.1.255 would allow the WinRM service to bind to network adapters with a IP address in that Range, but no other adapter. Do the same-IPv6 filter, using IPV6 addresses instead, or leave it blank to disable WinRM over IPv6 click "OK" double- Click Allow CredSSP Authentication Select Enabled Click "OK"Client Settings

To enable PowerShell remoting in the client side, create a new GPO and link it to an organizational unit containing the CO Mputer objects for the client machines. Open the GPO with the Group Policy editor and set the following options:Credential delegationNavigate to Computer Settings > Administrative Templates > System > Credentials delegation double-click Allow Del Egating Fresh Credentials Select Enabled Click "Show ..." Enter a list of service principal names representing hosts to which clients should is allowed to delegate credentials. Wildcards is allowed in the host name portion of the SPN. For Example:wsman/server01-allows delegation only to the server named Server01, and only using its Single-label name WS Man/server01.mydomain.local-allows delegation only to the server NamedServer01, and only using its fully-qualified domai N Name wsman/*.mydomain.local-allows Delegation to any host on the Mydomain.localdns domain, using their fully-qualified Domain names only wsman/*-allows delegation to any host by any name click "OK" click "OK"WinRM Client Parameters Navigate To computer Settings > Administrative Templates > Windows Components > Windows Remote Management ( WinRM) > WinRM Client double-click allow CredSSP authentication select enabled Click "OK" double-click  trusted hosts select enabled in the box labeled trustedhostlist, enter a comma-separated list of hosts the Client should trust. Wildcards is allowed, and there was a special <local> value meaning trust all Single-label names. For Example:server01 -trust only the server Named server01, and only using its Single-label name Server01.mydo Main.local -trust only the server Named server01, and only using its fully-qualified domain name *.mydomain.loc Al -trust any host in The mydomain.local dns domain, using their fully-qualified domain names only <loc Al> -trust any host by Single-label name * -trust any host by any name click "OK"Troubleshooting

Here is some common error messages and some troubleshooting tips for each: operation timed out

enter-pssession:connecting to remote server failed with the following error me
ssage:the WinRM client cannot compl Ete the operation within the time specified
. Check if the machine name is valid and was reachable over the network and firew all
exception for Windows Remote Manage ment service is enabled. For more informa
tion, see the about_remote_troubleshooting Help topic.

Can you ping the machine using the same name used for the ComputerName parameter? If the settings is defined in Group policy, have the machine performed a Policy refresh? Force One by running Gpupdate/target:computer with elevated privileges Does The machine has the Windows Remote managemen T (http-in) rules enabled in Windows Firewall? is the Windows Remote Management (ws-management) service running on the machine? Policy does not allow delegation of user credentials

 enter-pssession:connecting to remote server failed with the following error me ssage:the WinRM client cannot proc ESS the request. A computer Policy does not allow the delegation of the user credentials to the target computer.
Use GPEdit. MSC and look at the following Policy:computer Configuration, administrative T emplates, System, credential  s delegation, allow delegating Fresh Credentia ls. Verify that it's enabled and configured with a SPN appropriate for the TA rget computer. For example, for a target computer name "myserver.domain.com", TH-e SPN can be one of the Following:wsman/myserver.domain . com or wsman/*.domain.c om.
For more information, see the About_remote_troubleshooting Help topic. 

Make sure the name specified in the ComputerName parameter matches the SPN specified in the GPO. If The policy specifies a wildcard with a domain name, for example, make sure Thecomputername parameter are the Fully-quali Fied domain name of the remote host, not just its single-label name The target computer is not trusted

enter-pssession:connecting to remote server failed with the following error me ssage:the WinRM client cannot process t He request. A computer Policy does not allow the delegation of the user credentials to the target computer because the computer is n OT trusted. The identity of the target computer can verified if you configure the WSMAN service to use a valid certificate using T He following co mmand:winrm set Winrm/config/service ' @{certificatethumbprint= "<thumbprint>"} ' Or you can check T The He event Viewer for a event that specifies, the Followin G SPN could not be created:wsman/<computerfqdn>  If you find this event, you ca n manually create the SPN using Setspn.exe.  If the SPN exists, but CredSSP can does not use Kerberos to validate the identity of the target computer and you still w ant to Allow the delegation of the user credentials to the target computer, use gpedit.msc and look at the following Policy:co Mputer Configuration, Administr ative templaCredentials delegation, System-I, TES, Fresh Credentials w ith ntlm-only Server authentication. Verify that it's enabled and configured w ith an SPNs appropriate for the target computer. For example, for a target comput er name ' myserver.domain.com ', the SPN can be one of the Following:wsman/myserv Er.domai N.com or wsman/*.domain.com. 
Try the request again after these changes.
 For more information, see the About_remote_troubleshooting Help topic.

Make sure the remote host have a Service Principal Name starting with WSMAN and matching the value specified in the Compute Rname parameter. To list A host ' s service Principal names, run Setspn-l <computername> with elevated privileges on a domain controll Er. If A proper SPN does not exist, try restarting the Windows Remote Management (ws-management) service, and check the System Event Log for event ID 10154. If The event exists, you'll need to modify permissions in Active Directory in order for hosts to being able to register th EIR SPNs correctly (see below) Make sure is specifying a fully-qualified user name in the Pscredential object passed To the credential parameter (i.e. domain\username or username@domain.local) modifying Active Directory Permissions

Note: Perform These steps only  if you receive the ' target computer is not trusted ' error, Windows Remote Managment logs event ID 10154 in the Syste M event log, and setspn-l does not list Anywsman/... spns for the remote host! Open ADSI Edit click action > Connect to ... Under connection Point, Select select a well known naming Context and Choose default Naming Context U Nder computer, Select default (domain or server, logged in to) If your Domain controllers support it (i. E. You is running Active Directory Certificate Services), Tick use ssl-based encryption Expand the objects in the TR EE at the left until your find the container containing the computer object for the server exhibiting the issue, such AS&NB Sp Cn=computers Right-click on the container object and choose properties Click The security tab click "Advan CED "click" Add ... " In the box labeled enter the name of the "object to select", Enter network SERVICE in the drop-dOwn list labeled apply to, Select descendant computer objects Scroll all the "the" to the bottom of the permi Ssions list and tick the box in The allow column for validated write to service principal name TICK&NB Sp Apply these permissions to objects and/or containers within this container only click "OK" click "OK" click "OK" Repeat St EPS 6-17 for any container with computer objects for hosts on which PowerShell Remoting is enabled Restart The window S Remote Management (ws-management)  service on the affected hosts Run setspn-l <computername> with Elevated privileges on a domain controller to verify the SPN is correctly created