Subscribe via E-mail

Your email:

Learn More

  • A blog by GSX-ers featuring our takes on the fascinating world of Messaging, Mobile and Collaboration Servers
bouton gsx monitoring whitePaper

bouton gsx video2

GSX Blog

Current Articles | RSS Feed RSS Feed

Enhance your PowerShell experience by automatically loading scripts

  
  
  

PowerShellEver wanted to customize your PowerShell terminal so you can have all your custom function or scripts loaded automatically? Although it is possible to create aliases, functions or variables, everything is only kept for the current PowerShell session, meaning that those changes will be lost after you close the shell.

In order to store the information PowerShell, you can use a “Profile” that is loaded at every session. We’ll now explain how to enable your PowerShell profile and customize it.

The different Profiles

You can have four different profiles in Windows PowerShell, listed below in load order, the most specific having precedence over less specific profiles where they apply:

  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1
    This profile applies to all users and all shells. 

  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
    This profile applies to all users, but only to the Microsoft.PowerShell shell. 

  • %UserProfile%\My Documents\WindowsPowerShell\profile.ps1
    This profile applies only to the current user, but affects all shells.  

  • %UserProfile%\My Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
    This profile applies only to the current user and the Microsoft.PowerShell shell.

Enabling a profile

Open a PowerShell terminal and type in

$profile

This should display the path that would be used to store you profile. However it might not be created yet, so in order to find out, type the following:

test-path $profile

If the result is true, you’re all set, else type the following to create the profile:

new-item -path $profile -itemtype file -force

You’re now all set with your profile, and can customize it, by launching the PowerShell ISE:

powershell_ise $profile

 

Auto-load scripts on PowerShell startup

In the ps1 file of your profile, usually named “Microsoft.PowerShell_profile.ps1”, you can enter the following code, so that the folder of your choice will contain scripts that will be executed on startup:

# directory where my scripts are stored

$psdir="D:\Documents\Powershell\Scripts\autoload"  

# load all 'autoload' scripts

Get-ChildItem "${psdir}\*.ps1" | %{.$_

Write-Host "Custom PowerShell Environment Loaded" 

This script will browse the folder given in input, and load all the files. The files I have in this folder are “.ps1” files that contains a PowerShell function.

 

In order for those scripts to be executed, the policy needs to be updated to something else than "restricted", at least “remotesigned” by running the following:

Set-ExecutionPolicy remoteSigned

 

Here you go, you can now put as many “.ps1” files as you need in your “autoload” folder, and these will be executed everytime you launch your PowerShell session.

  

Sources

Comments

Very cool, I was doing: 
 
foreach ($FUNC in $(dir $FUNCTION_DIR\*.ps1)) {. $FUNC.FullName} 
 
...but I like your version better!
Posted @ Thursday, December 20, 2012 5:58 AM by Matt
Thank you Matt I'm glad I could help ;)
Posted @ Friday, December 21, 2012 8:55 AM by Olivier Raynaut
I use something similar for Module loading, where I define an array of module names then pass each to a function that wraps Import-Module inside a Measure-Command. Trapping errors it then Lists each Module as it loads with a RED or Green Forecolor to signify success/failure, and the load time in fractional seconds.  
 
Actually this worked so well, I stopped loading anything by PSCX until I need it. The visibility into how much time was lost was too helpful. 
 
You could similarly wrap your dot includes if you are doing any more work than just populating Function: and Variable: 
 
If you have to change 32/64 bit PS for compatibility (I also up my PS2.0 to .NET 4.0 so: 
Write-Host ("{1} Bit; {0} .NET " -f [Environment]::Version,([System.Runtime.InterOpServices.Marshal]::SizeOf([System.IntPtr])*8)) 
 
I know you were going more for the scripts aspect, but you hit the Key Profiles topics, so I thought I'd contribute in that direction.
Posted @ Thursday, December 27, 2012 9:08 AM by Josh Miller
Why do you Test-Path? Force will create needed directories.
Posted @ Thursday, July 04, 2013 8:43 AM by Stephan Onisick
Hi Stephan, 
I am testing the path to know if the profile file exists, and then only if not I suggest to run new-item to create the profile file. 
All of this could be done faster but for clarity I decided to show basic commands that are easier to understand.
Posted @ Thursday, July 04, 2013 9:15 AM by Olivier Raynaut
I really like your article: The thought and organization was Superb! 
 
I've just been thinking out loud.  
 
One of the things that have always bothered me about PowerShell profiles is that the parent directories of the profile are not created by default: 
For example: My profile path is C:\Users\Stephanoi364\Documents\WindowsPowerShell. Correct me if I'm wrong but the "WindowsPowerShell" is there at first. 
And I think the -force creates that directory. This always made it uncomfortable to just to a psedit $profile 
 
The other thing I've been thinking about is to just copy an existing profile (if it exists) to a Profile.yyyy-mm-dd_hhss and then create a new one from a standard place--maybe also do a psedit on the old one so both are open in the ISE. 
 
I think I'm going to write an article--but I'll definitely refer to you.  
 
I'm a SharePointer blog:http://blog.sonisick.com Twitter:@StephanOnisick. I've written a number of SharePoint articles lately for NothingbutSharePoint.com, SharePointReviews.com and SharePoint-Community.net. I've become fascinated with PowerShell lately. 
 
 
A fan, 
Stephan Onisick
Posted @ Thursday, July 04, 2013 9:44 AM by Stephan Onisick
I know this is an old article, and I hope that this is relevant for others.  
 
One thing it doesn't seem you can do is put this into a function in the profile. If you do, the files/scripts will be loaded (or run) but the aliases and functions will not be loaded into the shell. I suppose this is because of the way the profile is loaded. 
 
Is there a way around this? Basically, it would be ideal to only load the functions I need, so I would do: 
 
Set-Alias my_funcs1 Import-MyFuncs1 
Set-Alias my_funcs2 Import-MyFuncs2 
 
Function Import-MyFuncs1 

ChildItem "$script_path/funcs2/*.ps1" | %{.$_} 

 
Function Import-MyFuncs2 

ChildItem "$script_path/funcs2/*.ps1" | %{.$_} 

 
... 
 
Thoughts?
Posted @ Monday, June 16, 2014 9:49 AM by John
Hi John, 
 
This is the reason why I have all my scripts into a folder named "autoload". Every script file I put there will be loaded on PowerShell startup whereas the other ps1 file I put in the root "scripts" folder are not, I have to manually import them. 
 
Is what you're looking for to be able to group functions into a larger set that you could decide to import? If so what are the motivations behind that?
Posted @ Tuesday, June 17, 2014 7:11 AM by Olivier RAYNAUT
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics