How to customize your Windows PowerShell environment

One of Windows PowerShell's strongest traits is its extensibility. The scripting engine can be customized in many ways and extended to include functionality not available by default. Once you understand the basic terms and cmdlets, personalizing PowerShell is the next step.

Controlling your PowerShell environment

With scripting environments, there is no such thing as one size fits all. But users can control what Windows PowerShell does at start up with the following:

• Profile
  A profile is a script that runs when PowerShell starts up. (I like to think of it like an autoexec.bat for PowerShell, which may be old school but it's still applicable.)

  There are two types of profiles, and they can be stored in two locations:

  1. System profiles -- Apply to all PowerShell sessions
  2. Host-specific profiles -- Only apply to a specific host (i.e. PS+).
• Global
  Located in $PShome, which is in System32 of the system ( C:windowssystem32WindowsPowerShellv1.0), this profile applies to all PowerShell sessions launched on the host.
• User
  This user-specific profile is the last profile to load. It is located in $Env:UserProfileDocumentsWindowsPowerShellprofile.ps1.

PowerShell also lets you create custom hosts with their own profiles, but that is beyond the scope of this series and delves deep into the developer space.

More PowerShell lessons from the Scripting School What makes Windows PowerShell unique? The terms and commands you absolutely need to know

Extending PowerShell's functionality

Although most scripting environments include a process for extensibility, these methods are often convoluted and reserved for more experienced users. Windows PowerShell, however, offers several levels of extensibility that even the most novice users can use.

• Function
  Functions are the easiest to add -- simply wrap a command in a function block (function {command}) -- and let the user create cmdlets of their own that can be loaded via a profile and are accessible on demand.
• Snap-in
  Snap-ins are the primary method for adding binary cmdlets to a PowerShell session in version 1.0. Compiled code delivered by an application provider like Citrix, Vmware or Exchange, snap-ins are controlled by two cmdlets: Get-PSSnapin and Add-PSSnapin.
• Module
  Introduced in Powershell 2.0, modules provide a bridge between functions (admin-centric) and snap-ins (developer-centric). Modules can be loaded on-demand and can contain binary cmdlets, functions and scripts, which are managed with the following:
  • Get-Module -- Gets currently loaded modules
  • Import-Module -- Imports a module
  • Remove-Module -- Removes a module from the current session
  • New-Module -- Creates a module that lives in memory only.

Overall, there is plenty of room for growth in Windows PowerShell -- for everyone from the novice admin to the most experienced developer. Check out the following cmdlets for more information:

• Get-Help about_profiles
• Get-Help about_functions
• Get-Help about_PSSnapin
• Get-Help about_modules