It’s like an Autoexec.bat file for Windows PowerShell. Although your Windows PowerShell profile can do things Autoexec.bat could only dream of doing.
You must admit, Windows PowerShell has a great profile. You hadn’t noticed? Start Windows PowerShell and stand to the side of your monitor. See it now? True, you can’t see much of anything on the monitor anymore, but you must be able to see that Windows PowerShell looks great from the side. Title bar not too big, coloring about right, smooth face…yep, Windows PowerShell has a great profile. You don’t see any of the slight imperfections you might see while looking at it head-on.
So why would we want to mess with something like that? Well, we wouldn’t. Instead we’re going to explain how to set up and change a different type of profile, a profile that gives you a tremendous amount of control over your Windows PowerShell experience. This profile will help you smooth out some of those head-on imperfections – sorry, some of those beauty marks – you might have noticed.
Before we get started, stop staring at the side of your monitor and sit back down in front of it. Sorry, but it really will be easier to follow along this way.
So what is this profile we’re talking about? In the simplest sense, it’s a text file. A little less simple, it’s a Windows PowerShell script file (a file with a .PS1 file extension). So what makes this a profile rather than just a script file? Location, location, location. Well, that and name. And – well, we’ll get to all that in a moment.
The Windows PowerShell profile is simply a script file that runs when Windows PowerShell starts up. You can put cmdlets, scripts, functions – basically any valid Windows PowerShell commands – into this script file. Each time you start Windows PowerShell, this script file will run. That means you can use the profile to set up your Windows PowerShell environment. Typically that would be custom console settings and aliases, but if use your imagination you can come up with other things you’d like to customize in PowerShell before you start working with it.
Finding the Profile
A little while ago we mentioned location (in fact, we mentioned it three times, which should give you some idea how important that is). What makes the profile a profile and not a regular script file is the name and the location of the file. Type this at your PowerShell command prompt:
On Windows Vista, Windows Server 2008, or Windows 7 that built-in variable will return something like this:
This is the full path to the file Windows PowerShell will try to run when it starts. Notice we said “try” to run. Here’s an interesting fact: just because you were able to find the profile doesn’t mean it actually exists. As it turns out, $profile is simply a built-in variable that contains the full path to where the profile will be if there is one; the file doesn’t actually have to exist, and by default it actually doesn’t exist. If you want a profile to run when you start Windows PowerShell, you need to create this file before you do anything else.
Before we create our profile, we should point out that Windows PowerShell (as of version 2.0) actually recognizes multiple profiles. The profile we already showed you (you know, the one with a path stored in the $profile variable – did you forget already?) applies to the current user and the current host. Notice, in the example path we gave, that the path starts out with Users\kenmyer. When you set this profile, it runs only when keymyer is the logged-on user. That means each user of a computer can have a unique profile.
There are also machine-specific profiles: these profiles will run for all users on a given machine. In addition, profiles can be created for specific hosts, which means that third-party PowerShell hosts can have their own profiles. If multiple profiles do exist, user profiles take precedence. That’s important in case one profile wants to say, set $x to 5 and another profile wants to set $x to 7.
Why any of your profiles would even want to set the value of $x is another story.
Here’s a list of profiles and their locations:
Current User, Current Host
Current User, All Hosts
All Users, Current Host
All Users, All Hosts
For the rest of this discussion we’re going to keep things simple and work only with the current user, current host profile ($profile). But everything we talk about applies to all of these profiles.
Creating a Profile
Before we decide to create a profile, let’s check to see whether we already have one:
If the profile exists this command will return True; if it doesn’t exist, the command will return False. If this command returns False, you need to create the profile.
Creating a profile in Windows XP (not that anyone we know still uses Windows XP, mind you) is really easy. Simply type this at the command prompt:
This command opens the profile in Notepad. If the profile doesn’t exist, you’ll be prompted to create it. If you choose Yes, the file will be created for you and will be opened in Notepad. Remember, though, we said this is for Windows XP. If you’re running Windows Vista, Windows Server 2008, or Windows 7 things get a little more complicated. (But just a little bit, not very much.) If the full path to this file doesn’t exist, trying to open it in Notepad will return an error; you won’t receive any prompts and the file won’t be created for you. The way to create this file in post-XP operating systems (and which will also work in Windows XP) is to use the New-Item cmdlet:
New-Item -path $profile -type file –force
We pass three parameters to New-Item:
· -path $profile. We’re passing the full path, stored in the $profile variable, of the item we want to create.
· -type file. This tells New-Item what type of item we’re creating, in this case a file.
· -force. This parameter tells New-Item to create the full path and file no matter what.
Now you can open the profile and take a look:
And what will you see? Notepad:
What Goes in the Profile?
There are lots of different things you can put in your profile. We’re going to do just a couple of simple things to show you how this works. You might notice that, when you start Windows PowerShell, you always start out in the same folder. For example, on Windows 7, by default, you start in your user folder:
Well, suppose this isn’t the folder you usually work in; maybe you usually work in your C:\Scripts folder. If so, then every single time you start Windows PowerShell the first thing you have to do is change directories to the C:\Scripts folder. Not a big deal, but kind of a hassle. Well, why not just set up your profile to start you out in the C:\Scripts folder in the first place? Give this a try:
1. If your profile isn’t open, open it now. (Remember, we just showed you how to do that.) Inside your profile type this:Set-Location C:\Scripts
2. Save the profile and close Windows PowerShell. Now open PowerShell again. Voila!
Now every time you open PowerShell, you’ll go straight to your C:\Scripts folder. You can also do things such as set aliases and run functions. Not only that, but it’s simple to set up all these things on other computers; simply copy the commands from your profile to the profile on the other machine.
For an example of other things you can do with profiles, take a look at the article Customizing the Windows PowerShell Console.
Wait, My Profile Didn’t Run
What’s that? You say you opened a new instance of Windows PowerShell and all you got was an error message? You mean an error message like this?
File C:\Users\kenmyer\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
There’s a very good explanation for this: you haven’t set your execution policy. We talk a little more about this in the Introduction to Scripting article, but here’s a quick explanation.
By default, Windows PowerShell does not allow scripts to run within the console window. And because the profile is nothing more than a script file that automatically executes when PowerShell starts up, the profile can’t run. (Because you can’t run scripts and the profile is a script.) In order to allow your profile to run you need to set your execution policy to a level that allows scripts to run. First, check your execution policy by typing this cmdlet at the command prompt:
By default this will return a value of Restricted. To allow scripts to run, use the Set-ExecutionPolicy cmdlet to change the policy to something like this:
Close your Windows PowerShell window and reopen it. Now your profile should run just fine.
Now if you’d like to go back to looking at Windows PowerShell in profile, go right ahead. But you’ll probably find it much more useful to remain head-on and work with the Windows PowerShell profile files.
Just to report that at least on 2k8 R2, notepad $profile works normally with missing file (passes the string to notepad and notepad asks "wanna create this".