Learn about Windows PowerShell
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.”
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 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
When to use the all users, all hosts profile
Disadvantages of using the all users, all hosts profile
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
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
When to use a central script for a PowerShell profile
Disadvantages of using a central script for a PowerShell profile
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 email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
I really like the "have ONE file" for all users idea!
But to be honest, I'm afraid that we won't have ONE but maybe SOME profiles located somewhere in our network! But SOME is less the ALL :-)
Having ONE profile and using script logic inside the script to distinguish between script types and user "groups" and ... whatsoever ... might be possible but will lead to rather complicated profiles ... especially if you are going to add functionality later on which should be available to group 1,2,4,8,16 ... but only for ISE hosts ... and not on Monday to Wednesday ... Well, than this script will be astonishingly difficult :-)(
@K_Schulte you are absolutely correct ... having one file for all users can become really complex. One thing you might consider in having multiple profiles is to have a basic one that ALL users do get for all hosts. Then Have additional commands for one group of users, and different file for the administrators. If you keep them like this,then the basic profile only goes to this group. The next group gets the basic profile, plus the other commands in the other file. The administrtors get all three files.
The profile in the MyDocuments folder is the one to use for most things. If we redirect 'MyDocuments' to a network location in a GPO we can always have the same code available on any system. This is an All-Hosts on steroids. The profile can contain any or all modules in its modules folder. Just think, Anywhere you log into the network you have all of your code.
I have hundreds of scripts and modules in this location along with my per-user profile. I also have this set up on every network I support. We can also use BITS to keep things sync’d although I haven’t yet set this up.