Summary: Ed Wilson, Microsoft Scripting Guy, talks about Windows PowerShell profiles.
Microsoft Scripting Guy, Ed Wilson, is here. Today I am heading back to the basics. Why? Because my hard disk drive died, and I had to order a new drive to replace it. It gave me a good chance to reinstall Windows 8.1. Now, my laptop is really fast. It is amazing how dramatically the stuff that you install slows down your laptop. Even when you uninstall stuff, most programs leave components behind, so my poor laptop bogs down like a tractor in a muddy field. I didn’t lose any data because I sync everything on a regular basis to my Microsoft OneDrive account. The cool thing is that signing-in to my Microsoft account automatically syncs many of my profile items, such as my Internet Explorer Favorites.
Still i have to make all the various tweaks that I made previously. For example, my Windows PowerShell profile. Oh, I have backup copies of my Windows PowerShell profile; in fact, I even copied it back to my Windows PowerShell Documents folder so it would automatically come back into play. I also copied all of my Windows PowerShell modules back to their locations. But it still doesn’t work.
A PowerShell profile can be a great help
For me, my Windows PowerShell profile is a lot like eating pizza. I don’t eat pizza all that much, but when I do, it is hard to quit. My Windows PowerShell profile is like that. I seem to go in spurts where I mess around with my profile a lot, and then I simply leave it alone. Maybe it is partly because it is easy to get really busy, but that is not the only reason.
Eating too much pizza can make you slow and a bit sluggish, just like installing lots of apps that you never use, so it is easy to get addicted to your Windows PowerShell profile. I got to the point where I became lost without it. I had that experience once before when I reinstalled Windows, and I did not have a backup profile. I was lost until I re-created a bigger and a better profile.
I was talking to Windows PowerShell MVP June Blender a while back. She mentioned one thing about profiles that is easy to forget—a Windows PowerShell profile is simply a Windows PowerShell script. And to talk about scripts, you need to talk about Windows PowerShell script execution policies. And to talk about script execution policies, you need to talk about scope. So what should be an easy topic ends up depending on four topics. This is why Windows PowerShell is sometimes thought of as overly complicated. When learning it, you need to learn a lot of things at one time, but then it tapers off, and you can get tremendously compounded results by combining these elements of basic knowledge.
In VBScript script, you simply fire up the script editor and write Wscript.Echo “Hello World” – click Run, and you get a dialog box saying “Hello World.” In Windows PowerShell, you have to talk about the difference between the Windows PowerShell console and the Windows PowerShell ISE, about script execution policies, about running as and administrator or a non-elevated user, and then you can finally type “Hello World” and see it come back in the output pane of the Windows PowerShell ISE. If you want a dialog box that says “Hello World,” it is much more complicated.
But after you learn all that, how much easier is it to return the computers BIOS version information in Windows PowerShell or in VBScript? Or if you want the profiles from a hundred computers, how much easier is it to get them in Windows PowerShell? Whereas the initial learning curve can be overwhelming in Windows PowerShell (for example, the first eight hours in a class), after the initial start, it gets easier. But in VBScript script, it keeps getting more and more complicated, and it never seems to taper off.
Like eating pizza every day, monkeying around with the Windows PowerShell profile every day can be detrimental. Why? Because you become dependent on your Windows PowerShell profile to the point where you can’t use anyone else’s Windows PowerShell. For example, you can define aliases in your Windows PowerShell profile. If you always use your custom aliases, you might forget what the actual cmdlet is called. You might not even know the command except by your own alias. The same holds true for custom Windows PowerShell drives. I might not know where the data resides, except for the location of my custom Windows PowerShell drive. I might have functions that I always use, and forget how I actually accomplished the task that is encapsulated in that function.
There are a lot of simple things that I don’t want to give up, such as changing my working directory to the root of the drive, instead of the deeply nested User folder. I want the free space for my Windows PowerShell command line. Starting the transcript utility is definitely useful, but of course, you can eventually forget that the actual command name is Start-Transcript. So with this in mind…
Enable script execution
I want to enable script execution for the current user, and set the execution policy to Remote Signed. This does not require using an elevated Windows PowerShell console because it only affects the current user. Here is the command (there is no output from the command):
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force
I use Tab completion so I don’t have to do so much typing. Tab completion works for the scope name (current<tab>), the execution policy (remote<tab>), and the cmdlet name (Set-Exe<tab>).
Create the profile
If I don’t have a profile, I use the New-Item cmdlet to create it. This command is shown here:
PS C:\> New-Item -ItemType file -Path $profile -Force
Mode LastWriteTime Length Name
—- ————- —— —-
-a— 7/16/2015 4:00 PM 0 Microsoft.PowerShell_profile.ps1
Now, I can open the profile in the Windows PowerShell ISE:
I add two commands to my Windows PowerShell profile:
I close the Windows PowerShell console, and then open it again. This time, I am greeted with a transcript statement, and my Windows PowerShell prompt opens at drive C. This is shown here:
Copyright (C) 2014 Microsoft Corporation. All rights reserved.
Transcript started, output file is C:\Users\ed\Documents\PowerShell_transcript.EDLT.r5NTdamI.20150716160247.txt
Cool. I h ave a Windows PowerShell profile. Now to add stuff to it tomorrow.
That is all there is to using a Windows PowerShell profile. Profile Week continues tomorrow when I will talk about more cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy