12. Execution policies
EMS
is powerful, and just a few cmdlets can have a tremendous effect on
many objects throughout Exchange. You might have thought about how to
control the ability of users to execute EMS commands.
RBAC
provides the first line of protection. As you recall, users are
permitted access only to the set of cmdlets and parameters available to
the roles each user holds. Even though trusted users are assigned the
roles they need to do their work, you still don’t want them to execute
scripts they download from the Internet or obtain elsewhere.
A
second line of defense is therefore provided by Execution Policies,
which define the conditions under which Windows PowerShell loads files
for execution. There are four policies: Restricted, AllSigned,
RemoteSigned, and Unrestricted. You configure the execution policy used
for a server by using the Set-ExecutionPolicy cmdlet. The default is
RemoteSigned, which you can verify by using the Get-ExecutionPolicy
cmdlet. In this mode, EMS permits the execution of any script created
locally and any script downloaded from the Internet, provided the
script includes a digital signature. All the scripts that come with
Exchange are signed for this purpose (see Table 2).
The caveat is that any script you attempt to run can contain only
Exchange cmdlets that are supported by the role the user holds who
invokes the script. Table 2 lists the alternate modes together with the potential trade-off in security that you might have to make for each mode.
Table 2. Windows PowerShell execution policies
Execution Policy mode | Meaning |
|---|
Restricted | No scripts can be run, even if they are signed by a trusted publisher. |
AllSigned | Scripts must be digitally signed by a trusted partner before EMS will run them. |
RemoteSigned | EMS
will run any script created locally. Scripts that originate outside the
system (such as those downloaded from the Internet) cannot be run. |
Unrestricted | EMS will run any script. This mode should be used for test environments only. |
If you attempt to run an unsigned script that doesn’t comply with
policy, Windows PowerShell signals that it cannot load the script.
Scripts are signed with the Set-AuthenticodeSignature cmdlet, but you
need to get a valid certificate first. The certificate can be one you
generate yourself or one you buy from a commercial vendor such as
VeriSign.
Caution
Obviously,
running an Exchange server with an unrestricted execution policy is a
bad idea. In fact, you should avoid any deviation from the default
policy unless you have an excellent reason to change. For example, you
might decide that you want to run scripts you find on the Internet.
This might be acceptable if you run the scripts on a test system only,
but it’s a much better idea to take the time to go through the code to
understand exactly what it does before you think of deploying to a
production system. Remember that if you edit a script to create a new
version on your computer, that version of the script is now considered
local and can be run without changing the execution policy. Opening a
downloaded script and saving it can lead to unintended consequences, so
be sure that you only save a script that you didn’t write when you
absolutely intend to create a new version.
If you deem it
necessary to change the policy, use the Set-ExecutionPolicy command to
update the default execution policy on an Exchange 2013 server. For
example:
Set-ExecutionPolicy –ExecutionPolicy Unrestricted
The
change to the execution policy is effective immediately. Be sure to
test any change you want to make before you enable the change in
production because it might break scripts on which you or applications
depend. Execution policy is a server-specific setting. However, its
setting is recorded in the system registry, and it is possible to use
Group Policy to apply the same setting to every server within the
organization. To do this, configure Group Policy to set the value of
ExecutionPolicy to the desired execution mode. The key is located under:
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft\PowerShell
Note
that because the setting for the execution policy is held in the system
registry, Windows will deny any attempt to update the value unless your
account has the privilege to change the system registry.
When you start EMS, PowerShell runs a script called
Bin\RemoteExchange.ps1 to initialize EMS by loading the Exchange
snap-in and defining a set of variables that EMS uses, such as the
default scope for Active Directory queries. The script also prints some
welcome information for EMS.
If you use EMS frequently, consider
creating a profile EMS can load when it initializes a new session. If
it finds a profile, PowerShell executes the commands in it before it
runs Exchange ps1 to create the EMS session. This order ensures that
you can’t interfere with the creation of the EMS session.
I
like profiles because they remind me of the convoluted logon command
procedures I used to create for OpenVMS. Typical examples of commands
included in profiles are the following:
Define
some aliases (shorthand for commands). For example, you could use
Set-Alias gmbx Get-Mailbox to use gmbx any time you want to run the
Get-Mailbox cmdlet.
Add one or more directories containing scripts to the path, as discussed earlier.
Position your session in a specific directory in which you prefer to work.
PowerShell
defines a global variable called $Profile to hold the location of your
profile. The exact location varies across different versions of
Windows. The profile doesn’t exist by default, and you might have to
create it before you can edit it to add some commands. First, see
whether a profile is available for the account you use:
Test-Path $Profile
If the response is $True, you know that a profile exists. If not, you have to create it with:
New-Item –Path $Profile –Type File –Force
After you have a profile, you can edit it as follows:
Notepad $Profile
Here’s a simple profile that you could begin with:
$env:path = $env:path + ";c:\Scripts"
'You are now entering PowerShell: ' + $env:Username
$StartTime = (Get-Date)
Write-Host "Session starting at $StartTime"
Set-Location c:\temp
After
you finish updating the profile, save the file and restart EMS to see
whether your changes are effective. There are endless possibilities for
inventive code to run within a profile.
