\nTo ensure proper placement of Active Directory components in relation to computers that are running\u00a0Exchange Server, you must understand how Exchange Server 2013 communicates with AD DS and uses\u00a0Active Directory information to function. AD DS stores most Exchange Server 2013 configuration\u00a0information.<\/p>\n
![\"AD](\"http:\/\/www.davidpapkin.net\/wp-content\/uploads\/2015\/08\/ADExchangeIntegration.jpg\")
<\/a>\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 AD Exchange 2013 Integration<\/strong><\/p><\/div>\n Forests<\/strong> Global Catalog<\/strong> DNS Server Requirements for Exchange Server 2013<\/strong> One option is to register DNS records by site name, which enables computers that are running Exchange Server to find domain controllers and global catalog servers in the local Active Directory site. Exchange Server always performs DNS resource queries for the local Active Directory site first.<\/p>\n SRV resource records use the following format:<\/strong><\/p>\n _Service_.Protocol.Name Ttl Class SRV Priority Weight Port Target<\/em><\/strong> Host Records<\/strong> Exchange Server 2013 requires that some software be preinstalled before you start the deployment process. First, you should plan for the operating system platforms that will be used for Exchange Server 2013. The following operating systems are supported for installation of Exchange Server 2013 roles: Note<\/strong>: Server Core installation option is not a supported operating system option for Exchange Server 2013 installation. In addition, Windows Server 2008 R2 Standard does not support failover clustering and cannot use database availability groups (DAGs) in Exchange Server for high availability. You cannot upgrade Windows Server after you have installed Exchange.Depending on which Exchange Server role is installed, different Windows components can be installed on a server. However, you do not need to install these roles and features prior to Exchange Server installation because the installation process can install the necessary roles and features automatically.<\/p>\n However, there are additional components that you should install manually. These components, freely available to download from Microsoft, include: Infrastructure Requirements for Exchange Server 2013<\/strong> infrastructure requirement for Exchange 2013<\/p><\/div>\n AD DS Requirements<\/strong> Preparing AD DS for Exchange Server 2013 Deployment<\/strong> \u2022 Creates the default Accepted Domains entry if it does not exist, based on the forest root ******<\/p>\n Exchange Server Role Architecture in Exchange Server 2013<\/strong> Server Roles in Exchange Server 2013<\/strong> Mailbox Server<\/strong> The Mailbox Server role also interacts with the Client Access server, as well as with AD DS domain controllers and global catalogs. The Mailbox Server role never communicates with clients directly, as it did in previous versions of Exchange Server. All client-based communication is performed through the Client Access server role.
\nAn Exchange Server organization and an Active Directory forest have a one-to-one relationship. You\u00a0cannot have an Exchange Server organization that spans multiple Active Directory forests. You also cannot\u00a0have multiple Exchange Server organizations within a single Active Directory forest.
\nNote: In Exchange Server 2013, you can also add Office 365 domain to the Exchange
\nAdministration Center (EAC) console. This enables you to manage multiple organizations from
\na single management console.
\nSchema Partition<\/strong>
\nThe Exchange Server 2013 installation process modifies the schema partition to enable the creation of\u00a0Exchange Server-specific objects. The installation process also adds Exchange Server-specific attributes to\u00a0existing objects. For example, the installation process updates user objects with additional attributes to\u00a0describe storage quotas and mailbox features.
\nConfiguration Partition<\/strong>
\nThe configuration partition stores configuration information for the Exchange Server 2013 organization.\u00a0Because AD DS replicates the configuration partition among all domain controllers in the forest,\u00a0configuration of the Exchange Server 2013 organization replicates throughout the forest. The\u00a0configuration partition includes Exchange Server configuration objects, such as global settings, email\u00a0address policies, transport rules, and address lists.
\nDomain Partition<\/strong>
\nThe domain partition holds information about recipient objects. This includes mailbox-enabled users,\u00a0and mail-enabled users, groups, and contacts. Objects that are mailbox-enabled or mail-enabled have\u00a0preconfigured attributes, such as email addresses.<\/p>\n
\n\u2022 When you install Exchange Server 2013, the email attributes for mail-enabled and mailbox-enabled objects replicate to the global catalog. In the context of Exchange Server, global catalog is used for the following: The global address list (GAL) is generated from the recipients list in an Active Directory forest\u2019s global catalog.
\n\u2022 Exchange Server 2013 transport service access the global catalog to find the location of a recipient mailbox when delivering messages.
\n\u2022 Client Access servers access the global catalog server to locate the user Mailbox server and to display the global address list to Microsoft Office Outlook\u00ae, Microsoft\u00ae Outlook Web App, or Exchange ActiveSync clients.
\nNote<\/strong>: Because of the importance of the global catalog in an Exchange Server organization,
\nyou must deploy at least one global catalog server in each Active Directory site that contains
\nan Exchange 2013 server. You must deploy enough global catalog servers to ensure adequate
\nperformance. Exchange Server 2013 does not use Read-Only Domain Controllers(RODCs) or <\/span><\/strong>RODCs that you configure as global catalog servers (ROGC). This means that you should not <\/span><\/strong>deploy an Exchange 2013 server in any site that contains only RODCs or ROGCs.<\/span><\/strong><\/p>\n
\nEach computer that is running Exchange Server must use DNS to locate AD DS and the global
\ncatalog servers. As a site-aware application, Exchange Server 2013 prefers to communicate
\nwith domain controllers that are located in the same site as the computer that is running
\nExchange Server. Exchange Server services use DNS to locate a valid domain controller or global catalog. By default, each time a domain controller starts the Netlogon service, it updates Domain Name System(DNS) with service (SRV) records that describe the server as a domain controller and global catalog server, if applicable. To ensure that the domain controller updates DNS records properly, it is essential that all domain controllers use an internal DNS server that supports dynamic updates. After DNS records are registered, computers that are running Exchange Server can use DNS to find domain controllers and global catalog servers.
\nSRV Resource Records<\/strong>
\nSRV resource records are DNS records that identify servers that provide specific services on the network. For example, an SRV resource record can contain information to help clients locate a domain controller in a specific domain or site.
\nAll SRV resource records use a standard format, which consists of several fields that contain information that AD DS uses to map a service back to the computer that provides the service. The SRV records for domain controllers and global catalog servers are registered with different variations to allow locating domain controllers and global catalog servers in several different ways.<\/p>\n
\nWhen a computer that is running Exchange Server is a member server, Exchange Server configures it dynamically with its site each time it authenticates to AD DS. As part of the authentication process, the registry stores the site name. When the Exchange Server queries DNS for domain controller or global catalog server records, the Exchange Server always attempts to connect to domain controllers that have the same site attribute as the Exchange Server.<\/p>\n
\nHost records provide host name to IP address mapping. Host records are required for each domain controller and other hosts that need to be accessible to Exchange Servers or client computers. Host records can use Internet Protocol version 4 (IPv4), which are A records; or Internet Protocol version 6 (IPv6) records, which are AAAA records.
\nMX Records<\/strong>
\nA Mail Exchanger (MX) record is a resource record that allows servers to locate other servers to deliver Internet email by using the Simple Mail Transfer Protocol (SMTP). An MX record identifies the SMTP server that will accept inbound messages for a specific DNS domain. Each MX record contains a host name and a preference value. When you deploy multiple SMTP servers that are accessible from the Internet, you can assign equal preference values to each MX record to enable load balancing between the SMTP servers.
\nYou also can specify a lower preference value for one of the MX records. All messages are routed through the SMTP server that has the lower preference value MX record, unless that server is not available.
\nNote: In addition to SRV, Host, and MX records, you also might need to configure
\nSender Policy Framework (SPF) records to support Sender ID spam filtering. In addition, some
\norganizations use reverse lookups as an option for spam filtering, so you should consider adding reverse lookup records for all SMTP servers that send your organization\u2019s email.
\nSoftware Requirements for Exchange Server 2013\u00a0<\/strong><\/p>\n
\n\u2022 Windows Server\u00ae 2012 Standard or Datacenter
\n\u2022 Windows Server 2008 R2 Standard with Service Pack 1 (SP1)
\n\u2022 Windows Server 2008 R2 Enterprise with SP1
\n\u2022 Windows Server 2008 R2 Datacenter RTM or newer<\/p>\n
\n\u2022 Microsoft .NET Framework 4.5 (only for Windows Server 2008 and 2008 R2).
\n\u2022 Windows Management Framework 3.0 (already included with Windows Server 2012).
\n\u2022 Remote Server Administration Tools (RSAT) for AD DS (can be installed with Server Manager).
\n\u2022 Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit.
\n\u2022 Microsoft Office 2010 Filter Pack SP1 64-bit or Microsoft Office 2013 Filter Pack.
\n\u2022 Exchange Server Updates for Knowledge Base articles KB974405, KB2619234, and KB2533623 when installing Exchange Server 2013 on Windows Server 2008 R2.
\nYou also should ensure that the Task Scheduler service is enabled and running on the server where you plan to install Exchange Server 2013.<\/p>\n
\nBefore you deploy Exchange Server 2013 in your organization, you need to ensure that your
\norganization meets AD DS and DNS requirements.<\/p>\n<\/a>
\nYou must meet the following AD DS requirements before you can install Exchange Server 2013:
\n\u2022 The domain controller that is the schema master must have Windows Server 2012,
\nWindows Server 2008 R2, Windows Server 2008, or Windows Server 2003 with Service
\nPack 2 (SP2). By default, the schema master runs on the first Windows domain controller installed in a forest.
\n\u2022 In each of the sites where you deploy Exchange Server 2013, at least one global catalog server must be installed and must run Windows Server 2012, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2003 SP2.
\n\u2022 In each site where you plan to install Exchange Server 2013, you must have at least one writable domain controller running Windows Server 2012, Windows Server 2008, or Windows Server 2008 R2.
\n\u2022 The Active Directory domain and forest functional levels must run Windows Server 2003, at the minimum, or newer versions.
\nDNS Requirements<\/strong>
\nBefore you install Exchange Server 2013, you must configure DNS correctly in your Active Directory forest. All servers that run Exchange Server 2013 must be able to locate Active Directory domain controllers, global catalog servers, and other Exchange Servers.<\/p>\n
\nBefore implementing Exchange Server 2013 in your environment, you must prepare AD DS.
\nAD DS, by default, does not have necessary classes, objects, and attributes defined for the
\nExchange Server. By preparing AD DS, you extend the AD DS schema, and also modify
\nconfiguration and domain partitions of AD DS. In addition, Exchange Server requires several
\ngroups and special permissions in AD DS; these are also configured during AD DS preparation.<\/p>\n<\/a>
\nYou can prepare your AD DS by running the Exchange Sever 2013 Setup Wizard with a user\u00a0account that has the permissions required to prepare Active Directory and the domain. To prepare the AD DS schema and configuration partition, you must use an account that is a member of the Schema Admins and Enterprise Admins groups. By using this type of account, the wizard automatically prepares Active Directory and the domain.
\nAlternatively, you can also prepare AD DS for Exchange Server by running the Exchange Server 2013 setup utility from the command line. If you want to prepare the AD DS schema, and upgrade it to a version supported by Exchange Server 2013, you should run either of the following setup commands:
\nsetup \/PrepareSchema or setup \/ps<\/em><\/strong>. To execute this command, you must also be a member in the Enterprise Admins or Schema Admins groups.
\nThis command performs the following tasks:
\n\u2022 Connect the Exchange Server to the schema master domain controller.
\n\u2022 Import LDAP Data Interchange Format (LDIF) files to update the schema with Exchange Server 2013 specific attributes.
\n\u2022 Set the schema version (ms-Exch-Schema-Version-Pt) to 15132.
\nNote: You can also prepare the schema as a part of the PrepareAD procedure, which is
\ndescribed below.
\nTo prepare AD DS objects and the AD DS configuration partition for Exchange Server 2013, you should run setup with the \/PrepareAD switch, by executing the following command:
\nSetup.exe \/PrepareAD \/IAcceptExchangeServerLicenseTerms \/OrganizationName:\u201dName of <\/strong><\/em>
\nOrganization\u201d<\/strong><\/em>
\nThis command performs the following tasks:
\n\u2022 Creates the Microsoft Exchange container if it does not exist; the container is created under
\nCN=Services,CN=Configuration,DC=<root domain>.
\n\u2022 Verifies that the schema has been updated, and that the organization is up to date, by checking the objectVersion property in Active Directory. The objectVersion property is in the CN=<your organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container. The objectVersion value for Exchange Server 2013 is 15448.
\n\u2022 Creates all necessary objects and containers needed for Exchange Server 2013, under
\nCN=<Organization Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root
\ndomain>.<\/p>\n
\nnamespace, under CN=Transport Settings,CN=<Organization Name>,CN=Microsoft
\nExchange,CN=Services,CN=Configuration,DC=<root domain>.
\n\u2022 Assigns specific permissions throughout the configuration partition.
\n\u2022 Imports the Rights.ldf file. This adds the extended rights required for Exchange to install into
\nActive Directory.
\n\u2022 Creates the Microsoft Exchange Security Groups OU in the root domain of the forest, and assigns specific permissions to this OU.
\n\u2022 Creates the management role groups within the Microsoft Exchange Security Groups OU.
\n\u2022 Adds the new universal security groups (USGs) that are within the Microsoft Exchange
\nSecurity Groups OU to the otherWellKnownObjects attribute stored on the CN=Microsoft
\nExchange,CN=Services,CN=Configuration,DC=<root domain> container.
\n\u2022 Creates the Unified Messaging Voice Originator contact in the Microsoft Exchange System Objects container of the root domain.
\n\u2022 Prepares the local domain for Exchange Server 2013.
\nTo perform this command, you must be a member of Enterprise Admins security group, and you must run this command on the computer that is in the same domain as the schema master domain controller.
\nIf you have more than one domain, you should wait for a period of time after running this command, so that changes performed to AD DS are replicated to all other domains and domain controllers.At the end of this process, you should execute the setup \/PrepareDomain command in each domain where Exchange recipients will be located. You do not need to run this command in a domain where you ran setup \/PrepareAD.
\nAlternatively, you can also run setup \/PrepareDomain:<FQDN of domain you want to prepare> to prepare a specific domain, or you can run setup \/PrepareAllDomains or setup \/pad to prepare all domains in your organization.
\nThis command performs the following tasks:
\n\u2022 Creates the Microsoft Exchange System Objects container in the root domain partition in AD DS, and sets permissions on this container for the Exchange Servers, Exchange Organization Administrators, and Authenticated Users groups.
\n\u2022 Sets the objectVersion property in the Microsoft Exchange System Objects container under DC=<root domain>. This objectVersion property contains the version of domain preparation. The version for Exchange Server 2013 is 13236.
\n\u2022 Creates a domain global group called Exchange Install Domain Servers in the current domain.
\n\u2022 Assigns permissions at the domain level for the Exchange Servers USG and the Organization
\nManagement USG.
\n\u2022 After all of these commands are successfully completed, your AD DS is ready for Exchange Server 2013 installation. You can check if preparation went well, by performing the following tasks: In the Schema naming context, verify that the rangeUpper property on ms-Exch-Schema-Version-Pt is set to 15132.
\n\u2022 In the Configuration naming context, verify that the objectVersion property in the CN=<your
\norganization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container is set to 15448.
\n\u2022 In the Default naming context, verify that the objectVersion property in the Microsoft Exchange System Objects container under DC=<root domain is set to 13236.<\/p>\n
\nIn Exchange Server 2013, Microsoft made\u00a0major changes in the server role architecture. In
\nExchange Server 2007 and Exchange Server 2010, there were five server roles hosting various
\nfunctionalities, including:
\n\u2022 Mailbox Server role
\n\u2022 Client Access role
\n\u2022 Hub Transport role
\n\u2022 Edge Transport role
\n\u2022 Unified Messaging role
\nIn Exchange Server 2013, the number of server roles is greatly reduced, to only these two roles:
\n\u2022 Mailbox Server role
\n\u2022 Client Access server role
\nAll other roles, except the Edge Transport role (which does not exist in Exchange Server 2013), are integrated within these two roles.<\/p>\n<\/a><\/p>\n
\nUnlike Microsoft Exchange Server 2010, in which the Mailbox Server role hosted only mailbox and public folder databases and provided email storage, in Exchange Server 2013, the Mailbox Server role also includes Client Access protocols, Hub Transport service, mailbox databases, and Unified Messaging components. This means that the functionality of three roles in Exchange Server 2010 (Mailbox, Hub Transport, and Unified Messaging) is now integrated in only one role in Exchange Server 2013.
\nThe Client Access Server role has changed in Exchange Server 2013. The Client Access server is now basically a proxy server that handles all client connections, by admitting all client requests and routing them to the correct active Mailbox database. It provides authentication, redirection, and proxy services, and offers support for the following client access protocols: HTTP, POP and IMAP, and SMTP.
\nAlso unchanged is the fact that the Client Access server does not store any user data on itself; nor does it do any message queuing. The Client Access server role also provides some security functionality, by enforcing SSL in communication with clients. In some scenarios where the Exchange Server is deployed in multiple sites within one organization, the Client Access server also can redirect the request to a more\u00a0suitable Client Access server or proxies the connection to the right Mailbox server.
\nNote: The Edge Transport role is not included in Exchange Server 2013. However, you can
\nuse the Exchange Server 2010 Edge Transport server with Exchange Server 2013 servers.
\nClient Access Server<\/strong>
\nThe Client Access Server in Exchange Server 2013 provides the following features:
\n\u2022 Stateless server. In Exchange Server 2007 and 2010, most of the protocols on the Client Access server required session affinity in scenarios where the Client Access server was in a load-balancing cluster. That meant that all requests from a single Outlook Web App client had to be handled during an entire session by a specific Client Access server within a load-balanced array of Client Access servers.
\nIn Exchange Server 2013, this is no longer the case, and the Client Access server is now stateless. All processing for the mailbox now happens on the Mailbox server, so it does not matter which Client Access server in an array of Client Access servers receives each individual client request. By implementing this, you can use Layer 4 load balancing instead of the more expensive Layer 7 load balancing. This allows hardware load balancing devices to support significantly more concurrent connections.
\n\u2022 Connection pooling. As in previous releases of Exchange, the Client Access Server manages
\nclient authentication for client connections and sends AuthN data to the Mailbox server role. The connection between the Client Access Server and Mailbox server is established by using a privileged account that is a member of the Exchange Servers group. This allows the Client Access servers to effectively pool connections to the Mailbox servers. With this technology, a Client Access array can handle millions of client connections from the Internet or internal network, but uses many fewer connections to proxy the requests to the Mailbox servers than in previous versions of Exchange.<\/p>\n
\nIn Exchange Server 2013, the Mailbox Server role provides much more functionality than in previous Exchange Server versions. This includes integration of the Hub Transport service (previously known as the Hub Transport server role) and Unified Messaging service (previously known as the Unified Messaging server role). This is the key role for storing mailbox and public folders data, as well as for Unified Messaging functionality and message queuing.<\/p>\n
\nClient and Server Communication in Exchange Server 2013
\nBecause of the modifications that were made to the Exchange Server 2013 architecture, changes were also made to the way in which clients communicate with the Exchange Server, and how Exchange Server 2013 roles communicate with each other and with AD DS components.
\nFrom the client perspective, the most important connectivity change is that remote procedure call (RPC) is no longer supported as a direct client access protocol. In previous Exchange versions, Outlook clients from an internal network were connecting to Exchange Server by using RPC (or MAPI). In Exchange Server
\n2013, all client connections are established by using RPC over HTTPS. This means that all clients are\u00a0connecting by using the Outlook Anywhere service. This eliminates the need to have the RPC service running on the Client Access server. In addition, you will have one fewer FQDN to manage, because all clients will be using a new connection point made up of the user\u2019s mailbox GUID + @ + UPN suffix. As a result of these changes, only Outlook 2007 and newer clients support connection to Exchange Server 2013.
\nDeployment Options for Exchange Server 2013<\/strong>
\nWhen you plan an Exchange Server 2013 installation, you must decide how you will
\norganize server roles, and you must choose the appropriate Exchange Server 2013 version.<\/p>\n<\/a>
\nExchange Server 2013 is available in both the Standard Edition and Enterprise Edition. The
\nStandard Edition should meet the messaging needs of most small and medium corporations,
\nbut it also may be suitable for specific server roles or branch offices. The Enterprise Edition, designed for large enterprise corporations, enables you to create additional databases, and includes other advanced features. The main difference between Standard and Enterprise versions is that Enterprise version supports up to 50 mailbox databases while with Standard version you can create up to five databases. The version used is determined by product key that you enter when activating your Exchange installation. You should also make sure that you select the appropriate version of client access license (CAL) from the following options:
\n\u2022 Exchange Server Standard CAL. This license provides access to email, shared calendaring, Outlook Web App, and ActiveSync.
\n\u2022 Exchange Server Enterprise CAL. This license requires a standard CAL, and provides access to
\nadditional features such as unified messaging, per-user and per-distribution-list journaling, managed custom email folders, and Microsoft Forefront\u00ae Endpoint Protection for Exchange Server.In general, there are three deployment scenarios that you can choose from, including:
\n\u2022 Single server deployment. In this scenario, you deploy both Exchange Server roles on a single server. This scenario is appropriate for small organizations with limited resources. Deploying all Exchange Server services on a single server has several drawbacks. These include having a single point of failure for your whole messaging system, and not having any high-availability options. If you choose to have a single-server Exchange deployment, it is recommended that you deploy Exchange Server inside a virtual machine, and that you keep that virtual machine highly available or at least replicated to another Hyper-V\u00ae in Windows Server 2012 host. This will provide you with high availability and redundancy for critical Exchange services.
\n\u2022 Multiple server deployment. In the multiple-server deployment scenario, you usually install the Client Access Server role and the Mailbox server role on separate servers, or you install more than one server with both roles installed. This requires that you provide at least two virtual or physical machines for the Exchange Server deployment. In scenarios where you also want to provide high availability, you should add more machines to build the Client Access load balancing cluster and DAGs. You cannot use DAGs and network load balancing (NLB) on the same set of machines. To achieve full redundancy for Exchange Server, you need at least four servers for Exchange, and at least two domain controllers.
\n\u2022 Hybrid deployment. A hybrid deployment provides the ability to extend on-premises Exchange Server functionality to the cloud. In this scenario, you connect your AD DS and Exchange Server with\u00a0\u00a0Microsoft Office 365. This allows you to move some of your Exchange resources to Office 365. A \u00a0hybrid deployment also can serve as an intermediate step prior to moving completely to an Exchange Online organization.
\nExchange Server 2013 Hybrid Deployment with Office 365<\/strong>
\nOffice 365 is a suite of four Microsoft services that are now available in an online version: Exchange Online, Lync\u00ae Online, SharePoint\u00ae Online, and Office Professional Plus. It is a subscription-based service that features various pricing options.<\/p>\n