May 26, 2015 at 10:36 am
Server is running Windows 2008R2 Standard. SQL Server is 2008R2 SP2
Code:
$path = "I:\SQLBackupsFromPROD"
$destination = "I:\SQLBackupsFromPROD\CaaS_Backups"
$shell_app= New-Object -com shell.application
$files = Get-ChildItem -Path $path -filter *.zip -recurse
foreach($file in $files) {
$zip_file = $shell_app.namespace($file.FullName)
$copyHere = $shell_app.namespace($destination)
$copyHere.Copyhere($zip_file.items())
}
It is set to run as the SQL Server Agent Account. I have logged into the server using that account and I can run the script successfully.
When I put it into a SQL Job Step and run it, it shows SUCCESS but no files are unzipped.
"Message
Executed as user: <Username>. The step did not generate any output. Process Exit Code 0. The step succeeded."
:crazy:
May 27, 2015 at 12:45 am
Have you tried writing anything to a log file? For example, a list of files selected?
Does the script work outside of SQL Agent?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 27, 2015 at 6:42 am
Have not tried the Log File trick. Did try capturing the Job Step output to a TXT file but it was blank.
I did log onto the box using the SQL Agent credentials and was able to run this script successfully in PS and SQLPS. Since the SQL Job is supposed to cal SQLPS.exe to run the script and the script does run when I call SQLPS manually I am at a complete loss as to why it will not run inside a job step.
Fred
May 27, 2015 at 8:23 am
You could try logging $env:username from the script file to be sure.
Also, are your paths absolute? What is the current directory? Find out using:(Resolve-Path .\).Path
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 28, 2015 at 8:09 am
Path checked out OK.
Revised the script somewhat:
$path = "\\Servername\SQLBackupsFromPROD"
$destination = "\\Servername\SQLBackupsFromPROD\CaaS_Backups"
$Extension = "*.zip"
$shell_app= New-Object -com shell.application
$Files = Get-Childitem $path -Include $Extension
#Format-List -InputObject $Files
foreach($file in $files) {
$zip_file = $shell_app.namespace($file.FullName)
$copyHere = $shell_app.namespace($destination)
$copyHere.Copyhere($zip_file.items())
}
Now I get this error in SQLPS:
Get-ChildItem : Invalid Path: '\\ATXSQL50DV'.
At line:1 char:23
+ $Files = Get-Childitem <<<< $path -Include $Extension
+ CategoryInfo : NotSpecified: (:) [Get-ChildItem], ArgumentException
+ FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.GetChildItemCommand
But the script runs fine in powershell.
May 28, 2015 at 8:20 am
I believe that SQLPS is defaulting to a different provider than the PowerShell command line so if you change the following line:
$path = "\\Servername\SQLBackupsFromPROD"
to this:
$path = "FileSystem::\\Servername\SQLBackupsFromPROD"
then you are explicitly specifying Get-Item to retrieve from the file system.
Let me know how you get on.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 28, 2015 at 12:10 pm
Your revised script worked GREAT in SQLPS. Pasted it in. Ran it. Unzipped the files to the correct folder.
HOWEVER,when I used the same script as a Job Step, it made like the Energizer Bunny and kept running and running and running. Even tried it as a CmdExec calling the ps1 file. Same thing.
Thank you for your help.
May 28, 2015 at 4:52 pm
Not sure why that would happen. I guess you need some diagnostic logging in there.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 28, 2015 at 6:27 pm
We had the same exact problem with something we were working on yesterday (same use case, same copyhere and movehere, same successful completion but nothing actually happening....).
After searching for an answer (and finding this post as the closest thing, but no answer), and trying a lot of things we solved it by:
1) In the agent job, create an "Operating system (CmdExec)" step.
2) In the "Command" put "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe c:\script_location\script_to_call_the_other_script.ps1". (or whatever the path is to powershell and the place where you store your scripts)
3) This calls a new script that has one line in it with the full path and name of the real script you want to run and any parameters you need to pass.
I don't know why it needs to wrapped in so many layers, but it works now. Tested and in production and happy customers!!!
DS
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply