Tuesday, October 21, 2014

PowerShell Profile Tips & Tricks


What is it?


A PowerShell profile is just a normal PowerShell script with a specific name and location. This means it's subject to your current ExecutionPolicy, so you'll either need to sign your profile or use RemoteSigned.
It's a similar concept as say autoexec.bat or .bashrc; when you launch the PowerShell console, or open a new tab in the ISE, the host process looks for and executes the applicable profile.
There are multiple possible profiles, and you can have several of them, although I prefer (and suggest) not doing so unless you have an overriding need as it makes it more complicated.
The Scripting Guy has an excellent post that explains in excellent detail, but here's the short version:
  • There is a CurrentUser set of profiles which live in your Documents\WindowsPowerShell folder
  • There is a AllUsers set of profiles which live in $PSHOME
  • Each set can have an AllHosts profile, as well as a host specific profile for each host (generally console and ISE)
  • If you have multiple profiles, the most specific one runs last (and thus "wins")
  • None of the profiles exist by default, they have to be created.
  • The profile scripts do not get invoked automatically by remote session.
There is a built-in variable ($profile) that makes life easier. Here's a command to show you where the profiles would live: $profile | get-member –membertype noteproperty

What good is it?


Here's the real meat of the story. J

Since the profiles are standard PowerShell scripts, anything you can do in a PowerShell script can be in your profile. Just remember though, that the profile scripts run every time you launch PowerShell, so you don't want them to take a long time to run. You also do not want them to require any user input as PowerShell won't finish loading until that input is provided. This is especially painful if you have PowerShell logon/logoff or start/shutdown script defined in your GPOs.
Anything you find yourself running/typing every time you launch the console or ISE should probably go in your profile.

The most common and useful things to put in your profile are:


  • Functions (help about_Functions)
  • Aliases (help about_Aliases)
  • PSDrives (help About_Providers)
  • PSDefaultParameterValues (help about_Parameters_Default_Values)
My profile started out originally because I didn't want to have to launch each of the different, separate, PowerShell "consoles" that each snap-in or tool seemed to create. After all, why go launch PowerCLI or Exchange Management Shell when I can just create a function in my profile that adds those things to my current session?
Another very useful case are modules/snap-ins that have to be run from a server with a specific role such as XenApp or SharePoint. The SharePoint PowerShell snap-in has to be run from a SharePoint server that is part of the farm you're working with. So rather than have to create a new session each time you want to access it (or worse RDP to the server to run PowerShell!) I've created a function that uses implicit remoting to import the snap-in.
I've posted a generalized and heavily commented version of my own profile script on GitHub: https://github.com/dsolodow/IndyPoSH/blob/master/Profile.ps1

Feel free to read through it, post questions or comments in the Issues or Discussion pages for the project. Also feel free to borrow snippets or sections out of it that you want to use for yourself.

Other ideas: 

The Scripting Guy has a series of posts about "What's in your profile" with information from various PFEs, PowerShell MVPs, members of the PowerShell team, etc. Links below.
What's in your profile (PFEs): http://bit.ly/1BxOImo

What's in your profile (PowerShell team): http://bit.ly/1rGAzm4

What's in your profile (MVPs): http://bit.ly/1vrjqxJ

What's in your profile (User favorites Part 1): http://bit.ly/1mIUOyV

What's in your profile (User favorites Part 2): http://bit.ly/1qPP7uf

What's in your profile (Scripting Guy): http://bit.ly/1uxMdlt

Any rules, best practices, no-nos? 

There aren't a lot of hard, fast rules but here are the ones I know of as well as some good practices/suggestions:
  • Don't make your profiles require user input
  • Be careful about system/version dependent features/cmdlets
  • Make sure you either sign your script or run PowerShell with the RemoteSigned executionPolicy
  • Don't make your profile script something that takes a long time to run as you'll run it a lot
  • It's a PowerShell script, treat it accordingly. This means comment it, format it appropriately, put it in version control, etc.
    http://windowsitpro.com/blog/my-12-powershell-best-practices
  • Do share cool tricks or ideas with your co-workers, fellow IndyPosh members, the PowerShell community
  • Let your profile grow organically; when in doubt K.I.S.S.
  • Remember: help about_profiles

No comments:

Post a Comment