Sometimes i just can't understand why it throws errors at me.
I found a nice article about this over at Dmitry's blog.
1. Get your script ready
Surprising as it might sound, your script might actually not be ready to run in a scheduled task as is. This happens if it uses cmdlets from a particular PowerShell module or snapin, and it worked for you interactively because you used a specialized shell (e.g. Exchange Management Shell) or a tool like PowerGUI Script Editor which loads the modules for you.
If you indeed are using using any non-default cmdlets, simply add Add-PSSnapin or Import-Module to the beginning of the script. For example:
Surprising as it might sound, your script might actually not be ready to run in a scheduled task as is. This happens if it uses cmdlets from a particular PowerShell module or snapin, and it worked for you interactively because you used a specialized shell (e.g. Exchange Management Shell) or a tool like PowerGUI Script Editor which loads the modules for you.
If you indeed are using using any non-default cmdlets, simply add Add-PSSnapin or Import-Module to the beginning of the script. For example:
Add-PSSnapin Quest.ActiveRoles.ADManagement
2. Schedule the task
To schedule a task simply start Windows Task Scheduler and schedulepowershell.exe executable passing the script execution command as a parameter. The
-File
parameter is the default one so simply specifying the script path as the argument would work in a lot of cases:
You can find powershell.exe in your system32\WindowsPowerShell\v1.0 folder.
4. Report task success or failure
If you want your script to report success or failure (or some sort of other numerical result) simply use the exit keyword in the script to pass the value, e.g.:
exit 4
Then your Windows Task Scheduler will show the value in the Last Run Result (you might need to hit F5 to refresh the column in the task scheduler):
3. Passing parameters
If you need to pass parameters things get a little trickier. Say, you have a script which adds two numbers:
param($a=2, $b=2)
"Advanced calculations ahead"
exit $a + $b
To pass the numbers as parameters, you would want to use
powershell.exe -Command
instead of powershell.exe -File
. This -Command
argument will then have the script invocation operator &
, path to the script, and the parameters. E.g.:
Program:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add argument (optional): -Command "& c:\scripts\hello.ps1 -a 2 -b 3"
If you want to also get your exit code from the script, you would need to re-transmit that by adding
exit $LASTEXITCODE
to the command (I learnt this tip from MoW). E.g.
Program:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add argument (optional): -Command "& c:\scripts\hello.ps1 -a 2 -b 3; exit $LASTEXITCODE"
5. Run x86 PowerShell on x64 Windows
On 64-bit versions of Windows you actually have both 64-bit and 32-bit versions of PowerShell. In most cases you don’t care but in some cases (e.g. specific COM objects being used) you might need specifically a 32-bit version. To get that to run, simply pick the proper executable when you schedule the task:
Regular PowerShell (64-bit version on 64-bit Windows):
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
32-bit PowerShell (x86):
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe
6. Other options
To learn about all parameters PowerShell executable has simply run it with /? option (from either cmd.exe or a PowerShell session).
I normally use -noprofile to make sure that nothing in the PowerShell profile interferes with the task.
Also, if your Execution Policy does not allow running scripts the -ExecutionPolicy parameter comes handy allowing you to make an exception just for this task. E.g.:
c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -File c:\scripts\hello.ps1 -ExecutionPolicy RemoteSigned
Here are some other parameters provided by PowerShell:
-PSConsoleFile
Loads the specified Windows PowerShell console file. To create a console
file, use Export-Console in Windows PowerShell.
I guess you could use that is you want the exact environment you have in the predefined shell from Exchange, AD, or SQL. E.g.:
PowerShell -PSConsoleFile SqlSnapIn.Psc1
-Version
Starts the specified version of Windows PowerShell.
I don’t think this one actually works.
-NoLogo
Hides the copyright banner at startup.
Not really relevant for scheduled tasks, imho…
-NoExit
Does not exit after running startup commands.
Might be useful for troubleshooting.
-Sta
Start the shell using a single-threaded apartment.
If your script needs STA mode (if you don’t know what this is – most likely you don’t need this. ;))
-NonInteractive
Does not present an interactive prompt to the user.
Not really relevant for scheduled tasks, imho…
-InputFormat
Describes the format of data sent to Windows PowerShell. Valid values are
"Text" (text strings) or "XML" (serialized CLIXML format).
-OutputFormat
Determines how output from Windows PowerShell is formatted. Valid values
are "Text" (text strings) or "XML" (serialized CLIXML format).
Not sure how I would use those… Here’s one example of how
-InputFormat none
can help fix issues with PowerShell becoming unresponsive when waiting for input.-WindowStyle
Sets the window style to Normal, Minimized, Maximized or Hidden.
Unfortunately, I could not make this work. I tried to use
-WindowStyle Hidden
to avoid the PowerShell console window popping up during task execution but with no luck.-EncodedCommand
Accepts a base-64-encoded string version of a command. Use this parameter
to submit commands to Windows PowerShell that require complex quotation
marks or curly braces.
# To use the -EncodedCommand parameter:
$command = 'dir "c:\program files" '
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encodedCommand = [Convert]::ToBase64String($bytes)
powershell.exe -encodedCommand $encodedCommand
Can be useful when having to pass advanced expressions and getting issues with parser.
No comments:
Post a Comment