{"id":26186,"date":"2016-05-16T00:00:00","date_gmt":"2016-05-16T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/persistent-powershell-the-powershell-profile\/"},"modified":"2017-10-03T13:33:44","modified_gmt":"2017-10-03T13:33:44","slug":"persistent-powershell-the-powershell-profile","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/sysadmin\/powershell\/persistent-powershell-the-powershell-profile\/","title":{"rendered":"Persistent PowerShell: The PowerShell Profile"},"content":{"rendered":"
\n

While you work with a PowerShell session, you can modify its state (or environment) in any number of ways: You might import modules, create functions, specify aliases, or define variables, to name a few. But all of those are transitory: their effects disappear as soon as you close the PowerShell session. However, PowerShell provides a mechanism, called the PowerShell profile<\/em>, which allows you to recreate any such environmental constructs and settings each time you start up a new PowerShell session. And if one profile is good, wouldn’t more be better? It turns out that any single PowerShell session may use any one (or all) of four<\/em> different profiles, and different<\/em> PowerShell hosts provide yet more profile choices: But it is actually much simpler to use than all this might appear, once you appreciate where all the moving parts fit. Let’s take a look.<\/p>\n

The Shell in PowerShell<\/h2>\n

There is a distinction between the shell<\/em> and the host<\/em> in PowerShell. Don Jones, in his aptly titled post The Shell vs. The Host<\/a>, explains that you-as a user typing at the keyboard-do not<\/em> directly interact with PowerShell’s shell (or engine). Rather more accurately, you interact with a host application (like powershell.exe or powershell_ise.exe) that creates a runspace<\/em> (an instance of the PowerShell engine). You can actually see the distinction by displaying the contents of the Name property of the $Host<\/code> system variable alongside the $ShellId<\/code> variable. You will see that, if you examine the values for the three most common PowerShell hosts, they all use the same engine (shell) while each presents a different user interface (host).<\/p>\n\n\n\n\n\n\n\n
Host<\/td>\n$Host.Name<\/td>\n$ShellId<\/td>\n<\/tr>\n<\/thead>\n
PowerShell<\/td>\nConsoleHost<\/td>\nMicrosoft.PowerShell<\/td>\n<\/tr>\n
PowerShell ISE<\/td>\nWindows PowerShell ISE Host<\/td>\nMicrosoft.PowerShell<\/td>\n<\/tr>\n
Visual Studio Package Manager Console<\/td>\nPackage Manager Host<\/td>\nMicrosoft.PowerShell<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Other PowerShell hosts could potentially have different $ShellId<\/code> values (for example, some of the freely available PowerShell IDEs include PowerGUI, PowerShell Analyzer, and PowerShell Plus, but I’ve not checked their $ShellId<\/code> values).<\/p>\n

The PowerShell Profile<\/h2>\n

A PowerShell profile is nothing more than a fancy name for a script that runs when a PowerShell host starts. Quoting standard PowerShell help on about_profiles<\/a>, “You can use the profile as a logon script to customize the environment. You can add commands, aliases, functions, variables, snap-ins, modules, and Windows PowerShell drives. You can also add other session-specific elements to your profile so they are available in every session without having to import or re-create them.”<\/p>\n

Each PowerShell host actually supports two<\/em> profiles, one is user<\/em>-level, distinct for each user, and the other is system<\/em>-level, common to all users. This should be a familiar paradigm that you will have seen with many Windows applications. PowerShell adds its own unique twist, though: it similarly distinguishes between host<\/em>-level (one profile for each host) and system<\/em>-level (one common profile for all hosts).<\/p>\n

Thus, taking all the combinations of users and hosts, you could potentially use any (or all) of four<\/em> different profiles:<\/p>\n