June 4, 2012 at 11:58 pm
I am totally new to powershell(just 2 days) so please bear my ignorance.Here is the code I am trying to execute as a sql agent job that basically deletes files over 2 days old.
function LoopFolders([string]$path,[string]$logpath) {
$fs = new-object -com scripting.filesystemobject
$folder = $fs.getfolder($path)
$today = get-date -uformat "%Y_%m_%d"
$log = $logpath + "Deleted_" + $today + ".log"
foreach ($i in $folder.files)
{
if($folder.path -contains "Master" -or $folder.path -contains "Model" -or $folder.path -contains "Certificates")
{break}
else
{
$dt = ((Get-Date) - $i.DateLastModified).Days
if ($dt -gt 2 -and $i.PsISContainer -ne $True )
{
$deleted = "Deleting - " + $i.path + " - Last Write Time - " + $i.DateLastModified
add-content $log -value $deleted
remove-item $i.path
}
}
}
foreach ($i in $folder.subfolders)
{
LoopFolders($i.path)
}
}
LoopFolders "C:\DatabaseBackUps" "C:\DatabaseBackUps\BackUpDeleteLogs"
LoopFolders "\\10.1.1.10\DatabaseBackups" "\\10.1.1.10\Database\BackUpDeleteLogs"
The problem here is that the code works fine for local path but errors out for network path with the following message.
The corresponding line is 'remove-item $i.path'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'Invalid Path: '\\10.1.1.10\database\LogBackUp\PRODUCTION_ALLIED\PRODUCTION_ALLIED_backup_2012_06_01_093000_6722391.trn'. '. Process Exit Code -1. The step failed.
The same question has been asked here
--------------------------------------------------------------------------------------------------
I am just an another naive wannabe DBA trying to learn SQL Server
June 5, 2012 at 1:23 pm
Try something like this. Running it with the -WhatIf will only report what would be deleted by this command. Remove the -WhatIf when you're ready for it to do work.
#################################################
#init variables
$directory = "\\servername\sharename"
$retentionDate = (Get-Date).AddDays(-2)
#################################################
# nothing below here needs to change
Get-ChildItem $directory |? {($_.PSIsContainer -eq $false) -and ($_.LastWriteTime -lt $retentionDate)} | Remove-Item -WhatIf
Add -Recurse to the Get-ChildItem call to also delete old files from sub-directories:
#################################################
#init variables
$directory = "\\servername\sharename"
$retentionDate = (Get-Date).AddDays(-2)
#################################################
# nothing below here needs to change
Get-ChildItem $directory -Recurse |? {($_.PSIsContainer -eq $false) -and ($_.LastWriteTime -lt $retentionDate)} | Remove-Item -WhatIf
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
August 17, 2012 at 12:33 pm
Same problem for me - did you ever get this figured out?
August 17, 2012 at 12:56 pm
bwperrin (8/17/2012)
Same problem for me - did you ever get this figured out?
Did you try the code I provided?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
August 20, 2012 at 10:33 am
Yes, I did the following from a SQL Agent PowerShell job step:
$src = "\\serverpath\filename"
$dst = "e:\path\filename"
Copy-item $src -destination $dst
and still get the SQL Agent error:
The error information returned by PowerShell is: 'Invalid Path: '\\serverpath\filename'. '. Process Exit Code -1. The step failed.
The following from PowerShell on the server box succeeds:
Copy-item "\\serverpath\filename" -destination "e:\path\filename"
Must be some permission issue, but I'm not smart enough to figure it out. Thx
August 20, 2012 at 10:57 am
Does the account the SQL Server Agent service runs under have permissions to that path?
August 20, 2012 at 11:00 am
bwperrin (8/20/2012)
Yes, I did the following from a SQL Agent PowerShell job step:$src = "\\serverpath\filename"
$dst = "e:\path\filename"
Copy-item $src -destination $dst
and still get the SQL Agent error:
The error information returned by PowerShell is: 'Invalid Path: '\\serverpath\filename'. '. Process Exit Code -1. The step failed.
The following from PowerShell on the server box succeeds:
Copy-item "\\serverpath\filename" -destination "e:\path\filename"
Must be some permission issue, but I'm not smart enough to figure it out. Thx
When running it via SQL Agent it will be running as the SQL Agent service account, i.e. whatever account the service is running as. If your SQL Agent is running as a built-in account such as NetworkService, LocalSystem or LocalService you may have trouble since those accounts likely do not have rights to access the network share you're looking to access, whereas when you rin the same PowerShell locally under your own security context you will have access.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
August 28, 2012 at 10:46 am
Finally figured out how to get it working. SQL uses the sqlps utility, which is a Windows PowerShell mini-shell, and it has some restrictions such as mentioned above. The SQL Agent solution is to use a job step type of not PowerShell, but Operating system (CmdExec). In the code window do: powershell.exe -command "your powershell script"
August 28, 2012 at 11:00 am
bwperrin (8/28/2012)
Finally figured out how to get it working. SQL uses the sqlps utility, which is a Windows PowerShell mini-shell, and it has some restrictions such as mentioned above. The SQL Agent solution is to use a job step type of not PowerShell, but Operating system (CmdExec). In the code window do:powershell.exe -command "your powershell script"
What are you referring too specifically?
You are right that the PowerShell step type runs code in a sqlps mini-shell, however Copy-Item is not restricted in the mini-shell. I just tested it again to be sure. I am happy you got it working via the command-line call but you did not need to do that. Something else was wrong in your previous attempts. Does a sysadmin own your job? Are you using a proxy?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
September 5, 2012 at 1:19 pm
You need to change the provider when the job runs. It's running under the sqlserver:/ provider. Just do a cd c: at the top of your script and it will now accept the unc path.
Scott
September 5, 2012 at 1:33 pm
Scott Newman-212556 (9/5/2012)
You need to change the provider when the job runs. It's running under the sqlserver:/ provider. Just do a cd c: at the top of your script and it will now accept the unc path.Scott
Hmm, that was not necessary for me. My test was successful with only a single command like so:
Copy-Item "\\server\path\file.extension" -Destination "C:\localpath\localfilename.extension"
For the record I am using 2008 R2 Build 10.50.2806.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
September 13, 2012 at 4:45 pm
"cd c:" works! Thanks!!
September 13, 2012 at 6:56 pm
bwperrin (9/13/2012)
"cd c:" works! Thanks!!
What build are you on?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
July 28, 2013 at 7:11 am
sgnewman (9/5/2012)
You need to change the provider when the job runs. It's running under the sqlserver:/ provider. Just do a cd c: at the top of your script and it will now accept the unc path.Scott
Nailed it! This is the only place I've been able to find on the whole internets that has the solution. This has been driving me crazy for days! I chose to use the newer PowerShell command "Set-Location c:" instead, which does the same thing.
opc.three (9/13/2012)
bwperrin (9/13/2012)
"cd c:" works! Thanks!!What build are you on?
I'm willing to bet it worked for the guy using SQL 2012. Our powershell scripts were all working perfectly fine running as SQL agent jobs in SQL 2008 R2. We upgraded to SQL 2012 and all of our powershell scripts that performed file copy or moves would fail with "invalid path". Scott knew exactly what is happening now in SQL 2012.
Thanks Scott!
July 28, 2013 at 7:35 am
You're very welcome.
Scott
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply