Introduction to the storage location of Powershell Profiles configuration files

Applicable to: Windows PowerShell 2.0, Windows PowerShell 3.0

When we open a PowerShell dialog box and create some variables and functions in it, these variables and functions are only valid in the current session. Once we close this dialog and reopen PowerShell, these variables no longer exist. If we want to keep these settings, we need to use profile, which is the configuration file when translated. When PowerShell starts, the settings in the configuration file will be automatically imported. This is a bit like that. If you have an impression of the Dos system, you should know this.

The configuration files are stored in the following places, with different configuration files and different scopes.

1、%windir%\system32\WindowsPowerShell\v1.0\profile.ps1
It works on all users and all shells.

2、%windir%\system32\WindowsPowerShell\v1.0\ Microsoft.PowerShell_profile.ps1
It works on all users, but only on this shell. I don't understand what this means. Is there another PowerShell shell that is not PowerShell? Uh, it's kind of like a tongue twister.

3、%UserProfile%\My Documents\WindowsPowerShell\profile.ps1
All shells that act on the current user.

4、%UserProfile%\My Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
This shell that acts on the current user.

The above Windows PowerShell profiles are not automatically created. The implication is that if we want to use it, we will create it ourselves. We just need to write our own content according to the file path and file name given above.

There is a variable: $profile, which saves the path to the current Profile. Use Test-Path $profile to see if there is currently this file. If not, you can use the new-item -path $profile -itemtype file -force command to create it. Then use notepad $profile to quickly open it for editing. We enter function pro { notepad $profile } in it, and anyone with discerning eyes understands it. When we want to modify the profile in the future, just run the pro command directly.

Finally, if PowerShell can successfully load the configuration file when it starts, you also need to set it to allow it to do so in PowerShell's Execution Policy. Otherwise, attempts to load the configuration file will fail and an error message will also be displayed on the PowerShell interface. The error prompt for the configuration file cannot be loaded is as follows:

In fact, solving this problem is the same as solving the problem of executing ps1 files, because this Profile is actually a ps1 format file. So use Set-ExecutionPolicy RemoteSigned.

Reference article: /en-us/library/bb613488%28VS.85%