Learn about Windows PowerShell
Summary: Microsoft Scripting Guy, Ed Wilson, teaches how to use a Windows PowerShell module to simplify your profile.
Hey, Scripting Guy! I have a problem and I hope you can provide some answers. My Windows PowerShell profile is, I guess, a bit excessive. I have a function that customizes my Windows PowerShell command prompt. I created a number of custom aliases and a couple of Windows PowerShell drives. So far, so good. The problem is all the customized functions that I wrote and use on a regular basis. I have them all pasted into my profile as well. I am not saying I wrote all this stuff. Heck no! For example, the Test-IsAdministrator and some of the other functions I use, I stole from you. The problem is that my profile is now more than 2,000 lines long. I have it grouped according to the way you said: aliases, variables, PS Drives, functions, and commands. But still it is a problem when I need to add stuff to it. I loved your blogs this week, because one problem I have is keeping things straight between the Windows PowerShell ISE and the Windows PowerShell console; but still, I need more help. Got any more good ideas?
Microsoft Scripting Guy, Ed Wilson, is here. Today, things are a bit groggy for me. I was up late last night listening to the Scripting Wife and Hal’s wife on the PowerScripting Podcast last night. Things always go a bit long there with people hanging around in the chat room while Jon begins the lengthy process of editing the show. Although I do not exactly turn into a pumpkin after midnight, my brain does begin to resemble a gourd.
Note This is the fourth in a series of four blogs discussing 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. The third blog in the series, Use a Central File to Simplify Your PowerShell Profile, appeared yesterday. For additional information about the Windows PowerShell profile, refer to this collection of blogs on the Hey, Scripting Guy! Blog.
One of the main ways to clean up your Windows PowerShell profile is to group related items into modules. For example, suppose your Windows PowerShell profile contains a few utility functions such as the following:
All of these functions relate to the central theme of being utility types of functions. They are not specific to one technology, and they are in fact, helper functions that are useful in a wide variety of scripts and applications. It is also true that as useful as these utilities are, you might not need to use them everywhere, at all times. This is the advantage of moving the functionality into a module—you can easily load and unload them as required.
There are two locations that are used by modules by default. The first is in the user module location in the users MyDocuments special folder. The following command points to the user module location on my computer.
Join-Path -Path $home -ChildPath documents\windowsPowerShell\Modules
Note The user module location does not exist by default. It must be created when you store the first module. For more information, refer to the Hey, Scripting Guy! blog, How Do I work with Windows PowerShell Module Paths.
The second location is in the System32 directory hierarchy. The following code uses the Join-Path cmdlet and the $pshome automatic variable to retrieve the system module folder on my system.
Join-Path -path $PSHOME -ChildPath modules
If you run your system as a nonelevated user, do not use the user module location for modules that require elevation of privileges. This will be an exercise in futility because once you elevate the user account to include admin rights, your profile shifts to another location, and then you do not have access to the module you were attempting to access.
Therefore, it makes sense to store modules that require admin rights in the System32 directory hierarchy. Store modules that do not require admin rights in the user profile module location. When modules reside in one of the two default locations, Windows PowerShell automatically picks up on them and displays them when you use the ListAvailable command as seen here.
However, this does not mean that you are limited to modules from only the default locations. If you are centralizing your Windows PowerShell profile and storing it on a shared network drive, it makes sense to likewise store the module (and the module manifest) in the shared network location.
Note Keep in mind that the Windows PowerShell profile is a script, as is a Windows PowerShell module. Therefore, your script execution policy impacts the ability to run scripts (and to load modules) from a shared network location. Even if you have a script execution policy of unrestricted, if you have not added the network share to your trusted sites in Internet Explorer, you will be prompted each time you open Windows PowerShell. You can use Group Policy to set the Internet Explorer trusted sites for your domain, or you can add them manually. You may also want to examine code signing for your scripts
When you decide where to store your module (or modules), your Windows PowerShell profile mainly consists of a series of Import-Module commands. For example, the following commands comprise my Windows PowerShell ISE profile. The first four commands import four modules. The last three commands, call functions from various modules to back up the profile, add menu items to the Windows PowerShell ISE, and create a Windows PowerShell drive for the locations of my modules.
For more information about using a module to clean up your profile, refer to the Weekend Scripter blog, Clean Up Your PowerShell ISE Profile by Using a Module.
VG, that is all there is to using a module to simplify your Windows PowerShell profile. This also concludes Profile Week on the Hey, Scripting Guy! Blog. Join me tomorrow for a great blog by Bill Stewart about working with directory sizes. Bill is a moderator for the Hey, Scripting Guys! Forum, and he is a really great resource for the Windows PowerShell community.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
On WIndows 7 with PowerSHell V3 the profile path does not change when elevated. It should not change in PosH V2 either. If it does then something may have altered the registry settings.
I have now checked numerous WS2008, Windows 7 and WS2008R2 systems with PowerShell V2. On all tests, when running elevated, the profile is always pointed correctly. The PowerShell setup is basic. No changes have been made. The GPO just sets the security and enables remoting. Nothing else has been done.
If you are not seeing this on your systems then there is a problem with your installation. This may be because you upgraded to V2 without first removing V1. (that is a guess)
@JV My normal user account is called ed. It is the one I use to log onto my computers day in and day out. That account is not a memember of any admin group -- either on the local computer or in the domain. Therefore, when i need to elevate the Windows PowerShell console, to do admin work, I must right click and select RUN AS Administrator. When this happens, a credential dialog box appears prompting me for credentials. I then type in EdAdmin for my domain, and supply the password. This IS in fact, a completely different domain user, that has ADMIN rights on my local computer. If you do not see a different profile path being used, then it means you are running your computer as a user that has administrator rights ... and that is not a very good security practice. But thank you for clarifying this point ...
this is probably a very good idea ...
But I have to admit that I never had to (or just avoided to) create a reasonably complex module on my own!
I'm using some modules ... for sure ...
But developing a module is something else than consuming a module.
So I'm really excited to see, what the weekend scripter will be blogging here!
On all of my sites I have both admin and standard user ‘My Documents’ redirected by a GPO to the same network folder. I can access all scripts and modules from both sessions and from Win7/08 elevated. I constantly create and modify scripts in the standard user environment then just click a link on the desktop that does ‘RunAs’ my admin account. I can then test the scripts as an admin when needed. I am finding that most things do not require elevation if we are querying remote systems as I can just use credentials. Once I launch PosH I enter my Admin password into a $cred and have it to use whenever needed. I only need to log in as an admin to run some code against the local machine.
The trick is to use a GPO to redirect you’re ‘My Documents’ for both accounts. They will then share the same network folder where PowerShell stores its profile.
@K_Schulte Yes, modules are GREAT. I have even written a blog article called Don't Write Scripts, Write Modules. The nice thing is that if prople write modules and share them, perhaps on the Scripting Guys Script Repository, then others can easily use those modules. In this way, only ONE person needs to write a specific module, and thousands of others can share in the use of that modules. Modules are a great way to share code.
@JV this makes sense and would provide a very simple and powerful solution. I would love to hear more about it ... can you email me at Scripter@Microsoft.Com please?
@Ed - email@example.com - invalid address.
<Scripter@Microsoft.Com>: host mail.messaging.microsoft.com[184.108.40.206]
said: 550 5.4.1 Scripter@Microsoft.Com: Recipient address rejected: Access
Denied (in reply to RCPT TO command)
@JV yes, Scripter@Microsoft.com is down right now. I have been working with the help desk to get it back up, but it might take a bit of time. I will let you know. In the mean time, can you Direct Message me on Twitter, @ScriptingGuys or message me on Facebook?