I am trying to do an unattended backup our websites from 2 webservers to our backup server.
$FolderName = $(Get-Date -Format D)
New-Item -ItemType directory -Path D:\backups\webservers\$FolderName
New-Item -ItemType directory -Path D:\backups\webservers\$FolderName\ColoWebP1
New-Item -ItemType directory -Path D:\backups\webservers\$FolderName\ColoWebD1
Copy-Item \\colowebp1.wa.local\e$\websites D:\backups\webservers\$FolderName\ColoWebP1 -recurse
Copy-Item \\colowebp1.wa.local\e$\backup D:\backups\webservers\$FolderName\ColoWebP1 -recurse
Copy-Item \\colowebd1.wa.local\e$\websites D:\backups\webservers\$FolderName\ColoWebD1 -recurse
Copy-Item \\colowebd1.wa.local\e$\backup D:\backups\webservers\$FolderName\ColoWebD1 -recurse
Now I still have not got this to run unattended. It creates the folders but does not copy the files. And now a new wrinkle has occured. When I run it manually I recieve this error:
Copy-Item : Access to the path 'D:\backups\webservers\Tuesday, February 25, 2014\ColoWebD1\websites\Agent_eVantage_Beta
\Master_wSlider.master' is denied.
At C:\scripts\Webserverbackup.ps1:12 char:10
+ Copy-Item <<<< \\colowebd1.wa.local\e$\websites D:\backups\webservers\$FolderName\ColoWebD1 -recurse
+ CategoryInfo : PermissionDenied: (Master_wSlider.master:FileInfo) [Copy-Item], UnauthorizedAccessExcept
ion
+ FullyQualifiedErrorId : CopyFileInfoItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.CopyItemCommand
But all the files appear to be there. (I haven't attempted a restore of this yet).
So my questions are:
Am I reading this error right? Is it having trouble authenticating to the server this is running from?
And how do I get this to run unattended?
The problem is with the dollar sign in your Copy-Item (i.e. \$e\)
PowerShell is interpreting the $ sign as a variable. I would instead use a shared folder instead of the drive letter.
Copy-Item '\\colowebp1.wa.local\Share\websites' "D:\backups\webservers\$FolderName\ColoWebP1" -recurse
You have to set proper permissions to access Admin share. What happens when you access the target path above with Explorer? If everything is set up correctly, you should be able to get into the share without authentication. (ex. with default network credentials). Your solution itself is fine however and it will work once the authentication is not required. There are workarounds to this with PS but you would have to provide some details on network and UAC setup. I will happily attempt to resolve this once you provide the details.
At work I use such paths to admin share and these are working perfectly, Powershell doesnt treat the share as a variable.
Thanks,
Alex
Related
I need to set SASS_BINARY_PATH environment variable with the local file I've downloaded to be able to install node-sass behind a corporate firewall. So on windows cmd, I just do:
SET SASS_BINARY_PATH=C:\Source\Repos\SRT\Srt.Web\sass-binary\v4.7.2\win32-x64-48_binding.node
And the installation works fine since it successfully sets the variable. But when I try doing it via Powershell, it doesn't work:
$env:SASS_BINARY_PATH="C:\Source\Repos\SRT\Srt.Web\sass-binary\v4.7.2\win32-x64-48_binding.node"
I've also tried another way on Powershell:
[Environment]::SetEnvironmentVariable("SASS_BINARY_PATH", "C:\Source\Repos\SRT\Srt.Web\sass-binary\v4.7.2\win32-x64-48_binding.node", "Machine")
Upon checking it on the control panel, it successfully added a "SASS_BINARY_PATH" system variable. But upon trying to reinstall node-sass, it fails again.
One of my observations is when I'm doing it the windows cmd way then check it by using the command line set, the variable shows up along with others. But when I use both the Powershell methods, it does not show up. Any ideas on this?
The error encountered when trying to npm-install node-sass over a corporate firewall is:
Downloading binary from
https://github.com/sass/node-sass/releases/download/v4.7
.2/win32-x64-48_binding.node Cannot download
"https://github.com/sass/node-sass/releases/download/v4.7.2/win3
2-x64-48_binding.node":
HTTP error 401 Unauthorized
Download win32-x64-48_binding.node manually
Put it in C:\Users\<user>\AppData\Roaming\npm-cache\node-sass\4.7.2 folder.
Then try to run npm install node-sass
here is the PowerShell command #jengfad used based on above solution which is commented in the discussion
$cacheSassPath = $env:APPDATA + '\npm-cache\node-sass'
if( -Not (Test-Path -Path $cacheSassPath ) )
{
Write-Host "cacheSassPath not exists"
New-Item -ItemType directory -Path $cacheSassPath
Write-Host "cacheSassPath CREATED"
}
<# Ensure has no content #>
Get-ChildItem -Path $cacheSassPath -Recurse| Foreach-object {Remove-item -Recurse -path $_.FullName }
<# Copy local sass binary (~Srt.Web\sass-binary\4.7.2) file to cache folder #>
$sassBinaryPath = split-path -parent $MyInvocation.MyCommand.Definition
$sassBinaryPath = $sassBinaryPath + "\sass-binary\4.7.2"
Copy-Item -Path $sassBinaryPath -Recurse -Destination $npmcachedir -Container
Write-Host "node-sass binary file successfully copied!"
I have a script that needs to copy files on a regular basis (every hour). I can open the source and destination folder using windows explorer and copy the file without issue.
However, if I try the same thing in PowerShell I get an Access to the path is denied error. I've checked the permissions on the share and I have full access. Why does this fail through PowerShell?
Copy-Item command:
Copy-Item \\idmststtrm2\tns_admin$\tnsnames.ora -Destination \\bts13r2b\tnsnames -Force
Errors:
Copy-Item : Access to the path '\\bts13r2b\tnsnames\tnsnames.ora' is denied.
At line:1 char:1
+ Copy-Item \\idmststtrm2\tns_admin$\tnsnames.ora -Destination \\bts13r2b\tnsnames ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (\\idmststtrm2\tns_admin$\tnsnames.ora:FileInfo) [Copy-Item], UnauthorizedAccessException
+ FullyQualifiedErrorId : CopyFileInfoItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.CopyItemCommand
Copy-Item : Access to the path '\\bts13r2b\tnsnames\tnsnames.ora' is denied.
At line:1 char:1
+ Copy-Item \\idmststtrm2\tns_admin$\tnsnames.ora -Destination \\bts13r2b\tnsnames ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Copy-Item], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.CopyItemCommand
Edits:
When I execute a Get-ChildItem against the destination path, I'm able to see the folder contents.
Results from get-item:
get-item \\idmststtrm2\tns_admin$\tnsnames.ora
Directory: \\idmststtrm2\tns_admin$
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 3/10/2017 8:49 AM 14143 tnsnames.ora
get-item \\bts13r2b\tnsnames\tnsnames.ora
Directory: \\bts13r2b\tnsnames
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 3/8/2017 9:51 AM 15991 tnsnames.ora
get-item \\bts13r2b\tnsnames
Directory:
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 3/21/2017 11:14 AM tnsnames
Tried using xcopy:
xcopy \\idmststtrm2\tns_admin$\tnsnames.ora \\bts13r2b\tnsnames\tnsnames.ora
Access is denied.
This problem is due to permissions writing to a network share. While the share permissions were set correctly, the NTFS permissions were missing. A system administrator will need to ensure both sets of permissions allow for the account to write to the folder. Once this was updated correctly the script was able to perform a copy to the network share.
I know this is old, but I had a hair-pulling experience trying to get a scheduled job (running as a GMSA) to work calling a .ps1 using Copy-Item and getting the same "Access to the path ... is denied" error. I checked and double-check permissions on the remote shares - both Share permissions and NTFS permissions. It ran successfully with my login, it ran successfully with Admin login.
Finally, just for grins, I changed the Share permissions from "All Users" to "Everyone" and it started working! Therefore, it appears that GMSA accounts are not part of "All Users". I would have never guessed!
Hopefully this saves someone 10 hours of fruitless labor...
You have the correct idea, but what if you try using the 'Administrative Share' to access the other system.
Created some standard variables: $Source and $Target. Now we use Get-ChildItem and the switch -Path to grab the file or directory we need. Then we use Copy-Item and the switch -Force to send the file to the other server. This method should work, but will describe another method.
I assume it would look something like this.
$Source = "\\idmststtrm2\c$\app\oracle\product\11.2.0\dbhome_1\network\admin\tns_admin$\tnsnames.ora"
$Target="\\bts13r2b\c$\app\oracle\product\11.2.0\dbhome_1\network\admin\tnsnames"
Get-ChildItem -Path $Source | Copy-Item -Destination $Target -Force
Another option is to make sure that you first have write access to both shared directories. Once that is verified, we run the following:
$Source="\\idmststtrm2\tns_admin$\tnsnames.ora"
$Target="\\bts13r2b\tnsnames"
Get-ChildItem -Path $Source | Copy-Item -Destination $Target -Force
#(Get-Acl $Source).Access #Verify $Source Access
#(Get-Acl $Target).Access #Verify $Target Access
Let us know if this works.
Try opening powershell as an administrator, some times that causes this issue
I am getting the following error when attempting to use Copy-Item in powershell;
Logon failure: account currently disabled
The powershell code;
Copy-Item -Path $_ -Destination $remotePath -Recurse -Container -Force
UP until yesterday, this was working fine. Today, nope. I can access the remote machine using the UNC path that it is copying the file to. I can login to the machie directly using RDP and I am in the local Admins group.
I can see nothing in the standard logs. A reboot of the target machine does nothing.
I wrote functional in powershell which delete virtual folder in IIS, delete physical path, unzip archive to folder, and create virtual path in IIS with old name. The problem in step 2. Script try delete files and folder.
...
get-childitem ($pathToIIs + "*") -recurse | remove-item -Force -recurse
...
Powershell throws error:
Cannot remove item C:\inetpub\test\css: The directory is not empty. + CategoryInfo : WriteError: (css:DirectoryInfo) [Remove-Item], I
OException
+ FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell
.Commands.RemoveItemCommand
+ PSComputerName : test.cloudapp.net
If understand correct, to stop and start IIS it's bad idea. So how fix this error?
You MUST stop IIS to be able to remove files locked by IIS:
...
iisreset /stop
get-childitem ($pathToIIs + "*") -recurse | remove-item -Force -recurse
iisreset /start
...
Stopping IIS will obviously and temporarily prevent your server from serving web pages.
I am trying to copy some files from my server to a workstation. If I change $Foldername to C:\the process works fine. However if I leave the code the way it is, i.e. If I decide to copy files to C:\Program Files\Interrogator.
I get this error:
Copy-Item : Access to the path 'C:\Program Files\Interrogator\Setup Instructions.txt' is denied.
At C:\Users\coduy\Desktop\Copy2Test.ps1:20 char:10
+ Copy-Item <<<< -Path \\10.10.0.10\DeploymentShare\Applications\JDE-Interrogator\* -Destination $Foldername
+ CategoryInfo : PermissionDenied: (\\10.10.0.10\De...nstructions.txt:FileInfo) [Copy-Item], Unauthorized
AccessException
+ FullyQualifiedErrorId : CopyFileInfoItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.CopyItemCommand
I can see that the access is denied but why? I have not shared any of the folders and that should not make any difference if I decide to copy to C:\ or C:\Program Files
$net = New-Object -comobject Wscript.Network
$net.MapNetworkDrive("Z:","\\10.13.0.10\DeploymentShare\Applications\JDE Interrogator",0,"mydomain\coduy","P0kroy$")
$uncServer = "\\10.10.0.10\"
$uncFullPath = "\\10.13.0.10\DeploymentShare\Applications\JDE Interrogator"
$username = "coduy"
$password = "password"
$Foldername="C:\Program Files\Interrogator"
net use $uncServer $password /USER:$username
try
{
mkdir C:\'Program Files'\Interrogator
Copy-Item -Path \\10.10.0.10\DeploymentShare\Applications\JDE-Interrogator\* -Destination $Foldername
}
finally {
net use $uncServer /delete
}
Found out that other user has similar issue and this seems to be a reasonable answer:
Windows Vista and above default to not allowing non-administrative
users to write to the `%PROGRAMFILES% folder. This means that you're
not going to be allowed to copy the files there; you're also not going
to be able to save them after doing your find/replace operation.
You can write them to your user documents folder
(%USERPROFILE%\Documents) folder instead, if that will work for you.
share|edit answered Dec 23 '12 at 6:32
Ken White
74.5k770140