PowerShell profiles in Windows Server 2008 R2

There are four different types of PowerShell profiles in Windows Server 2008 R2, including the all users profile, and you will learn the settings and uses of each of them.

Solutions provider takeaway: From the all users profile to the current user's host-specific profile, you will find out how to locate and load each of the PowerShell profiles in Windows Server 2008 R2. This excerpt provides information on the different settings and uses of each profile.

About the book:
This chapter excerpt on Automating Tasks Using PowerShell Scripting (download PDF) is taken from the book Windows Server 2008 R2 Unleashed. Solutions providers can use this book to learn about Windows Server 2008 R2 migration, administration, deployment and troubleshooting. This book also provides information on management and security tools and features, such as Hyper-V's Live Migration.

Profiles

A PowerShell profile is a saved collection of settings for customizing the PowerShell environment. There are four types of profiles, loaded in a specific order each time PowerShell starts. The following sections explain these profile types, where they should be located, and the order in which they are loaded.

The All Users Profile

This profile is located in %windir%\ system32\ windowspowershell\ v1.0\ profile.ps1. Settings in the All Users profile are applied to all PowerShell users on the current machine. If you plan to configure PowerShell settings across the board for users on a machine, this is the profile to use.

The All Users Host-Specific Profile

This profile is located in %windir%\ system32\ windowspowershell\ v1.0\ ShellID_profile.ps1. Settings in the All Users host-specific profile are applied to all users of the current shell (by default, the PowerShell console). PowerShell supports the concept of multiple shells or hosts. For example, the PowerShell console is a host and the one most users use exclusively. However, other applications can call an instance of the PowerShell runtime to access and run PowerShell commands and scripts. An application that does this is called a hosting application and uses a host-specific profile to control the PowerShell configuration. The host-specific profile name is reflected by the host's ShellID. In the PowerShell console, the ShellID is the following:

PS C:\ $ShellId
Microsoft.PowerShell
PS C:\

Putting this together, the PowerShell console's All Users host-specific profile is named Microsoft.PowerShell_profile.ps1. For other hosts, the ShellID and All Users host-specific profile names are different. For example, the PowerShell Analyzer (www.powershellanalyzer.com) is a PowerShell host that acts as a rich graphical interface for the PowerShell environment. Its ShellID is PowerShellAnalyzer.PSA, and its All Users host-specific profile name is PowerShellAnalyzer.PSA_profile.ps1.

The Current User's Profile

This profile is located in %userprofile%\ My Documents\ WindowsPowerShell\ profile.ps1. Users who want to control their own profile settings can use the current user's profile. Settings in this profile are applied only to the user's current PowerShell session and don't affect any other users.

The Current User's Host-Specific Profile

This profile is located in %userprofile%\ My Documents\ WindowsPowerShell\ ShellID_profile.ps1. Like the All Users host-specific profile, this profile type loads settings for the current shell. However, the settings are user specific.

Note:
When PowerShell is started for the first time, you might see a message indicating that scripts are disabled and no profiles are loaded. This behavior can be modified by changing the PowerShell execution policy.

Security

When WSH was released with Windows 98, it was a godsend for Windows administrators who wanted the same automation capabilities as their UNIX brethren. At the same time, virus writers quickly discovered that WSH also opened up a large attack vector against Windows systems.

Almost anything on a Windows system can be automated and controlled by using WSH, which is an advantage for administrators. However, WSH doesn't provide any security in script execution. If given a script, WSH runs it. Where the script comes from or its purpose doesn't matter. With this behavior, WSH became known more as a security vulnerability than an automation tool.

Execution Policies

Because of past criticisms of WSH's security, when the PowerShell team set out to build a Microsoft shell, the team decided to include an execution policy to mitigate the security threats posed by malicious code. An execution policy defines restrictions on how PowerShell allows scripts to run or what configuration files can be loaded. PowerShell has four primary execution policies, discussed in more detail in the following sections: Restricted, AllSigned, RemoteSigned, and Unrestricted.

Note:
Execution policies can be circumvented by a user who manually executes commands found in a script file. Therefore, execution policies are not meant to replace a security system that restricts a user's actions and instead should be viewed as a restriction that attempts to prevent malicious code from being executed.

Restricted By default, PowerShell is configured to run under the Restricted execution policy. This execution policy is the most secure because it allows PowerShell to operate only in an interactive mode. This means no scripts can be run, and only configuration files digitally signed by a trusted publisher are allowed to run or load.

AllSigned The AllSigned execution policy is a notch under Restricted. When this policy is enabled, only scripts or configuration files that are digitally signed by a publisher you trust can be run or loaded. Here's an example of what you might see if the AllSigned policy has been enabled:

PS C:\ Scripts> .\ evilscript.ps1
The file C:\ Scripts\ evilscript.ps1 cannot be loaded. The file
C:\ Scripts\ evilscript.ps1 is not digitally signed. The script will not
execute on the system. Please see "get-help about_signing" for more
details.
At line:1 char:16
+ .\ evilscript.ps1 < < < <
PS C:\ Scripts>

Signing a script or configuration file requires a code-signing certificate. This certificate can come from a trusted certificate authority (CA), or you can generate one with the Certificate Creation Tool (Makecert.exe). Usually, however, you want a valid code-signing certificate from a well-known trusted CA, such as VeriSign, Thawte, or your corporation's internal Public Key Infrastructure (PKI). Otherwise, sharing your scripts or configuration files with others might be difficult because your computer isn't a trusted CA by default.

RemoteSigned The RemoteSigned execution policy is designed to prevent remote PowerShell scripts and configuration files that aren't digitally signed by a trusted publisher from running or loading automatically. Scripts and configuration files that are locally created can be loaded and run without being digitally signed, however.

A remote script or configuration file can be obtained from a communication application, such as Microsoft Outlook, Internet Explorer, Outlook Express, or Windows Messenger. Running or loading a file downloaded from any of these applications results in the following error message:

PS C:\ Scripts> .\ interscript.ps1
The file C:\ Scripts\ interscript.ps1 cannot be loaded. The file
C:\ Scripts\ interscript.ps1 is not digitally signed. The script will not execute on
the system. Please see "get-help about_signing" for more details..
At line:1 char:17
+ .\ interscript.ps1 < < < <
PS C:\ Scripts>

To run or load an unsigned remote script or configuration file, you must specify whether to trust the file. To do this, right-click the file in Windows Explorer and click Properties. On the General tab, click the Unblock button (see Figure 21.2).

After you trust the file, the script or configuration file can be run or loaded. If it's digitally signed but the publisher isn't trusted, however, PowerShell displays the following prompt:

PS C:\ Scripts> .\ signed.ps1

Do you want to run software from this untrusted publisher?

FIGURE 21.2 Trusting a remote script or configuration file.

File C:\ Scripts\ signed.ps1 is published by CN=companyabc.com, OU=IT,
O=companyabc.com, L=Oakland, S=California, C=US and is not trusted on your
system. Only run scripts from trusted publishers.
[V] Never run [D] Do not run [R] Run once [A] Always run [?] Help
(default is "D"):

In this case, you must choose whether to trust the file content.

Unrestricted As the name suggests, the Unrestricted execution policy removes almost all restrictions for running scripts or loading configuration files. All local or signed trusted files can run or load, but for remote files, PowerShell prompts you to choose an option for running or loading that file, as shown here:

PS C:\ Scripts> .\ remotescript.ps1

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful,
this script can potentially harm your computer. Do you want to run
C:\ Scripts\ remotescript.ps1?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):

In addition to the primary execution policies, two new execution policies were introduced in PowerShell 2.0, as discussed in the following sections.

Bypass

When this execution policy is used, nothing is blocked and there is no warning or prompts. This execution policy is typically used when PowerShell is being used by another application that has its own security model or a PowerShell script has been embedded into another application.

Undefined

When this execution policy is defined, it means that there is no execution policy set in the current scope. If Undefined is the execution policy for all scopes, the effective execution policy is Restricted.

Setting the Execution Policy

About the authors:

Rand Morimoto has been in the IT industry for more than 25 years and is the president of Convergent Computing, an IT-consulting firm. Morimoto has also co-authored Exchange Server 2010 Unleashed.

Michael Noel is an IT expert and partner at Convergent Computing and co-wrote Microsoft SharePoint 2007 Unleashed.

Chris Amaris cofounded Convergent Computing and serves as the chief technology officer. Amaris has also co-authored Microsoft Exchange Server 2007 Unleashed.

Omar Droubi has been in the computer industry for more than 15 years and has co-authored Windows 2003 Unleashed.

Ross Mistry has spent more than a decade in the computer industry and has also published Microsoft SQL Server 2008 Management and Administration.

By default, when PowerShell is first installed, the execution policy is set to Restricted. To change the execution policy, you use the Set-ExecutionPolicy cmdlet, shown here:

PS C:\ > set-executionpolicy AllSigned

Or, you can also use a Group Policy setting to set the execution policy for number of computers. In a PowerShell session, if you want to know the current execution policy for a machine, use the Get-ExecutionPolicy cmdlet:

PS C:\ > get-executionpolicy
AllSigned
PS C:\ >

Execution policies can not only be defined for the local machine, but can also be defined for the current user or a particular process. These boundaries between where an execution policy resides is called an execution policy scope. To define the execution policy for a scope, you would use the Scope parameter for the Set-ExecutionPolicy cmdlet. Additionally, if you wanted to know the execution policy for a particular scope, you would use the Scope parameter for the Get-ExecutionPolicy cmdlet. The valid arguments for the Scope parameter for both cmdlets are Machine Policy, User Policy, Process, CurrentUser, and LocalMachine.

Note:
The order of precedence for the execution policy scopes is Machine Policy, User Policy, Process, CurrentUser, and LocalMachine.


Automating Tasks Using PowerShell Scripting
  PowerShell commands in Windows Server 2008 R2
  PowerShell remoting in Windows Server 2008 R2
  Using PowerShell ISE and alias cmdlets
  PowerShell profiles in Windows Server 2008 R2

Printed with permission from Sams Publishing. Copyright 2010. Windows Server 2008 R2 Unleashed by Rand Morimoto, Michael Noel, Omar Droubi and Ross Mistry. For more information about this title and other similar books, please visit Sams Publishing.

This was first published in April 2010

Dig deeper on Server Operating Systems: Windows, Linux and Unix

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

MicroscopeUK

SearchCloudProvider

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchConsumerization

SearchDataManagement

SearchBusinessAnalytics

Close