Hey, Scripting Guy! Why Would I Even Want to Create a Profile in Windows PowerShell?

ScriptingGuy1

Hey, Scripting Guy! Okay, I get that I can create a profile for Windows PowerShell. What I don’t understand is why I would want to create a profile in the first place. It seems to me that Windows PowerShell 2.0 works just fine the way it is. Can you enlighten me a bit?

— VW

Hello VW,

Microsoft Scripting Guy Ed Wilson here. Today, it is Meat Loaf—not the food, but the singer. After a couple days of beautiful sunny weather, the autumn grays have returned with a vengeance, and it is damp and cool outside. On such days, I like a little loud upbeat guitar rock with a strong pot of English Breakfast tea, lemon grass, and cinnamon to chase the cobwebs out of my head. I was up late last night working on the Scripting Guys Twitter account and am therefore a little sluggish this morning. Per my normal morning routine, I am perusing the e-mail that has been sent to scripter@microsoft.com. I ran across your e-mail, VW, and it reminded me that I had not mentioned why someone would want to use a profile. I guess I just thought it was intuitive. Sorry about that.

Note: Portions of today’s Hey, Scripting Guy! post are excerpted from the Microsoft Press book, Windows PowerShell 2.0 Best Practices by Ed Wilson. The book is available for pre-order.

For someone who is trying to migrate from VBScript to Windows PowerShell 2.0, the concept of a Windows PowerShell profile has to be totally foreign because there is nothing like it in VBScript. One of the problems with trying to learn Windows PowerShell is there are many concepts that are new. A good place to begin learning about Windows PowerShell is to check out our Windows PowerShell scripting page. There are links to Windows PowerShell scripts as well as information about the cmdlets and other fundamental Windows PowerShell concepts.

A Windows PowerShell profile commonly contains four items.

·         Variables

·         Aliases

·         Functions

·         Windows PowerShell Drives

We will examine adding variables to the Windows PowerShell profile today, but before we get too far, it is important to remember that a Windows PowerShell profile is a Windows PowerShell script. It has a special name, and it is located in a special place (in this regard you can consider it a sort of an AUTOEXEC.BAT file for Windows PowerShell), but it is still a script.

When Windows PowerShell is first installed, the script execution policy is set to Restricted, which means no scripts are permitted to run. Because a profile is a ps1 file, it is therefore a script and by default will not run. There are five levels of execution policy that can be configured in Windows PowerShell by using the Set-ExecutionPolicy cmdlet. These five levels are listed in Table 1. The Restricted execution policy can be configured via Group Policy by using the Turn on script execution policy setting in Active Directory. It can be applied to either the computer object or to the user object. The computer object setting takes precedence over other settings.

User preferences for the Restricted execution policy can be configured by using the Set-ExecutionPolicy cmdlet, but they will not override settings configured by Group Policy. An example of changing the current execution policy to RemoteSigned is seen here. To run the Set-ExecutionPolicy cmdlet, the Windows PowerShell console must have been launched with administrator rights. To do this, right click the shortcut to Windows PowerShell and click Run as administrator. If you attempt to run the Set-ExecutionPolicy cmdlet—even when logged on to the computer as the administrator or a user who is a member of the local administrators group—the error seen in the following image will appear if you are using Windows Vista or later.

Set-ExecutionPolicy -ExecutionPolicy remotesigned

The resultant set of Restricted execution policy settings can be obtained by using the Get-ExecutionPolicy cmdlet.

Table 1  Restricted Execution Policy Settings

In addition to the five Restricted execution policy settings, you also have the option to configure the scope of the policy. When you set the scope of the Restricted execution policy, it determines how the policy is applied. There are three valid values: Process, CurrentUser, and LocalMachine. These values are detailed in Table 2.

<

p style=”MARGIN: 3pt 0in” class=”TableNum-Title”>Table 2  Scope of Restricted Execution Policy Settings

After you have enabled script support on your computer, it is time to edit your Windows PowerShell profile. To edit your profile, you can use either Notepad or, because a Windows PowerShell profile is a script, your favorite Windows PowerShell script editor such as the Windows PowerShell ISE. (I almost never use an ISE to edit the profile because I do not like navigating to the $profile location. Instead, I use Notepad and the Windows PowerShell command line.) With Notepad, I can easily open the profile from the Windows PowerShell command like this:

PS C:> notepad $PROFILE
PS C:>

This assumes you have in fact created a profile. The creation of a Windows PowerShell profile was discussed in yesterday’s Hey Scripting Guy! post.

After you have opened the Windows PowerShell profile script, you will want to add comments to it that indicate a date and a version, and to supply placeholders for each of the four types of items that are normally stored in a Windows PowerShell profile. This is seen here:

A Windows PowerShell profile with some common types of variables added to it is seen in the Profile.ps1 script shown here.

Profile.ps1

# My PowerShell Profile
# HSG-11-24-09
# Ed Wilson, MSFT, 11/18/2009
# Version 1.0

The first variable to create is one called ProfileFolder. It points to the location where the $PROFILE resides. To find this location on computers that run various operating systems, it is necessary to use the Split-Path cmdlet to retrieve the parent portion of the location. One thing to keep in mind when creating variables using the New-Variable cmdlet is that the name of the variable does not include the dollar sign (this was something that tripped me up more than once when I was just learning Windows PowerShell.) The description parameter is used to assign a common name to all of the variables you create in your profile. The use of this parameter will be detailed a bit later:

New-Variable -Name ProfileFolder -Value (Split-Path $PROFILE -Parent) `
   -Description MrEd_Variable

The second variable I like to create in my Windows PowerShell profile is the IseProfile variable. Whereas when you are inside the Windows PowerShell ISE the $PROFILE variable refers to your ISE profile, outside of the Windows PowerShell ISE, the $PROFILE variable refers to your Windows PowerShell console profile. (For a more detailed explanation of this, refer to yesterday’s Hey, Scripting Guy! post.)

To make it easy to work with my Windows PowerShell ISE profile and to avoid confusion, I like to use the variable shown here:

New-Variable -Name IseProfile `
   -Value (Join-Path -Path (Split-Path $PROFILE -Parent) `
   -ChildPath Microsoft.PowerShellISE_profile.ps1) `
   -Description MrEd_Variable

I have a few computers on my network with which I routinely work. I get tired of typing individual computer names when I want to find out information about my remote machines. By using a variable to store the various computer names, I can use a command such as this one to test the connections:

PS C:> Test-Connection -ComputerName $MyComputers

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
——        ———–     ———–      ———–                              —–    ——–
MRED1         Hyperv          192.168.1.100    {}                                       32       0
MRED1         Win7-PC         192.168.1.110    {}                                       32       0
MRED1         Hyperv          192.168.1.100    {}                    

ScriptingGuy1

Follow