PowerShell introduces a substantial amount of flexibility and possibilities. With Microsoft introducing PowerShell in more products, we have the ability to perform tasks amongst several different resources, all from within a PowerShell window. Given the potential, it’s easy to spend a fair amount of time in PowerShell. It’s time now to make the environment a little friendlier. With these few changes, we’ll do just that.
First, we’ll tweak the shortcut that launches the Exchange Management Shell. Click on Start > All Programs > Microsoft Exchange Server 2007. Right click on Exchange Management Shell and click Properties. On the Shortcut tab, set the Start In field to be your Scripts folder as seen in Figure 1 below.
Figure 1 Exchange Management Shell Properties Shortcut tab
By default, this is c:\Program Files\Microsoft\Exchange Server\Scripts. That way, you’ll get tab completion for .ps1 files in this folder, and won’t have to go hunting for them. If your environment uses a single repository for all PowerShell scripts, adjust the path accordingly.
Next, click on the Options tab. Set the Command History Buffer Size to 999 to allow a much bigger buffer. This gives us the ability to look further back into what we’ve done. Next, check the box that says Discard Old Duplicates. This way, if you run the same command several times, it only shows up in the buffer once. After all, it doesn’t make sense to show more than that, right?
Check the two boxes marked Quick Edit Mode and Insert Mode as seen in Figure 2 below. Quick Edit allows us to highlight and copy information in the PowerShell window, and Insert Mode allows us to paste information into the window.
Figure 2 Exchange Management Shell Properties Option tab
Click on the Layout tab. Set the width to 120 for both the Screen Buffer Size and the Window Size, and the Height for the Window Size to 50, as seen in Figure 3 below. This gives us a bigger window to work in, and results in less word wrapping. Note: If you use a lower resolution, you may need to adjust these values accordingly.
Figure 3 Exchange Management Shell Properties Layout tab
Now that we’ve adjusted the shortcut in the Start menu, copying that shortcut to the desktop and/or Quick Launch bar gives us a much friendlier PowerShell environment.
When PowerShell, and the Exchange Management Shell, which runs on top of PowerShell, are started, some code compilation takes place. This Just In Time compilation causes the PowerShell startup to take longer. Fortunately, we can work around this by doing a onetime compilation of the managed code to a native code. This negates the need to perform the compilation at runtime. This results in a shorter startup of PowerShell. Here’s how to perform this one time task.Copy and paste the following into Notepad:
Set-Alias ngen @(
$ngen_path = Join-Path ${env:\windir} "Microsoft.NET\Framework"
if(${env:PROCESSOR_ARCHITECTURE} -eq "AMD64"){
$ngen_path = Join-Path ${env:\windir} "Microsoft.NET\Framework64"
}
dir $ngen_path ngen.exe -recurse | where {$_.length -gt 0} | sort -descending lastwritetime
)[0].fullName
[appdomain]::currentdomain.getassemblies() | %{ngen /nologo $_.location}
Save this as Update-Gac.ps1 in the \scripts folder for Exchange, which, as mentioned above, is by default
c:\Program Files\Microsoft\Exchange Server\scripts
Now, we’ll run the script. Click Start > All Programs > Windows PowerShell 1.0 > Windows PowerShell, (NOT Exchange Management Shell), and navigate to the scripts folder. Type Update-Gac.ps1 and press Enter. Or, test the tab completion by the earlier tweaks and type Update and hit the tab key until you see the right script, then press enter. The script will go through and make the appropriate changes to the files, as seen in Figure 4 below.
When it’s finished, close the Windows PowerShell window, and open either Windows PowerShell or the Exchange Management Shell, and you should notice that it does open and get to a prompt quicker than before. While it’s still not lightning fast, it is quicker. If you look at the code, you’ll notice it checks to see if it’s running on a 64 bit or 32 bit machine, and updates the correct files. So, the script is perfect for both 64 bit production boxes and lab servers, as well as 32 bit management workstations. We can thank Jeffery Snover of the Microsoft PowerShell team for this tidbit, and their contributor “Justin” for the 32bit/64bit flexibility.
With these changes, it should be more fun playing with PowerShell. In future articles, I’ll touch on performing more administrative tasks from within PowerShell.
Got a question? Post it on our Exchange Server Forums!