Unable to access UNC Paths in Powershell remote session

Question

I am unable to access the UNC paths on my servers in a Powershell remote session from my local machine. I am able to use them from Servers Cmd prompt directly.

Actually, I have logged into the server and mapped a UNC path as local drive (say X:). Used Reconnect on Login option.

I have a batch file which resides in this X: drive, I want to run it remotely using invoke command from my local script. But, it fails.

It says "Cannot find drive. A drive with name X doesn't exist".

Also, when I try to map drive using net use command in the scriptblock then also it throws an error - System error 1223 - Native Command Error.

I use administrator credentials to log into this server.

Can anyone please help me on this, all i want to do is to run the script remotely which resides on this UNC path ?

Also, when I map a UNC Path in the server as a local drive, why am I unable to use it in a PS remote session ?

Thanks in Advance. TS

Answer 1

alroc's helpful answer explains the problem well and points to resources for solving it through prior configuration.

• An explanation of the underlying problem, the infamous Kerberos double-hop problem, as well as an overview of available solutions can be found in this blog post.

As for an ad hoc solution for accessing a network share in a remote session (PSv3+):

• Pass the credentials for the session via a variable; e.g., -Credential $cred

• Then use these credentials inside the session too - e.g., as $using:cred - to establish a session-scoped auxiliary drive that maps the network location, using New-PSDrive.
  Once the drive has been mapped, the target location is accessible - whether via the drive name, or directly by UNC path.

^{Note: This is a variation of the approach discovered by the OP him/herself and discussed briefly in a comment on alroc's answer, except that New-PSDrive is used rather than net use, which obviates the need for retrieving the password as plain text.}

The following sample code demonstrates running a script from a network share from inside a remote session:

# A sample script to run from a network share on a remote computer.
$script = '\\server-001\install\Install-Agent.ps1'

# A sample target computer.
$computer = 'ws-002'

# Obtain the credentials for the remote session and store them in a variable.
$cred = Get-Credential $env:USERNAME

Invoke-Command -ComputerName $computer -Credential $cred {
  # Map the target network share as a dummy PS drive using the passed-through
  # credentials.
  # You may - but needn't - use this drive; the mere fact of having established
  # a drive with valid credentials makes the network location accessible in the
  # session, even with direct use of UNC paths.
  $null = New-PSDrive -Credential $using:cred -Name dummy -Root (Split-Path -Parent $using:script) -PSProvider FileSystem
  # Invoke the script via its UNC path.
  & $using:script
}

Note:

• $null = ... suppresses New-PSDrive's output (it outputs an object describing the newly created drive).

• Since the drives created by New-PSDrive are not persistent (except if you pass -Persist), there's no need to explicitly remove the dummy drive again, but you can do so with Remove-PSDrive.

  • Also note that PS drive definitions are scoped so that only the calling scope and its descendants see the drive; this enables wrapping statements in & { ... } to call them in a child scope, which means the a PS drive created inside that block will automatically go out of scope when the block is exited.

Answer 2

You've really got 3 different things going on here.

1 & 3. Drives are only mapped when you log on interactively. So when you remoted into the other computer, mapped a drive, and then logged off/disconnected, that mapped drive was disconnected. Except in interactive GUI user sessions, you cannot depend upon a mapped drive letter that you don't create yourself. Within scripts or any remote session, just use UNC paths for everything - it's more reliable.

2 . When you attempt to map the drive in the remote PS session, you're encountering what's known as the "double hop" problem. There is a solution to this, but there's extra setup you have to do. See Double hop access to copy files without CredSSP