1. Exchange 2013 editions
Exchange 2013 is available in two editions. The same code is
used in both editions, but the license you load by installing a product
key determines which edition is active on a server. You can mix and
match servers running the two editions within the same organization.
The
Standard edition is the least expensive to purchase and contains all
the necessary functionality an email server requires, including the
ability to participate in a Database Availability Group (DAG). However,
it is limited to five databases. If you attempt to mount a sixth
database, Exchange 2013 Standard edition will gracefully refuse and
issue event 9591, “Exceeded the max numbers of 5 MDBs on this server.”
You must also operate under the same restriction if you install a trial
version of Exchange 2013. Because there is no need for these servers to
mount mailbox databases, Exchange 2013 Standard edition is the right
choice for standalone CAS servers or as a multirole server when a
relatively small number of mailboxes need to be supported. For some
companies, the number of mailboxes will be fewer than a thousand.
Others will differ, and the choice eventually comes down to the degree
of high availability and resilience the organization wants to provide
to the mailboxes.
Exchange
2013 Enterprise edition is designed to meet the needs of large
enterprises. A server running the Enterprise edition can mount up to
100 databases, so it is the obvious choice for large-scale deployments,
deployed as single-role mailbox servers or as multirole servers. The
ability to mount up to 100 databases is the only difference between the
two editions.
To use a DAG, you need to deploy Exchange on
Windows Server 2008 R2 Enterprise edition with SP1 or on Windows 2012
to provide the Windows failover clustering feature that underpins the
DAG. Although it is possible to construct and operate a DAG using
Exchange 2013 Standard edition, the five-database limit restricts the
number of mailboxes that can be supported and the degree of resilience
that you can incorporate into the DAG through database copies. For this
reason, unless you are confident that a DAG based on Exchange 2013
Standard edition is capable of meeting all your needs, it is better to
use Exchange 2013 Enterprise edition within DAGs.
Any server that
has not had a license loaded is deemed to run the trial version. After
120 days of running a trial server, you’ll begin to receive
notifications that it’s time to install a proper license. Installing a
valid product key is sufficient to transform a trial version of
Exchange into a licensed (and therefore supported) version. Exchange
also enables you to input an Enterprise edition product key to upgrade
a Standard edition to the Enterprise edition. However, it does not
allow you to downgrade a server from Enterprise to Standard, so you
must ensure that the correct product keys are installed on the servers.
If you make a mistake and need to downgrade a server from Enterprise to
Standard, the supported method is to uninstall the server from the
organization and then reinstall Exchange.
Apart from
deciding on the version of Exchange to deploy, you’ll also need to be
sure that you buy the right user CALs. Use of some Exchange features
such as archive mailboxes require an enterprise CAL per mailbox, as
does voice mail integration, the discovery and retention features, and
extended Exchange ActiveSync policies. The enterprise CAL is additive;
first you buy a standard CAL to license the standard features, and then
you purchase an enterprise CAL if you need to use the extended
features.
2. Active Directory
The
successful deployment and management of Active Directory has been a
fundamental prerequisite for Exchange since Exchange dropped its own
directory service in Exchange 2000. In fact, Active Directory shares
many of the characteristics of the earlier Exchange directory services,
and Microsoft learned a lot about how to design and operate directories
from the experience it gained with Exchange 4.0 to Exchange 5.5.
Using the strong link between Exchange and Active Directory
By any measure, Exchange makes the most extensive use of
Active Directory of any Microsoft application. When Exchange is
installed for the first time, the installation procedure does the
following:
Extends
the Active Directory schema to add a large number of new objects and
attributes to support Exchange features and allow the creation of
objects such as connectors in Active Directory. New attributes such as
email addresses extend existing objects such as users, contacts, and
groups to enable them to work with Exchange. Other attributes are
created for new objects and are used for those objects only. For
example, the ability to define a maximum number of active databases
that a server can support depends on the msExchMaxActiveMailboxDatabases
attribute (almost all the objects and attributes that belong to
Exchange are prefixed with “msExch”) that the Exchange installation
program adds when it prepares the Active Directory schema before
servers can be deployed.
Most of the attributes are single
valued, such as the database that hosts a mailbox. Others are
multivalued, such as the email addresses for a mailbox. LegacyExchangeDN
is the most famous attribute Exchange added because it has served as an
X.500-based identifier for Exchange objects since the first version of
the product and now provides backward compatibility for applications
that rely on it to identify objects such as mailboxes. Today, Exchange
relies on globally unique identifiers (GUIDs), 16-byte numbers, when it
needs to assign an identity that won’t change to objects.
Creates
a container called Microsoft Exchange under the Services root in the
Configuration Naming Context. All the configuration data about objects
Exchange manages are located here. (You can see the structure of the
container in Figure 1.)
The objects include servers, policies, address lists, connectors, and
so on. Data about mail-enabled objects are not held in this container.
Instead, they are stored as attributes on the mail-enabled objects
themselves, so they usually are found in the organizational units (OUs)
in the default naming context. Mail-enabled objects use the extended
schema to populate attributes such as email addresses. The Exchange
Administration Center (EAC) relies heavily on data fetched from the
Exchange container.
Adds
a set of attributes to the Partial Attribute Set (PAS), which is the
subset of Active Directory data that is replicated to global catalog
servers and is available to every domain within the forest. For
example, Exchange adds many mailbox attributes, such as the GUID that
allows the Store to locate a mailbox or the full set of Simple Mail
Transfer Protocol (SMTP) addresses for a mailbox, to ensure that
message routing works throughout the forest. Other user data form the
basis of the Global Address List (GAL) and are added to the PAS so that
it is available everywhere.
Adds
a set of extended rights (permissions) to enable administrators to
manage objects such as databases. These rights are defined in the form
of the roles and permissions managed through Exchange’s Role Based
Access Control (RBAC) system.
Adds
and extends the set of Active Directory property sets (groups of
properties) to make management easier by managing sets of properties as
single entities rather than handling the individual properties that
make up a set. For example, the Exchange Personal Information property
set contains all the attributes Exchange holds about individual users,
such as their phone numbers.
Note that Exchange
2013 cumulative updates might also require a schema update or some
other preparatory work to be done with Active Directory before the
update can be applied. For instance, Exchange 2013 RTM CU2 required
administrators to update the schema and then update the Exchange
configuration data held in Active Directory with new RBAC role
definitions and other information. Table 1 summarizes the position by showing where Exchange stores the data on which it relies within Active Directory.
Table 1-1. Where Exchange stores information in Active Directory
Partition | Active Directory Location | Exchange data stored | Replication scope |
|---|
Domain | Dc=domain, DC=parent domain | Mail-enabled recipients (groups, contacts, accounts) | Every domain controller in the domain |
Configuration | CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=domainroot | Exchange configuration objects such as policies, global settings, address lists, templates, and connectors | Every domain controller in the forest |
Schema | CN=Schema, CN=Configuration, DC= domain root | Exchange-specific classes and attributes | Every domain controller in the forest |
ADSIEdit has proven its worth to Exchange administrators to
fix problems with Active Directory objects or simply to help them
understand the complex relationship between Exchange and Active
Directory. Figure 1
illustrates the utility in use to browse the Exchange container and
review the values of properties of an object. Microsoft refers to ADSIEdit as a Lightweight
Directory Access Protocol (LDAP) editor to manage attributes in Active
Directory. It is installed on servers running Windows Server 2008 R2
and Windows Server 2012 along with the Active Directory Domain Services
role, after which you can access ADSIEdit in Administrative Tools in
the Start menu. After you start ADSIEdit, you must connect it to the
Configuration Naming Context to access Exchange data.
ADSIEdit
began in Windows 2000 as an add-in for Microsoft Management Console
(MMC) that Microsoft didn’t really support, probably because it didn’t
want administrators to have the ability to mess up Active Directory by
editing objects and properties. Remember that ADSIEdit allows you to
work with raw data through a user interface that doesn’t do much to
protect you with warnings about the potential consequences of certain
actions such as editing an attribute.
Caution
You
can do great harm with ADSIEdit if you don’t know what you are doing.
It’s best to be cautious and use ADSIEdit to gain an insight into the
internal workings of applications such as Exchange that depend on
Active Directory to hold their configuration data.
