OK, so why haven’t I posted the second part in so long? LIFE. No other reason. So—on to the next part:
In Part I I told you that aliases were important and we wanted to make sure we didn’t have to remember what they were and to make them specific. OK, so that means we have to learn a little about PowerShell profiles.
So what is a PowerShell profile?
The PowerShell profile is a text file that has a .ps1 extension. The extension is looked at by PowerShell as a script and the text in the script tells PowerShell how to act. In this file it will tell PowerShell what aliases it should remember, what snap-ins to load, what colors to use, etc.
OK, now to confuse you a little bit—there are four of these profiles. Here they are, what they are, and where they are located:
a. All Users Profile – This profile is located in the windows directory\system32\WindowsPowerShell\v1.0\profile.ps1. This one is the profile that gets loaded when anyone invokes PowerShell.
b. All Users Host Profile – This profile is located in the windows directory\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1. This is the profile that gets loaded when anyone using a particular shell environment invokes PowerShell. Think of this one as the profile that pertains to the machine regardless of user.
c. Current User Profile – This profile is located in the %userprofile%\Documents\WindowsPowerShell\profile.ps1. This is the profile that gets loaded by the current logged on user that invokes PowerShell.
d. Current User’s Host Profile – This profile is located in the %userprofile%\Documents\WindowsPowerShell\Microsoft.Powershell.ps1. This is the profile that gets loaded when a user invokes PowerShell on a specific machine. Think of this one as the profile that pertains Shell environment on a machine but is specific to the particular user that invoked PowerShell.
Why is that all important? Well, you need to know which profile to change if you want to be able to benefit from the change. if I want a change to be “Global”, I need to update *all four* of the profiles.
Configuring my PowerShell environment
I want to make sure of at least three things when I enter the PowerShell world: that I have blue background with yellow lettering, that my aliases that I set up are loaded and that the PowerShell snap-ins are loaded for SharePoint. So how would I do that? Here is how:
First thing is to find out where your profile is. Go to the PowerShell command prompt and type $profile. It will give you an output of %userprofile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 . Now attempt to go to that location; what do you see? Nada. Nothing. Zilch. Goose egg. Now type this at the prompt: ‘
The output will be ‘FALSE’. So in order to “see” the path and the profile script that PowerShell is reading from type the following:
New-Item -path $profile -type file –force
The output will be
Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 8/5/2011 12:59 PM 0 Microsoft.PowerShell_profile.ps1
Now if you were to attempt to browse to the path, you would see it. Cool, huh? OK, before we go any further, let’s make sure our envrionment is set up to change the contents of this file. If you are on a Windows 7 machine, you are already good to go, but if you are on Windows Server 2008 R2, you will need to type this command in the console:
Import-Module ServerManager;Add-WindowsFeature PowerShell-ISE
After running those commands you should see the PowerShell ISE option as in the following diagram:
You will also see the following diagram if you were to right-click on the PowerShell icon on the taskbar:
OK, now right-click the file profile.ps1 script and click OPEN. This will open the PowerShell ISE you will notice that it is empty. This means that PowerShell will simply load into memory and display the console. But we want to make it behave in a certain way, remember? So—let’s do that—first we want to make sure that the SharePoint snap-ins get loaded every time so that we don’t have to type in that long command that we can never remember. So in the script type the following:
It should look like the following
Then click the green ‘RUN’ icon. It shouldn’t give you any errors, just load the snap-in for SharePoint. OK, now minimize this window and go back to the PowerShell console.
It’s just black with white text. You may like this—I don’t; and besides this will be good practice for you. (YES YES, I *KNOW* you can change all of that by right-clicking on the menu bar, yada yada—but you will thank me later for this)
Now, type Get-Host and click Enter. The output will look something like this:
Name : Windows PowerShell ISE Host Version : 2.0 InstanceId : e9c2a9ca-9ea3-4887-9067-f2e111b9db64 UI : System.Management.Automation.Internal.Host.InternalHostUserInterfaceCurrentCulture : en-US CurrentUICulture : en-US PrivateData : Microsoft.PowerShell.Host.ISE.ISEOptions IsRunspacePushed : False Runspace : System.Management.Automation.Runspaces.LocalRunspace
OK, so we are looking at the UI property. This is what we want to change from the default to a blue background with yellow letters. How do we do that? Well let’s talk through it-- we know that we have to invoke the ‘Get-Host’ cmdlet and we have to address the property UI. There is a property *inside* of UI that talks to the colors and its name is RawUI. To find out what we are currently using we need to invoke that property. So— at the run command type Powershell, and then type the following:
Remember to use the parentheses here around Get-Host, or you will get an error message. The reason is that you first want PowerShell to get the local environment and then give you the properties. When you hit enter, you will see something like this:
ForegroundColor : Gray BackgroundColor : Black CursorPosition : 0,1 WindowPosition : 0,0 CursorSize : 25 BufferSize : 100,300 WindowSize : 100,25 MaxWindowSize : 100,48 MaxPhysicalWindowSize : 168,48 KeyAvailable : False WindowTitle : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
OOOOOOH!!!! Now if this doesn’t get the wheels turning in your head, you’re more of an OSITA than I am, and you need to get with it!
So let’s change the colors. I hate the black background and gray/white lettering. I want a dark blue background with yellow lettering. So, how do we do that? Let’s walk through this-- you already know that the previous command we ran showed us what colors we were using, so all we have to do now is change them. So how do we *change* them? We know (Get-Host).UI.RawUI.BackgroundColor = Black; so let’s change it to Dark Blue. Simple—just remember that names must be in quotes and can’t have spaces. So, type the following and hit enter:
(Get-Host).UI.RawUI.BackgroundColor = “DarkBlue”
And the screen should look like this:
Notice how the background after the carriage return turned to dark blue? Now let’s change the lettering. Type the following and hit enter:
(Get-Host).UI.RawUI.ForegroundColor = “Yellow”
And you should see this:
Now clear the screen and what do you think? Now exit PowerShell and re-open it. What happened? Why did it go away? Because PowerShell loaded your profile. The changes we made pertained to our current session only and aren't yet part of your profile. So now let’s fix that. Type Notepad $profile and add the following lines of code:
set-alias wipe clear-host wipe (Get-Host).UI.RawUI.ForegroundColor = “Yellow” (Get-Host).UI.RawUI.BackgroundColor = “DarkBlue” wipe
Save the file and re-open the PowerShell command. How ‘bout *THAT*?!! Now, for the ‘coup de grâce’ – open up the profile.ps1 file add the line ‘Add-PSSnapin Microsoft.SharePoint.PowerShell’ and save the file. Exit the PowerShell editor and reopen it. For those of you who have SharePoint installed on your machine, the snapins are now loaded and you can type any SharePoint specific cmdlet and PowerShell will understand you. For those of you who do *NOT* have SharePoint installed on your machine, you might see a flash of red before the screen ‘wipes’ or clears itself because PowerShell can’t load the snap-in if the SharePoint dlls don’t exist. But no worries, you have a pretty editor screen in front of you.
In Part 3 (Final Part) I talk about the Top Ten most common PowerShell actions for which a SharePoint Admin can use.