Types of profile
There are six different ones.
- Both the Windows PowerShell console and the Windows PowerShell ISE have their own profiles.
- There are profiles for the current user, as well as profiles for all users.
The whole table:
| Description | Path |
| Current User, Current Host – console | $Home\[My ]Documents\WindowsPowerShell\Profile.ps1 |
| Current User, All Hosts | $Home\[My ]Documents\Profile.ps1 |
| All Users, Current Host –console | $PsHome\Microsoft.PowerShell_profile.ps1 |
| All Users, All Hosts | $PsHome\Profile.ps1 |
| Current user, Current Host – ISE | $Home\[My ]Documents\WindowsPowerShell\Microsoft.P owerShellISE_profile.ps1 |
| All users, Current Host – ISE | $PsHome\Microsoft.PowerShellISE_profile.ps1 |
In the table, the automatic variable $home points to the users\username directory on the system. The $pshome automatic variable points to the Windows PowerShell installation folder. This location typically is C:\Windows\System32\WindowsPowerShell\v1.0 (for compatibility reasons, the Windows PowerShell installation folder is in the v1.0 folder—even on Windows PowerShell 4.0).
Understanding the six different windows Powershell Profiles
The Shell , The Host
Before we getting deep into the profile, we need to figure out the meaning of host, shell.
To interact directly with PowerShell’s engine you need a host application that lets you do so. The standard console – PowerShell.exe – is one such host; the Integrated Script Environment (ISE) is another. Those hosts “spin up” a run-space, which is essentially an instance of the PowerShell engine.
Most of the “built-in” variables you’re used to working with in the ISE or the console aren’t actually built into the engine, they’re built into those hosts.
It’s pretty important to understand these potential differences. When a developer sets out to create their own host application – like most of the commercial script editors do – it can be very confusing and frustrating, because they essentially have to reverse-engineer much of what the PowerShell.exe console application is doing, so that they can provide an equivalent experience. But you should never assume that a script’s behavior under one host will be consistent in all other hosts; test and verify.
Profiles
The first thing to do in understanding the six different Windows PowerShell profiles is to keep in mind that the value of $profile changes depending on which Windows PowerShell host you use. It’s a moving target. In most cases, people are referring to the current user, current host profile.
PowerShell profile is a Windows PowerShell script, you must enable the script execution policy prior to configuring and using a Windows PowerShell profile.
$profile variable
The $profile automatic variable contains the path to the Current User, Current Host profile.
In the Powershell Console:
User_profile_folder\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
In the Powershell ISE:
User_profile_folder\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1
Unraveling the different Profiles
You can pipeline the $profile variable to the Get-member cmdlet and see additional properties that exist on the $profile variable:
$profile | get-member -membertype NoteProperty | fl
or
$profile | format-list * -Force
Return the specific profile: directly access each of these specific properties—just like you would access any other property—via dotted notation.
$Profile.AllUsersAllHosts
$Profile.AllUsersCurrentHost
$Profile.CurrentUserAllHosts
$Profile.CurrentUserCurrentHost
Determine whether a specific profile exists
To determine if a specific profile exists, use the Test-Path cmdlet and the appropriate note property of the $profile variable.
test-path $profile.currentUserCurrentHost
Create a specific profile
Use New-item cmdlet, new-item $profile.CurrentUserAllHosts -ItemType file -Force
Edit: To open the profile for editing, use the ise alias, as appears here:
ise $PROFILE.CurrentUserAllHosts
Design consideration for profile
The distinction between the Windows PowerShell ISE profiles and the Windows PowerShell console profiles is the ISE in the name of the Windows PowerShell ISE profiles. There are three different names used for the Windows PowerShell profiles:
1. Microsoft. Powershell_profile.ps1 : Refers to profiles for the windows Powershell console
2. Profile.ps1 : refers to profiles for all windows Powershell hosts.
3. Microsoft. PowershellISE_profile.ps1: refers to profiles for Windows Powershell ISE
The location of the Windows PowerShell profile determines the scoping, whether the profile applies to either the current user or to all users.
- All user profiles appear in the Windows\system32\WindowsPowerShell\v1.0 directory, which can be referenced by the $pshome variable.
- Three Current user Windows Powershell Profiles is located in user’s my documents folder, which can be referenced by the GetFolderPath method from the system.Environment.Net framework class.
[environment]::getfolderpath("my documents")
Using one or more profiles
using one Windows PowerShell profile for the Windows PowerShell console and another profile for the Windows PowerShell ISE may be a perfectly acceptable solution. Simplicity makes this approach work. For example, certain commands, such as the Start-Transcript cmdlet, do not work in the Windows PowerShell ISE. In addition, certain commands, such as those requiring Single-Threaded Apartment model (STA), do not work by default in the Windows PowerShell console.
All users, All hosts profile
■ Advantages of using the All Users, All Hosts profile:
• It’s simple; you can use one location for everything, especially when added during the build
process.
• One file affects all Windows PowerShell users and hosts.
• It avoids conflict between admin users and non-admin users, since both types of users use the same profile.
• $profile.AllUsersAllHosts always points to the correct file.
• It’s great for central management—one file is used for all users of a machine.
■ Disadvantages:
• You must have admin rights on the current machine to make changes to the file.
• It provides no distinction between different hosts—some commands will not work in ISE and others will not work in the Windows PowerShell console.
• It makes no distinction between admin users and non-admin users. Non-admin users will not be able to run certain commands.
• The les are distributed among potentially thousands of different machines. To make one change to a profile, you must copy a file to all machines using that profile.
■ Uses:
• Use for your personal profile when duties require both elevation and non-elevation of
permissions across multiple Windows PowerShell hosts.
• Use as part of a standard image build to deploy static functionality to numerous machines and users.
Use your own file
Keep the profile itself as simple as possible, but bring in the function via other means.
One popular way is storing that function file in a central location, and then dot-source it to the profile.
Central Profile Script:
1. Create a windows Powershell Script containing the profile information you require, and store it in a central share location.
2. In the windows Powershell profile script to host the central profile, dot-source the central profile.
E.g. a File is saved in C:\scripts\myprofile1.ps1, which has a sharing address \\mydomain\scripts\myprofile1.ps1
In the Profile file, use
. \\mydomain\scripts\myprofile1.ps1
Advantage:
• It provides one place to modify the profile, or all users and all hosts having access to
the file.
• It’s easy to keep functionality synchronized among all Windows PowerShell hosts and users.
• It makes it possible to have one profile for the entire network.
Disadvantages:
• It’s more complicated due to multiple files.
• It provides no access to the central file, which means you won’t have a profile for machines without network access.
• It is possible that non-role-specific commands will become available to users.
• Filtering out specific commands for specific hosts becomes more complex.
• One central script becomes very complicated to maintain when it grows to hundreds of lines.
Group similar functions into a module
Fo example functions such as:
■ A function to determine admin rights
■ A function to determine if the computer is a laptop or a desktop
■ A function to determine if the host is the Windows PowerShell ISE or the Windows PowerShell console
■ A function to determine if the computer is 32 bit or 64 bit
■ A function to write to a temporary file
Where to store the profile module
If you run your system as a non-elevated 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 requiring admin rights in the system32 directory hierarchy. Keep in mind that updates to admin modules will also require elevation and therefore could add a bit of complication. 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 shown here:
Get-Module -ListAvailable
However, this does not mean 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 module manifest) in the shared network location as well.