PowerShell Profiles: Dos, Don'ts, Etc.

I'm on vacation next week, so I'm doubling-up on the blogging this week - here's another bonus article to get you through the weekend! This one was actually suggested to me on Twitter; if you've got an idea for an article, I'd love to hear it. Just include @concentrateddon in your tweet so that I'll see it, and consider following me

Open PowerShell and run "Help about_profiles" - you'll find a lot of information on these special scripts, which run automatically when the shell is opened (assuming you've enabled script execution, of course). What should you use them for, though? What can they do, and what shouldn't they do?

First, a couple of background concepts. PowerShell is designed to be hosted within many applications; both the "blue console window" and the PowerShell ISE are just two of the hosts you might find PowerShell inside of. So the profile scripts are designed in a way that provides one script which is supposed to be run for ALL hosting applications (although it's up to the application to actually run it), and another script which only runs for a SPECIFIED hosting application. There are also per-user and per-machine hosts - giving any instance of the shell up to four scripts that it's supposed to run.

None of these exist by default; nor do, in the case of the per-user scripts, the folders in which the scripts must live. Here's where the ISE and console host will look for the per-user scripts:

Current User, Microsoft host: $Home\[My ]Documents\WindowsPowerShell\Profile.ps1
Current User, all hosts: $Home\[My ]Documents\Profile.ps1

$Home is a built-in PowerShell variable that references your profile folder on your computer; the [My ] bit indicates that it'll either be under "Documents" or "My Documents," depending on your version of Windows. The all-user scripts live in:

All Users, Microsoft host: $PsHome\Microsoft.PowerShell_profile.ps1
All Users, All hosts: $PsHome\Profile.ps1

$PsHome refers to PowerShell's installation folder, usually something like C:\Windows\System32\WindowsPowerShell\v1.0. So, normally, only a local admin would have permission to create these files on most computers.

Why use a profile? I use them mainly to import modules and add snap-ins that I use all the time, like the ActiveDirectory and ServerManager modules in Windows Server 2008 R2. You could also define some custom functions - I have a "New-Tweet" function I use to send quick notes to Twitter, for example. The profile scripts always execute in the shell's global scope, so whatever happens in the profile STAYS in the shell when the profile finishes running. You probably want to avoid loading a ton of stuff in the profile, simply because it'll slow down the shell's start time.

In fact, here's what's in my profile:

Import-Module ActiveDirectory
$sessions = New-PSSession -computer 'server2','server3','2008r2-dc'
function p {
 param($computername)
 return (test-connection $computername -count 1 -quiet)
}
cd \

That's loading the ActiveDirectory module, and then opening remoting sessions to three computers that I test with a lot. Those sessions are held in a $sessions variable for future use. I also define a function, "p," which returns True or False if a computer is pingable. With it defined in my profile like this, I can just run:

p server2

And get a True or False if Server2 is pingable right then. Finally, I change to the root of the drive, which is where I prefer to operate when I'm shelling around.

I'm a paranoid sort, and I've worked in environments where pranks were all too common. So, I set my local machine's execution policy (Set-ExecutionPolicy) to AllSigned, and I created a local certificate using Makecert.exe (run "help about_signing" for info on how to do that). I use that to sign every script I write, since I generally only run scripts on the local machine (which is the only place my local certificate is trusted). That signature helps prevent a prankster from modifying my profile scripts without my knowledge, although if they were to modify it and re-sign it using a certificate that I trusted, then they could sneak one by me. 

Having created and installed the certificate (complete step-by-step in the about_signing help file), I use Set-AuthenticodeSignature to actually apply a signature to my profile (see the help for that command for a specific example - run Help Set-AuthenticodeSignature -example). 

What do you do with your profile? What wouldn't you put into one? What would you like to know about profiles that I haven't covered? Drop a comment!

My PowerShell home page offers access to the latest blog articles, along with PowerShell FAQs - why not bookmark it? Your continued visitations help keep this blog alive! You can also get the latest on Windows PowerShell in my Twitter feed @concentrateddon. And, if you’d like to download recent conference materials (slide decks, scripts, etc) I’ve delivered, visit ConcentratedTech.com. That site also contains details on private classes and conferences, or you can learn about public classes this Fall in Chicago, Minneapolis, Philadelphia, and more!

Discuss this Blog Entry 1

EricTravers (not verified)
on Jul 9, 2010
Excellent introduction. I think the best advice you gave is to keep it short and simple. My first attempt at a profile had so much stuff packed in it was rediculous. Now it's just one function, one alias and two PSDrives.

I see that you cd to the root direcotry. Have you seen the "Powershell Prompt Here" shortcut? http://goo.gl/9sT1. I thought it didn't work until I remembered my profile contained 'cd ~'



Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×