Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
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.