Architecting an On-premises Exchange 2010 Organization (Part 1)

So you decided to migrate to Exchange 2010 On-Premises. As with any project, the planning phase is critical in order to successfully execute your migration project. In this blog post, I'm going to discuss some of the areas within yourActive Directory Forest that you need to be aware of when migrating to an On-Premises Exchange 2010 Organization, and how the overall directory services topology comes into play during your migration.

Sizing matters in every aspect of your Exchange environment and, like I’ve said in the past, Microsoft Exchange is truly a mix of Active Directory and message routing. A solid Active Directory will surely increase the success of your migration project. Unlike Domino, Exchange relies heavily on Active Directory.  So, it’s important to understand what your Active Directory is used for before starting your migration. Determining what’s currently working and how well it’s working may save you time later when deciding what you may need to modify in order to maintain the service levels your end users or customers are accustom to on a daily basis.

So, let’s dig into Active Directory by taking a look at the logical partitions of Active Directory:


The Configuration Partition: The configuration partition stores information about the forest-wide configurations. For the most part, the information includes Active Directory sites, global Exchange settings, transport settings, mailbox policies, and UM dial plans. These configurations are stored in a container in the configuration partition, which is avialable via ADSI. Exchange configuration information is stored in a subfolder under the configuration partition's Services container. The following information can be located in this container:

  • Address lists
  • Global settings
  • Client access settings
  • Connections
  • E-mail address policies
  • System policies
  • Transport settings
  • Address and display templates
  • Administrative groups
  • Messaging records management, mobile, and UM mailbox policies
Migrate from Notes to Exchange
Schema Partition: The schema partition holds two different types of information: Attributes and Classes. Schema classes set the definition of all the types of objects that can be created and stored in Active Directory. Schema attributes define all the properties of these objects.
 

Domain Partition: The domain partition stores information in default containers and in organizational units that are created by the Active Directory administrator. These containers hold the domain-specific objects, such as computers, users, and groups. Specific to Exchange, this is where system objects are referenced, added, or altered. When Exchange is implemented into your Active Directory Forest, Exchange updates the objects in this logical partition to support all of its functionality. This functionality affects how recipient information is stored and accessed in the future.

Now that we have a grasp on what Active Directory really is, and we understand that Exchange 2010 stores all configurations and recipient information within the Active Directory Directory Services Database (AD DS), the next question we need to ask is, “how do we retrieve that information when we need it?” When a system running Exchange wants to obtain information, it must query Active Directory to access this information. The process that takes place is technically referred to as DSACCESS.  Now we’ll examine what the three main Exchange Server roles store in Active Directory.

Mailbox Server Role: The Mailbox server role stores configuration information about mailbox users in Active Directory. Additionally, the configuration for agents, address lists, and policies regarding this role reside there as well. The Mailbox server retrieves this information when enforcing mailbox policies and for all global or organization wide settings.

Client Access Server Role: The Client Access server role receives connections either from the Internet or internally for users who access their mailboxes using the Outlook Web Application or Microsoft Exchange ActiveSync. When a user connection attempt is made, the Client Access server contacts Active Directory to authenticate the user and to determine the location of the user's mailbox server. If the user's mailbox is in the same Active Directory site as the Client Access server, the user is connected directly to their mailbox. If the user's mailbox is in a different Active Directory site than the Client Access server that received the initial connection, the connection is redirected to a Client Access server in the appropriate Active Directory site. This also holds true when looking up information. If a user tries to query another users calendar to determine the best time for a meeting, they’re directed to the Client Access server first, and then the process explained above takes place. This Exchange validation process ensures that the user has the appropriate permissions to view the information they are requesting.

Hub Transport Server Role: The Hub Transport server role contacts Active Directory when it performs message categorization. Categorization is how Exchange determines where to send a specific email. The categorizer must query Active Directory to perform recipient lookup and routing resolution. The information that the categorizer retrieves during recipient lookup includes the location of the recipient's mailbox and any restrictions or permissions that may apply to the recipient. The categorizer also queries Active Directory to expand the membership of distribution lists and to perform the Lightweight Directory Access Protocol (LDAP) query processing that is required when mail is sent to a distribution list. During routing resolution, the categorizer uses the topology information that is cached by the Active Directory Topology service to discover the routing path for a message. Ever wonder why, having a fully meshed network could slow down your messaging environment? Well, it’s because the Hub Transport server uses Active Directory site configuration information to determine the location of other servers and connectors in the organizations topology to find the path to submit the message. When the Hub Transport server has resolved the location of the recipient's mailbox, it uses Active Directory site information to locate the mailbox store and the mailbox server. If the mailbox store is in the same Active Directory site as the Hub Transport server, the Hub Transport server delivers the message directly to the user's mailbox. If the mailbox store is in a different Active Directory site than the originating Hub Transport server, the Hub Transport server delivers the message to a Hub Transport server in that Active Directory site. The Hub Transport server stores all configuration information in Active Directory and accesses Active Directory to retrieve this information. Additionally, Active Directory stores all information regarding transport rules, journal rules, and connectors. Let’s imagine an environment where we send and receive 50,000 internal messages a day and accept 50,000 external messages. That is 100,000 queries against your Active Directory!

I certainly hope you found this overview useful. In my next post, I’ll discuss the coexistence of Domino and Exchange, as well as coexistence between different versions of Exchange (2003, 2007, 2010). I’ll also examine how directory services can be enhanced as well as a few common roadblocks. Stay tuned!

- Jason