This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(214.4, 61%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ES5%3C/text%3E%3C/svg%3E)
I'm connecting with PowerShell from my computer to a remote computer (10.44.5.142) and trying to mount a DFS share there (\10.44.5.143\dfs1\share1). It doesn't work correctly - I get error "A specified logon session does not exist. It may already have been terminated".
The root cause seems to be the combination of DFS share and remote PS session, because mounting a basic non-DFS share through PS remote session works fine. Also, mounting the DFS share directly on the computer (without PsSession) works fine.
I tested on different Windows versions but it behaves the same way.
Does anyone have any solution or ideas to solve this issue?
Below are the steps that I used to reproduce the problem. I also tried capturing network packets for analysis.
$hostRemote = New-PsSession -Computername 10.44.5.142 -Credential mydomain\administrator
Enter-PsSession $hostRemote
pktmon filter add -t TCP
pktmon start --capture --pkt-size 3072 --file-name C:\tcpdump.etl
New-PsDrive -PsProvider 'FileSystem' -Scope 'Global' -Persist -Name E -Root \\10.44.5.143\dfs1\share1 -Credential mydomain\administrator
pktmon stop
pktmon etl2pcap C:\tcpdump.etl -o C:\tcpdump.pcap
You cannot use mydomain\administrator, you have to pass a credential object.
I would also think that with DFS you would need to use the domain name and not an IP address.
It should also work without providing the credential object and it should also work with an IP address (tested this directly on the computer without doing PS remote session).
Anyway, I also tried putting credentials in a variable and using fqdn address but the result was the same.
It would appear that you are running into the infamous double hop problem.
https://www.bing.com/search?pglt=41&q=invoke-command+double+hop
I will take an educated guess that since DFS is involved, that the New-PSDrive is attempting to contact an Active Directory domain controller to gather information about how the DFS share is hosted and it's not using the credentials object on that call. Since you have a Wireshark trace, do you see any network traffic to domain controllers?
One thought would be to map a network drive to your primary domain controller's netlogon or sysvol share using those credentials before you try to map the DFS share. That way you will already be authenticated to the DC.
I reviewed your question, and I see that you are passing the same credentials on the New-PsSession call that you are on the New-PsDrive call. The credentials (userid+pswd) on the New-PsSession call should be sufficient to authenticate to any server. Add some Test-Path calls to verify that you can see the shares on a few remote servers.
Yes, I figured it is the double-hop problem.
I tried your suggestion for mapping a network drive to DC's netlogon/sysvol share but it doesn't help.
The credentials in my example above are the same for PS session and New-PsDrive call but that's just an example so they could also be different. I already tried using the same and different ones but no luck. So having authenticated PS session is not enough for calling New-PsDrive (even if the credentials are the same).
I found this article https://learn.microsoft.com/en-us/archive/blogs/sergey_babkins_blog/another-solution-to-multi-hop-powershell-remoting
I tried the described procedure and it works so I can mount the DFS share over a remote PS session. But I'm not totally satisfied because it's not as straightforward as I hoped. You need to make start 2 PS sessions, and you need to register a custom configuration which is saved on the remote computer and it has to be maintained (e.g. if credentials change).
# Open remote PS session and define custom RunAsCredential configuration
$credRemote=get-credential
Enter-PsSession -Computername 10.44.5.142 -Credential $credB
$credSmb=get-credential
Register-PSSessionConfiguration -Name test -RunAsCredential $credSmb
exit
# Open new remote PS session with provided ConfigurationName
Enter-PsSession -Computername 10.44.5.142 -Credential $credB -ConfigurationName test
# Mounting share without setting Credential parameter - credentials are taken from predefined configuration
New-PsDrive -PsProvider 'FileSystem' -Scope 'Global' -Persist -Name EF -Root \\10.44.5.143\dfs1\share1
Can you try invoke-command and see if you can access shares? See if you can access the IPC$ share on the servers that host the DFS share.
$script =
{
get-childitem \\server1\share
get-childitem \\server2\share
get-childitem \\yourdomain\path2dfsshare
test-path \\dfshost1\ipc$
test-path \\dfshost2\ipc$
}
$User = ".\admin"
$PWord = ConvertTo-SecureString -String "admin" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $PWord
Invoke-Command -ComputerName "test10b" -credential $Credential -ScriptBlock $script
This site is acting flakey. See my invoke-command comment.
Nope, doesn't work. I get "Access is denied" error when trying to access shares over the invoke command.
Sorry. I was thinking that Invoke-Command worked like IIS. It doesn't.