Sharing common PowerShell profiles for a PowerShell admin team

(This article works with PowerShell V2 and PowerShell V3)

I work with other PowerShell Admins and having separate profiles on our machines that load the same settings, functions and modules can be a pain to keep current. I started using a common profile; one that is shared from a server so making changes and additions was one step. I also wanted to start placing our Tool modules in a central location. I thought I would take a minute and show how I did it and some of the problems I ran into.

Also, I wanted to finally get the execution policy changed to “AllSigned”.  A common profile, whether on a network share or Dropbox, needs to be signed if you’re using an execution policy of “RemoteSigned” or “AllSigned”, so I’ll show you how I solved this as well.

The Tools 

You don’t need much in the way of tools for this exercise. You can use Notepad to edit the profiles and PowerShell to sign them. I’m going to be using a new tool from SAPIEN called the “PowerShell Profile Editor”. I’ve been playing with it for a while and I really like it for managing local and remote profiles. If you have any registered SAPIEN software you can download it for free from your account, but you can also get it from one of their ToolKit CD’s. I have some of these CD’s if your going to be at TechMentor and I’ll give you one. Here is the blog from SAPIEN explaining more about it.

The Shared Profile

So, making a shared profile is fairly straightforward. Create a network share on a local server (or Dropbox if you want). Make sure to set permissions for only you and your administrative friends.

Create a profile (text file with a .ps1 extension) and you’re good. In my case, I also wanted the shared profile to load a ToolsModule that we all use. I copied the ToolsModule to the same network share and added the last line to import the module. 

Figure 1 – My new shared profile located on a server share

The local Profile

Now, how to get that darn shared profile to load on my computer when I launch a PowerShell console…

Easy, have each PowerShell admin change their local profile to load the shared profile. Did you know that you could do that? Take a look at my example. Pretty cool huh?

Figure 2 – Configuring the local profile to open the shared profile from the server share

The Test #1 

So, to test to see if it worked I opened a PowerShell console. Notice I also used tab completion to see if the function in the profile and a function from the module worked.

Figure 3 – Testing the shared profile and module

Problem #1

The problem is that I’m using a very bad and very unsafe execution policy of “unrestricted”. I want to change this to “AllSigned” but as soon as you do you will receive the following error:

Figure 4 – Execution policy error when I attempt to use AllSigned

Solution #1

The solution is to sign the profile and any additional modules. This is not a hard task but if you haven’t done it before it can be a little confusing. You first need a code-signing certificate on your computer. I chose to use Active Directory Certificate Services for this because all the Admins could install the cert. If you haven’t done this with ADCS before check out this article written by friend Mike Pfeiffer.

You can use PowerShell to the sign the profile, but SAPIEN’s Profile Editor already has this feature (like PrimalScript and PowerShell Studio). Open the File menu and click Options after you have installed the code-signing certificate. Select the option “Sign Scripts when saving” like my example below:

Figure 5 – Setting the options for PowerShell Profile Editor to sign scripts when saving

Now just save the shared profile again and notice that it gets signed.


Figure 6 – The signed profile

NOTE: If you’re loading modules from this share, you will need to sign those as well. That’s why I love SAPIEN’s Profile Editor, it makes it easy to “Save and Sign”!


Figure 7 – The signed tools module

NOTE: If you’re using “AllSigned” you will need to save and sign the local profile with the code-signing certificate!

With the execution policy set to “RemoteSigned” or “AllSigned”, start the PowerShell console and enjoy!

Figure 8 – Working shared profile and module with AllSigned execution policy

Problem #2

My next problem was no surprise I just hadn’t planned on dealing with it yet. With all the admins using a shared profile and tool module change-control quickly became an issue. If one admin makes a breaking change, then everyone has a problem! I need the ability to quickly rollback to previous version and be able to track changes.

This is a problem that developers have solved for a long time with Source Control. For most admins using PowerShell this is a new concept, however one that is going to grow as more shared scripts, module and profiles become the norm.

Unfortunately, implementing a good source control solution can range from big complex products designed for development teams to Duct-Tape-and-Bailing-Wire solutions using Dropbox. What I need is a simple solution that’s easy for admins to use that also is a professional product that doesn’t have all the cost and complexity involved with other solutions.

Solution #2

My solution? I don’t have one yet but I’m trying one out that I think is going to fit perfectly. I’ll share the details in a later blog post on my experience but since I already own many SAPIEN tools I’m going to use SAPIEN’s ChangeVue. It’s designed to be easy (especially for guys like me) but still provide the professional qualities I’m looking for without a complicated setup. 

I’ll let you know how it goes! I hope you found the article helpful for using shared profiles and module.

Knowledge is PowerShell,



One thought on “Sharing common PowerShell profiles for a PowerShell admin team

Comments are closed.