3. Exploring the New Exchange Administration Center (EAC)
As
mentioned in the previous section, Microsoft completely did away with
the Exchange Management Console in place of the Exchange Administration
Center, or EAC. EAC works just like OWA. An administrator uses a web
browser and types in the uniform resource locator (URL) with /ecp at
the end instead of accessing OWA with a /owa at the end. So after
typing https://{owa address}/ecp, the administrator sees a screen similar to what is shown in Figure 2.
Figure 2. The new Exchange Administration Center (EAC).
Note
The /ecp for the Exchange Administration
Center refers to the old Exchange Control Panel (ECP) that was
introduced in earlier versions of Exchange. At some point, Microsoft
may change the URL for access to the EAC, but for now, the URL includes
ecp at the end.
The benefit of the Exchange
Administration Center is that it no longer requires installing the
64-bit Exchange Management Console program along with the .NET
Framework, Active Directory Domain Services remote admin tools, and
everything else that was needed to administer Exchange. Now, an
administrator can be anywhere, and as long as the administrator has
access to Outlook Web App, the administrator can also access the
Exchange Administration Center. For the longtime Exchange
administrator, think about it: No more having to remote into a server,
using Remote Desktop Protocol (RDP) to access a server—just log on from
any web browser to perform administration tasks.
The
administration tasks in EAC include everything from creating and
managing Exchange recipients to creating Active Directory distribution
lists, creating send and receive connectors for mail routing, managing
the public folder hierarchy, checking for anti-malware traps, creating
new Exchange databases, failing over database availability groups,
doing eDiscovery, and so on.
The Exchange
Administration Center is available for users to manage their personal
mailbox settings such as user-specific content like mobile phone
numbers, photos, OWA settings, and the like. So the EAC serves as a
tool for user Exchange settings, Exchange-related Active Directory
settings, and Exchange administration tasks.
4. Architectural Changes in Exchange Server 2013
The architecture of Exchange Server 2013 has undergone significant changes. Most users will never
see or know these changes were made other than hopefully better
performance and reliability. The core of the changes made were to
simplify Exchange Server 2013 and make it more geo-redundant, scalable,
and ultimately more reliable.
Specifically,
with Exchange Server 2013, Microsoft eliminated the Hub Transport role
and the Unified Messaging role, so the core roles are now the Client
Access server and the Mailbox server (MBX) roles. The Client Access
server (CAS) no longer does data rendering; the role just focuses on
authentication, redirection, and proxy. The Mailbox server role now
includes Client Access protocols, Hub Transport services, mailbox
databases, and Unified Messaging services.
Because
the Client Access server role is drastically simplified to just support
HTTP, HTTPS, POP, and IMAP client protocols with no requirement for
session affinity between the CAS and MBX roles, Exchange Server 2013
now has better failover and the ability to do simple Level 4 load
balancing.
CAS and MBX servers no longer
need to be geographically close to one another, whereas in the past,
the two roles needed to be on the same subnet with high-speed
connectivity because of the amount of data transferred between the two
servers and the dependence on split roles shared between the two
servers. As such, the CAS role can now be geo-centralized with MBX
servers distributed to various sites in the enterprise. In addition,
with the elimination of integrated components between the CAS and the
MBX servers, the requirement of identical patch
levels between CAS and MBX servers is no longer a dependency.
Organizations can patch and update CAS and MBX servers in a pattern and
manner that makes sense to the organization, greatly providing better
flexibility in updating an Exchange environment, and greatly improving
the uptime of Exchange.
Another
significant improvement in Exchange Server 2013 is the simplification
of the namespace used in Exchange. Instead of having the seven names
used in Exchange Server 2010 and requiring large and sometimes
expensive Subject Alternative Name (SAN) certificates, Exchange Server
2013 can use as few as two names in the environment. In fact, the
Mailbox server has a self-signed certificate automatically assigned to
it on installation that is trusted by the Client Access server. Because
the MBX role is no longer exposed directly to the endpoint client, the
public or trusted root certificate only needs to reside on the Client
Access server. The relationship between the CAS and MBX can remain a
self-signed certificate, again, a movement to simplify certificate
management in the Exchange Server 2013 environment.
Specific
to Exchange Server 2013 certificate management, the management of
certificates is part of the Exchange Administration Center through the
Certificate Management Wizard shown in Figure 3.
Figure 3. Certificate management in Exchange Server 2013.
