PowerShell Basics: Console Configuration

The Windows PowerShell console provides an easy-to-use environment for creating and running PowerShell commands as well as generating script files that you can run at a later time. The more you work in that environment, the more likely you'll want to customize the console to meet your individual development style. For example, you might want to expand the buffer size or change the font and background colors. To configure these and other types of settings, PowerShell provides several methods that are easy to use. You can set the console properties directly from the command window, run PowerShell commands that configure these settings, or add scripts to your PowerShell profile so that the settings are automatically applied at startup.

Note that it's also possible to modify the registry to configure the PowerShell console, but a full discussion of this approach is beyond the scope here. Keep in mind that modifying the registry is neither the most flexible nor the easiest method for customizing the PowerShell console. Furthermore, it needs to be approached with great care.

Configuring the PowerShell Console Properties

When you first launch PowerShell, the console's appearance is determined by the default property settings or by the settings defined within a shortcut and passed in as arguments to the PowerShell executable. For example, if you run PowerShell by double-clicking the powershell.exe file directly, it opens with the default property settings. The same goes for launching PowerShell from a shortcut you created for the executable or launching PowerShell from the Windows command prompt. In most cases, you'll see a small command shell window with a black background and gray font, as shown in Figure 1.

Launching the PowerShell Console from the Executable File

Figure 1: Launching the PowerShell Console from the Executable File

If you launch PowerShell from the Start menu, you get a somewhat different picture. In this case, the console window is larger with a blue background and gray font, as shown in Figure 2. It's different because the PowerShell installation process sets up the Start menu shortcuts with the configuration settings necessary to modify the console environment.

Launching the PowerShell Console from the Start Menu

Figure 2: Launching the PowerShell Console from the Start Menu

Regardless of how you launch PowerShell, you can modify the console's appearance through its property settings. To access those settings, click the PowerShell icon in the top-left corner of the console window and click Properties to open the Properties dialog box.

The Properties dialog box includes four tabs—Options, Font, Layout, and Colors—each of which contain configuration settings that you can modify as necessary. Figure 3 shows the Options tab. Here you can configure settings related to cursor size and command history. You also have two important editing options: QuickEdit Mode and Insert Mode. The QuickEdit Mode option lets you use your mouse to copy and paste commands in the PowerShell console. The Insert Mode option inserts new text into a line rather than overwriting it.

Configuring PowerShell Options in the Console's Properties

Figure 3: Configuring PowerShell Options in the Console's Properties

Figure 4 shows the Font tab, which includes options specific to the font used in the PowerShell console. Although these options are somewhat limited, you do have a few choices for size and style.

Configuring Font Settings in the Console's Properties

Figure 4: Configuring Font Settings in the Console's Properties

The Layout tab lets you choose the buffer size, window size, and window position, as shown in Figure 5. The buffer size determines the width (number of characters) and height (number of lines) in your buffer. Your buffer size can be the same size or larger than your window size, but it can't be smaller. Many administrators find it handy to increase the buffer size, particularly the height. That way, they can preserve many more commands during a session and refer to them as needed by simply scrolling up or down. The window size determines the width and height of the actual console window. Again, this can't be larger than the buffer size. The window position determines where the console should be placed on your desktop, based on the top-left corner—or you can let the system position the window for you.

Configuring Layout Settings in the Console's Properties

Figure 5: Configuring Layout Settings in the Console's Properties

Figure 6 shows the Colors tab, where you can choose your text and background colors. The easiest way to choose a color is to select a category option (e.g., Screen Text), then click a color in the color bar. If you know the specific Red Green Blue (RGB) value associated with a color, you can enter those numbers, but be aware that this will affect other items that share the same base color, resulting in some rather bizarre effects. Luckily, you can view your changes in the preview windows to see what impact your changes are having on the console.

Configuring Color Settings in the Console's Properties

Figure 6: Configuring Color Settings in the Console's Properties

After you've configured the different properties, click OK to close the Properties dialog box. Your changes will be applied immediately. Figure 7 shows what the PowerShell console looks like if you enlarge it, change the background to white, and change the text to black.

Examining a Reconfigured PowerShell Console

Figure 7: Examining a Reconfigured PowerShell Console

Your changes will be preserved as long as you restart PowerShell from the same location from which you originally launched it. For example, if you launch PowerShell from the Start menu, change the property settings, and relaunch PowerShell from the Start menu, your changes will be preserved. However, if you then launch PowerShell from a shortcut you created for the executable, your changes won't be reflected. To make your changes persist regardless of how you launch PowerShell, you have to take other steps, the first of which is to learn how to script your configuration settings.

Scripting the Console Configuration

PowerShell is first and foremost a scripting environment. Although PowerShell is often referred to as an interactive management console, you're still primarily writing and running scripts, even if they do interact with other systems. With PowerShell, you can script just about anything, including settings that affect the PowerShell console. Being able to control your settings through scripts provides an easy way to apply the same settings to multiple instances of the PowerShell console, whether they're on the same computer or different computers. You can save your settings in a script file and run it whenever you want the settings applied to your workspace. Or better still, you can save your settings in a profile file (which is covered in the next section) so that the settings are applied whenever you open PowerShell, no matter whether you open it by clicking the executable, a shortcut for the executable, or a shortcut on the Start menu. Scripting also lets you to access settings not available through the console's properties, such as the colors used for warning messages.

To script your PowerShell settings, it helps to have a basic understanding of how objects are handled in PowerShell. Objects form the basis for much of the scripting you do in PowerShell, even if it's not obvious that's what you're doing. Objects provide a structure for representing data within PowerShell. The structure is made up of properties, methods, and other members that you can access during your PowerShell session.

For example, when you run the Get-Host cmdlet, PowerShell returns an object that provides details about the PowerShell environment, such as the name, version, and information related to the shell's configuration. One of the members of the Get-Host object is the UI property, which is a special type of property associated with its own object, derived from a Microsoft .NET Framework class. The UI object, in turn, includes the RawUI property, which provides access to the specific console properties.

When working with objects in PowerShell, it's often best to assign them to a variable so you can easily access the object's members. As it turns out, PowerShell provides a built-in variable—$host—for accessing the Get-Host object. That means you can use the $host variable to access the UI and RawUI properties.

The RawUI property is a special type of property that's associated with its own object, just like the UI property. You access the console's properties through the RawUI object. Let's look at an example to help make sense of how all this works. The following command creates a variable named $console and assigns an instance of the RawUI object to that variable:

$console = $host.UI.RawUI

Notice that the RawUI object is accessed by first specifying the $host variable, then specifying the UI property, followed by specifying the RawUI property. By assigning the $host.UI.RawUI command to the $console variable, the variable is created as a RawUI object type, which gives you access to the console's properties so that you can configure them.

For example, the following commands set the ForegroundColor property (i.e., the text) and BackgroundColor property of the RawUI object:

$console.ForegroundColor = "black"$console.BackgroundColor = "white"

As you can see, you need to specify only the $console variable, followed by the property name. You then follow this with an equals sign (=) and the new color, enclosed in double quotes. In this case, the foreground color is being set to black and the background color is being set to white.

If you ran these commands, you probably noticed that the changes were immediately applied to the console, leaving you with a rather odd-looking window because only the most recent lines reflect the changes to the background and foreground colors. The easiest way to make your screen presentable is to run the following command to clear the screen and start with a clean prompt:

Clear-Host

Now let's look at another RawUI property: BufferSize. As the name suggests, this property lets you set the buffer's width and height. However, this is another one of those special properties associated with its own object, so the best strategy is to define a variable to hold the object. You can then access the properties from that variable, as shown in this example:

$buffer = $console.BufferSize$buffer.Width = 130$buffer.Height = 2000$console.BufferSize = $buffer

First, you create the $buffer variable to hold the BufferSize object. Then, you use that variable to set the Width and Height properties, similar to the way in which the foreground and background colors were set previously. However, you must take an additional step, which is to assign the settings in the $buffer variable to the actual BufferSize property of the RawUI object.

The same holds true if you want to set the size of the window itself, as shown in this script:

$size = $console.WindowSize$size.Width = 130$size.Height = 50$console.WindowSize = $size

In this case, you first create a variable named $size to hold the object associated with the WindowSize property. You then set the Width and Height properties, just as you did for the BufferSize object. Finally, you assign the $size variable to the WindowSize property of the RawUI object. Note that when setting the window size, it can't be larger than the buffer (as mentioned earlier) and it can't be larger than what your system will support. If you receive an error that the window width or height can't be more than a specified size, adjust your code accordingly.

As handy as the RawUI object is, it doesn't contain all the properties that you can set. The Get-Host object also supports the PrivateData property, which itself is associated with an object. The PrivateData object includes a number of properties specific to the font and background colors used for console responses such as error and warning messages.

To simplify calling these properties, you can assign the PrivateData property to a variable, then call that variable, as seen in this script:

$colors = $host.PrivateData$colors.VerboseForegroundColor = "white"$colors.VerboseBackgroundColor = "blue"$colors.WarningForegroundColor = "yellow"$colors.WarningBackgroundColor = "darkgreen"$colors.ErrorForegroundColor = "white"$colors.ErrorBackgroundColor = "red"

First, you create a variable named $colors to hold the PrivateData object. Then, you use the variable to access several of the object's properties in order to set their colors. This is basically the same approach used to set the ForegroundColor and BackgroundColor properties of the RawUI object. You define simple assignments, without having to assign the $colors variable back to the PrivateData property, as you did with BufferSize and WindowSize.

After you've defined all your properties, run the Clear-Host cmdlet again:

Clear-Host

Your screen should now look similar to what you see in Figure 7. Now let's test the new format by running a few commands. The following commands generate several types of messages that should be displayed in the colors you configured previously:

Write-Output "This is a test message."Write-Verbose "This is a verbose message." -VerboseWrite-Warning "This is a warning message."Write-Error "This is an error message."

For the most part, the cmdlets used in these commands are self-explanatory. The Write-Output cmdlet generates a regular message in the default background color and font. The other three cmdlets generate the types of messages reflected in their names. Figure 8 shows what your console should look like after you generate these test messages.

Testing the Fonts in the PowerShell Console

Figure 8: Testing the Fonts in the PowerShell Console

Notice that the first message uses a white background with black text, but the other messages reflect the colors that you assigned to the properties associated with the PrivateData object.

Adding the Console Configuration Script to Your Profile

Being able to script your console settings makes it easy to apply those settings whenever you need them. You can save them to a script file and call that file when necessary. Or you can cut and paste the script into the console and run the commands that way. In either case, you must access your script file whenever you want to apply the configuration settings to the console. A better approach is to save the script to one of the PowerShell profile files.

PowerShell supports four types of profile files and executes them in a specific order upon startup. However, a full discussion of PowerShell profiles is beyond the scope here. So, let's just set up the profile file that applies to the current user.

To find where the file should be located, you can use the built-in variable $profile to return the path and filename used for the file. To do so, simply run the command:

$profile

The variable will return a fully qualified filename, such as C:UsersAdministratorDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1. However, just because the $profile variable points to this file, it doesn't mean the file exists. Therefore, the next step is to run the command:

Test-Path $profile

The Test-Path cmdlet checks for the existence of the file. If it exists, the command returns True; otherwise, it returns False. If the command returns False, you should run the following command to create the file before you do anything else:

New-Item -path $profile -type file -force

The New-Item cmdlet creates the file based on the argument passed in with the -path parameter, which in this case is the $profile variable. The -type parameter indicates that the item being created is a file (as specified by the "file" keyword) rather than another type of item. The -force parameter tells the cmdlet to create the file, no matter how Windows might balk.

After you've created your file, you can rerun the Test-Path command to ensure that it returns True. Once you know that the file is in place, you can easily edit it by running the command:

notepad $profile

This command opens the blank profile file in Notepad. You can then add whatever configuration script you want to include. If you add the configuration code previously discussed, the file will look similar to the one shown in Figure 9.

Editing the Profile File in Notepad

Figure 9: Editing the Profile File in Notepad

(Note that you can download this configuration code by clicking the Download the Code button.) However, notice that the script in the figure also includes the command:

Set-Location C:

This command merely tells PowerShell to set the startup folder to C: whenever the settings are applied. You can specify whatever folder you want. You can also specify the startup folder in a shortcut or within a PowerShell session. However, adding it to your profile file helps keep all configuration settings in one location. Note that you can also include additional commands in your profile file, such as defining variables that you might want to use in each session.

After you're satisfied that the profile file contains everything it needs, you simply save it and close Notepad. You must then relaunch PowerShell for the settings to be applied. However, you can relaunch PowerShell from any location. The same profile file will be applied in each case. In fact, it's even possible to save your profile file to a different location, such as a jump drive or network share, so that you can apply your settings to other instances of PowerShell, regardless of which computer you're working on. This approach also lets you share a common profile file among a team of users. Be sure to check the PowerShell documentation for more information about working with profile files.

If you haven't set up PowerShell to run script files (which includes profile files), you might receive an error the first time you relaunch PowerShell. Figure 10 shows what the error looks like. Basically, it's telling you that your execution policies have not been properly configured to support script files.

Receiving an Execution Error in PowerShell

Figure 10: Receiving an Execution Error in PowerShell

To permit scripts to run on your local system, run the command:

Set-ExecutionPolicy RemoteSigned

This command lets you run local scripts or remote scripts that have been digitally signed by a trusted publisher. Keep in mind, however, that the execution policy controls what scripts can and can't be run on your system. An incorrect setting could jeopardize your system's security. Be sure to carefully read the information about execution policies in PowerShell's documentation before making any changes to your system.

Console Customization

PowerShell provides a fair amount of flexibility when setting up your console. You can set the console's properties, run scripts that configure those settings, or modify your profile file to apply the settings whenever you launch PowerShell. Clearly, adding the necessary configuration script to your profile file will provide you with the most flexibility and least maintenance over the long haul. The profile file will persist your script, so you don't have to reapply your settings each time you start PowerShell. This approach also provides more options than the console's properties, and you don't have to be concerned about whether you start PowerShell from the Start menu or another location. Given the powerful scripting environment that PowerShell provides, there's no reason you shouldn't make the console itself as useful and comfortable as possible.