How Exchange Leverages Windows PowerShell

From an Exchange perspective, Windows PowerShell provides a way to perform tasks quickly and simply in variety of manners. Prior to Exchange 2007, there was no way for administrators to automate common tasks to meet need to their organization; essentially if exchange engineer didn't code something into product, it couldn’t be done.

Below figure illustrates the central role that Windows PowerShell now plays in the Exchange architecture and how it provides a central place to encapsulate Business Logic that underpins the Exchange Setup program, EMS, EMC and ECP.

       Figure: Windows PowerShell at the heart of Exchange

The options presented by EMC to work with mailboxes, connectors, servers and other objects invariably results in a call to one or more PowerShell cmdlets that actually do the work.

The critical point is that the four major administrative interfaces in Exchange all lead to the same place and execute same Business Logic. Apart from removing redundant and overlapping code, having single place to implement Business Logic allows Exchange Engineer to concentrate on implementing new functionality rather than redeveloping features separately and specifically for EMC, EMS or other setup programs. This approach allows Exchange to deliver more consistent environment and a comprehensive method to automate tasks to deal with mailboxes, connectors, databases and all other components that collectively make up and Exchange Environment.

                                                                       

The RTM release of Exchange 2010 includes 584 cmdlets that are added to EMS to join standard set of Windows PowerShell cmdlets, including cmdlets to work with system registry, file system, variables ( including environment variables) and so on. The number of cmdlets grows again to 619 in Exchange 2010 SP1.

You can determine exact number of cmdlets owned by Exchange with the following command:

Get-ExCommand | Measure-Object | Select Count

You can use below command to generate full list of Exchange cmdlets that your account can access:

Get-ExCommand > C:\ExCommand.Csv

By comparison, Exchange 2007 includes 394 cmdlets, 26 of which have been removed in Exchange 2010. The 216 new cmdlets provided in Exchange 2010 reflects the new functionality in the product, such as introduction of RBAC model, mailbox archives, Database availability group (DAG) along with expansion of existing functionality such as messaging records management.

# Remote PowerShell:

Windows PowerShell has been at the heart of Exchange since Exchange 2007. Exchange 2007 was the first major server product to embrace Windows PowerShell extensively. However lack of remote capability was more serious because it required installation of Windows PowerShell and its snap-ins for exchange on any workstation or server from which you wanted to perform management tasks.

Installing software is an acceptable requirement in environments where all the servers are under your control and within your own network, but it caused problems when you want to manage servers remotely. The Microsoft introduction of Online services where companies will be able to run their exchange environments inside large Microsoft datacenters means that remote management has taken a new importance.

Exchange 2010 includes many new feature designed to ease the transition to online services and remote PowerShell provides the fundamental building blocks for management.

Exchange 2010 extends the concept of remote management to support the remote execution of commands in a secure manner using HTTPS and a Kerberos-based encryption. Here is an interesting thing to know about Exchange 2010 sessions. In Exchange 2010, remote PowerShell is used for all EMS sessions. Which means, even if you are logged on the server and want to user EMS to change property of that server, EMS still creates a remote session to the local server to the work. The same applies to EMC. In effect, remote PowerShell replaces local PowerShell in Exchange 2010 for all server roles except Edge servers.

Removal of local PowerShell and the concentration on the combination of remote PowerShell with and RBAC as the basis for administrative control over Exchange components is a major change in the product.

The logic of replacing local PowerShell with remote model is simple. Just like then change in Exchange 2007 to force all messages to flow through the transport system so that single common place existed to apply features such as transport rules, remote PowerShell forces exchange administration to flow through RBAC so that the PowerShell session will only ever include set of cmdlets to do your job !

The logic of keeping local PowerShell on Edge servers is simple too. These are the isolated from the rest of the organization so they do not have access to remote RBAC roles. Anyone who logs on the Edge server as an administrator operates in the context of management of just that server and has complete control over that server. However, he can not affect any other server or object in the Exchange organization.

The need to support hosting platforms such as Microsoft Business Productivity Online Services (BPOS) was major influence on Exchange’s move to remote PowerShell.

Permissions granted through RBAC are evaluated at the time of session initialization. If you are assigned a new role then you have to create a new session with EMS, ECP or EMC before you can access the cmdlets made available through newly assigned role.

# Advantage of Remote PowerShell:

Microsoft does not make changes to product like Exchange unless they see some clear advantage. There are 3 potential advantages of remote PowerShell.

1 1.Separating client and server processing and using IIS as the mechanism to route the traffic allows communication through a well understood route that can flow across firewalls and so accommodate both Microsoft Online Services and enterprise customers that operate multiple active directory forest.

2 2.The ability for administrators to delegate the tasks to other users on the basis of well defined roles adds to overall system security and prevents inadvertent mistakes that can affect essential data.

   3. Remote capability means you can perform Exchange management tasks from a workstation connected to your network without installing Exchange management tools. Of course you still need to install Windows PowerShell and any prerequisites software such as WinRM, .Net Framework, but these components are more likely to be part of corporate build for administrator’s workstation.