Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Using Windows PowerShell in an Exchange Server 2010 Environment : Starting the Exchange Management Shell

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/24/2011 2:38:34 PM
Quite a bit happens behind the scenes when the Exchange Management Shell is launched.

When the administrator clicks the Exchange Management Console shortcut to open EMS, Windows PowerShell V2 is launched, and some Exchange Server-specific scripts are run. These scripts find the most suitable Exchange Server 2010 server and attempt to connect to its PowerShell virtual directory in IIS using WinRM. Assuming the administrator has rights to connect, Exchange Server then determines which RBAC management roles have been assigned to the administrator. Finally, it creates an ESM environment that contains all the Exchange Server management cmdlets that the administrator is allowed to use.

As noted earlier, all EMS instances are actually made as remote connections, even if EMS is opened on a local Exchange server. The previous steps occur every time EMS is opened.

Note

Simply opening PowerShell V2 is not the same as the Exchange Management Shell. PowerShell does not automatically make a remote connection to the Exchange server and does not include any of the Exchange Server–specific cmdlets, such as Get-Mailbox.


When the administrator opens EMS the first time, all the Exchange Server cmdlets available for that RBAC role will be downloaded to the local computer. Figure 1 shows EMS connecting to an Exchange Server 2010 server for the first time and importing the cmdlets to which the administrator has access.

Figure 1. Connecting to an Exchange Server 2010 server with EMS.

After connecting, the administrator can run EMS and PowerShell cmdlets, as usual.

Note

The PowerShell Get-Command cmdlet is useful to see a list of cmdlets to which the administrator has access.


It is important to understand that the Exchange Server–specific cmdlets that are downloaded to the local computer actually run on the Exchange Server 2010 server. For example, when an administrator with the RecipientAdministrator role launches EMS from a remote computer, the cmdlets associated with that role are imported into the remote computer’s EMS environment. When the administrator runs an Exchange Server 2010 cmdlet, EMS proxies the command to the Exchange server, on which the command is carried out. The output from the command is then proxied back to the remote computer for display or further processing.

When EMS opens a remote connection to an Exchange Server 2010 server, the connection remains open until EMS is closed. This is made possible by a managed hosting API built into PowerShell and is also utilized by the Exchange Management Console. By keeping the connection open, better performance is achieved in both EMS and EMC.

Starting EMS from a Non-Exchange Server

To use EMS on a remote computer, PowerShell V2 and its prerequisites must be installed on the computer and the Active Directory account must be given remote administration rights.

EMS relies on remoting, which is possible using PowerShell V2, WinRM 2.0, and the .NET Framework 2.0, or greater. All these components are available for free download from the Microsoft Download Center. PowerShell V2 is installed with the operating system by default in Windows 7 and Windows Server 2008 R2. It must be downloaded and installed on Windows XP SP2 or greater, Windows Vista, and Windows Server 2008.

Note

Windows Server 2008 includes Windows PowerShell as an optional feature that can be installed after the operating system is installed. This feature is PowerShell V1, not PowerShell V2 as required by Exchange Server 2010 EMS. You must uninstall the PowerShell feature if it is installed before installing PowerShell V2 from the Microsoft Download Center.


It doesn’t matter whether the x86 or x64 version of PowerShell V2 is installed on the local computer because the EMS commands are actually run on the remote Exchange Server 2010 server, as described in the previous section.

After PowerShell V2 is installed, you must also configure the PowerShell script execution policy. By default, Windows PowerShell is set to a secure configuration that prevents any scripts from running. To allow EMS to run its connection scripts, you must set the execution policy to run digitally signed scripts with the following command:

Set-ExecutionPolicy RemoteSigned

Note

Setting the execution policy writes to the Registry. You might need to run PowerShell as an Administrator to configure the execution policy.


The Active Directory account used to install Exchange Server 2010 will be granted remote management rights in PowerShell by default. To grant this right to another Active Directory user, the administrator must use the Set-User cmdlet with the RemotePowerShellEnabled parameter. For example, to grant this right to a user named Keith Johnson, the administrator enters the following at the PowerShell prompt:

Set-User 'Keith Johnson' –RemotePowerShellEnabled $True

After these one-time prerequisites are met, it’s time to run EMS remotely. The Active Directory user (Keith Johnson, in this example) enters the following commands at the PowerShell prompt:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<Exchange2010fqdn>/PowerShell -Authentication Kerberos
Import-PSSession $session


The first line defines the variable $session to be the remote PowerShell session object on the Exchange Server 2010 server. The second line tells PowerShell to import the remote session object to this computer. When this second line is executed, PowerShell makes a remote connection to the specified Exchange server over the standard HTTP port 80, authenticates using Kerberos, and imports all the cmdlets that the user has rights to use, based on the RBAC role(s) assigned to the user in Exchange Server.

It’s important to understand that EMS will only download the appropriate cmdlets for the RBAC administration role of the user running EMS. For example, a user running EMS who is a member of the Records Management security group gets a small subset of Exchange Server cmdlets to work with. If that same user runs PowerShell using the Windows RunAs command as a user who is a member of the Organization Management group, almost all the Exchange Server cmdlets will be available to work with.

The EMS environment is dynamic. When the remote Exchange Management Shell is closed, the local cmdlets are cleared from the environment. That means that another user running EMS from the same computer will not have access to cmdlets that he doesn’t have rights to run.

Connecting to Another Exchange Server Organization

Connecting to an Exchange Server 2010 server in a different Active Directory forest is achieved basically the same way as previously described. The main difference is that we cannot use Kerberos for authentication. For this, we must use explicit credentials. Open a PowerShell prompt and enter the following command:

$UserCredential = Get-Credential

This causes PowerShell to invoke the Windows GUI to prompt for a username and password, as shown in Figure 2.

Figure 2. Creating the $UserCredential variable.


Now we run the following two PowerShell commands to connect to the remote Exchange Server 2010 server, authenticate, and create the EMS environment:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<Exchange2010fqdn>/PowerShell -Authentication $UserCredential
Import-PSSession $session


Notice that the commands are identical to the previous command, except that we are now passing the $UserCredential variable for authentication instead of using Kerberos.

Creating a Shortcut for Remote EMS

Typing the preceding commands every time you want to run EMS remotely is tedious. The following procedures explain how to create a PowerShell script that runs these commands by clicking a shortcut.

First, open a text editor, such as Notepad, or use the Windows PowerShell Integrated Scripting Environment (ISE), which is new to PowerShell V2. Then enter the same commands, as previously entered:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<Exchange2010fqdn>/PowerShell -Authentication Kerberos
Import-PSSession $session


Save the new file as EMS.PS1 somewhere on your local computer or a network share, making note of the path where you saved it. Now create a new shortcut to PowerShell on the Windows desktop. Rename the new shortcut to Exchange Management Shell. Right-click the shortcut and select Properties. Add the following text to the end of the Target text:

-noexit <path>\EMS.PS1

Click OK to save the shortcut. When you double-click the Exchange Management Console icon on the desktop, PowerShell opens, launches the EMS.PS1 script, and remains open after the script executes.

Other -----------------
- Using Windows PowerShell in an Exchange Server 2010 Environment : Understanding the Exchange Server Task Model
- SharePoint 2010 : Creating Meeting Workspaces from Outlook 2007 and Outlook 2010
- Connecting SharePoint 2010 Content to Outlook 2010
- Using SharePoint Workspace with SharePoint 2010
- Coauthoring Word 2010 and PowerPoint 2010 Documents Stored in SharePoint 2010
- Exchange Server 2010 : Address List Configuration (part 2) - Working with Offline Address Books
- Exchange Server 2010 : Address List Configuration (part 1) - Creating and Configuring an Address List
- Windows Server 2008 R2 : Supporting Remote Desktop Services
- Windows Server 2008 R2 : Securing Remote Desktop Services
- Exchange Server 2010: Deploying Exchange Databases (part 3) - Managing Public Folder Databases
 
 
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
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server