What’s New In Exchange 2010 & Remote PowerShell

It might seem a little odd to write an article entitled “what’s new” about any aspect of Microsoft Exchange Server 2010, given that it has been out for almost 2 years now. It’s true that many aspects of Exchange 2010 have been covered in great detail.

However, the changes to the Exchange Management Shell (EMS) haven’t been covered in great detail. These changes are significant because EMS underlies and is intertwined with Exchange management at every level. All the GUIs you see in Exchange are built on top of EMS, and everything you can do in the Exchange Management Console (EMC), from the command line, or from the Exchange Control Panel (ECP) ultimately relies on the correct execution of EMS.

For the purposes of this article, I assume you’re somewhat familiar with EMS in either Exchange 2010 or Exchange 2007. The article focuses on new features and changes in Exchange 2010, so if you’re a complete PowerShell beginner, you might find the Learning Path at the end of the article to be helpful.
 

PowerShell Architecture

You can’t really tell from just looking at its character-based interface, but PowerShell itself is actually quite a sophisticated piece of engineering. Its designers wanted to replace the traditional Windows Command-Line Interface (CLI) with something better: something that combines the expressive power of previous CLI implementations such as DEC VMS, the rich composition ability of UNIX shells, and the ability to manipulate objects that represent things in the system, as opposed to mere text on screen.

To do this, the PowerShell team built a language interpreter, a runtime, and a set of interfaces that allow PowerShell cmdlets to call native Windows services. On top of this, the Exchange team built a large set of Exchange-specific cmdlets that let us directly interact with and manage various parts of Exchange. Figure 1 shows EMS’s layered architecture.
 

Figure 1: EMS is layered, like a parfait

In Exchange Server 2007, EMS commands are executed locally. In Exchange 2010, EMS commands are executed across the network. This is possible because of a new component known as Windows Remote Management. WinRM is Microsoft’s implementation of an Internet-standard management protocol known as Web Services for Management (WS-MAN). (For information about other related standards, see the Distributed Management Task Force—DMTF—website at www.dmtf.org/standards.) Microsoft included WinRM support in Windows Vista, Windows Server 2008, and later OSs, as well as making a downloadable runtime available for other Windows versions. If you’re familiar with Windows Management Instrumentation (WMI), then the concept behind WinRM will be very familiar: It’s designed to provide a network-based management layer that Microsoft’s own management tools can use to query and change various system parameters across the network. The difference is that because WinRM is based on WS-MAN instead of Microsoft’s own proprietary standard, it offers a higher degree of interoperability. PowerShell uses WinRM to send commands remotely to other Exchange servers on the network. The actual implementation of Exchange 2010 EMS sends commands from the local PowerShell interpreter through WinRM, even when you’re executing commands on the very same machine read.

When you open an EMS window, you’re actually creating a PowerShell runspace, into which the EMS command set is loaded. Your local runspace is what backs the EMS window that you see. There’s also a corresponding runspace on the Exchange server that you’re talking to. Even if you’re running EMS on the Exchange server itself, you’ll still have two runspaces. The object that links the two runspaces is known as a session. If you think of a Telnet or Secure Shell (SSH) session, you’ll have an idea of what a PowerShell session is, with a twist: Telnet and SSH pass text back and forth; a PowerShell session sends binary data blocks that represent system objects back and forth. The PowerShell session is actually passed over the network via IIS.

This implementation offers a lot of benefits. For one, it makes the process of sending commands to remote machines transparent. Its implementation is tied into IIS, which means that IIS authentication and authorization can be used to control who can do what, which in turn enables the use of Role Based Access Control (RBAC), another key Exchange 2010 feature.
 

RBAC

The reason you can run Exchange commands in EMS is that when you launch the PowerShell interpreter, the Exchange command set is automatically loaded. In Exchange 2007, all the Exchange commands are loaded, meaning that any administrator can run any command. RBAC gives us a much more granular system of control. You can assign permissions to individuals or groups so that they can run only the commands you specify. In fact, you can control which parameters of those commands they can supply. For example, you could enable a group of Help desk technicians to use the Set-Mailbox cmdlet while giving them access to only some parameters rather than all of them.
 

This is possible because the RBAC permissions that you set are used to control which EMS cmdlets are loaded. If a user doesn’t have permission to load a particular cmdlet, he or she can’t execute that cmdlet. This means the user can’t use functions in EMC or ECP that depend on that cmdlet. Both EMC and ECP are RBAC-aware, so they automatically hide things that the user can’t do in the UI.

From a practical standpoint, you need to be aware of how RBAC permissions, roles, role assignments, and scopes work, because if any of them are set to deny users access to a particular cmdlet, the users won’t be able to run the cmdlet. (For more information about RBAC, see “Exchange Server 2010 Role Based Access Control.” )

New EMS 2010 Features

In addition to the changed architecture, the EMS 2010 shell has several interesting new features compared with Exchange 2007. (Some of these features are actually included in SP1; however, I’ll lump the release to manufacturing—RTM—and SP1 features together.)

New cmdlets for importing and exporting mailbox contents and PST files. In Exchange 2007, you could perform some limited manipulation of mailbox contents, but you had to have a 64-bit version of Microsoft Outlook installed on the server. In Exchange 2010 SP1, we now have the *-MailboxExportRequest and *-MailboxImportRequest cmdlet families. These cmdlets let you create mailbox import or export requests; these requests are analogous to the mailbox move requests you might already be familiar with.

When you create a request to export or import content, the Mailbox Replication Service (MRS) takes care of scheduling and processing the request. To export content, you use New-MailboxExportRequest to specify what mailboxes you want to export content from, which items should be exported, and where the results should go; the corresponding New-MailboxImportRequest lets you control how PST files are ingested and their contents stored in mailboxes. Note that you must specify the location of the PST files you want to import; Exchange doesn’t currently include a way to search for PSTs on the network.

There are also cmdlets for getting the status of import or export requests. Microsoft’s PST Capture tool  leverages these cmdlets to do some of its work, and you can combine these cmdlets with the multi-mailbox search functionality included in Exchange 2010 to find and archive the messages you’re interested in.

Administrator audit logging. A common request (sometimes more of a plea, actually) from administrators is to find out who changed something or when it was changed. Exchange 2010 offers an administrator audit logging feature that does exactly this. When this feature is enabled, every cmdlet on the auditing list is audited and the audit results are stored in a hidden arbitration mailbox that you can search with the Search-AdminAuditLog and New-AdminAuditLogSearch cmdlets, so you can see who ran a cmdlet, when, where, and what the results were. Interestingly, you can only add cmdlets that change things (e.g., the Set-* family) to the auditing list; you can see who changed things but not who looked at things using the Get-* cmdlets. For more information about how audit logging works and how to take advantage of it, see the Microsoft TechNet article “Overview of Administrator Audit Logging."

A set of cmdlets, *-MailboxFolderPermissions, for managing permissions on mailboxes and mailbox folders. These cmdlets make it ridiculously easy to do things such as give calendar reviewer permission to every user or find all users who have particular permissions. (For a clear example of how to write a useful script using these cmdlets, see Jan Egil Ring’s Set-CalendarPermissions script .)

The Send-MailMessage cmdlet. This cmdlet does just what its name suggests. You can use it to spam your friends, but it’s more useful as a means to send status or warning email messages for tasks such as automatically notifying users whose passwords are about to expire, sending welcome email messages to new users, and so on.

The EMC cmdlet log. Technically, this might not be an EMS feature—but it’s still useful. EMC 2010 can maintain and display a log of all the cmdlets that ran during an EMS session. This is a great way for you to keep track of what you did while fixing a problem or to get a head start on automating a frequently needed set of commands. Auditing only records cmdlets that make changes, whereas the cmdlet log preserves every action taken in the session. To enable the log, use the View command in EMS’s action pane, then select View Windows PowerShell Command Log; when the log appears, select Action, Start Command Logging. All the cmdlets you ran will appear in the log window. The log is retained only until you quit EMC, although you can export it to a file if you want to save it.
 

Other features. In addition to the other new bells and whistles, there are new cmdlets for working with the new features introduced in Exchange 2010—including cmdlets for creating and managing federation trusts, database availability groups (DAGs), Outlook Web App (OWA) mailbox policies, Exchange ActiveSync allow/block/quarantine lists, and other constructs that are new to Exchange 2010. One of the beautiful things about PowerShell in general is that if you can think of an object name, you can probably figure out what cmdlets apply to it. For example, if you know there’s such a thing as an OWA mailbox policy, it doesn’t take a lot of imagination to figure out that you’d create one with New-OwaMailboxPolicy or remove one with Remove-OwaMailboxPolicy.

Office 365

One very cool aspect of Exchange 2010 PowerShell that many administrators haven’t run into yet is its ability to connect directly to Microsoft Office 365. This makes perfect sense when you think about it, given that Office 365 and Exchange 2010 run essentially the same PowerShell bits. However, the ability to seamlessly manage a hybrid Exchange organization using PowerShell is both very useful and technically slick.

To accomplish this task, all you need to do is create a PowerShell session that points to a specific URL at the Office 365 service. Because of the way the EMS uses WinRM, which in turn plugs into Microsoft IIS, it’s simple to set up a connection by using code such as the following:

$creds = Get-Credential$s = New-PSSession  -ConfigurationName Microsoft.Exchange  -ConnectionUri    https://ps.outlook.com/powershell  -Credential $creds  -Authentication Basic -AllowRedirection$importresults = Import-PSSession $s

This code looks more complicated than it is. The first line obtains your administrative credentials and stores them securely in a PowerShell credential object. The second line (which is actually shown here on multiple lines, for fit) establishes a new PowerShell session that connects to a remote endpoint. The third line attaches the Office 365 session to your local PowerShell session—it links your local session with the remote runspace. After completing these steps, you can issue partial commands that will be sent remotely to the Office 365 servers that host your mailboxes. Of course, you might not be able to do everything you can do with your on-premises Exchange servers: Microsoft has applied RBAC permissions to restrict what administrators can do, as well as what you can do. There doesn’t seem to be a published guide that details exactly which commands are enabled for which roles, so it might require some experimentation. However, you’ll probably find that most of the commands you have access to are related to recipient management and setting configuration parameters on mailboxes; don’t expect to have access to cmdlets that control mailbox servers, Client Access servers, and other aspects of the environment that belong to the service provider.

An EMS 2010 Annoyance

One circumstance that often trips up administrators who are making the transition from Exchange 2007 to Exchange 2010 is that EMS 2010 handles object pipelines a bit differently. You’ll recall that PowerShell collects sets of objects into pipelines for efficient, linear processing; the first object in a given pipeline is the first one evaluated, then the second, and so on. In Exchange 2007, pipelines are always local. In Exchange 2010, they’re not. That’s fine as long as you’re trying to execute only one pipeline at a time. As soon as you do something that has the potential to generate multiple pipelines, you’ll get an error that, rather unhelpfully, says, “Pipeline not executed because a pipeline is already executing. Pipelines cannot be executed concurrently.”

The simplest way to fix this problem is to reduce the pipeline stage count. Instead of taking the output of one command and piping it directly to another, use an intermediate variable to separate the two. For example, instead of using Get-Mailbox and piping it directly to the foreach object or where object, you can get the output of Get-Mailbox, store it, and then pass it on like this:

$mailboxes = Get-Mailbox$mailboxes | foreach { doSomething }

In this case, first we collect all the mailboxes into a single object, then we unpack that object—which is really a pipeline—and pass it through the foreach cmdlet so that we can perform the doSomething action on each object. This command involves a bit more typing, but it eliminates the additional pipeline stage that causes the concurrency error.

Moving Ahead

If you’re familiar with EMS in Exchange 2007, you already know about 90 percent of what you need to manage Exchange 2010 effectively. As you learn more about the new Exchange 2010 features, you’re already well-equipped to manage them with EMS 2010. If you’re coming directly to Exchange 2010 from an older version of Exchange, you’ll find that most of the material that covers EMS 2007 is still useful as an introduction. (For a list of applicable resources, see the Learning Path.) Learning how to use PowerShell effectively is a key aspect of becoming comfortable with Exchange 2010, and this trend will only continue in future Microsoft releases as additional products embrace the use of PowerShell for management and control.

Learning Path

For more information about Exchange Management Shell (EMS) for Microsoft Exchange Server 2010 and 2007:

“Exchange Management with EMS: Fundamental Concepts”

“Exchange Management with EMS: Getting Exchange Objects”

“Exchange Management with EMS: Setting Properties”

“Exchange Management with EMS: Turning Actions into Scripts”

“Setting Up Exchange Management Shell”

“Refining Your Exchange Management in the Shell”

“Using the Shell to Manage Exchange 2007”

“Exchange 2007 SP1's Standby Continuous Replication”