What’s in Your Powershell Profile?

“What’s in Your Profile?”

This is a question you see often in Powershell blogs and forums. Powershell profiles can be a powerful way to automate your command line environment and most importantly save typing and time.

In my previous post I went over how to make a portable Powershell profile. In this post I’ll go over what I have in my profile scripts and why.

The Main Profile

In this profile script I configure most of the settings that will apply to both the Powershell console and the ISE:

Let’s walk through this bit-by-bit. The first two lines import credential objects that I have previously saved using the New-SavedCredential function and saves them in variables. This saves the username and password securely in an XML file that represents a Powershell credential object. I typically run powershell with a standard user account and use these credentials in commands that require more privilege. I save the credentials in SAM and UPN formats – SAM format is for things like domain servers and Active Directory, and the UPN credentials can be used against web services like Office 365.

Next I extend the Powershell module path to include my script library; this adds quick access to modules stored in OneDrive. I also remove my local documents modules folder from the modulepath variable. I do this because I often work over a VPN connection and my documents are stored on a file server in our datacenter. This can mean that automatic module enumeration is very slow over the WAN connection. This cripples tab-completion and Intellisense because it constantly checks your module path to discover commands and parameters.

Next in line is a prompt function. When you create a function named prompt, the text output of that function will be used as the command-line prompt. I like mine with some color and it also displays the execution time of the last command run.

Next I load several modules that I work with on a regular basis. Since Powershell version 3.0 this is not really necessary since modules when auto-load when they are called upon, but I prefer that they load at startup to save time later. Besides that I still sometimes run Powershell version 2.0 which does not auto-load modules, so this ensures the right modules are loaded when I run Powershell. I have recently begun using the Windows Azure module but I don’t really want to load it when I launch the shell, so I save the path to the module in a variable and call that later when I need to access the Azure cmdlets.

I manage a print server on a daily basis and use cmdlets in the PrintManagement module to do so. These modules leverage WMI/CIM to retrieve and configure printer settings. For quick access I like to have a CIM session to my print server already open when I load Powershell. I use one of my imported admin credentials to establish this connection.

I use the $PSDefaultParameterValues automatic variable to configure default values when I run certain commands. This is a huge time-saver if you find yourself typing the same parameter values in on a regular basis. An example of this is setting the -CimSession parameter of all of the PrintManagement cmdlets with a value of $CimPs01 from the previous line in my profile script. This makes sure that I am always running printer cmdlets against the right computer without having to enter the parameter at the command line.

Lastly, if the current Powershell host is the ISE editor, I import a module called ISELibrary with a collection of functions for interacting with the ISE. I then run another profile script that makes some changes like the default pane view and loading custom add-ins.

The ISEConfig script above also calls another profile script – load-addons.ps1. This script uses some of the functions in my ISELibrary module to create ISE add-ons. These add-ons take advantage of the extensibility of the ISE object model and allow you to create ISE menu items that run Powershell code and can be called with a keyboard shortcut.

Well, that’s my Powershell profile! I hope this wasn’t too long-winded but instead illustrates how flexible and dynamic Powershell profiles can be.

So, what’s in your profile?

Take Your Powershell Profile on the Road

As my Powershell skills have progressed I began to use profile scripts to customize and extend the Powershell experience. I tend to work from a few different computers at work, at home, and sometimes on the road and keeping these profiles in sync was often a hassle. Eventually I decided that what I needed was a way to automate the syncing of my profile on any machine that I use regularly.

Powershell Profiles

A Powershell profile is nothing more than a script that is run by default any time you load a Powershell host. These scripts can contain any Powershell code you would like to have dot-sourced into your session. There are six different profiles that will be run depending on the host and third-party hosts can add their own profile as well. I typically use the ‘Current User, All Hosts’ profile which ensures that whether I open the console or the ISE I will still have my customized experience. Continue reading

ISE Steroids Snippet Manager

For those of us who write Powershell scripts frequently, ISE Steroids version 2.0 comes with some exciting new features. My favorite feature is the graphical Snippet Manager. It extends the ISE’s code snippet capabilities far beyond what you get out-of-the-box. It allows you to easily define your own snippets in the ISE and assign shortcuts to each.

Once you have downloaded ISESteroids and unzipped it to your module path, run Start-Steroids from the ISE console window to launch it. Continue reading