I have the need to run a Powershell command on a remote computer that will move a file from the remote computer to another computer on the network.
PS H:\> invoke-command -computername server1 -scriptblock {move-item c:\jobs\archive\A1051626.zip "
\\FilerServer\jobs\archive\"}
This command results in the following error:
Access to the path is denied.
+ CategoryInfo : PermissionDenied: (C:\jobs\archive\A1051626.zip:FileInfo) [Move-Item], Unauthorized
AccessException
+ FullyQualifiedErrorId : MoveFileInfoItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.MoveItemCommand
If I edit the PS command to copy the file to a local system folder the command runs fine.
The user account that I am running the PS script from on my local computer has permissions to copy files to the remote file server. I have double checked this, and I can mannually copy the files to the file share from Windows Explorer.
What is preventing the copy operation in PowerShell? How can I get this task to run?
Thanks!
It is probably a double hop issue. You have to use CredSSP to delegate your credentials to the remote computer.
Try the solution mentioned here: http://blogs.msdn.com/b/clustering/archive/2009/06/25/9803001.aspx
Also, note that Move-Item may not work for moving from filesystem to network share. You might have to use Copy-Item and Remove-Item
See this answer here: How do you move files/folders across volumes with Powershell?
Related
world !
I'm very new to the scripting world but I'm currently trying to automate a process a work that involves in moving a folder and its contents to the windows directory on C:.
currently, I have this
Copy-Item -Path "C:\Java Config Files*" -Destination "C:\Windows\" -R
it's returning with an error message
Copy-Item : Access to the path 'C:\Windows\Java Config Files' is denied.
any thoughts how I can elevate privileges without having to run the script as admin? or if there is a cmdlet that could achieve this?
fixed by running as admin by adding runAS cmdlet
I am on a corporate VPN. I have access to two remote file shares which have windows mapped paths. I can view both file shares in Windows Explorer. My goal is to copy a 1.8 gb .csv file from one share, to the other. I can copy much smaller files with no problem, simply using windows explorer. However, for files around 300mb or greater, I get an error copying the file. The file appears in the destination file share as the correct size, but reading it into python confirms that not all the csv rows are copied.
I am now attempting to copy the file using Windows 10 PowerShell, to open the door to more control over the copy operation, rather than the GUI copy command executed through the Windows 10 desktop environment. (I am replacing the true path names, with stand-ins for privacy)
When I run: Copy-Item \\sourcePath\aFile.csv \\destinationPath\aFile.csv -Verbose -Force
I get the error
Copy-Item : An unexpected network error occurred.
At line:1 char:1
+ Copy-Item '\\sourcePath\ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Copy-Item], IOException
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.CopyItemCommand
I am hoping that in powershell there is some way to either make the copy operation more robust to VPN bandwidth/connection stability limitations, or to cut my client computer out of the copy operation, and order the source file share to directly copy the file to the destination machine, without my machine serving as a middle man relay between the two. It is clear from my network traffic that my machine is downloading and then uploading the file while the failing copy operation runs.
Are you looking to replace the same item that's in the remote path?
Copy-Item -path \\sourcePath\aFile.csv -destination \\destinationPath\aFile.csv\ -Verbose -Force
It could very well be creds aren't being passed since youre on a VPN which you would have to double hop.
A solution is to use robocopy to copy the file.
robocopy “\\aSourcePath\\” “\\aDestinationPath\\” “aFileInSourcePath.something” /mt /z
runs until the file is transfered, is robust to VPN disruptions that seem to cause standard Windows Explorer copy/paste to fail.
I'm having trouble moving from command prompt to powershell. Usually I hold the shift key while right clicking, select 'open command prompt here', and use dir /s>filename.txt to get a list of all files in a directory and its subfolders. However, my company just updated our computers and now I can't access the command prompt from the network folder I'm trying to get a directory list of.
When I right click and hold the shift key there is no option to 'open the command prompt' from the folder I'm selecting. I opened command prompt manually and attempted to navigate to the network folder, but no dice. I get an error regarding UNC (?) or that it basically can't do it because it's a network folder.
I attempted to use powershell the same way I use Command prompt given as an answer Here, however I get an error message
PS Microsoft.PowerShell.Core\FileSystem::\\my.company.com\companydata\MainProject\Records\Field Work\Invoices> dir /s >file.txt
dir : Cannot find path 's' because it does not exist.
At line:1 char:1
+ dir /s >file.txt
+ ~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (s:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
I also attempted to re-instate the command prompt option in the expanded right-click +shift key list as detailed here. However, I don't have the permissions required to run all the steps.
I just need a directory of everything in a specified network folder, just a list of all the files in the folder and subfolders: file paths, file names, and dates created. I used to be able to get it using command prompt but apparently, that's not available. I'm unsure how to use powershell, and help is much appreciated, in either getting new, simple, easy to understand powershell resources so I can teach myself, or in finding a work around so I can continue using command prompt.
Is there an interpretation guide I can use that goes from Command Prompt to Powershell, and also will let me list files in network drives? (I can sort of understand the current resources out there for having powershell list files in a directory on the computer, but what I need is the powershell to be able to list files in a specified network folder).
In powershell, dir is an alias for Get-ChildItem I believe you're getting that error because switches/arguments work differently in PowerShell. The first parameter by position is Path, so the system thinks you are providing the value /s for the path.
You can do this in PowerShell without having to launch cmd by leveraging Get-ChildItem. As you what the complete structure including the subfolders, user -Recurse
You could also export to csv instead of text file. There's a lot of data - Select can be used to restrict which fields you export.
$Path = "\\my.company.com\companydata\MainProject\Records\Field Work\Invoices"
$Files = Get-ChildItem -Path $Path -Recurse
$Files | Out-file file.txt
$Files | Select-Object FullName,CreationTime | Export-Csv file.csv -NoTypeInformation
How can I get a remotely executed script to know it's own location? I'm using Invoke-Command to run a script on a remote server. The script needs to create files in the directory in which it lives. Running with relative addressing doesn't work (i.e. .\output.log), the scripts generally end up in my user profile on the remote server. I tried all the methods outlined in this question but none of them seem to work when the script is remote.
Update: Provided script invocation code per request
$server='ad1hfdahp802'
$remotepath='\\ad1hfdahp802\d$\AHP\pi_exceed_presentation\pi_exceed_presentation_deploy.ps1'
$SDFEnvironment='INT'
Invoke-Command -ComputerName $server -FilePath $remotepath -ArgumentList($SDFEnvironment,$remotepath)
The remote script takes the $remotepath and turns it into a file system path.
Using -FilePath with Invoke-Command means that you read the script locally and send the content as the scriptblock to the remote computer. $PSScriptRoot only works when the script is executed directly on the target. You could try using:
Invoke-Command - ComputerName "computer1" -Scriptblock { & '\\server\path\to\script.ps1' } -Authentication Credssp
Be aware that you need CredSSP to make this work since the remote computer can't use your credentials to access network-resources without it. As an alternative, you could use psexec (or start a process remotely). Ex.
psexec \\computer1 powershell -noprofile -file \\server\path\to\script.ps1
After trying some of the changes proposed I've come to understand that the Invoke-Command isn't actually running the remote script at its original location, but rather loading it from the original location and then running it under the context of PowerShell as the user running the local script. The "script directory" is actually a directory in the user's workspace regardless of where the script originally lived.
This clarifies things for me somewhat. While there may be ways to divine where the script originally came from or to actually start a session on the remote server then run the script as a "local" script there, the need for the remote script to further access other servers, creating multiple hops in authentication, means I have to add CredSSP to the mix.
It seems my original plan, to pass the path I'm using to locate the script to the script so it can place output files in the original directory, is probably the best approach given that I also have to add CredSSP to the mix.
I'm open to refutation, but I don't think any of the proposed solutions actually improve the functionality of the remote script so I'm going to stick with what I started with for now. Thanks to everyone for their contributions.
Enter a session on the remote server, and call the script from there.
local PS> Enter-PSSession -ComputerName $server ...
remote PS> powershell d:\AHP\...\script.ps1
remote PS> exit
local PS>
Then you can use $PSScriptRoot in the script in the remote server to get the local path of the directory of the script on the remote server.
EDIT:
To locate the script on the remote server, you can use your knowledge of the network path of the script file, and parse the output of net share to map network path to local path on the remote server.
remote PS> net share | where { $_.StartsWith('D$ ') } | foreach { [regex]::Split($_, " +")[1]}
My script uses the Powershell splitpipeline module, to bring parallel process and queues features.
The script and the module are stored on shared server, like \server\c$ , the idea is be able to run it from any computer.
Tried to put at begining of the script import-module \\server\c$\SplitPipeline but I recieve the error:
import-module : Could not load file or assembly 'file://\\server\c$\SplitPipeline\SplitPipeline.dll' or one of its dependencies.
Operation is not supported. (Exception from HRESULT: 0x80131515)
At D:\scripts\powershell\OstReport_BETA-PIPE.ps1:6 char:1
+ import-module \\server\c$\SplitPipeline
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Import-Module], FileLoadException
+ FullyQualifiedErrorId : FormatXmlUpdateException,Microsoft.PowerShell.Commands.ImportModuleCommand
If I try to copy it from the srv to the pc with:
Copy-Item -Path \\server\c$\SplitPipeline -Destination C:\windows\system32\WindowsPowerShell\v1.0\Modules -recurse -force
I get a access denied
any ideas¿?
thanks
The issue you're experiencing is that .NET assemblies can't be loaded from an untrusted UNC path, without special configuration. As you already discovered, the simplest solution is to copy the module to your local computer first.
To work around the "Access Denied" message, copy the module to your user directory, not the system-wide directory.
c:\users\<username>\Documents\WindowsPowerShell\Modules
You need to run PowerShell "as Administrator" in order to have permission to copy to the system folder, however it is generally recommended not to modify the default system directory. Instead, copy the module to your user folder (as above).