Skip to content

How to standardize PowerShell with profiles

Black and White PDQ logo
Kris Powell|December 6, 2017
Generic blog header
Generic blog header
  1. Want to make sure your colors and font are always the same?

  2. Want to make sure you always load a specific PowerShell module?

  3. Want a nice little message each time you load PowerShell?

PowerShell profiles are the answer!

What are PowerShell profiles?

Simply put, a PowerShell profile is a script that runs when I load an instance of PowerShell. I favor having nice little messages each time I load PowerShell, especially when they’re in the flavor of Futurama.

Message when starting PowerShell

After all, who doesn’t want a fancy message when they start PowerShell?!

Creating profiles in PowerShell

Great! I’m sold on profiles. Let’s get a profile made and get the magic started. I can find out where my default profile is stored by typing $profile inside PowerShell. It is one of the built-in automatic variables (See help for more info on automatic variables).

$profile
$profile lists your powershell profiles

By default, this file doesn’t exist. So, I’m going to need to create the file before I can add any code to it. (See New-Item)

New-Item $profile -ItemType File -Force
New Item $profile  ItemType File  Force

Now that my profile is created, I can easily edit it with my preferred text editor. For simplicity, I’m going to use notepad. Running the following will open up that file via notepad.

Notepad $profile
notepad $profile

Using PowerShell Profiles

Let’s put some code into it and see what happens. I’m a fan of random quotes, so I’ll add a nice thought about procrastination to my $profile.

Clear Host / Write Output

Closing and reopening PowerShell should kick off that extra code.

As a result, every time that I start PowerShell, my motivation will skyrocket to new heights… or something! I’ll figure it out later.

NOTE: Profiles are simply PowerShell scripts (.ps1 files) that run when PowerShell starts up, so the execution policy will be applied. If I have a restrictive execution policy, I will end up with an error when I start up my PowerShell console.

Execution Policy Error

In any case, that’s really all there is to create my $profile in PowerShell and kicking off some code at the beginning.

But wait, there’s more profiles

Order now and you’ll get not one, but six (or more) profiles with your standard PowerShell! We’ll even throw in free shipping!

…okay. That was cheesy and dumb. PowerShell doesn’t need free shipping. It sells itself!

Now don’t spit out your drink, but in all seriousness, there really are six PowerShell profiles out of the box.

In fact, there can be even more profiles if I have other applications that act as a PowerShell host (Visual Studio Code, PowerShell Studio, etc.).

How do I know what profiles are available?

Great question! I’m going to ask PowerShell.

I’m going to take a deeper look at the $profile variable and see what else I can find. To do that, I’ll use Get-Member and investigate.

$profile | Get-Member
$profile | Get Member

Towards the top, I can see that type of object is a System. String. Scrolling to the bottom, I can see that there are extra properties that aren’t normally part of a String object.

System.String

Those look promising, so I’m going to select all those properties: (See Select-Object)

$profile | Select-Object *
$profile | Select Object *

This is showing me that there are four profiles that can be used by PowerShell.

  • AllUsersAllHosts

  • AllUsersCurrentHost

  • CurrentUserAllHosts

  • CurrentUserCurrentHost

Breaking down the profile names a bit, the Current User and All Users portion seems straightforward enough for the profile type, but what does Current Host and All Hosts refer to?

Running that previous code in PowerShell ISE allows me to compare the results with the regular PowerShell console.

PowerShellISE.profile.ps1

I’ve highlighted the tiny difference that I’ve found — path to the AllUsersCurrentHost profile and the CurrentUserCurrentHost profile. It is the word ISE.

Without diving too much into the weeds, each host application that runs PowerShell can have two sets of profiles that are specific to that host application, broken down by Current User and All Users.

That means that I should see two profiles for each program that implements a PowerShell runspace: PowerShell console, PowerShell ISE, Visual Studio Code, etc.

  • AllUsersCurrentHost (PowerShell, PowerShell ISE, Visual Studio Code)

    • C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1

    • C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShellISE_profile.ps1

    • C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.VSCode_profile.ps1

  • CurrentUserCurrentHost (PowerShell, PowerShell ISE, Visual Studio Code)

    • C:\Users\kris.powell\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

    • C:\Users\kris.powell\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1

    • C:\Users\kris.powell\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1

In addition to the two sets of profiles per host application, I have two profiles defined for all hosts.

  • AllUsersAllHosts

    • C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1

  • CurrentUserAllHosts

    • C:\Users\kris.powell\Documents\WindowsPowerShell\profile.ps1

This makes for 6 total profiles with just regular PowerShell and PowerShell ISE. In my case, I also have Visual Studio Code installed, so I have 8 total profiles to work with!

I can find more info about the current application host with the Get-Host cmdlet or the $host built-in variable.

Black and White PDQ logo
Kris Powell

Kris was an employee at PDQ.

Related articles