Learn about Windows PowerShell
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.
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
Current User, All Hosts
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
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.
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.
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.
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 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.
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.
Figure 9-2 Use dotted notation to access the various properties of the $profile variable.
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 email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
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?
@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.
$Home is wrong if you use different home paths in AD user config:
The right path is:
$home is not where the Power is.
Set-Variable -Name home -Value $pwd -Force
There is no mapping between AD and PowerSHell. Set it in the profile.