IT tutorials
 
Applications Server
 

Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 7) - Execution policies, Profiles

12/1/2013 8:24:10 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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.

13. Profiles

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.

 
Others
 
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 6) - Bulk updates, Calling scripts
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 5) - Server-side and client-side filters
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 4) - Identities, Piping
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 3) - Using common and user-defined variables, Using PowerShell ISE with Exchange
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 2) - Handling information EMS returns , Selective output
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 1) - Command editing
- Exchange Server 2013 : The Exchange Management Shell - Using remote Windows PowerShell - Connecting to remote PowerShell
- Exchange Server 2013 : The Exchange Management Shell - How Exchange uses Windows PowerShell
- Active Directory Planning and Installation : Installing Active Directory - Promoting a Domain Controller
- Active Directory Planning and Installation : Understanding Domain and Forest Functionality
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
Facebook
 
Technology FAQ
- IIS Web site works in all browsers except Safari on Mac
- notification
- alternative current in to a pc
- parse url in JavaScript
- Dual WAN on a Fortigate 60
- Should Sys Admins (Domain Admins) also have user accounts?
- DR solution for data warehouse
- C# Creating Plugins
- SCCM 2007 collection by OU not showing all pc's
- Email account got spoofed?
programming4us programming4us