Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In attempting to create a PowerShell script using remoting I ran into what I believe is the double-hop problem. In that article, Perriman gives a succinct description of the problem as well as the specific steps to resolve the issue (almost trivial if you know the commands, but for someone less familiar like myself, that information was invaluable!).

I ran Enable-WSManCredSSP Server on my Win7 server without incident, but attempting to run Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server> on my Win7 client generated this error:

Enable-WSManCredSSP : 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 com mand on the destination
to analyze and configure the WinRM service: "winrm quickconfig".

Running winrm quickconfig confirmed my server was running WinRM:

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

And Get-WSManCredSSP confirmed my server was ready to accept credentials from a client:

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

I also found Boessen's article on WinRM wherein he describes general WinRM setup and found one tidbit to get a useful data point in diagnosis; this command run on the client uses the winrs tool to remotely access the server:

winrs -r:http://<FQDN of my server>:5985 -u:<myDomain>\msorens "dir c:\"

That command returned the expected result, the contents of the root directory on the server, without incident, confirming that my FQDN is correct and that WinRM is enabled.

Boessen indicates port 5985 is the default for Win7; this command run on the server confirms a value of 5985:

get-item wsman:\localhost\listener\listener*\port

The question: Why am I unable to execute the Enable-WSManCredSSP command on the client side?

2011.06.07 Update

I found a solution to the above question: invoking Enable-PSRemoting, advertised to configure a computer to receive remote commands, allowed the Enable-WSManCredSSP on the client to work successfully! Curious, but its man page indicates it does a number of different actions, so I assume one of those inadvertantly did what I needed.

But then I reached another roadblock when I attempted to use CredSSP authentication. Here is the command:

Invoke-Command { Write-Host "hello, world" } -computername $serverName `
-credential $testCred  -Authentication Credssp

And here is the response:

Connecting to remote server failed with the following error message:
The WinRM client cannot process 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 Templates -> System -> Credentials Delegation
-> Allow Delegating Fresh Credentials.  Verify that it is enabled and
configured with an SPN appropriate for the target computer. For example,
for a target computer name "", the SPN can be one of
the following: WSMAN / or WSMAN/*
For more information, see the about_Remote_Troubleshooting Help topic.

I verified the settings just as this remarkably helpful error message suggested, and it looks to me like it is configured properly.

The new question: What does this remote connection attempt with CredSSP fail?

In answering please keep the following in mind: Let me dispell in advance any notion that I know what I am doing here, any appearance to the contrary notwithstanding.:-) Windows admin is not my area of expertise!

share|improve this question
up vote 5 down vote accepted

I came back to this after a brief hiatus to look again with fresh eyes (both mine and a co-worker) and decided to go back to the basics again:

On the client I executed (in administrator shell):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

On the server I executed (in administrator shell):

enable-wsmancredssp -role server -force

Both returned normal output indicating CredSSP was now "true".

I then used the following exerciser code to walk through increasing levels of complexity:

$block = {
  Write-Host ("hello, world: {0}, {1}" -f $env:USERNAME, (hostname))
$username = "test_user"
$password = "..."   
$adjPwd = $password | ConvertTo-SecureString -asPlainText -Force
$testCred = (New-Object System.Management.Automation.PSCredential($username,$adjPwd))    

switch ($choice)
  "basic"       { Invoke-Command $block }
  "remote"      { Invoke-Command $block -computername $serverName }
  "credentialA" { Invoke-Command $block -computername $serverName -credential $testCred  }
  "credentialB" { Invoke-Command $block -computername $serverName -credential $testCred  -Authentication Credssp}
  "session"     { 
      $testSession = New-PSSession -computername $serverName -credential $testCred -Authentication Credssp
      if ($testSession) { Invoke-Command $block -Session $testSession; Remove-PSSession $testSession }

All of that is in my run.ps1 script so the transcript went as follows (and this ran in a non-administrator shell):

PS C:\> .\run.ps1 basic
hello, world: msorens, MyLocalMachine
PS C:\> .\run.ps1 remote MyRemoteServer
hello, world: msorens, MyRemoteServer
PS C:\> .\run.ps1 credentialA MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 credentialB MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 session MyRemoteServer
hello, world: test_user, MyRemoteServer

Previously, only basic, remote, and credentialA worked. Now all 5 work. Whew!

share|improve this answer
CredSSP is good solution? Microsoft says: Caution: Credential Security Service Provider (CredSSP) authentication, in which the user's credentials are passed to a remote computer to be authenticated, is designed for commands that require authentication on more than one resource, such as accessing a remote network share. This mechanism increases the security risk of the remote operation. If the remote computer is compromised, the credentials that are passed to it can be used to control the network session. – Kiquenet Sep 5 '12 at 8:24

When I had to do this, this is what I did to get it working (there may also have been some GPO settings, but it looks like you've got those covered).

To enable the CLIENT to use CredSSP to connect to any machine in the domain:

Enable-WSManCredSSP -Role Client -DelegateComputer "*" -Force | out-null
#the following is used because -delegatecomputer (above) doesn't appear to actually work properly.
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain -Name WSMan -Value "WSMAN/*"

Then I ran the following on each target machine (server) to enable the CredSSP authentication:

Connect-WSMan -ComputerName $computer 
Set-Item "WSMAN:\$computer\service\auth\credssp" -Value $true 

This of course requires that you're running the script with appropriate permissions. This worked for me -- I hope it helps you out.

share|improve this answer
Thanks for the suggestion but it still failed with the same result. – Michael Sorens Jul 12 '11 at 19:02
I'm not sure if this makes a difference, but my original post may have been misleading. I ran all of these commands from the CLIENT machine. So "$computer" in the second code block above was the name of the server that I was attempting to connect TO. – jbsmith Jul 14 '11 at 18:00
I had somewhat figured that out because it did not make sense that the server had to have a priori knowledge of the clients. I just reran the whole sequence again to be sure, though, and it does fail with the same error. One other variation: I omitted the -Authentication parameter and confirmed that everything else in my statement works (Invoke-Command { Write-Host "hello, world" } -computername $serverName -credential $testCred). So the CredSSP authentication is strictly the issue. – Michael Sorens Jul 14 '11 at 19:25
Agreed -- basic WinRM is fine; I don't what the exact issue is, but I suspect it's related to the 'allow fresh credentials' policy and the SPN you set up. I'd take a closer look at that policy setting and perhaps dig in a little deeper to make sure your kerberos is working right. This link looks like it might be helpful: [link] – jbsmith Jul 15 '11 at 3:17
Why use Connect-WSMan to Server, better use enable-wsmancredssp -role server, isn't? – Kiquenet Sep 5 '12 at 6:47

I got where I could live migrate a VM from one hyper-v 2012R2 server to another, but could not migrate it back. (I'm trying to use SAMBA 4.2 as my domain controller and wanted to see if I could live migrate with CredSSP as I couldn't use constrained delegation with Samba4).

Ultimately I went to the working hyper-v and copied the registry entries at hklm:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation to the non-working hyper-v. Worked fine both ways after that.

share|improve this answer
The registry tree copy worked for me too. hklm:\SOFTWARE\...\CredentialsDelegation node did not exist, the value was stored in hklm:\SOFTWARE\Wow6432Node\...\CredentialsDelegation and in HKEY_USERS\...\Group Policy Objects\...\CredentialDelegation. – Der_Meister Feb 2 at 10:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.