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

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, currenthost 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
C:\Users\ed.IAMMRED\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

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
C:\Users\ed.IAMMRED\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1

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

Name
----
AllUsersAllHosts
AllUsersCurrentHost
CurrentUserAllHosts
CurrentUserCurrentHost

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 *
C:\Users\ed.IAMMRED\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

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 forceparameter—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.

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.

$PROFILE.CurrentUserAllHosts

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

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
True
PS C:\> test-path $PROFILE.CurrentUserCurrentHost
True
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
False
PS C:\> test-path $PROFILE.AllUsersCurrentHost
False
PS C:\> test-path $PROFILE.CurrentUserAllHosts
False
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