Deciding Between One or Multiple PowerShell Profiles

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, discusses some of the decision points between using one or multiple Windows PowerShell profiles.  Hey, Scripting Guy! OK, so I understand that there are different types of Windows PowerShell profiles (I liked your blog yesterday by the way). But you failed on one major point: How do I know which profile to use? For example, suppose it was different types of tea—you have an Earl Grey, an English Breakfast, and a generic green tea. When would you drink which tea? I hope this makes my question clear. Thanks. —BH  Hello BH, Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I are getting ready for Atlanta TechStravaganza 2012. It happens on Friday June 1, 2012, and there are just a few tickets remaining. This event is going to be held at the Microsoft Office in Atlanta. It is free, and it features a number of awesome speakers (including me). There is, in fact, an entire Windows PowerShell track (as tracks for Windows Server and System Center). This high profile, high impact event will be awesome. So how did the Scripting Wife and I get ready for the Atlanta TechStravaganza? We were on the website of my favorite computer store making a shopping list because no trip to Atlanta is complete without a trip to my favorite computer store. My list is already running two pages long, so maybe I need to implement a dedup routine.

Note   This is the second in a series of four blogs that discuss the Windows PowerShell profile. The first blog, Understanding the Six PowerShell Profiles, appeared on Monday. For additional information about the Windows PowerShell profile, refer to this collection of blogs on the Hey, Scripting Guy! Blog.

Design considerations for profiles

The first thing to do when deciding how to implement your Windows PowerShell profile is to analyze the way in which you use Windows PowerShell. For example, if you confine yourself to running a few Windows PowerShell scripts from within the Windows PowerShell ISE, there is no reason to worry about a Windows PowerShell console profile. If you use a different Windows PowerShell scripting environment than the Windows PowerShell ISE, but you also work interactively from the Windows PowerShell console, you may need to add stuff to the other scripting environment’s profile (assuming it has one) in addition to the Windows PowerShell console profile. If you work extensively in the scripting environment and the Windows PowerShell console, and you find yourself desiring certain modifications to both environments, well…that leads to a different scenario. There are three names used for the Windows PowerShell profiles. The names appear in the table that follows along with the profile usage.

The distinction between the Windows PowerShell ISE profiles and the Windows PowerShell console profiles is the letters ISE in the name of the Windows PowerShell ISE profiles. The location of the Windows PowerShell profile determines the scoping (whether the profile applies to the current user or to all users). All user profiles (any one of the three profiles detailed in the previous table) appear in the Windowssystem32WindowsPowerShellv1.0 directory; a location that is referenced by the $pshome variable. The following script illustrates using the $pshome variable to obtain this folder.

PS C:Usersed.IAMMRED> $PSHOME

C:WindowsSystem32WindowsPowerShellv1.0 The folder that contains the three current user Windows PowerShell profiles is the WindowsPowerShell folder in the user’s mydocuments special folder. The location of the user’s mydocuments special folder is obtained by using the GetFolderPath method from the System.Environment .NET Framework class. This technique is shown here.

PS C:> [environment]::getfolderpath(“mydocuments”)

C:Usersed.IAMMREDDocuments The table that follows details a variety of use-case scenarios, and it points to the profile to use for specific purposes. 

Note   Depending on how you perform administrative work, you may decide that you want to use a current user type of profile. This would be because you log on with a specific account to perform administrative work. If your work requires that you log on with a number of different user accounts, it makes sense to use an all users profile.

Using more than one profile

Many Windows PowerShell users end up using more than one Windows PowerShell profile. This may not be intentional, but that is how it winds up. What happens is that they begin by creating a current user, current host profile via the Windows PowerShell $profile variable. (For more information about this, refer to yesterday’s Hey, Scripting Guy! Blog, Understanding the Six PowerShell Profiles.) After adding a number of great items in the Windows PowerShell profile, the user decides that it would nice to have the same features in the Windows PowerShell console—or the Windows PowerShell ISE—whichever was not the original source. Therefore, after creating an additional profile, the user soon realizes there is a duplication of work. Depending on how much you add to your Windows PowerShell profile, you may be perfectly fine with having multiple Windows PowerShell profiles. If your profile does not have very many items in it, using one Windows PowerShell profile for the Windows PowerShell console and another profile for the Windows PowerShell ISE may be a perfectly acceptable solution. Simplicity makes this approach work. For example, certain commands, such as the Start-Transcript cmdlet, do not work in the Windows PowerShell ISE. In addition, certain commands, such as those requiring STA, do not work by default in the Windows PowerShell console. By creating multiple $profile profiles (current user, current host), and only editing them from the appropriate environment, much complexity leaves the profile creation process. However, it will not become too long before duplication leads to inconsistency, and that leads to frustration, and finally to a desire for correction and solution. A better approach is to plan for multiple environments from the beginning. Advantages of using more than one profile

• Simple
• $profile always refers to the correct profile
• Removes concern about incompatible commands

When to use more than one profile

• With a simple profile
• When you do not have administrator or non-elevated user requirements

Disadvantages of using more than one profile

• Duplication of effort
• Inconsistencies between profiles (for variables, functions, PSDrives, and aliases)
• Maintenance due to the number of potential profiles

Using one profile

If you need to customize the Windows PowerShell console and the Windows PowerShell ISE (or other Windows PowerShell host), and you need to log on with multiple credentials, your need for Windows PowerShell profiles increases exponentially. Attempting to keep a number of different Windows PowerShell profiles in sync quickly becomes a maintenance nightmare. This is especially true if you are prone to making quick additions to your Windows PowerShell profile when you see a particular need. In addition to having a large number of different profiles, it is also possible for a Windows PowerShell profile to grow to inordinate proportions—especially when you begin to add many nicely crafted Windows PowerShell functions and helper functions. One solution to the problem of profile bloat (in fact, the best solution) is to use modules. My Windows PowerShell ISE profile uses four modules. The profile itself consists of the lines that load the modules.

Note   This approach of containing functionality for a profile inside modules, and then loading the modules from the profile file, is presented in the Hey, Scripting Guy! Blog, Create a Really Cool PowerShell ISE Profile. Advantages of using one profile

• Less work
• Easier to keep different profiles in sync
• Consistency from different Windows PowerShell environments
• Portability (the profile can more easily travel to different machines)

When to use one profile

• With more complex profiles
• When your work requires multiple user accounts or multiple Windows PowerShell hosts
• If your work takes you to different computers or virtual machines

Disadvantages of using one profile

• More complex to setup
• Requires more planning
• $profile does not point to correct location

BH, that is all there is to deciding about how to work with Windows PowerShell profiles. Windows PowerShell Profile Week will continue tomorrow when I will talk about setting up a single profile environment. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow