First, we all start using PowerShell immediately without paying attention how PowerShell profiles can help us in our scripting experience. All of the sudden, we got a big number custom build scripts and functions that we are loading manually. Well, to cut down time to build and access our code we are going start getting our PowerShell Profiles.
For further information about Windows PowerShell Profiles, check this MSDN link:
Quick Profiles Overview:
For the PowerShell Console we have 4 profiles:
With PowerShell V2, the Windows PowerShell ISE has two additional profiles:
In this blog, I will cover only the 2 profiles #1 and #3:
User Profile (Microsoft.PowerShell_profile.ps1) and the Windows global profile (profile.ps1).
User Profile – “Microsoft.PowerShell_profile.ps1”:
Where is the User Profile located? You’ll find it in the User Document folder under “WindowsPowerShell”. The name of the file is “Microsoft.PowerShell_profile.ps1”. This file doesn’t exist, so it need to be created. Keep in mind, if you have already install any other third-party PowerShell tool, there’s a chance they have created their product PowerShell profile in this folder too.
PowerShell User profile located in: (example)
Windows Profile – “profile.ps1”:
Where is the Windows Profile located? It’s in your Document folder under “..\Windows\System32\WindowsPowerShell”. You need to create this file because it doesn’t exist. This profile will be use globally available to all users. Again, PowerShell installation will not create this file for you.
Windows PowerShell Profile located in:
Using both Profiles
Now, there’s a loading for profiles, if you are using both the User and the Windows profiles. First, loads the User profile, follow by Windows profile. It’s important to understand the possibility the last profile could overwrite the previous one.
Loading installed 32 and 64bit Third-party snapins
As you find and installed some “Excellent” Third-party PowerShell tools, then you realized that they can be a 32bit, 64bit, and sometimes they will include both versions. Keep in mind, each vendor will provide you with their version of the PowerShell console were they load their product snapins. Now, thanks to Windows 7 both 32bit and 64bit version of PowerShell including their ISE Editor. So, there’s no excuses about you can’t build a script on you 64bit machine because you can’t use your 32bit snapins. Let’s get to work!! You will get errors when loading 32bit snapins on a 64bit PowerShell , or the way around. Now to work around this issue we are going to take advantage of PowerShell profiles. Keep in mind, there’s only one User Profile and/or one Windows Profile for both 32 and 64bits PowerShell. Forgot to mention, you can build your own profile if you want.
Working with User Profile
The following sample will demonstrate a simple start to handle both 32bit and 64bit PowerShell with the help of Profiles. On my computer, I have an instance of SQL Server 2008 installed. As you all know by now, SQL Server 2008 has its own version of Powershell (a mini-shell based on version 1) to help manage your database engine.
Now, I add to my User Profile (“Microsoft.PowerShell_Profile.ps1”) the necessary PowerShell code to load all the SQL Server snapins and provider. This will work when I open my 64bit PowerShell console. But, I’ll get an error when I open the 32bit version of PowerShell.
Sample 32bit: Errors shows because it can’t load any 64bit snapins on a 32bit console:
Sample 64bit PowerShell Console loading SQL Server 2008 snapins and providers:
A Simple Solution:
We can add the $Environment variable “Process_Architecture” to identify on which version of PowerShell Console is running: 32bit (x86) or 64bit. Then, with a conditional “if” inside our profile, we can help identify our environment. And, will look something like this:
Now, we get the following results with no errors while loading PowerShell console:
As you notice, it isn’t a bad idea to change the PowerShell Console colors. You can easily identify which console you have open.