Exchange 2013: New Features and Changes, Part 4

Administration

Exchange Administration Center
Exchange 2013 leverages the use of the web interface for administration of the majority of its components. The Exchange Management Console (EMC) is no longer available as a tool, but the majority of its functionality is found through the Exchange Control Panel virtual directory. This eliminates the need to install the heavy console on the computer you use to administer Exchange, providing more management flexibility. While some might be concerned with security, the web access is secured just like the EMC in previous versions, as it uses SSL as well to reach the Exchange components.

PowerShell
The Exchange Management Shell is still the advanced tool needed when it comes to more granular management, advanced features, and bulk tasks. There are hundreds of new PowerShell cmdlets in Exchange 2013 to reflect the various features that have been added to the product.

Testing and Upgrading Exchange Server 2013

Getting the latest software and new features to integrate in your current environment requires careful planning. While most organizations that are going to transition to Exchange 2013 have Exchange Server 2007 or 2010 running (2003 is not supported), the actual co-existence of 2013 with these earlier versions is a process that will only be feasible with the release of appropriate service packs and cumulative updates. The transition process will be similar to what was done when transitioning from earlier versions to Exchange Server 2010.

Schema upgrade: One of the first requirements, and a sensitive change, will be to update the schema to enable new objects and attributes from Exchange 2013 to be visible in AD. This step is not something new, as numerous previous versions use AD as the storage engine of Exchange settings.

Updates and service packs: Older versions of Exchange, as well as 2013 itself will need to run the latest software in order to fully merge versions and enable co-existence scenarios.

Exchange 2013 installation: This process involves the setup of Exchange 2013 within the same organization that is used by legacy versions of the product.

CAS configuration and co-existence: This step involves routing all client access to the 2013 CAS role by modifying existing DNS records to point to the newly installed server. The use of a new legacy A record allows redirection of users with older mailboxes to their legacy servers, while still providing a single point of access for all client scenarios. Tasks such as certificate changes to reflect legacy records must be done as well. Typically, Internet-facing sites are first affected by this change.

Mailbox configuration and co-existence: After determining and building the appropriate databases and storage settings on mailbox servers (including the creation of DAGs), moving mailboxes to the new server is normally a straight-forward process. Settings we should look after include transitioning the public folders, OAB generation servers, and few others, helping us gradually decommission the mailbox servers.

Mail flow configuration: Since the majority of mail flow settings are stored in AD, and SMTP is always used to exchange e-mails, the e-mail routing should be relatively simple; 2013 should be set to receive all incoming e-mail for the organization. As e-mail for legacy mailboxes enters the organization, the 2013 mailbox and CAS components will route the messages to appropriate legacy servers, where legacy mailboxes are stored. A similar technique applies to messages that leave a legacy mailbox, and recipients on 2013: AD will find which server is responsible for the 2013 mailbox, and legacy SMTP servers will transfer the message to appropriate 2013 e-mail routing servers.

With the mentioned steps, there will be a coexistence period, where multiple versions of Exchange will be present in the organization at the same time. This is a typical scenario, as it is often impossible to move a large number of mailboxes and eliminate legacy servers so quickly. However, this is not considered to be a problem in terms of taking advantage of Exchange 2013. As more mailboxes are moved to the new servers, more users will have the latest web interface, and administrators will benefit from simplified scalability scenarios, access methods, mail flow, and so on.

It is also absolutely feasible to install Exchange 2013 in a new forest/organization and test the product, while waiting for Microsoft to provide us with the appropriate service pack levels that will enable coexisting Exchange versions.

Given the number of tools and programs that often integrate with a messaging system, you may need to run multiple versions of Exchange Server for years. Decommissioning Exchange servers can be risky, given how complex an infrastructure can be. It can take quite a while to test and eliminate the risk of moving everything to the new version of Exchange.