The Exchange Management Shell

THE ESSENTIAL GUIDE TO Exchange Management Using EMS By Paul Robichaux SPONSORED BY The Exchange Management Shell (EMS) offers more power and flexibility for managing and monitoring Exchange Server 2010 and Exchange Server 2013 than the graphical user interface (GUI)-based and web-based management tools. Some critical tasks require using EMS, and many everyday tasks are faster or easier to perform using EMS instead of the GUI. In this Essential Guide, we'll cover some of the key tasks you need to know how to perform using EMS and discuss ways to speed up everyday administration, management, and reporting tasks by using the built-in EMS cmdlets and simple scripts. Why You Should Use EMS When Microsoft first introduced Windows PowerShell in 2006, the IT world 1

was very different. Virtualization of server workloads was still rare, and most system configuration and administration was done through Windows applications that provided a GUI, such as the familiar Microsoft Management Console (MMC) and the Exchange tools based on it. Automation was difficult and complicated, in part because Exchange had multiple, partly overlapping application programming interfaces (APIs) for some tasks and no APIs for others. If you wanted to effectively automate the management of your Exchange and Windows servers, you had to be a master of multiple scripting languages and APIs. However, when Microsoft started publicly showing Exchange Server 2007, one of the major surprises was its reliance on EMS a customized environment that ran on top of PowerShell to provide a unified set of management and automation capabilities for much of Exchange. This was seen as a radical step at the time, but now all of Microsoft s server products have PowerShell-based automation built in, and with each new release, we get more capabilities. Whether you use Exchange 2010 or Exchange 2013, it s important to know how to use EMS for three reasons: 1. There are tasks you can only perform with EMS. For example, the Edge Transport role in Exchange 2013 can only be configured with EMS. There aren't any controls for it in the SP1 version of the Exchange Admin Center (EAC). 2. There are tasks that are tedious to perform manually through the GUI. For example, enabling 100 mailboxes for unified messaging in EAC requires that you manually select each mailbox and click a link. With EMS, you can enable 100 mailboxes with one line of code. 3. There are tasks that are dangerous, tedious, or error-prone that you can automate with a script once, then use that script forever. Automation can be a great time-saver, even more so when you use it to automate tasks that you don t do often (such as a data center-level failover). Building a known-good 2

set of scripts that you can use to save yourself time and hassle is a great investment, even if it means having to learn how to use EMS from scratch. Microsoft has done a good job of documenting which tasks require EMS. Even if it hadn t, you d be able to figure it out quickly by looking for cmdlets that don t seem to correspond to functionality listed in the EAC or Exchange Management Console (EMC) GUIs. Rather than go over that list, it s more interesting to talk about the three types of management and monitoring tasks you can perform with EMS: Tasks you perform frequently Tasks you perform occasionally but can benefit from being automated Complex or risky tasks that can benefit from being automated Using EMS for Frequently Performed Tasks Even when Exchange doesn t seem to be doing anything, it s busy behind the scenes. Messaging records management, database page verification, and calendar repair are just three of the many scheduled tasks that the Information Store process (and its various assistants) runs as background tasks. For that reason, there isn t much scheduled maintenance, apart from backups, that you have to do yourself. However, the daily life of an Exchange administrator revolves around performing tasks that Exchange can t do, such as managing user accounts. Here are a few examples of how you can use EMS for these common chores. First, you can use cmdlet extension agents to run scripts or cmdlets of your choice when another cmdlet is triggered. In particular, the scripting agent is the extension component that lets you run a script of your choosing when a specific cmdlet (e.g., New-Mailbox, Enable-Mailbox) fires. As a result, whenever that cmdlet runs, so does your script. This is true whether the cmdlet is triggered from EMS or the Exchange GUI. 3

To create an extension agent, you need to take three steps: 1. Write the extension script. For example, here s a simple script that automatically disables Exchange ActiveSync (EAS) for any newly added user: <?xml version="1.0" encoding="utf-8"?> <Configuration version="1.0"> <Feature Name="Mailboxes" Cmdlets="New-Mailbox Enable-Mailbox"> <ApiCall Name="OnComplete"> if($succeeded) { $Name=$provisioningHandler.UserSpecifiedParameters ["Name"] Set-CASMailbox $Name -ActiveSyncEnabled $false } </ApiCall> </Feature> </Configuration> The interesting part is the code inside the <ApiCall> block because it s what gets executed when the specified cmdlets are run. 2. Add the script to the \bin\cmdletextensionagents\scriptingagentconfig.xml file in your Exchange installation. If you don t have this file, it just means your server doesn t have any cmdlet extension agents installed yet, so you need to create the file. If it already exists, add your new code block to it. You ll need to make this change on every Exchange server in your organization. If you execute the targeted cmdlet on a server that doesn t have the agent installed, the script won t run. 3. Enable the scripting agent by running the command: Enable-CmdletExtensionAgent "Scripting Agent" 4

This is a great example of a task that can be done only in EMS. There s no way to enable these agents from within EAC or EMC. There are lots of potential uses for extension agents. You can automatically export user mailboxes to personal folder files (PSTs) when the Remove-Mailbox cmdlet is called by using the Validate tag in the <ApiCall> block to run your script before the mailbox is removed. You can have Welcome email messages sent to new users when the New-Mailbox and Enable-Mailbox cmdlets are used. Or you can have an event log entry created when a certain cmdlet is executed. The most common tasks performed by administrators involve managing user accounts and mailboxes. How often you perform these tasks is driven by the size and complexity of your environment. If you work at a small company in which you add or remove only one mailbox a month, EMS doesn t seem to offer much advantage. However, if you re adding or removing 5 to 10 mailboxes a day, getting comfortable with the syntax for the New-Mailbox and Remove- Mailbox cmdlets can give you a big advantage, especially if someone else is creating the user objects in Active Directory (AD) and you only have to mailbox-enable them. The basic pattern that underlies all of these tasks is simple: You get a batch of objects, select only the objects you need to manipulate, and do whatever it is you need to do. For mailbox-related operations, this will often involve using the Get-Mailbox or Get-DistributionGroupMember cmdlet, combined with the Select-Object or Where-Object cmdlet. With experience, you ll learn which cmdlets support the -Filter parameter. This parameter improves performance by having the server fetch all the relevant objects, then apply a filter before passing the results to the machine where you re running the cmdlet. You can also use the -ResultSize parameter with cmdlets that support it to restrict the number of results returned if performance becomes an issue. Exchange 2013 supports the use of call answering rules for unified messaging, out-of-office settings, and other customizable behaviors. 5

The Set-MailboxAutoReplyConfiguration, New-UMCallAnsweringRule, Set-UMCallAnsweringRule, New-InboxRule, and Set-InboxRule cmdlets can be very useful in providing a uniform set of behaviors for mailboxes. For example, when you decommission a mailbox, you can quickly set up an automatic reply that tells outsiders that the mailbox owner is no longer with the company by running a command like this: Set-MailboxAutoReplyConfiguration Identity jsmith AutoReplyState:enabled ExternalAudience:all ExternalMessage "Joe Smith no longer works for Contoso. For further assistance, please contact info@contoso.com" Reporting is another example of something that you probably do often. Many organizations use third-party reporting tools to prepare elaborate reports of usage and resource consumption, but Exchange includes a number of built-in cmdlets (e.g., Get-MailboxStatistics, Get-MobileDeviceStatistics) that let you get simple reports quickly. You can automate reporting with these cmdlets using the Windows Task Scheduler to get a quick, inexpensive (albeit limited) picture of who s using what resources on your servers. (For more information about this, see Automate Mailbox Size Reporting in Office 365. ) Using EMS for Tasks Performed Occasionally EMS is a great example of the 80/20 rule: 80 percent of the tasks automated with EMS are likely achieved using 20 percent of the available cmdlets and functions, but which 20 percent can vary from organization to organization. For example, if you don t have any public folders, you probably won t be using the public folderrelated cmdlets much, but the person sitting next to you on the shuttle bus at the Microsoft Exchange Conference (MEC) might use them heavily. With that said, there are some common patterns that emerge across organizations of different sizes and in different industries and markets. 6

Any task that you have to perform more than once a quarter is probably a decent candidate for automation. The specific tasks that fall into this category will vary. Tasks that you might want to automate, but don t necessarily perform often, include: Building a new server. There are lots of ways to automate the process of building a new Exchange server, ranging from scripting every aspect of the installation process to using sysprep followed by an automated installation of Exchange to installing everything manually. The more you can automate, the easier it is to break out a new server when you need one and the smaller the risk that you ll forget to apply an important setting, such as the settings required for integration between Outlook Web App (OWA) and Lync. Managing mail flow through send and receive connectors. Most of the time, you ll set up these connectors when you first deploy Exchange, then you ll leave them alone. You can use the Set-SendConnector and Set-ReceiveConnector cmdlets to perform tasks such as changing the size limit for inbound or outbound messages. Creating or managing federation relationships with business partners. Although it s simple enough to do this directly in EAC, a script to automatically enable Exchange and Lync federation at the same time is arguably a better way to handle this task because it ensures that the process works the same way each time. Performing various kinds of scheduled maintenance. In Exchange 2013, the Managed Availability subsystem watches over the health of Exchange components, restarting them if they fail. Therefore, before you patch or update a server, it s a good idea to get the Managed Availability subsystem in on the action by suspending the services of the server you re patching. This is particularly useful when you re applying a cumulative update or service pack to the member servers in a database availability group (DAG). Your maintenance script might send notification emails to users or administrators, put an individual server into maintenance mode, 7

change client access connections through your load balancers, or perform other tasks related to controlling which servers are working and what they re doing. Using EMS for Complex or Risky Tasks The third type of task you should automate is those tasks in which a misstep can have unpleasant consequences. Probably the most obvious example of this is the process of failing services over to an alternate data center. Exchange is fully capable of failing transport and storage services from one server to another, thanks to the DAG architecture and transport redundancy features. However, the decision to fail over operations between data centers is a human decision one which Microsoft wisely decided that Exchange shouldn t make on its own. Consider what has to happen when you fail over to an alternate data center: 1. You need to make sure that all the mailbox servers in the failed site are cleanly shut down. 2. You must run the Restore-DatabaseAvailabilityGroup cmdlet in the target site, which might require you to stop the Windows cluster service on the DAG member servers. 3. You ll probably want to rebalance the active copies of your mailbox databases across the DAG member servers in the target site by running the RedistributeActiveDatabases EMS script. 4. If you re using public folders with Exchange 2010, you might need to update the mailbox databases so that they point to a public folder database in the target site. 5. If you have an Exchange 2010 client access array object, you need to make sure it points to the correct data center. 6. You might need to make changes to your public and internal Domain Name System (DNS) servers to send traffic to the correct location. 7. Your load balancers might need to be reconfigured to point to the target site. 8

You must verify that each step completes successfully before proceeding to the next one. In addition, you need to perform these steps in the correct reverse order to move operations back to the original data center. To make things worse, this particular set of steps is one that you ll perform infrequently enough that you re likely to forget some of the nuances of how to do it. That means it s an excellent opportunity to write a script to do the dirty work for you. Exchange Most Valuable Professional (MVP) Jason Sherry has written a script to handle failovers that you can use as a starting point. Any procedure that can potentially cause data loss is a good candidate for automation. For example, consider the common process of decommissioning a user mailbox when that user leaves the company. You could just remove the mailbox, but it s often necessary to save a copy of its data first. A reliable script that disables the AD user account object, creates a mailbox export request to put the mailbox data in a PST, disables the mailbox, uses the old Simple Mail Transfer Protocol (SMTP) address as a proxy address for a catchall mailbox, and removes the no-longer-needed objects (after a waiting period) is a much better way to handle this process than doing it manually. It minimizes the chances that a forgotten step will result in lost mail. What About Office 365? If you re using (or thinking about moving to) Office 365, you might be wondering whether you still need to use EMS. The answer is a rousing It depends! Many of the tasks you perform in an on-premises Exchange implementation aren t available to you as an Office 365 tenant administrator. For example, you can t create DAGs, create mailbox databases, or move mailboxes between databases. Almost all of the tasks you are allowed to perform are available through EAC. However, Microsoft has put a lot of effort into making EMS work well remotely. So, for bulk tasks involving user or mailbox properties, user licensing and provisioning, or reporting, you can use EMS just as you would use it on-premises. The TechNet Magazine article Geek of 9

All Trades: Manage Office 365 with Windows PowerShell discusses how to use EMS remotely for managing Office 365. Plus, there are many other articles available covering specific tasks that you might want to perform. EMS Has Come a Long Way EMS has come a long way since its introduction in Exchange 2007. Although Microsoft has put a lot of effort into adding functionality to the graphical Exchange management tools, literally every management function that can be performed in Exchange is available to you in EMS. As PowerShell becomes more deeply entrenched in Microsoft s product lines and as Microsoft continues to add new functionality to new versions of Exchange, investing the time to get comfortable with EMS automation will greatly ease your day-to-day life as an Exchange administrator. 10