Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use a central file to simplify configuring your Windows PowerShell profile.

 Hey, Scripting Guy! So can you tell me without all the chatter, what is the best way to create a single Windows PowerShell profile? I don’t want to hear about a whole lot of other junk because I am rather busy. So please, as one American police person on television used to say, “Just the facts, just the facts.”

—ZQ

 Hello ZQ,

Microsoft Scripting Guy, Ed Wilson, is here. Today is the third day in a row that we have had the windows open and the air conditioner turned off. The cool breeze and sounds of birds playing in the lawn are a welcome relief to the incessant thrum of electric motors. I just fixed a pot of Gun Powder Green tea with a half spoonful of organic lavender and a cinnamon stick for my midmorning tea. I also opened the cookie jar, and retrieved the next to last Anzac biscuit. I gave the Scripting Wife the last Anzac biscuit in honor of her appearance tonight on the PowerScripting Podcast. She and Hal’s wife will be the guests on the show tonight, and it is sure to be a hoot. We did pretty well at making the Anzac biscuits last as long as possible. We cannot find Anzac biscuits in Charlotte, so a friend who is a Windows PowerShell MVP in Australia shuttled them to us via another Windows PowerShell MVP from Charlotte. We retrieved the elusive biscuits in the parking lot of the Microsoft office in Charlotte one night following a Windows PowerShell User Group meeting.

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

One Windows PowerShell profile—but which one?

One way to use a single Windows PowerShell profile is to put everything into the all users, all hosts profile. I know some companies that create a standard Windows PowerShell profile for everyone in the company, and they use the all users, all hosts profile as a means of standardizing their Windows PowerShell environment. The changes go in during the image build process; and therefore, the profile is available to machines built from that image.

Advantages of using the all users, all hosts profile

• Simplicity. One location for everything, especially when added changes during the build process.
• One file affects all Windows PowerShell users and all Windows PowerShell hosts.
• No conflict between Admin users and non-admin users, both types of users use the same profile.
• $profile.AllUsersAllHosts always points to the correct file.
• Great for central management—one file for all users of a machine.

When to use the all users, all hosts profile

• For a personal profile when duties require elevation and non-elevation of permissions across multiple Windows PowerShell hosts.
• As part of a standard image build to deploy static functionality to numerous machines and users.

Disadvantages of using the all users, all hosts profile

• You must have administrator rights on the current machine to make changes to the file.
• No distinction between different hosts—some commands do not work in ISE, and others do not work in the Windows PowerShell console.
• No distinction between administrator users and non-admin users. Non-admin users cannot run some commands.
• The files are distributed among potentially thousands of different machines. To make one change to the profile, the file must copy to all machines that are using that profile. This can be a major issue for computers such as laptops that connect only occasionally to the network. It is also a problem when attempting to use a shutdown script on a Windows 8 device (because Windows 8 devices do not perform a true shutdown).

Use your own file

Because the Windows PowerShell profile is a Windows PowerShell script (with the added benefit of having a special name and residing in a special location), it means that anything that can be accomplished in a Windows PowerShell script can be accomplished in a Windows PowerShell profile. A much better approach to dealing with Windows PowerShell profiles is to keep the profile itself as simple as possible. But bring in the functionality you require via other means. One way to do this is to add the profile information you require to a file. Store that file in a central location, and then dot-source it to the profile.

Just the steps: Use a central profile script

1. Create a Windows PowerShell script containing the profile information that you require. Include the aliases, variables, functions, Windows PowerShell drives, and commands to execute on start up of Windows PowerShell.
2. In the Windows PowerShell profile script, dot-source the central profile file. The following command (placed in the $profile script) brings in functionality that is stored in a Windows PowerShell script named myprofile.ps1 that resides in a shared folder named c:\fso:

. c:\fso\myprofile.ps1

The advantages of using a central Windows PowerShell script to store your profile information is that only one location requires updating when you add additional functionally to your profile. In addition, if folder permissions permit, the central Windows PowerShell script becomes available to any user for any host on the local machine. If you store this central Windows PowerShell script on a network file share, you need to update only one file for the entire network.

Advantages of using a central script for a PowerShell profile

• One place to modify for all users and all hosts having access to the file.
• Easy to keep functionality synchronized among all Windows PowerShell hosts and users.
• Makes it possible to have one profile for entire network.

When to use a central script for a PowerShell profile

• Provide basic functionality among multiple hosts and multiple users.
• Use for single user who wants to duplicate capabilities between Windows PowerShell hosts.
• Use to provide a single profile for networked computers via a file share.

Disadvantages of using a central script for a PowerShell profile

• More complicated due to multiple files.
• No access to the central file means no profile for the machine.
• It is possible that non-role specific commands become available to users.
• More complicated to filter out specific commands for specific hosts.
• One central script becomes very complicated to maintain when it grows to hundreds of lines.

ZQ, that is all there is to using a central file for your Windows PowerShell profile. Windows PowerShell Profile Week will continue tomorrow when I will talk about using a Windows PowerShell module for a profile.

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