Profiles are not created by default, but you may want to verify one has not already been created. Start off by running the Test-Path cmdlet:

Test-Path $profile

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

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

A PowerShell profile is 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 $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:

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.

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

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.