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? —VG  Hello VG, 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.  

Group similar functionality into a module

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:

• A function to determine admin rights
• A function to determine if the computer is a laptop or desktop
• A function to determine if the host is the Windows PowerShell ISE or Windows PowerShell console
• A function to determine if the computer is 32-bit or 64-bit
• A function to write to a temporary file

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.

Where to store the profile module

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 documentswindowsPowerShellModules

C:Usersed.IAMMREDdocumentswindowsPowerShellModules

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

C:WindowsSystem32WindowsPowerShellv1.0modules 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.

Get-Module –ListAvailable 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.

import-module PowerShellISEModule

import-module MenuModule

import-module SnippetModule

import-module copymodule

BackUp-Profile

Add-MenuItems

New-ModuleDrives 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 scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy