Windows PowerShell: PowerShell.exe
As with many other Windows PowerShell functions, there’s more than one way to open it in the first place.
Most of the time, you’ll want to open Windows PowerShell using the Start menu shortcut. However, there are also times when you’ll want to programmatically start a new shell session. This is the way to go when you’re scheduling a script, or having a script run as part of an external batch file.
In those and many other circumstances, the key to accomplishing what you need will be the PowerShell.exe executable. You’ll find this in the Windows PowerShell installation folder.
PowerShell.exe starts a new console shell session, but it can do so much more. The command comes fully equipped with a bevy of command-line parameters that tell it exactly how to behave. Run PowerShell -? from the command line for a full list, or read on for the highlights.
Run the Command
The –command parameter accepts a single Windows PowerShell command, along with any parameters that command requires. Enclose the entire command string in quotes if it contains any spaces or parameters. You can also include a complete pipeline of multiple cmdlets, if needed.
You could also use the –file parameter. This accepts the path and filename of a .PS1 file. Windows PowerShell will then execute that file’s contents. This is a much easier way to run a complex series of commands than trying to jam them all into the –command parameter. Keep in mind that the shell’s Execution Policy affects script execution, which brings us to the next point.
The –executionpolicyparameters accepts one of the Windows PowerShell Execution Policy settings: Unrestricted, AllSigned, RemoteSigned and Restricted. Whatever you specify will take effect for that shell session only, and will override any policy previously set locally with Set-ExecutionPolicy or by a Group Policy Object (GPO).
Wait, isn’t this a security issue? Shouldn’t a GPO be incapable of being overridden? No and no. The Execution Policy isn’t a firewall, and it isn’t anti-malware software. It’s designed to keep uninformed users from unintentionally executing an untrusted script. If you’re specifying the –executionpolicy parameter, by definition, you’re doing so intentionally. You therefore accept the consequences of that action.
Normally, whatever runs in the Windows PowerShell session will be output by PowerShell.exe as text. If all you want to do is capture that to a text file, that’s probably good enough.
However, alternatively you can specify –outputformat XML to have PowerShell.exe capture the objects output by the shell script or command. You can then serialize those objects into a CliXML file. This is essentially the same as if you had the shell pipe objects to Export-CliXML. It gives you an output format that you can more easily re-import into another shell session.
There are three other command-line parameters you’ll want to know about:
- -noProfile prevents Windows PowerShell from loading any profile scripts as it executes. If you know you won’t need whatever’s in the local profile scripts, not loading them can save a little time. This is also a useful trick if you have a profile that’s causing problems. You can open the shell without it and start troubleshooting.
- -noExit tells the shell to execute whatever was specified by –command or –file, but to keep the shell open afterward. Normally, using one of those two parameters closes the shell when it’s done, which is what you’ll usually want. Using –noExit lets you continue working with the shell. This is useful for debugging and checking the results of whatever you just ran.
- -nonInteractive tells the shell to run, but not give the user an interactive prompt. You’ll often use this in conjunction with –command or –file.
Using PowerShell.exe gives you a variety of options for executing scripts, controlling output and so on. Whether you’re using it to schedule scripts, run logon scripts, run commands as part of a larger batch or some other purpose, it’s a good trick to have up your sleeve.