Customize PowerShell with default parameters and save time

If you do a lot of PowerShell-based management, you will likely find that there are certain cmdlet parameters that you use over and over again. A few examples of this might include the name of a VM that you regularly manage, a set of administrative credentials, the name of your SMTP mail server, or even the name of a process or service that you check frequently. If there are parameters that you find yourself typing more often than you would like, you can configure PowerShell to treat those parameters as default values. In this article, I will show you how it works.

For this article, I am going to pretend that for whatever reason I constantly find myself checking to see if the Windows Defender Service (WinDefend) is running. As a way of reducing the typing that is required, I am going to set the Windows Defender Service to be the service that is displayed by default when I use the Get-Service cmdlet.

Default value works for almost every cmdlet

Before I show you how this works, there are two things that I need to point out. First, you aren’t limited to working with the Get-Service cmdlet. You can set a default value for almost any PowerShell cmdlet that accepts parameters. I just picked the Get-Service cmdlet because it makes for a relatively simple example.

The second thing that I want to mention is that when you set a default value, that default value is stored in a hash table. This hash table can accommodate default values for any number of cmdlet parameters. In other words, you can use the technique that I am about to show you to set default parameters for as many cmdlets as you want.

So, let’s go ahead and get started. Normally, if you type the Get-Service cmdlet, Windows displays a list of all of its system services. If you wanted to specifically examine the Windows Defender Service, you could do so by typing Get-Service WinDefend. The figure below shows a portion of the output that is generated by running the Get-Service cmdlet by itself, as well as what happens when you type Get-Service WinDefend.

One thing that is important to understand about the screen capture above is that even though it is very common to examine system services in this way, typing Get-Service followed by the service name does not fully adhere to the Get-Service cmdlet’s syntax. The Get-Service cmdlet supports a parameter called Name that accepts a service name as its input. When I type Get-Service WinDefend, PowerShell assumes that WinDefend is the name of a service and appends it to the -Name parameter. All of this is to say that the “proper” way to retrieve information about a system service is to use this command:

Get-Service -Name WinDefend

The reason why I am telling you this is because as previously noted, custom default parameters are stored in a hash table. Hash tables are made up of key/value pairs. The key is the cmdlet name and the parameter name, and the value is the parameter value. As such, you need to know the name of the parameter that you are supplying the default value for. In this example, the parameter is Name, even though PowerShell doesn’t require you to explicitly specify the Name parameter when entering a service name.

Creating a default parameter

Let’s go ahead and create a default parameter. Here is the command that is used to do so:

$PSDefaultParameterValues = @{ "Get-Service:Name"="WinDefend"}

As you can see, the key, in this case, is the command name (Get-Service), a colon, and the parameter name (Name). The value is the default value that you want to assign to the parameter.

Now when I type the Get-Service cmdlet, Windows displays the Windows Defender service but does not show me the other system services. You can see what this looks like in the screenshot below.

This, of course, raises the question of what happens if you need to check a different service. You can still do that. All you have to do is specify the service name, just as you would have done before the introduction of default parameters. Similarly, if you want to see all of the system services, then just append an asterisk to the end of the Get-Service cmdlet (Get-Service *).

Another thing that you may be wondering is whether or not the default parameters are persistent. Unfortunately, the default parameters list is purged whenever you reboot the system. On one hand, this is nice because it means that you can easily create temporary default parameters. If you happen to be doing maintenance on one particular server, for example, you might create some temporary defaults that are specific to the server that you are working on.

If you would rather make your default parameters more permanent, then the easiest thing to do is to create a script that sets up all of your default parameters. You can include multiple default parameters within a script, but you will need to separate each parameter with a semicolon. Here is an example provided by Microsoft:

$PSDefaultParameterValues = @{
"Send-MailMessage:SmtpServer"="Server123";
"Get-WinEvent:LogName"="Microsoft-Windows-PrintService/Operational"
}

This script sets up two default parameters, one for the Send-MailMessage cmdlet and another for the Get-WinEvent cmdlet. The script is written in such a way that each default parameter is on its own line, but this is done for the sake of clarity rather than being an actual requirement. The important thing is that all of the default parameters be included in brackets {} and that a semicolon is placed between each parameter. In this example, the semicolon appears just after “Server123.” If a third parameter were added to the script, then a semicolon would need to be added after “Microsoft-Windows-PrintService/Operational.”

Default parameters for PowerShell: A real time-saver

As you can see, Microsoft makes it simple to set up default parameters for PowerShell. Although using default parameters can take a bit of getting used to, these parameters can save you a lot of time in the long run.

Featured image: Shutterstock