Windows PowerShell: My Windows PowerShell profile
The profile scripts are a powerful way to customize Windows PowerShell and have it ready to work the way you want it to work.
Don Jones
Whenever I set out to explain Windows PowerShell profile scripts, the discussion inevitably leads to someone asking what’s in my profile script. Generally, I think they’re just trying to get an idea of how they should use their profile.
Profiles are neat, but they can seem kind of magical at first because they happen under the hood as Windows PowerShell starts. In reality, they’re a lot less magical than you might think.
First, you need to understand that Windows PowerShell is just a big DLL sitting on your computer. That’s what I call the Windows PowerShell engine. It doesn’t do anything with profiles. For the most part, you can’t even interact directly with the engine unless you’re a .NET developer.
Mere human beings deal with Windows PowerShell by means of a hosting application, often just called the host. PowerShell.exe, the standard blue-screen console that most of us use, is one such host. The Windows PowerShell Integrated Scripting Environment (ISE) is another. Third-party Windows PowerShell editors such as PrimalScript, PowerShell Plus, PowerSE, PowerGUI and so on are also hosts. The host is responsible for loading—or not loading, as the case may be—profile scripts. The host actually determines which scripts it loads.
In the case of the PowerShell.exe host and the Windows PowerShell ISE, they’ll load up to four scripts. Two of them are in your user profile, in a folder called \Documents\WindowsPowerShell. These are the per-user profiles. Of those, one of them is supposed to be loaded by all Windows PowerShell hosts: profile.ps1.
The other is specific to the hosting application, as in Microsoft.PowerShell_profile.ps1. This is loaded by the PowerShell.exe host. The other two scripts are machine-wide scripts, with one being host-specific and the other being all-hosts.
You can run Help about_profiles in the shell to read up on these files. For third-party hosts such as script editors, you’ll need to consult their documentation. To offer behavior consistent with the Microsoft shell, some of them will load the same profile scripts as PowerShell.exe. Others will have their own per-host script they look for, while others let you specify the scripts you want loaded at startup.
The long and short of it is that your host will look for these scripts at startup. If they exist, it will execute them. None of the scripts used by the Microsoft hosts exists by default. In fact, the Documents\WindowsPowerShell folder isn’t created by default, either. You have to create them if you want to use them. You also have to enable script execution by setting the Execution Policy to something other than Restricted (which is the default setting).
My Profile
So what’s in my profile? Generally nothing, I’m somewhat ashamed to say. That’s because I tend to do a lot of specific things with Windows PowerShell—film training videos, teach classes, write articles and so on. These necessitate a completely default, fresh-out-of-the-box shell experience. I don’t want anything preloaded, because in most cases I want people to see me going through the act of loading whatever I need.
If I were in a normal production environment, though, what would I put in there? I’d start with any modules I use every day. For example, I might add Import-Module ActiveDirectory. I’d expect to be messing around with Active Directory a lot and having the module preloaded would help.
I wouldn’t put any custom functions into my profile. Instead, I’d put those into their own script module, and then import that into my profile. That keeps the profile cleaner, and it makes it easier to remove that module (and the functions it contains) if I find they’re conflicting with something else I need to do.
I wouldn’t mess around with the Windows PowerShell window title bar, the Windows PowerShell prompt or anything like that. There’s nothing wrong with doing so, but I’m the kind of person who likes those things to look like the defaults. I’d just leave them alone. I know a lot of folks who like to tweak their prompt, though, and the profile is the place to do it.
I would make one change:
$host.privatedata.ErrorForegroundColor = 'green'
This turns error messages from red to green. I tell people that it’s because the default red-on-black color is too low-contrast for easy reading. The real reason is that a screen full of red text takes me back to high school English class and stresses me out. Green error messages make me feel like I’m doing something right, so I don’t stress so much. I know, it’s weird—blame my teachers Ms. Giovanni and Ms. Hansen.
I don’t define any custom aliases, because I’m afraid I’ll use them. Then I might pass them along to someone else who has no definition for them, so whatever examples I passed along wouldn’t work.
I don’t throw up a fancy-colored splash screen using Write-Host, and I don’t display a list of available functions or modules. I know how to list those things easily enough if I need to, and I don’t like a cluttered screen when I’m first starting the shell (I run cls all the time as it is, so I can feel like I’m getting a fresh start). I do run cd c:\ so that I’m starting at the root of the C: drive, rather than in my user profile folder.
So that’s what’s in my profile. What’s in yours?
.jpg "Don Jones")
Don Jones is a Microsoft MVP Award recipient and author of “Learn Windows PowerShell in a Month of Lunches” (Manning Publications, 2011), a book designed to help any administrator become effective with Windows PowerShell. Jones also offers public and on-site Windows PowerShell training. Contact him through ConcentratedTech.com or bit.ly/AskDon.