Setting up a PowerShell profile

You can use a PowerShell profile to customize your shell environment and to load functions, modules, aliases, and variables into the environment when you start your Exchange Management Shell session. In this recipe, we'll take a look at how you can create a profile.

How to do it...

Profiles are not created by default, but you may want to verify one has not already been created.

1. Start off by running the Test-Path cmdlet:

    Test-Path $profile  

2. If the Test-Path cmdlet returns $true, then a profile has already been created for the current user. You can open an existing profile by invoking notepad.exe from the shell:

    notepad $profile  

3. If the Test-Path cmdlet returns $false, you can create a new profile for the current user by running the following command:

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

How it works...

A PowerShell profile is a just a script with a .ps1 extension that is run every time you start the shell. You can think of a profile as a logon script for your PowerShell or Exchange Management Shell session. Inside your profile you can add custom aliases, define variables, load modules, or add your own functions so that they will be available every time you start the shell. In the previous example, we used the automatic shell $profile variable to create a profile script for the current user, which, in this case, would create the profile in the $env:UserProfile\Documents\WindowsPowerShell\directory.

Since PowerShell is simply executing a .ps1 script to load your profile, your execution policy must allow the execution of scripts on your machine. If it does not, your profile will not be loaded when starting the shell and you'll receive an error.

There are four types of profiles that can be used with PowerShell:

• $Profile.AllUsersAllHosts: This profile applies to all users and all shells and is located in $env:Windir\system32\WindowsPowerShell\v1.0\profile.ps1
• $Profile.AllUsersCurrentHost: This profile applies to all users but only the PowerShell.exe host and is located in $env:Windir\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
• $Profile.CurrentUserAllHosts: This profile applies to the current user and all shells and is located in $env:UserProfile\Documents\WindowsPowerShell\profile.ps1
• $Profile.CurrentUserCurrentHost: This profile applies to the current user and only to the PowerShell.exe host and is located in $env:UserProfile\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

Using the $profile variable alone to create the profile will default to the CurrentUserCurrentHost location and is probably the most commonly-used profile type. If you need to create a profile for all the users on a machine, use one of the AllUsers profile types.

You may be wondering at this point what the difference is between the Current Host and All Hosts profile types. The PowerShell runtime can be hosted within third-party applications, so the All Hosts profile types apply to those instances of PowerShell. The Current Host profile types can be used with PowerShell.exe and when you are running the Exchange Management Shell.

In addition to defining custom aliases or functions in a profile, you may want to consider loading any other modules that may be useful. For example, you may want to load the Active Directory module for PowerShell so that those cmdlets are also available to you whenever you start the shell.

When you're done making changes to your profile, save and close the file. In order for the changes to take effect, you can either restart the shell, or you can dot-source the script to reload the profile:

    .$profile  

You can create multiple .ps1 scripts that include aliases, functions, and variables and then dot-source these scripts within your profile to have them loaded every time you start your PowerShell session.

To give an applicable example would be to use Import-Module inside the profile script to import PowerShell modules immediately when launching Windows PowerShell or Exchange Management Shell. Functions, modules, and other PS1 script files can also be loaded into the profile script.

You can reference the help system on this topic by running Get-Helpabout_profiles.

There's more...

Trying to remember all of the profile types and their associated script paths can be a little tough. There's actually a pretty neat trick that you can use with the $profile variable to view all of the profile types and file paths in the shell. To do this, access the psextended property of the $profile object:

    $profile.psextended | Format-List  

This will give you a list of each profile type and the path of the .ps1 script that should be used to create the profile.

See also

• The Command aliases recipe in this chapter
• The Working with variables and objects recipe in this chapter