Understanding and Using PowerShell Profiles

Summary: Microsoft Scripting Guy, Ed Wilson, talks about understanding and using Windows PowerShell profiles.

Microsoft Scripting Guy, Ed Wilson, is here. Today, I thought I would provide another excerpt from my new Microsoft Press book: Windows PowerShell 3.0 Step by Step, which is available for pre-order now. Today’s excerpt is from the chapter on Windows PowerShell profiles.

Six different PowerShell profiles

Windows PowerShell profiles are a bit confusing. There are, in fact, six different ones. Both the Windows PowerShell console and the Windows PowerShell ISE have their own profiles. In addition, there are profiles for the current user, as well as profiles for all users. Table 9-1 lists the six different profiles and their associated locations.

Table 9-1 The six different Windows PowerShell profile paths and use



Current User, Current Host - console

$Home\[My ]Documents\WindowsPowerShell\Profile.ps1

Current User, All Hosts   

$Home\[My ]Documents\Profile.ps1

All Users, Current Host - console   


All Users, All Hosts      


Current user, Current Host - ISE

$Home\[My ]Documents\WindowsPowerShell\Microsoft.P owerShellISE_profile.ps1

 All users, Current Host - ISE  


Understanding the six different Windows PowerShell profiles

The first thing to do in understanding the six different Windows PowerShell profiles is to keep in mind that they move, they change, as long as you realize they are a moving target, you will be fine. In most cases, when talking about the Windows PowerShell profile, people are referring to the current user, current host profile. In fact, if no one qualifies the Windows PowerShell profile with its associated scope or description, it is safe to assume that they are talking about the current user, current host profile.

Note   The Windows PowerShell profile (any one of the six) is simply a Windows PowerShell script. It has a special name, and it resides in a special place, but it is simply a script. In this regard, it is sort of like the old-fashioned autoexec.bat batch file. Because the Windows PowerShell profile is a Windows PowerShell script, you must enable the Script Execution policy prior to configuring and using a Windows PowerShell profile.

Examining the $profile variable

When you query the $profile automatic variable, it returns the path to the current user, current host profile. This makes sense, and it’s a great way to easily access the path to the profile. The following illustrates this technique from within the Windows PowerShell console.

PS C:\> $profile

Inside the Windows PowerShell ISE, when I type query the $profile automatic variable, I receive the output as shown here.

PS C:\Users\ed.IAMMRED> $profile

To save you a bit of analyzing … the difference between the Windows PowerShell console current user, current host profile path and the Windows PowerShell ISE current user, current host profile path is three letters: ISE.

Note   These three letters often cause you problems. You are setting something in your Windows PowerShell console profile, and it is not available inside the Windows PowerShell ISE.

Unraveling the different profiles

You can pipe the $profile variable to the Get-Member cmdlet and see additional properties that exist on the $profile variable, as shown here.

PS C:\> $PROFILE | Get-Member -MemberType noteproperty | select name


If accessing the $profile variable from within the Windows PowerShell console, the AllUsersCurrentHost and the CurrentUserCurrentHost note properties refer to the Windows PowerShell console. If you access the $profile variable from within the Windows PowerShell ISE, the AllUsersCurrentHost and the CurrentUserCurrentHost note properties refer to the Windows PowerShell ISE profiles.

Using the $profile variable to refer to more than current host

When you reference the $profile variable, by default it refers to the current user, current host profile. If you pipe the variable to the Format-List cmdlet, it still refers to the current user, current host profile. This technique is shown here.

PS C:\> $PROFILE | Format-List *

This leads to a bit of confusion, especially because the Get-Member cmdlet reveals the existence of multiple profiles and multiple note properties. The way to see all of the profiles for the current host is to use the force parameter—it reveals the hidden properties. The command illustrating this technique is shown here.

$PROFILE | Format-List * -Force

The command to display the various profiles and the associated output from the command appear in Figure 9-1.

Image of command output

Figure 9-1 The $profile variable contains path to several different Windows PowerShell profiles.

It is possible to directly access each of these specific properties—just like you would access any other property—via dotted notation, as shown here.


The path to each of the four different profiles for the Windows PowerShell console appears in Figure 9-2.

Image of command output

Figure 9-2 Use dotted notation to access the various properties of the $profile variable.

Determine if a specific profile exists

To determine if a specific profile exists, use the Test-Path cmdlet and the appropriate flavor of the $profile variable. For example, to determine if a current user, current host profile exists, you can use the $profile variable with no modifier, or you can also use the currentusercurrenthost note property. The following example illustrates both of these.

PS C:\> test-path $PROFILE
PS C:\> test-path $PROFILE.CurrentUserCurrentHost
PS C:\>

In the same manner, the other three profiles that apply to the current host (in this example, I am using the Windows PowerShell console) are determined not to exist. This is shown in the code that follows.

PS C:\> test-path $PROFILE.AllUsersAllHosts
PS C:\> test-path $PROFILE.AllUsersCurrentHost
PS C:\> test-path $PROFILE.CurrentUserAllHosts
PS C:\>

Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (8)

  1. jrv says:


    $home is not where the Power is.

    cd c:scripts

    Set-Variable -Name home -Value $pwd -Force

    There  is no mapping between AD and PowerSHell.  Set it in the profile.

  2. Ben says:

    I would like to store my profile on my re-directed 'my documents' folder on my NAS. Does this mean my profile has to be signed?

  3. Ed Wilson says:

    @Ben It might be a good idea to sign your profile, but there are things you can do to avoid this is you wish. You need to look at your script execution policy — you are running a profile so you have already modified this. If it is set to RemoteSigned, a script that is determined to be a remote location is required to be signed. Now, if you trust your NAS, you might want to add it to Trusted Sites in Internet Explorer (you can use Group Policy) because this is how we determine if a script is local or remote.

  4. Grischa Zengel says:

    $Home is wrong if you use different home paths in AD user config:

    $Home[My ]DocumentsWindowsPowerShellProfile.ps1

    dir env:

    APPDATA                        C:UsersggzAppDataRoaming

    LOCALAPPDATA                   C:UsersggzAppDataLocal

    PSModulePath                   C:UsersggzDocumentsWindowsPowerShellModules;C:Windowssystem32WindowsPowerShellv1.0Modules

    USERPROFILE                    C:Usersggz

    HOMEDRIVE                      Z:                                                                                                                                                              


    HOMESHARE                      \hq1.localdfsAblageggz

    dir variable:

    profile                        C:UsersggzDocumentsWindowsPowerShellMicrosoft.PowerShellISE_profile.ps1

    HOME                           Z:

    The right path is:


  5. Bryan says:

    How handle bad profiles? I had powershell V1, V2, and uninstalled before installing V4. However, several items like profile paths include missing folders like …WindowsPowerShellv1.0…


    test-path $PROFILE

    notepad $PROFILE fails

  6. Mitz says:

    in the table you have $Home[My ]DocumentsWindowsPowerShellProfile.ps1 as the Current user, current host but in the next paragraph entitled examining the $profile variable you have C:Usersed.IAMMREDDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1
    as the current user current host. which one is correct?

  7. Brian says:

    The second row is incorrect it should be $Home[My ]DocumentsWindowsPowershellProfile.ps1

  8. BrianS says:

    Why is my ISE 4 or even version 5’s path is still showing as C:WindowsSystem32WindowsPowerShellv1.0 ? What’s with powershell and version 1.0? all scripts are saved as PS1 extension etc. will this 1.0 disappear or we stuck with this bad practice forever?

Skip to main content