Background / Goal

I am attempting to create a scheduled task that will:

  • Run at the specified time (once)
  • Run a PowerShell script that:
    • Logs all of its output as a transcript
    • Connects to my vCenter server using encrypted, stored credentials
    • Shuts down the Guest OSes of all VMs in a certain folder


The script executes perfectly from the console but doesn't even begin to execute as a task.

The Code

#Stop an error from occurring when a transcript is already stopped
Stop-Transcript | out-null

#Reset the error level before starting the transcript
Start-Transcript -path C:\temp\Shutdown_NonProductionVMs.log -append

#Add the VMWare Snap-in
Add-PSSnapin -Name VMWare.VimAutomation.Core

#Get the Credentials
$creds = Get-VICredentialStoreItem -file  C:\temp\pscreds.creds

#Connect to the server using the credentials file
Connect-VIServer -Server $creds.host -User $creds.User -Password $creds.Password

#Get all VMs within the non-production VMs folder and then shut them down
#NOTE the -WhatIf tag, which will stop it from shutting down the VMs until we're sure the script is good.

Get-Folder -Name "03. Non-Production VMs" | Get-VM | Shutdown-VMGuest -WhatIf

#Clean Up
Disconnect-VIServer -Force -Confirm:$false
Remove-PSSnapin -Name VMWare.VimAutomation.Core

What I've Checked/Tried so far and Other Leads

  • Again, this script runs perfectly fine in a console when the console is opened as an admin.
  • I have set a machinelevel execution policy of "Unrestricted" to see if that would help.
  • I am running the task as the same user I created the credentials file with
  • I am running the task with highest privileges.
  • I am running the task with stored credentials (my user credentials -- the same ones that work from the console).
  • I tried commenting out the transcript-related code to see if that did it; no dice.
  • The task just continues to run perpetually. I don't get any result and it doesn't terminate.

Any ideas? Thanks in advance for any help you can give!


If you launch Powershell in an interactive "console" session, you will most likely be launching the 64-bit version of Powershell. (The executable will reside in Windows\System32.) You can also launch 32-bit Powershell from 64-bit Windows by executing the version that resides in Windows\SysWOW64. Make sure you know which version Task Scheduler is launching.

Keep in mind that each version of Powershell has a completely separate Execution-Policy. So you need to set the execution policy twice to cover both 32 bit and 64 bit versions of Powershell.

The snap-in you're attempting to load can also be critical. Some snap ins and COM objects can only be loaded in either a 32 bit or 64 bit environment. However, I just tested on a Server 2008 R2 server with PowerCLI installed and had no problems loading the snapin you referenced in both environments. So I don't think that's the issue here. But it's still something to consider. It might depend on that version of PowerCLI that you installed. Make sure that snapin loads from both 32 and 64 bit PS shells.

Finally, can you tell us exactly what the Action screen in your scheduled task says? What exact command line (w/ arguments) you're running? You might get more debug information if you run something like cmd /c powershell.exe c:\yourscript.ps1 2>&1> C:\debug.txt

It might also help to give us the output of Get-ExecutionPolicy -List from both 32 and 64-bit environments.

Also in your post you mention:

The task just continues to run perpetually. I don't get any result and it doesn't terminate.

That usually indicates it's waiting on user input.

Edit: Typos, typos eveyrwhere

  • I believe this highlights the issue indeed. I was attempting to call the script directly from the .ps1 extension, which this answer helped reveal as a bad idea. Calling powershell.exe from cmd with the files worked perfectly. Thank you! – SeanKilleen Jan 28 '13 at 15:45
  • 1
    Ah, cool. You don't have to run Powershell from cmd, but it will work. But as you have realized, file associations don't work from Scheduled Tasks like they do from an interactive user session either. Now that you know what the issue was, you should be able to get rid of cmd.exe in the scheduled task and just use Powershell.exe. – Ryan Ries Jan 28 '13 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.