Scheduling a powershell script to work in a directory

I'm a little embarrassed to ask this. It seems like such a simple thing. And from all the examples I've found and tried, this should be working, but apparently I'm missing something.

I have a very simple powershell script:

[IO.Directory]::SetCurrentDirectory("C:\Program Files (x86)\MyFolder")
cp .\simpleTestScript.ps1 .\sucess.ps1

I've run, as admin: Set-ExecutionPolicy remoteSigned -scope localMachine. And I'm scheduling the script as administrator, so there shouldn't be permission issues. I discovered that "cd" didn't quite work as expected in powershell, but SetCurrentDirectory is a good stand in. But maybe it's still a working directory issue. I can run it from a batch file with this line:

powershell.exe -File "C:\Program Files (x86)\MyFolder\simpleTestScript.ps1"

And it runs to completion, copies the file, and life is good.

But

Scheduling that same command (in Win7's task scheduler) "completes successfully", but no file is copied.

No change when I put C:\Program Files (x86)\MyFolder\ in the "start in:" field.

So what am I missing here?

Edit, some other things I've tried

$scriptDir =  Split-Path $myInvocation.MyCommand.Path
cp $scriptDir\simpleTestScript.ps1 $scriptDir\sucess.ps1

Same behavior

$scriptDir = "C:\Program Files (x86)\MyFolder"
cp $scriptDir\simpleTestScript.ps1 $scriptDir\sucess.ps1

Same behavior

[IO.Directory]::SetCurrentDirectory((Convert-Path (Get-Location -PSProvider FileSystem)))
cp .\simpleTestScript.ps1 .\sucess.ps1

Same behavior. Running as a batch file, it works. But scheduled, it doesn't copy the file.

I've also tried scheduling the batch file which calls the powershell script, which is just plain silly and also doesn't work.

Edit, part Duex

Oh yeah, this would probably help. This is on windows server 2008 R2. Powershell 2.0

Edit hmmmmm, the advic开发者_如何转开发e out there, including manojlds, works fine when when applying it in windowsXP. So this is a Server 2008 issue.

Edit Finale So it turns out that it's a security issue. I'm running as admin to do this, but no, apparently when they changed the scheduler in Vista, they decided to add a "did you really mean to do this?" checkbox. So I'm sorry, StackOverflow and especially to you Manojlds, this turned out to be more of a super-user problem. But damn you Microsoft for adding a new feature that changed the behavior of an old tool. You could have had that checked by default and life would have been good.

All of my rage.

---

Use lines like below in your script to explicitly specify the directory:

$scriptDir =  Split-Path $myInvocation.MyCommand.Path
cp $scriptDir\simpleTestScript.ps1 $scriptDir\sucess.ps1

Also, see here about explanation on Current Directory: http://huddledmasses.org/powershell-power-user-tips-current-directory/

Update:

I tried out a task myself. When I was using the .\ variant I was able to see that it failed with following error:

Copy-Item : Cannot find path 'C:\Windows\system32\test2.ps1' because it does no
t exist.
At C:\Users\manojs\Desktop\git-python\test.ps1:5 char:3
+ cp <<<<  .\test2.ps1 .\test3.ps1
    + CategoryInfo          : ObjectNotFound: (C:\Windows\system32\test2.ps1:S
   tring) [Copy-Item], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyI
   temCommand

Clearly, it was looking at c:\windows\system32 for the file to be copied. But when I changed it to the $scriptdir\ form, it worked and I did see the file being copied.

To see why it is not doing the copy in your case, try adding -noexit argument in the task so that you can see if any error occurs.

---

Filling out an answer just so there isn't an unanswered question out there.

So it turns out that it's a security issue. I'm running as admin to do this, but no, apparently when they changed the scheduler in Vista, they decided to add a "did you really mean to do this?" checkbox. So I'm sorry, StackOverflow and especially to you Manojlds, this turned out to be more of a super-user problem. But damn you Microsoft for adding a new feature that changed the behavior of an old tool. You could have had that checked by default and life would have been good.