{"id":51943,"date":"2009-11-24T00:01:00","date_gmt":"2009-11-24T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2009\/11\/24\/hey-scripting-guy-why-would-i-even-want-to-create-a-profile-in-windows-powershell\/"},"modified":"2009-11-24T00:01:00","modified_gmt":"2009-11-24T00:01:00","slug":"hey-scripting-guy-why-would-i-even-want-to-create-a-profile-in-windows-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/hey-scripting-guy-why-would-i-even-want-to-create-a-profile-in-windows-powershell\/","title":{"rendered":"Hey, Scripting Guy! Why Would I Even Want to Create a Profile in Windows PowerShell?"},"content":{"rendered":"

\"Bookmark<\/a> <\/p>\n


<\/p>\n

\"Hey,<\/p>\n

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?<\/p>\n

— VW<\/p>\n

\"Hey,Hello VW, <\/p>\n

Microsoft Scripting Guy Ed Wilson here. Today, it is Meat Loaf—not the food<\/font><\/a>, but the singer<\/font><\/a>. 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<\/a> tea, lemon grass<\/font><\/a>, and cinnamon<\/font><\/a> to chase the cobwebs out of my head. I was up late last night working on the Scripting Guys Twitter account<\/a> 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<\/font><\/a>. 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. <\/p>\n

\"Image<\/p>\n

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

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<\/a>. There are links to Windows PowerShell scripts as well as information about the cmdlets and other fundamental Windows PowerShell concepts. <\/p>\n

A Windows PowerShell profile commonly contains four items. <\/p>\n

·         <\/span><\/span><\/span>Variables<\/p>\n

·         <\/span><\/span><\/span>Aliases<\/p>\n

·         <\/span><\/span><\/span>Functions<\/p>\n

·         <\/span><\/span><\/span>Windows PowerShell Drives<\/p>\n

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<\/font><\/a> file for Windows PowerShell), but it is still a script.<\/p>\n

When Windows PowerShell is first installed, the script execution policy is set to Restricted<\/b>, 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<\/b> cmdlet. These five levels are listed in Table 1. The Restricted<\/b> execution policy can be configured via Group Policy by using the Turn on script execution<\/b> 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.<\/p>\n

User preferences for the Restricted<\/b> execution policy can be configured by using the Set-ExecutionPolicy<\/b> cmdlet, but they will not override settings configured by Group Policy. An example of changing the current execution policy to RemoteSigned<\/b> is seen here. To run the Set-ExecutionPolicy<\/b> 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<\/b>. If you attempt to run the Set-ExecutionPolicy<\/b> 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. <\/p>\n

Set-ExecutionPolicy -ExecutionPolicy remotesigned<\/p>\n

<\/font><\/span><\/p>\n

\"Image
<\/a>
<\/p>\n

The resultant set of Restricted<\/b> execution policy settings can be obtained by using the Get-ExecutionPolicy<\/b> cmdlet. <\/p>\n

Table 1  Restricted Execution Policy Settings<\/strong><\/p>\n\n\n\n\n\n\n\n\n
\n

Level<\/p>\n

<\/strong><\/span><\/p>\n<\/td>\n

\n

Meaning<\/p>\n

<\/span><\/b><\/p>\n<\/td>\n<\/tr>\n

\n

Restricted<\/p>\n

<\/span><\/p>\n<\/td>\n

\n

Will not run scripts or configuration files.<\/p>\n

<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

AllSigned<\/p>\n

<\/span><\/p>\n<\/td>\n

\n

All scripts and configuration files must be signed by a trusted publisher.<\/p>\n

<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

RemoteSigned<\/p>\n

<\/span><\/p>\n<\/td>\n

\n

All scripts and configuration files downloaded from the Internet must be signed by a trusted publisher.<\/p>\n

<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Unrestricted<\/p>\n

<\/span><\/p>\n<\/td>\n

\n

All scripts and configuration files will run. Scripts downloaded from the Internet will prompt for permission before running.<\/p>\n

<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

Bypass<\/p>\n

<\/span><\/p>\n<\/td>\n

\n

Nothing is blocked and there are no warnings or prompts.<\/p>\n

<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\n

 <\/p>\n

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

<<\/p>\n

p style=”MARGIN: 3pt 0in” class=”TableNum-Title”>Table 2  <\/span>Scope of Restricted Execution Policy Settings<\/strong><\/p>\n\n\n\n\n\n\n
\n

Scope<\/p>\n

<\/strong><\/p>\n<\/td>\n

\n

Meaning<\/p>\n

<\/b><\/p>\n<\/td>\n<\/tr>\n

\n

Process<\/p>\n<\/td>\n

\n

The execution policy affects only the current Windows PowerShell process.<\/p>\n<\/td>\n<\/tr>\n

\n

CurrentUser<\/p>\n<\/td>\n

\n

The execution policy affects only the current user.<\/p>\n<\/td>\n<\/tr>\n

\n

LocalMachine<\/p>\n<\/td>\n

\n

The execution policy affects all users of the computer.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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<\/b> 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:<\/p>\n

PS C:> notepad $PROFILE
PS C:><\/p>\n

<\/font><\/span><\/p>\n

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<\/a>. <\/p>\n

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:<\/p>\n

\"Image<\/p>\n

A Windows PowerShell profile with some common types of variables added to it is seen in the Profile.ps1 script shown here. <\/p>\n

Profile.ps1<\/strong><\/p>\n

# My PowerShell Profile
# HSG-11-24-09
# Ed Wilson, MSFT, 11\/18\/2009
# Version 1.0<\/p>\n

# *** Variables ***
New-Variable -Name ProfileFolder -Value (Split-Path $PROFILE -Parent) `
   <\/span>-Description MrEd_Variable
New-Variable -Name IseProfile `
   <\/span>-Value (Join-Path -Path (Split-Path $PROFILE -Parent) `
   <\/span>-ChildPath Microsoft.PowerShellISE_profile.ps1) `
   <\/span>-Description MrEd_Variable
New-Variable -Name MyComputers -Value Hyperv,Win7-PC -Description MrEd_Variable
Set-Variable -Name MaximumHistoryCount -Value 128 -Description MrEd_Variable
New-Variable -name temp -value $([io.path]::gettemppath()) -Description MrEd_Variable<\/p>\n

<\/font><\/span><\/p>\n


The first variable to create is one called ProfileFolder<\/b>. It points to the location where the $PROFILE<\/b> resides. To find this location on computers that run various operating systems, it is necessary to use the Split-Path<\/b> cmdlet to retrieve the parent portion of the location. One thing to keep in mind when creating variables using the New-Variable<\/b> 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<\/b> 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: <\/p>\n

New-Variable -Name ProfileFolder -Value (Split-Path $PROFILE -Parent) `
   <\/span>-Description MrEd_Variable<\/p>\n

<\/font><\/span><\/p>\n

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

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

New-Variable -Name IseProfile `
   <\/span>-Value (Join-Path -Path (Split-Path $PROFILE -Parent) `
   <\/span>-ChildPath Microsoft.PowerShellISE_profile.ps1) `
   <\/span>-Description MrEd_Variable<\/p>\n

<\/font><\/span><\/p>\n

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:<\/p>\n

PS C:> Test-Connection -ComputerName $MyComputers<\/p>\n

Source        <\/span>Destination     <\/span>IPV4Address      <\/span>IPV6Address                              <\/span>Bytes    <\/span>Time(ms)
——        <\/span>———–     <\/span>———–      <\/span>———–                              <\/span>—–    <\/span>——–
MRED1         <\/span>Hyperv          <\/span>192.168.1.100    <\/span>{}                                       <\/span>32       <\/span>0
MRED1         <\/span>Win7-PC         <\/span>192.168.1.110    <\/span>{}                     <\/span>                  <\/span>32       <\/span>0
MRED1         <\/span>Hyperv          <\/span>192.168.1.100    <\/span>{}                    <\/span><\/font><\/font><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[51,144,3,4,45],"class_list":["post-51943","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-profiles","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/51943","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=51943"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/51943\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=51943"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=51943"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=51943"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}