Exchange Server 2010 Roles And Active Directory

In Exchange Server 2010, Mailbox server role is one of the roles that you can install and configure on a server running Windows Server 2008 R2. It is the most common role and the heart of the Exchange organization's infrastructure.

Edge Transport is a unique server role that is part of the Exchange server roles in 2010. This server role is not mandatory like the three that we mentioned earlier (i.e Mailbox, Client Access, Hub Transport). But it is recommended by Microsoft.

To those who have worked with Exchange Server 2007 in the past, the Exchange Server 2010 Installation Wizard will seem very familiar. The Wizard walks the administrator through the installation of several of the prerequisites and allows for the selection of specific server roles for deployment. However, the installation wizard does not cover all twists and turns. There are steps that must be taken to prepare the Active Directory environment and steps that must be taken to prepare the underlying operating system on the server you are installing on.

This chapter will focus on the installation process for a new Microsoft Exchange Server 2010 server in a typical configuration. In addition, this chapter assumes that the supporting infrastructure and server operating system do not exist and includes step-by-step instructions on how to install Windows Server 2008, Active Directory, supporting configuration settings, and the Exchange Server 2010 prerequisites from scratch.

As with Exchange Server 2007, Exchange Server 2010 has various roles that can be installed on the server to perform specific functions. There are five major server roles, most of which are modular and can reside on a single server (for small environments) or be distributed to multiple servers throughout an organization.

In Exchange Server 2010, however, the client access servers also manage MAPI (such as Outlook) client connectivity. In a pure Exchange Server 2010 environment, clients never have to connect directly to their mailbox servers -- all connectivity is to the client access server.

A Hub Transport server must be deployed in each Active Directory site that contains an Exchange Server 2010 Mailbox server, as all message routing in other sites goes through one or more Hub Transport servers.

For more information on the Unified Messaging server and detailed steps on installing and configuring the role, refer to Chapter 24, \"Designing and Configuring Unified Messaging in Exchange Server 2010.\"

Before installing Exchange Server 2010, the administrator should become familiar with the prerequisites for each of the server roles. This section covers the prerequisites for the implementation of Exchange Server 2010 in a Windows networking environment.

Windows Server 2008 ships with .NET Framework 3.0 already installed. However, Exchange Server 2010 requires .NET Framework 3.5 or above. When applying updates to the Windows Server 2008 server, if you elect to apply all updates the latest version of .NET Framework will be installed. If you elect to selectively install updates, make sure you install this update.

Exchange Server 2010 has built on these technologies and combined the on-site data replication features of CCR with the off-site data replication features of SCR. This combination of technologies is known as a database availability group (DAG). This architecture is designed to provide recovery from disk-level, server-level and site-level failures.

Installing Exchange Server 2010 Exchange Server 2010 server roles, prerequisites, high availability Exchange Server 2010 requirements: Hardware, Active Directory Exchange Server 2010 role-based access control

One of the design goals of Exchange Server 2010 was to use a single 1TB SATA disk for the mailbox database and its log files. Another goal was to allow multi GB mailboxes without any negative performance impact on the server. To make this possible, the database schema in Exchange Server 2010 has now been flattened, making the database structure used by the Exchange Server much less complex than it was in Exchange Server 2007 and earlier. As a result, the I/O requirements of an Exchange Server 2010 server can be up to 50% less than for the same configuration in Exchange Server 2007.

Speaking of which, Exchange Server 2010 also runs on top of PowerShell Version 2. This version not only has a command line interface (CLI), but also an Interactive Development Environment (IDE). This enables you to easily create scripts and use variables, and you now have an output window where you can quickly view the results of your PowerShell command or script.

In addition to PowerShell V2, Exchange Server 2010 also uses Windows Remote Management (WinRM) Version 2. This gives you the option to remotely manage an Exchange Server 2010 server without the need to install the Exchange Management Tools on your workstation, and even via the Internet!

The Schema Master in the forest needs to be Windows Server 2003 SP2 server (Standard or Enterprise Edition) or higher. Likewise, in each Active Directory Site where Exchange Server 2010 will be installed, there must be at least one Standard or Enterprise Windows Server 2003 SP2 (or higher) server configured as a Global Catalog server.

From a performance standpoint, as with Exchange Server 2007, the ratio of 4:1 for Exchange Server processors to Global Catalog server processors still applies to Exchange Server 2010. Using a 64-Bit version of Windows Server for Active Directory will naturally also increase the system performance.

These server roles can be installed on dedicated hardware, where each machine has its own role, but they can also be combined. A typical server installation, for example in the setup program, combines the Mailbox, Client Access and Hub Transport Server role. The Management Tools are always installed during installation, irrespective of which server role is installed.

When you run Microsoft Exchange Server 2010 Setup /PrepareAD, the Microsoft Exchange Server Analyzer Tool queries the existing Active Directory topology to determine whether any Microsoft Exchange Server 2007 server roles exist. If Exchange 2007 server roles are not detected, you receive the following warning message:

If you decide that you need to deploy an Exchange 2007 server prior to deploying Exchange 2010, the deployment of a single Exchange 2007 with all server roles is sufficient to enable the deployment of future Exchange 2007 servers in the organization. To deploy the Exchange 2007 server into your Exchange 2003 organization, follow these steps:

Next, look at the Reachability column. Generally, you see one of several possible numbers in this column. If the domain controller is a domain controller but not a global catalog server (Roles column shows CD-), this number is 6 (0x2 0x4) to signify that the server's domain controller port (389) is reachable by a TCP connection. If the domain controller is a global catalog server (Roles column shows CDG), this number is 7 (0x1 0x2 0x4), which signifies that the server's domain controller port (389) and global catalog server port (3268) are reachable by a TCP connection. If you see other numbers here (especially 0), there may be a problem with the connection from the Exchange server to the directory service.

Exchange 2013 uses the same Role Based Access Control (RBAC) permissions model that's used in Exchange 2010. When you install Exchange 2013 into an existing Exchange 2010 organization, the same management role groups, management roles, and management scopes apply to both Exchange 2013 and Exchange 2010 servers and recipients. Members of role groups, or users assigned to roles, can administer any Exchange 2013 or Exchange 2013 server or recipient that's included in the scope of the role group or role. If you don't use scopes in your organization and you want the members of your existing role groups to manage Exchange 2010 and Exchange 2013 servers and recipients, you don't have to do anything else. Those administrators will be able to manage Exchange 2013 servers and recipients that are added to the organization. If you need a reminder on how permissions work in Exchange 2010 and Exchange 2013, see Permissions.

In the new organization, you might want to separate the administration of Exchange 2010 and Exchange 2013 servers and recipients. The group of administrators responsible for administering Exchange 2010 servers and recipients may not be allowed to administer Exchange 2013 servers and recipients, and vice versa. In this case, you can use management scopes to define the servers and recipients each group of administrators should be allowed to manage. After you create the scopes you want, you can then copy existing role groups, add the administrators who should be a member of each, and then add the scopes to those role groups. When you're done, the members of each role group will only be able to administer the servers and recipients that match their respective scopes.

After you finish, the Exchange 2013 administrators will be members of the appropriate Exchange 2007 administrator role or roles. The Exchange 2013 administrators can use the Exchange 2007 management tools to manage Exchange 2007 servers and recipients.

This post assumes that your organization is maintaining some Exchange presence on-premises, whether Exchange 2013 or 2016 (we do not mention Exchange 2019 in this post because it cannot coexist with Exchange 2010). If your organization has moved all mailboxes to Office 365 and is in a Hybrid environment, we are assuming you will maintain an Exchange footprint per Scenario 2 in How and when to decommission your on-premises Exchange servers in a hybrid deployment.

Decommissioning Exchange 2010 cannot be initiated until all mailboxes have been moved to Exchange 2016. As an example, we cannot decommission Exchange 2010 Hub Transport servers completely until all of the mailboxes are moved off the legacy platform, this is due to how Delivery Groups are