search

PowerShell Fundamentals

2.1 The PowerShell CLI

For our first task, we should become familiar with the PowerShell Command Line Interface (CLI).

The PowerShell CLI provides us with access to built-in cmdlets, modules, functions, features, and provides a way to create tasks, functions, variables interactively, and more, directly from the CLI.

In most cases, accessing the CLI is as simple as just typing “powershell” in the Windows search field from the Start Menu. Alternatively, the shortcut to PowerShell can be found within the “%appdata%\Microsoft\Windows Start Menu\Programs\Windows PowerShell” directory

In this case, the shortcuts are unavailable; the PowerShell executable itself can found in the “C:\Windows\System32\WindowsPowerShell\v1.0” directory. If other versions are available on the system, they can be found in their corresponding version paths.

If you’re operating on a 64-bit system, the location of the 64-bit PowerShell executable can be found in C:\windows\system32\WindowsPowerShell. While the 32-bit version being located in the C:\windows\SysWOW64\WindowsPowerShell directory. This can be a bit confusing considering the directory naming convention.

Nonetheless, we can determine whether we’re running in a 32-bit or 64-bit PowerShell environment from the CLI with the following command: 

PS C:> [Environment]::Is64BitProcess

Which should return “True” if the current PowerShell process is 64-bit

On a 32-bit system, the executable will be in its usual location of: C:\Windows\System32\WindowsPowerShell*

When possible, we should try and launch PowerShell as the Administrator user as this will give us access to functions which we would be otherwise unable to access as a Lower-Privileged user. We can right-click on the Shortcut or Executable, and select “Run As Administrator.”

Although our examples are shown on Windows 10, all of the steps will be similar for Windows 7 and other versions of Windows, unless otherwise noted.

Like most other programs found on Windows, the PowerShell executable has its own set of command line options. We can view these options with the usual “/?” help parameter:

PS C:\Users\Offset> powershell /?

PowerShell[.exe] [-PSConsoleFile <file> | -Version <version>]
    [-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
    [-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
    [-WindowStyle <style>] [-EncodedCommand <Base64EncodedCommand>]
    [-ConfigurationName <string>]
    [-File <filePath> <args>] [-ExecutionPolicy <ExecutionPolicy>]
    [-Command { - | <script-block> [-args <arg-array>]
                  | <string> [<CommandParameters>] } ]

These options can alternatively be shown with the “-Help” parameter or “-?” as well and will be most useful when we’re calling PowerShell from a standard Windows command prompt. (cmd.exe)

The following are some of the more common PowerShell.exe command line parameters we will use for our purposes: The PowerShell execution policy determines which scripts if any, we can run and can easily be disabled with the “Bypass” or “Unrestricted” arguments.

The -WindowStyle parameter hides the Powershell window when used with the “hidden” argument.

The -Command parameter is used to specify a Command or Script Block to run.

The -EncodedCommand parameter is used to execute base64 encoded scripts or commands.

Don’t load any powershell profiles. Profiles are essentially scripts that run when the powershell executable is launched and can interfere with our operations.

We can use the -Version parameter followed by a version number as the argument to downgrade the version of PowerShell.

Furthermore, all of the PowerShell.exe command line parameters, as well as their arguments, can also be abbreviated, as long as the abbreviations are unique, and additionally, are not required to be case-sensitive either:

An extremely useful feature of the PowerShell CLI is the “Get-Help” cmdlet. Similar to *nix “Man Pages,” we can call upon the “Get-Help” command to obtain information related to any function, alias, module or cmdlet that PowerShell is aware of.

We can do this by including the cmdlet, function or module name we’re looking for information on, as an argument to the “GetHelp” cmdlet.

We can see here that we’re requesting the PowerShell Help pages for the “Get-Help” cmdlet itself:

To get “full” help for any cmdlet, which includes detailed information on associated parameters, we can use the - Full parameter:

And if we’d like to get examples on how to use a specific cmdlet, we can use the “-Examples” parameter.

Alternatively, if we want to get current Help pages from online for any of the cmdlets or Functions, we can simply supply the -Online parameter to our command line, and will launch a web browser to the corresponding help page:

If we’d like to update our locally installed help files for PowerShell via the CLI, we can do so with the “Update-Help” cmdlet:

More information on using the “Get-Help” cmdlet can be found here:

The “Get-Command” cmdlet is another very useful one. It allows us to list all cmdlets, aliases, functions, workflows, filters, scripts and any applications that are available for us to use in PowerShell.

Running the “Get-Command” cmdlet without arguments will simply list all commands, but, we can also use the -Name parameter to list any that are useful to us. For instance, we can list all functions related to modification of the Windows Firewall with the following command:

PreviousReferencesNextCmdlets

Last updated