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?
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 Breakfasttea, 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 firstname.lastname@example.org. 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.
·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-ExecutionPolicycmdlet, 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-ExecutionPolicycmdlet.
Table 1 Restricted Execution Policy Settings
Will not run scripts or configuration files.
All scripts and configuration files must be signed by a trusted publisher.
All scripts and configuration files downloaded from the Internet must be signed by a trusted publisher.
All scripts and configuration files will run. Scripts downloaded from the Internet will prompt for permission before running.
Nothing is blocked and there are no warnings or prompts.
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.
Table 2 Scope of Restricted Execution Policy Settings
The execution policy affects only the current Windows PowerShell process.
The execution policy affects only the current user.
The execution policy affects all users of the computer.
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:
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.
# My PowerShell Profile
# 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-Pathcmdlet 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.) Thedescription 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:
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:
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:
Two more variables that are useful to add to a Windows PowerShell profile are the MaximumHistoryCountand temp variables. In the first case, MaximumHistoryCount, the variable already exists. It is used to control how many items your command history will remember. To modify the value, use the Set-Variablecmdlet. The second variable is the temp variable. This variable points to your temporary folder, a favorite location of many applications, and one that is not easily discoverable because of its highly nested location. By having an easy-to-use variable, you can easily work with items in this location. The code to work with these two variables is shown here: