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

Ampereturn

Have you tried putting a $ after the 'x' in the file path so something like this:"\\ServerName\X$\Folder\PowershellFile.ps1"? – Domel

I have tried this but didn't work. – Ampereturn

Answer 1

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

Siliceous

The information you have provided was really useful. I have just figured out another way for this - Just Pass Credentials to the UNC Path where you use in Scriot block as a part of net use command - Refer Syntax of Net Use Command. This resolved my issue. I used Get-Credntial cmd-let to get AD Credential from the user at the beginning and it applies to all servers. To Pass Username and Password to net use cmd - I used GetNetworkCredntial().Username and GetNetworkCredential().Password for this and it worked - This password is in plain-text. you can even print it on the output console. – Ampereturn

PS is not secure as I thought as you can get password as a plain text too even if you use Get-Credential cmd-let. I'm unable to implement my script because of this. The password is available in plain-text and is not safe in corporates. – Ampereturn

Answer 2

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.

Painty

Answer 3

You can try to open the script by calling a WmiMethod :

$cmd = "CMD.EXE /c *\\\servername\somefolder\yourscript*.cmd" 

Invoke-WmiMethod -class Win32_process -name Create -ArgumentList $cmd -ComputerName *servername*

Note that this will run the script on the server. You can do much more with that, like installing a package remotely (after copying the package locally on the remote machine).

Hope this help!

Witch

This approach did not solve the issue for me. I believe the double-hop issue is still present. Used it like this directly from WMI: "powershell -ExecutionPolicy Bypass -file "\\server\path\file.ps1." Powershell complains it can't find the file. Also tried that as an embedded command in a .bat script on the remote server. When run directly from the server (ps1 or bat -> ps1) it works. Username as seen by powershell is the same for all cases. – Pung