Save Your PowerShell Code in Profile and Script Files

After you set the execution policy, close and reopen PowerShell to start a new session in order for the profile to be loaded and the code to take effect. In the new session, you can access the variable and function as you would if you had created them at the console. For example, to access the $today variable, you enter the variable's name in the console like this

$today

Figure 3 shows the type of results you can expect from this command.

Figure 3: Accessing the $today variable and events function in the profile file

You can also call the events function, which requires an event log name as an input parameter, as in

events "windows powershell"

PowerShell calls the function, passes in the parameter value, and returns the results, as shown in Figure 3. As you can see, profiles provide a useful way for storing code. To learn more about profile files, see the "Getting Started" guide that's included with the PowerShell installation.

When you add code to a profile file, PowerShell runs that code whenever you open the console. Although this might be useful for functions and variables, it's not very useful for code whose execution you want to control. For example, you might want to run a script that retrieves data about services running on multiple computers on the network, but you wouldn't want this script to run each time PowerShell starts. In such cases, you can save the code in a script file, then run that file from the PowerShell console when necessary.

As I mentioned previously, script files are text files with a .ps1 extension. To create a script file, you need to create a new text file in Notepad, add the code you want to run, and save the file with the .ps1 extension. For example, you might add code such as

# Retrieve running services.
Get-Service |
  where {$_.Status -eq 'running'} |
  sort -property DisplayName

to a file in Notepad and save it as Services.ps1 in the C:\PSscripts folder. Services.ps1 retrieves a list of running services and sorts them by their display names.

Before you run Services.ps1 (or any other script file) for the first time, you should use the Get-ExecutionPolicy cmdlet to make sure that PowerShell's execution policy allows you to run a script file. Once confirmed, you can call Services.ps1 by entering its entire pathname, as in

C:\PSscripts\Services.ps1

That's all there is to it. The script file will run and return results like those shown in Figure 4.

Figure 4: Running a script file

Note that you can also call a script file by dragging it from Windows Explorer to the PowerShell console. After you drag the script file to the console, press Enter to run it. Another way to run it is to change the current working directory to the directory where the script file is located with a command such as

Set-Location C:\PSscripts

then run the script file with statement

.\Services.ps1

The period before the backslash tells PowerShell to use the current working directory.

Like functions, script files can have input parameters. Input parameters let you pass values to a script file when you call it. To add input parameters, you must add a param statement to your script file. For example, to narrow the list of services that Services.ps1 retrieves, you can add a param statement to the script file, as in

# Retrieve running services.
param ($service="*windows*")
Get-Service -DisplayName $service |
where {$_.Status -eq 'running'} |
sort -property DisplayName

As the second line shows, a param statement begins with the param keyword, followed by one or more parameters in parentheses. (You should separate multiple parameters with commas.) You can also define your input parameters with default values, as I've done here. PowerShell allows wildcards in parameter values.

Now if you want to call Services.ps1, you enter its full pathname and the desired parameter value, with a space between them, as in

C:\PSscripts\Services.ps1 *net*

Services.ps1 will now return any running services whose display name includes the string net, as shown in Figure 5. If you don't include an input parameter, the script file will return running services whose display name includes the string windows.

Figure 5: Providing an input parameter value when running a script file

Although the code in Services.ps1 is basic, you can create complex script files that perform a variety of actions. And by being able to pass in parameter values, you can create a single script file that you can use in multiple environments and under different circumstances.

Profile and script files let you easily store the various commands and logic you need to perform a wide range of administrative tasks. Both types of files are easy to implement and maintain, and they can contain code that's as simple or complex as you need it to be. The more you work with PowerShell, the more useful you'll find both types of files. However, as is the case with any tool, these files are only as useful as your knowledge of the underlying technology, so the better you understand PowerShell and its language, the more effectively you can take advantage of profile and script files as well as any of the other powerful features in PowerShell.