Exchange Server 2010 continues the tradition of providing more and more Messaging features for the enterprise, and at the same time, significantly lowering mailbox associated costs. This new version brings a slew of features to the messaging and communication infrastructure such as: Archiving, Compliance, High Availability, Enhanced Messaging experiences from various entry points, and so on.
Naturally, with a set of new features, comes the requirement for managing these features. As we are all aware, Exchange Server 2007 was fully manageable with a set of PowerShell CmdLets, and the Exchange Management Console (EMC) was built on top of this. This continues to be the case with Exchange Server 2010: a whole new range of PowerShell CmdLets to manage the product's cutting edge features, and a vastly greater administrative surface exposed via the EMC.
This series of articles will quickly skim through all the new administrative features surfaced via the EMC.
High Availability is one of the core themes of Exchange Server 2010. High Availability (HA) in Exchange Server 2010 combines replication techniques and Windows Clustering to deliver a highly and continuously available Exchange infrastructure. One of the key concepts in managing HA in Exchange Server 2010 is "Database Availability Group" (DAG) - a logical container for a set of Mailbox servers that provide isolation from database, server or network failures. Associated with DAGs is the concept of DAG Networks, that can be turned on or off for creating customized continuous replication and database seeding networks. Creating and configuring DAGs as well as DAG Networks, are core scenarios made easy and seamless in the EMC. The following screenshots show the DAG and DAG Network management experience in EMC.
Figure 1: The new Database Availability Group Wizard.
Figure 2: Managing DAG Networks.
Figure 3: The new Manage DAG Membership wizard. We can quickly add/remove servers to/from a DAG here. Once a new server is added here, it immediately participates in providing automatic database recovery.
In Exchange Server 2010, databases are based on new storage architecture, and no longer rely on the older Exchange Server 2007 concept of Storage Groups. Aligning with this change, the EMC has also been enhanced to support the management and monitoring of Database Copies. Additionally, the EMC also allows administrators to manually perform switchovers. The following screenshots show the Database and Database Copy management experience in EMC.
Figure 4: The Add Mailbox Database Copy Wizard.
Figure 5: The new Database Management view.
Figure 6: Viewing properties for a Mailbox Database.
Archiving is another core theme in Exchange Server 2010. Archives deliver on a core legal compliance requirement by ensuring that your Exchange Server is in charge of all mailbox data, rather than being stored away in 3rd party backups, personal archives, PST files and such. Archiving can be turned on at a per-mailbox level either during mailbox creation or later individually or in bulk, for example, say at a department level. The following screenshots show the Archive management experience in EMC.
Figure 7: Enabling Archive while creating a new Mailbox.
Figure 8: Enabling Archive for an existing Mailbox.
Figure 9: Bulk-Enabling Archive on a set of mailboxes.
Figure 10: Archive listed as a Mailbox Feature in the Mailbox Property page.
Figure 11: Using the Create Filter option to view mailboxes that have Archive enabled.
Federation and Sharing:
Federated sharing allows organizations to effectively collaborate beyond the traditional email exchange. Exchange Server 2010 makes it simple to share and access PIM data (free/busy, calendar and contacts) stored in Exchange with users external to the Exchange organization while maintaining customer confidence around security and control, both at an information-sharing level as well as at the TLS level. Configuring and managing this is a snap with the EMC. The following screenshots show how to setup Federation and Sharing in an Exchange Server 2010 environment and how to share data with Exchange another organization.
Figure 12: Setting up Federation Trust between two organizations, with 3rd-party trusted certificates.
Figure 13: Setting up a new Organizational Relationship between Exchange organizations.
Figure 14: Setting up a new Sharing Policy that can be associated with users in an Exchange organization
In Exchange Server 2010, significant improvements have gone into managing certificates with the EMC. To name just a few enhancements: we can now assign a certificate to multiple Exchange services right within the EMC, we can specify wildcard certificates to apply to all sub-domains, we can renew both self-signed as well as 3rd party CA certificates, and so on. The EMC also allows administrators to positively identify and edit domains to be included on a certificate and identify the domain that will be used for the certificates' Common Name (CN).The following screenshots shows some of the new features of the Certificate management experience in the EMC.
Figure 15: Creating the new Wildcard certificate.
Figure 16: Assigning a Certificate to multiple services. You no longer need to switch to IIS to complete any Certificate Management tasks.
Managing Multiple Forests:
Prior to Exchange Server 2010, managing Exchange organizations with multiple forests required administrators to either terminal-server into each forest, to manage that forest. With Exchange Server 2010, administrators will now be able to view and manage multiple forests within the same Console. This vastly improves the management experience for large Exchange deployments. Adding multiple forests to the EMC is as simple as selecting the "Add Exchange Forest" action, and specifying the FQDN of the target server and credentials. Once successfully connected to this new forest, we will be able to see this new forest as a new node added to the Left Navigation pane, as shown in the screenshot below.
Figure 17: Adding a new Exchange forest to the EMC, by selecting the "Add Exchange Forest" action.
Figure 18: The Left Navigation Pane now shows two Exchange forests being managed in the same Console.
Exchange Server 2010 brings about a new set of PowerShell CmdLets to move mailboxes between databases and/or forests. The Move-Mailbox CmdLet of Exchange Server 2007 has been replaced with a set of *-MoveRequest CmdLets. As expected, the EMC also builds on top of this new CmdLet set. You can move mailboxes between databases using the New Local Move Request wizard. And, if we are connected to multiple forests in the same EMC (as described previously), we can also move mailboxes between forests using the New Remote Move Request wizard. Finally, we can monitor ongoing moves in the new Move Request child node under the Recipient Configuration node in the Left Navigation pane. The following screenshots demonstrate this functionality.
Figure 19: The new Local Move Request wizard can be used to move mailboxes between databases.
Figure 20: The new Remote Move Request wizard can be used to move mailboxes between Exchange forests.
Figure 21: Ongoing mailbox moves can be monitored in the new Move Request node. Ongoing moves can also be cancelled via the new Remove Move Request action.
With Unified Messaging in Exchange Server 2010, numerous administrative controls have been put in place across the management surface. Some of these include: Voice Mail Preview, Personal Auto Attendants, Protected Voice Mail, UM Gateway Configuration, and so on. Note that Fax functionality in Exchange Server 2010 is now delegated to 3rd party certified Fax solutions. The following screenshots show some of the new Unified Messaging management experiences in EMC.
Figure 23: Configuring Unified Messaging Mailbox Policies.
Figure 24: Configuring Unified Messaging Auto Attendants.
Figure 25: Configuring the Startup mode for a Unified Messaging server role.
Diagnostic Logging Management:
Diagnostic Logging Management is back in Exchange Server 2010. A new wizard based UI now enables administrators to quickly Exchange server-related logging and logging levels. This will assist in easy instrumenting of the Exchange servers for diagnostics. The following screenshot shows the new wizard. The new wizard also makes it simple to reset all event logging levels to the default setting when diagnostics are complete to ensure optimal server performance.
Figure 26: The new Manage Diagnostic Logging Properties wizard.
Outlook Web App Mailbox Policy Management:
In Exchange Server 2010, administrators will now be able to configure and manage Outlook Web App (OWA) Mailbox feature policies completely within the EMC. Once these policies have been created they can then be assigned to mailboxes (individually or in bulk) within the organization. The following screenshots demonstrate this new feature.
Figure 27: The new Outlook Web App Mailbox Policy Wizard. You can enable/disable individual bits at the Policy level.
Figure 28: Assigning the newly created OWA Policy to a mailbox.
EMC and RBAC:
A new Roles-Based Access Control (RBAC) model now controls access to the Exchange Server 2010 environment. This new model is completely managed with a new set of PowerShell CmdLets. Out of the box, the product comes with a set of well-defined Role Groups, such as Recipient Management, View-Only Organization Management, etc. This makes it easy for administrators in large enterprises to partition their administrative tasks in a scalable manner and delivers optimal administrator productivity. When administrators launch the EMC, a customized view is rendered based on the RBAC profile for the logged on user. This effectively prevents information disclosure and provides a clear and non-confusing UI/UX based on the role of each administrator in the organization. Thus, a "View-Only" administrator would only be able to view Exchange configuration data, and wouldn't be able to make any changes. Likewise, a "Recipient" administrator would only be able to work in the Recipient Configuration node of the EMC, as shown in the following screenshots. Using PowerShell, Organizational Administrators can create custom roles and groups which tailor a job specific user-experience to their EMC administrators.
Figure 29: Here, a "View-Only Organization Management" administrator is unable to make any changes at any object level. All input fields are locked, as indicated by a yellow lock icon. Note that the Actions Pane on the right also does not have several Actions such as New Mailbox, etc.
Figure 30: Here, a "Recipient Management" administrator does not see the Server Configuration node in the Left Navigation Pane, and only has read/write permissions in the Recipient Configuration node (as permitted by his/her RBAC profile), and only has read permissions in the Organization Configuration node (as permitted by his/her RBAC profile).
The new Organizational Health screen in the EMC gives administrators a quick, unified view of their Exchange infrastructure. Summarized information on databases, Client Access Licenses (CALs), servers (2003, 2007 and 2010 versions of Exchange), and recipients (both by type as well as feature usage) is available here.
Figure 31: The new Organizational Health screen.
PowerShell Command Logging:
PowerShell continues to be the core management platform for Exchange Server 2010. To provide visibility into what commands are being run by the EMC behind the scenes, and to also aid in learning Exchange PowerShell CmdLets, the administrator now has the ability to visualize which commands are being run in the background by the EMC. As a quick learning tool, this is a great addition that will aid administrators in rapidly scripting out advanced workflows. In Exchange Server 2007, the only place where commands were exposed was at the end of wizards. In Exchange Server 2010, administrators now have full visibility across the Console. The following screenshots show some of the new PowerShell logging experiences in EMC.
Figure 32: Clicking the highlighted image on every Property page brings up the PowerShell Command call.
Figure 33: Viewing a full log of PowerShell Command calls.
To make it easier for administrators to quickly edit multiple recipient objects in one operation, the EMC now enables Bulk Editing of mailbox objects. Prior to Exchange Server 2010, administrators would be forced to switch to scripting to perform this task. With EMC in Exchange Server 2010, this is as simple as selecting desired mailboxes, bringing up the properties dialog, and making edits as needed. Additionally, the cool new feature of PowerShell Command logging is also enabled in this scenario. The following screenshot shows Bulk Editing in the EMC in action.
Figure 34: Bulk Editing with PowerShell Logging.