I am typing the following command in Windows Powershell into a remote connected computer:
(code noted below)
I am getting the error message in windows Powershell :
Set-Clipboard : Cannot find drive. A drive with the name 'Q' does not exist.
HOWEVER, if I do the same when directly connected than the code works fine.
Could you please advise.
Thanks
Set-Clipboard -Path "Q:\Myname X\2019\07- Mon\City Name Job Nbr XXX 00-99"
I'm speculating a bit because you didn't provide the command line you used to connect to the remote machine. Probably the Q: drive represents a mapped network drive (unless you have a lot of USB/SATA drives connnected). You can confirm by running net use at a command prompt to show all the mapped drives and Remote/UNC paths. It should look like this
Status Local Remote Network
-------------------------------------------------------------------------------
Connected Q: \\server\share\ Microsoft Windows Network
You were probably remotely connected with the same account you use to log in, but it doesn't map all the drives when you are using a remote session. You can try to either map the drive in the remote session with net use q: \\server\share or you can try to use the full UNC path in your command line:
Set-Clipboard -Path "\\server\share\Myname X\2019\07- Mon\City Name Job Nbr XXX 00-99"
Where Server and Share are the values you got from the net use Remote column.
Related
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
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
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.
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!
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
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
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.
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!
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
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
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.
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!
Please note: security is not an issue at all with this application.
I have a "MachineA" that has a file we will call file.txt. I need to get this file onto a "MachineB". Here's the catch, this needs to be done by remotely sending an Invoke-Command script from MachineB to MachineA to kick back the file.
What I have tried so far:
I have setup a shared drive (using net use) on MachineB that MachineA can access. This drive is known as z:\ to MachineA.
I can send this command via Invoke-Command from MachineB to MachineA and it will transfer a file from one directory to another directory within MachineA
xcopy c:\users\administrator\desktop\file.txt c:\file.txt
Now if I send the following command in the same manner from MachineB to MachineA it will complain about not being able to see drive Z.
xcopy c:\users\administrator\desktop\file.txt z:\FilesFromVMs\file.txt
Note: if run the second command directly on MachineA from powershell it will move the file but I need to be able to do this remotely via Invoke-Command
If security is not an issue, maybe try using UNC Paths \MachineA\C$\Users...\ instead of relying on mapped drive letters? Perhaps that'll do the trick.
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
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
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.
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!