Tag Archives: Profile

Managing PowerShell Functions

Most of you probably know I’ve been using PowerShell since its beta days which now means I have about 10 years worth of PowerShell files. I find it hard to throw anything away. Over this time frame my PowerShell profile scripts have also grown, often loading functions that I’ve come up with. The effect has  been that it takes a little bit longer to bring up a new PowerShell console or ISE session. Since deep down I know there are functions I no longer use, I figured it was time for some profile cleanup. The first step was to identify my functions.

First, how many functions am I talking about? PowerShell stores currently defined and active functions in a PSDrive which means it is pretty easy to get a “directory” listing and count.


However, some of those functions are defined by Microsoft and other modules.


I don’t have any issues with functions defined from a given source. My problem is in that 100 that have no source.  Again some of those are defined by Microsoft which are fine. So I looked at one of them in more detail.


I noticed that these functions included a HelpFile. I knew that none of my functions didn’t. With this information I can get a directory listing and filter with Where-Object.


These are functions that are loaded from dot sourcing a ps1 file. By the way, the list had 62 items.

As an alternative I could use Get-Command which would get rid of any filters

Know that this will search for functions in modules not currently loaded so it takes a bit longer to run. This gave me 61 items.

But now at least I can go through the list and identify functions that I haven’t used in years or are now obsolete. Unfortunately, there’s no way to tell from the Function PSDrive or with Get-Command where the function came from.   Luckily I keep all my files in a single drive and most likely the function will be defined in a .ps1 script. I can use Select-String to find it.

In my list there is a function called Show-Balloon that I probably haven’t used in years. What file is it in?

I’m wrapping the function name in a regular expression word boundary so that I don’t get a match on something like show-balloontip. The –List parameter gives me the first match which is all I really need.


Because I write all of my functions with the same format, I could have searched like this and gotten the same result.

The output from Select-String is an object which includes a property for the filename or path.


Now I can put it all together.

I don’t want to have to re-list all the script files for every function, so I’ll get it once and then use that variable in the Select-Object expression.


With this information I can modify my PowerShell profiles and remove the lines that are loading the functions I don’t want or edit the source file to comment out the function if there was something else in the same file I did want to keep.  Any function in this list without a matching source is most likely defined directly in the profile script or will require a manual search.

Time now for a little housekeeping, although I’d love to hear how you keep things tidy in your PowerShell world.

Friday Fun: Create All PowerShell Profile Scripts

talkbubbleWhenever I train on PowerShell I inevitably get around to discussing PowerShell profile scripts. For those of you new to PowerShell, a profile script is where you put all the commands you want to run that will define your PowerShell session just the way you need it. You might load some snapins, create some PSDrives or define some variables. There are actually several profile scripts that can be run, depending on whether you are in the PowerShell console, the PowerShell ISE or some other PowerShell host.

The profile paths are hard-coded. You can see all of them by looking at the built-in $profile variable.

You can also look at just $profile which will show you the script for the current user on the current host. If you look at this in the ISE you’ll see some things are different.


This variable is a bit tricky. Even though you can see properties here, if you pipe $profile to Get-Member all you get is a string definition. Here’s another way you can discover these.

Although I don’t really care about the length so let’s filter it out.

Now for the fun part. That value is a path so I can use Test-Path to see if it exists. If not, I can create the profile and at least indicate that is isn’t being used. Because most of these files don’t exist by default and in fact the WindowsPowerShell folder doesn’t exist under Documents until you create it, you might have to create the parent folder first. So I came up with a little script called Create-AllProfiles.ps1.

The script takes advantage of a feature in PowerShell 3 that will automatically enumerate properties. In PowerShell 2.0 I would need to do this:

But now in v3 and later I can do this:

The value property would show all of the values, including the length so because I’m getting an array, I can use a range of index numbers to select just the ones I want. In my script each value is tested and those that don’t exist are passed on to Foreach-Object.

For each path, I first split it so I can test if the parent path exists. If not, it is created. Then I create some text that will be inserted into each new profile script. The script supports -WhatIf so you can see what it would do before you run it for real.


I end up with a profile script that looks like this:


Ideally, I would recommend you digitally sign the profile scripts, assuming you are using an AllSigned execution policy, so that no changes can be made to these scripts without your knowledge. Just don’t forget to run this in the PowerShell ISE as well. If you have profiles already created, they will be ignored. And should you decide later to take advantage of any of the profile scripts, they are ready for you to edit.

Learn, enjoy and have a great weekend.

PowerShell Version Profiles

talkbubble One of the best things about PowerShell 3.0, for me anyway, is the ability to run PowerShell 2.0 side by side. I often need to test commands and scripts in both versions not only for my writing projects but also when helping people out. Like many of you I have a PowerShell profile script that configures my console. And because I primarily use PowerShell 3.0 I tend to have a number of version specific commands in my profile. The problem is that when I launch a PowerShell 2.0 session it uses the same profile, resulting in error messages for things it can’t do. So this is how I handle having a single profile that can be used by two different versions of PowerShell.

Basically, my profile script checks the version first, before doing anything. You can use the $psversiontable variable.

The PSVersion property is what I’m looking for. With this information, I can wrap my PowerShell profile script in simple IF statement.

I think the comments in the code sample are pretty clear and there’s really not much else to add. The Write-Host lines are merely for testing. You don’t really need them.

Now I can get properly configured PowerShell sessions regardless of version and without errors.