Planning Your Network Configuration

Although it takes but a few words to say, planning your network configuration will take you on a long and winding road. In the following sections, we will cover some of the important parts of the planning process:

• Establishing naming conventions for objects in your Exchange server hierarchy

• Selecting a Microsoft networking domain model

• Defining administrative responsibilities

• Planning servers and internal connections to them

• Planning connections to other systems such as the Internet

• Validating and optimizing your design

You need to establish naming conventions for your Exchange organization, servers, connectors, and recipients. Some of these names depend on how you name Windows 2003 objects, while others have no dependency on the operating system. The Windows 2003 domain model that you choose will significantly affect how your Exchange servers interact, especially from a security standpoint.

Recipient, Organizational, and Server administrative permissions replace administrative group security in Exchange 2000/2003 How you set their boundaries depends heavily on how you want to parcel out responsibility for Exchange server management in your organization. Active Directory sites are now used as the boundary for local message routing instead of the routing group structure used in Exchange 2000/2003 and the server-to-server communication functionality of Exchange 5.5 sites.

The servers where you install Exchange 2007 must have adequate capacity; in Chapter 2, "Exchange Server 2007 Architecture," we reviewed some of the hardware requirements for Exchange Server 2007. Even if you plan for servers of very high capacity and even though Exchange 2007 allows lots of mailboxes on a server, you may consider distributing user mailboxes across multiple servers to increase performance. You also should consider setting user storage quotas to ensure adequate disk capacity over time. In addition, you should be sure that your servers are protected against low-level and catastrophic glitches by such things as fault-tolerant hardware, uninterruptible power supplies, and a reliable backup system. Finally, you should ensure that users have adequate bandwidth to access messages and other objects on your Exchange servers.

If you need to communicate with the Internet (and most organizations do), then you will need to think about message hygiene (antivirus and anti-spam protection), perimeter network protection, how you allow SMTP mail in to your organization, and which Hub Transport server(s) will be responsible for sending and receiving Internet mail.

Finally, when key aspects of your Exchange system are in place, you need to test them to be sure that they work at all. Then you need to ensure that they work up to whatever performance and other standards you need to meet.

Okay, let's start our trip down that long and winding road.

Establishing Naming Conventions

Using naming conventions seems like such a small thing, but you will quickly change your mind if you work in an organization in which the server's IP address is easier and quicker to type (or remember!) than its name. Here you set some criteria for naming the key Exchange organizational components:

• Organization

• Servers

• Storage groups and databases

• Recipients (including users, contacts, and distribution groups)

• Exchange components

Tip 

Note that the organization name is chosen when your first Exchange server is installed. Once it is set, it cannot be changed without removing all Exchange servers.

Your goal should be to establish a logical and consistent set of naming conventions that fit in well with your real-world organizational structure and culture.

Naming the Organization and Servers

Here's one easy and usually safe naming convention that you can use:

• Organization The master company name, for example, Barry Gerber and Associates. Names for the Exchange organizations can be up to 256 characters long, but we strongly suggest that you keep names to around 32 characters. Organization names should be less of a factor with Exchange 2007 since the organization name does not even appear in the Exchange Management Console.

• Server You can use generic naming, such as, for example, EXCHANGE01, LAXEXMB01, LAXEXCA01, and so on.

Server names are set when you install Windows Server. They are limited to a maximum of 63 characters, but you should limit them to 15 characters if pre-Windows 2000/XP clients will access them.

For most names, almost any character is permitted. However, we strongly suggest you use only the 26 uppercase and lowercase letters of the alphabet, the numerals 0 through 9, and the hyphen. Don't use spaces, underscores, or any accented letters.

When you begin to establish server names, if you are going to have more than one server in your organization, there are a couple of factors that you should take in to consideration:

• The naming standard should be easy to remember

• The naming standard should makes sense; yes it is fun to name servers after X-Men or Battlestar Galactica characters, but the naming makes absolutely no sense to anyone else.

• It should allow for some growth and scalability. Growth can be accomplished by including a couple of digits at the end of the name. Scalability can be accomplished by allowing for a portion of the name to identify a specific location if you have more than one location or think that you will.

• It should easily identify the server's function (mailbox server, domain controller, file server, and so on).

• In organizations with more than one location, the name should have a code that identifies the server's physical location. We are fond of airport codes or building numbers.

In an environment with more than a few servers, having some portion of the naming standard that helps to identify the role will quickly reduce frustration for everyone concerned. Table 3.1 shows some two-digit codes that can help to identify a server's role.

Table 3.1: Identifying Server Roles with Two-Digit Codes
Open table as spreadsheet

Server Function	Server Code
Mailbox	MB
Clustered mailbox	CM
Hub Transport	HT
Unified Messaging	UM
Client Access	CA
Edge Transport	ET
Combined functions	CF
Domain controller	DC
Cluster node	CN
File server	FS
Print server	PS
Web server	WB

Although the codes in Table 3.1 are merely examples, you can expand on them or develop your own to meet your needs. Many organizations use three-digit codes to more accurately represent the function of a server.

Once you have role codes, you can begin to determine what the naming standard will look like. A favorite of ours includes a three-digit location code, server type, and a unique number; many organizations use the local airport code as the location code. Table 3.2 shows some examples of server names and how they would be decoded.

Table 3.2: Examples of Server Names
Open table as spreadsheet

Server Name	Explanation
LAXCN01	Los Angeles cluster node 01
LAXCN02	Los Angeles cluster node 02
LAXCM01	Los Angeles clustered Mailbox server 01
LAXHT01	Los Angeles Hub Transport 01
LAXCA01	Los Angeles Client Access 02
HNLCF01	Honolulu combined function server 01
SFOMB01	San Francisco Mailbox server 01
SFOCF01	San Francisco combined function server 01

Naming Recipient Mailboxes

Even before you get to the point of assigning mailboxes, you should consider having a standard for creating and naming user accounts. Remember that the username (the pre-Windows 2000 name) must be unique for the entire domain. The user principal name (UPN) by default consists of the user's username and the forest root domain's DNS suffix; the UPN name must be unique for the entire forest. Ideally, the username should be unique across the entire forest. Some organizations will use the employee number (if applicable), while others randomly generate characters that are appended to the end of a username.

Tip 

TheusernamedoesnothavetobethesameastheExchangealias;theExchangealiasisused(by default) to generate SMTP e-mail addresses for the mailboxes.

You also need some criteria for naming mailboxes. There are four key names for each Exchange mailbox:

• First

• Last

• Display

• Alias

Mailbox administrators create and modify these names in the Windows 2003 Active Directory Users and Computers Microsoft Management Console snap-in; they can also be created or modified using the Exchange Management Console.

The first and last names are entered when the user's Windows 2003 login account is created. The display name is created from the first and last name (as well as the middle initial or name, if present). The alias name is created from the user's Windows 2003 logon name, which is entered when the user's Windows 2003 account is created.

The first and last names and the display name are Windows 2003 objects that are also used by Exchange. The alias is an Exchange object that is used in forming some Exchange e-mail addresses (for example, the user's Internet address). The Exchange alias should be unique, if possible, in order to avoid conflicts with other e-mail addresses that are created.

You can change the default rules for constructing mailbox names, and you can manually change these names. In Figure 3.1, you can see the first and last names as well as the display name for an Exchange 2007 mailbox in Active Directory Users and Computers, but this information can also be displayed and modified using the Exchange Management Console.

Figure 3.1: Display names are created using first and last names when a user account is created.

Figure 3.2 shows the Exchange alias name for a user's mailbox; this information is only visible in the mailbox properties when using the Exchange Management Console. This is a change for Exchange 2000/2003 administrators who may be used to finding this information in Active Directory Users and Computers.

Figure 3.2: The alias name for an Exchange 2007 mailbox

Display Names

The Outlook client global address list shows the display name for each mailbox (see Figure 3.3). You need to decide on a convention for display names. This naming convention should account for potentially duplicate display names and allow for information in the display name that will let a user pick the correct name when there is, for example, more than one John Smith. You might even want to include department names or titles in display names so that users aren't faced with ambiguous selections, as they might be if they encountered a list of 25 recipients named John Smith. Options include first-name-space-last-name (as in John Smith) or last-name-comma-space-first-name (as in Smith, John). You may even opt for something fancier that includes the user's location, title, or department. The default is first-name-space-last name.

Figure 3.3: The Exchange client global address book shows each mailbox's display name.

Display names can be up to 256 characters long. They are only a convenience - they're not a part of the mailbox's e-mail address. However, they are the way in which Exchange users find the people they want to communicate with, so don't scrimp when setting them up. You can also create custom address lists ordered by attributes of users. For example, you can create an address list that includes only users in a specific department.

Tip 

Display names will directly affect your users every day. Choose the naming standard for display names carefully.

Practically speaking, display name lengths should be limited only by your users' willingness to read through lots of stuff to find the mailbox they're looking for. The length (and additional information in the display name) may also be affected by the size of the organization and how familiar your users are with their fellow e-mail recipients. Additional information in the display name (such as title or location) can make it a lot easier for a user to determine that they are selecting the right mailbox from a list of thousands.

Tip 

Display names are also included in messages going to the Internet, so be careful about including information that might be considered sensitive, such as job title.

Full-blown arguments have sprung up around the metaphysics of choosing display name conventions. We'll leave the decision to you, although we prefer the convention Last_Name, First_Name (as in Doe, Jane). In a larger organization, it is easier to find Jane Doe among a list of the Does than among a list of the Janes. If you are interested in some examples of how different display name standards would look, here are some ideas. Which of these would help you in preventing duplicate display names for your organizations?

Mark Watts	The default, first name and last name.
Elfassy, David	Last name and first name, commonly used and easy to follow.
Martha Lanoza at HQ (x54321)	Identifies first name and last name as well as the location and the user's telephone number extension.
Jones, Damion Mr. (SFO - Network Manager)	Includes location and title.
Craig, Benjamin GS-14 US Air Force	Pay grade and organization.
Maher, Joshua MAJ-US Army, Fort Irwin	Title, organization, and location.
Swanson, Chuck (Volcano Surfboards)	Includes company name (useful for mail going outside of your organization). This is also a useful standard when naming mail-enabled contacts since it allows your users to identify recipients outside of your company.
Eiler Brian CAPT N651 COMPACFLT	User's last name and first name without the comma. Includes the title, job code, and the department.

Warning 

Something as apparently simple as changing the default order of last and first name in display names isn't all that simple with Exchange 2007. In Exchange Server 5.5, you made the change in the Exchange Administrator program. With Windows Server 2003/Exchange Server 2007, you have to edit the Active Directory schema. Why? Display names aren't just for Exchange mailboxes anymore. They're also used whenever end users or system administrators go looking for a specific Windows 2003 user in Active Directory. That's why it's an Active Directory issue. Editing Active Directory is somewhat akin to editing the Windows Registry. It's not a job for amateurs, and it's a job that may be done by someone not directly involved in day-to-day Exchange Server 2007 management. In addition, the decision to change the display name default for an Active Directory namespace is no longer simply an Exchange Server issue. It's an organization-wide issue because these changes affect more than electronic messaging.

Alias Names

For some messaging systems, the user's mailbox is identified by an alias name, which is part of the mailbox's address. Either Exchange itself or the gateway for the foreign mail system constructs an address using the alias. For other messaging systems, the mailbox name is constructed from other information.

Figure 3.4 shows the two addresses that Exchange built for a user by default for the Internet and for X.400. The Internet addresses use the Exchange alias Andy.Schan. X.400 addresses do not use the alias. Instead, they use the full first and last name attributes of the user. Natively, Exchange 2007 does not require the X.400 address but it is generated for backward compatibility with older e-mail systems.

Figure 3.4: Exchange Server uses the mailbox alias or the first and last names to construct e-mail addresses.

Aliases can be up to 63 characters long. That's too long, of course, because some people in foreign messaging systems will have to type in the alias as part of an electronic messaging address. Try to keep aliases short - 10 characters is long enough.

For some foreign messaging system addressing schemes, Exchange must remove illegal characters and shorten the alias to meet maximum character-length requirements. For example, underscores become question marks in X.400 addresses. You should do all you that you can to ensure that aliases are constructed using less-esoteric characters.

As with display naming, alias naming conventions are taken seriously, almost religiously. So don't be surprised if you have trouble deciding on one when you run them by "the committee."

Naming Mail-Enabled Groups

As simple as it sounds, many organizations spend hours or days debating and deciding their display name standard for mailboxes and then give no thought to naming their mail-enabled groups. The thought actually comes once all of the mailboxes and mail-enabled groups have been created and they realize that groups are distributed throughout the global address list alphabetically just as the users are. There should be a naming standard for distribution group names just as there is with display names and alias names, and again, as with all naming standards, people can get pretty passionate about what they think is the best.

Mail-enabled groups are sorted using the group name attribute. This is configured either through Active Directory Users and Computers or through the Exchange Management Console (EMC). Figure 3.5 shows the Group Information property page of a mail-enabled group using the EMC; the group's display name is changed in the Group Name field.

Figure 3.5: Mail-enabled group properties as viewed through the Exchange Management Console

Each of us has our own preferences, but most Exchange administrators agree that there should be something in distribution group names that identifies them as mail-enabled distribution groups. Another possible idea is to include some character or character string that identifies and sorts all of the distribution groups together. Here are some examples:

• _Directory Update Sales Team

• $Everyone in Marketing

• DL - IT Help Desk

• zz Human Resources

This list illustrates three possible ways to name and sort mail-enabled groups. The first is to use a special character - such as the underscore (_), the dollar sign ($), the exclamation symbol (!), or the pound symbol (#). The advantage of these characters is that they will sort all of the mail-enabled groups to the top of the global address list. Another example is using the letters DL (for distribution list) in front of each mail-enabled group; this will keep all of the mail groups sorted together. Finally, you could use characters such as zz; this will put the mail-enabled groups together but place them all at the bottom of the global address list. The advantage of having them all at the bottom rather than at the top is that it is less likely that a user will accidentally select a group.

Tip 

In Exchange 2007, all mail-enabled groups must be universal groups.

If a user just needs to see the groups in the global address list, they can also use the All Groups address list. The All Groups view shows only the objects in the directory that are mail-enabled groups.

Naming Exchange Components

Display names for mailboxes or groups affect the end user and therefore getting them right is a pretty important task. There are, however, a number Exchange-related components or objects for which you should consider naming standards. Why? Because incorporating standards for Exchange objects will make your life easier and the lives of your fellow Exchange administrators.

The objects and components that we are alluding to are found in the Exchange Management Console or the Exchange Management Shell:

• Managed folder mailbox policies

• Offline address books

• Exchange ActiveSync mailbox policies

• Transport rules

• Edge subscriptions

• E-mail address policies

• Unified Messaging dial plans

• Unified Messaging policies

• Storage groups

• Send connectors

• Receive connectors

• Mailbox databases

In a small organization, naming conventions for policies and objects that are listed in the organization-wide and server configuration settings are not as necessary since you may have only a few of these. However, in a larger organization with many locations and possibly many groups of administrators, include in the name of each policy or object enough information to identify what the object does and who is responsible for it. For example, even a small organization can identify with the transport rules (shown in Figure 3.6). Once an organization has dozen or more transport rules, it can be difficult to find the rule you need to edit.

Figure 3.6: Managing more than a few transport rules can become difficult.

Imagine the difficulty that an organization with administrators in multiple organizations around the world would face when they have to find a specific transport rule that affects only a certain part of their user community.

Storage groups and mailbox databases are sets of objects that should have standardized names. This helps not only the person that must administer the mailbox servers but also the recipient/mailbox administrators. A clearly defined naming standard can help when creating mailboxes or assigning mailboxes. Figure 3.7 shows the Mailbox Settings screen for the New Mailbox Wizard; note the Storage Group and Mailbox Database fields.

Figure 3.7: Assigning a storage group and mailbox database to a new mailbox

In the naming standard we are using for the storage groups and mailbox database, we include MBDB for mailbox database or SG for storage group. The name also includes the name of the server on which the database or storage group is found and a unique number for that storage group or mailbox store. Here are some examples:

• SG-LAXMB01-01

• SG-NYCCM01-02

• MBDB-LAXMB01-01

• MBDB-LAXMB01-02

• MBDB-LAXMB01-02

If you have already deployed some mailbox stores or storage groups, not to worry; you can easily rename them as you will find in later chapters. We recommend that you name the database file the same as the logical database. For example, the database MBDB-HNLEX03-01 would have a database file named MBDB-HNLEX03-01.EDB.

Selecting a Microsoft Active Directory Domain Model

Active Directory is widely deployed in organizations all over the world. This section may not be relevant to your organization since you may have a fully deployed Active Directory. However, even if you are a dedicated Exchange server administrator, understanding Active Directory is important and will make it easier for you to operate and troubleshoot Exchange.

As many different options for multiple trees and child domains as you may have (and may be tempted to use), we strongly urge you to consider a single domain mode whenever possible. This is by far the simplest to deploy and administer, and administrative permissions can still be delegated for individual resource and account management. Of course, if necessary, you can create a single root domain for your user accounts and create child domains (subdomains) and control access to various network resources using this model.

Aside from certain security requirements, one of the main reasons for multi-domain Windows NT networks was the difficulty of building single domains that crossed lower-bandwidth links. Microsoft has outfitted Windows 2003 with such features as sites and site connectors to deal with this issue. Unless you must adhere to strong regulatory or security requirements, the single-root domain model really makes the most sense.

If it works for your organization, you can even use your Internet domain name for your Windows 2003 root domain. This simplifies Exchange server installation just a little, although you need to be especially careful to protect any internal resources that shouldn't be accessible on the Internet. If you want to use a separate DNS name for your Windows 2003 root domain, then by all means do so. This can also help to reduce confusion and make your DNS names a little easier to support. You can still use your Internet domain name for external Exchange messaging. We like this approach and use .local for Windows domain names and .com, .edu, and so on for Internet domain names.

Tip 

Your Active Directory DNS names do not have to be the same as your Internet names and/or Internet SMTP addresses.

Defining Active Directory Sites

An Active Directory site is a collection of IP subnets that are all separated by reasonably high-speed connectivity. The definition of "high speed" is usually left up to the designer of the Active Directory, but we recommend that all of the subnets in a single Active Directory site have at least 10Mb Ethernet connectivity between each of the subnets in the site.

Since Windows 2000 was first released, Active Directory sites have been used to define replication paths between domain controllers and to help Windows clients find the closest domain controller when authenticating users. Exchange 2000/2003 servers used Active Directory sites to locate the domain controllers and global catalog servers that were closest to them on the network; they then used these domain controllers and global catalog servers for authentication, LDAP queries, and referring MAPI clients to global catalog servers.

In the past, administrators sometimes would not properly create all of the Active Directory sites for their organization or, worse, would not define all of the IP subnets properly. This would result in long login times and performance problems with Exchange because Exchange servers could be querying domain controllers and global catalog servers on the opposite side of the globe. An incorrect Active Directory site and subnet configuration is a mistake that you cannot afford to make with Exchange 2007. In addition to all of the performance problems that might occur with past versions, you may experience mail delivery failures because Exchange 2007 relies on the site architecture to properly deliver mail between Exchange servers in different sites.

Tip 

One simple way to check for Active Directory site problems is to check on each domain controller's Netlogon.log file found in the \windows\debug folder. If you see reports of clients logging in to that domain controller from undefined subnets, then you know you have some subnets that are not fully defined with Active Directory.

If you have more than one network physical location that has domain controllers and Exchange servers, you need to get your site and subnet architecture clearly and accurately defined. This is done in the Active Directory Sites and Services management console (Figure 3.8). For each of your physical locations, you must define the IP subnets and associate those subnets with the correct Active Directory site.

Figure 3.8: Defining Active Directory sites and subnets

Exchange 2003 Administrative Group Boundaries

If you are planning to migrate from an Exchange 2000/2003 organization, you will retain the Exchange 2000/2003 administrative groups through the migration. If you are building a brand-new Exchange 2007 organization, you will not need to worry about administrative groups.

Administrative groups play a couple of roles in an Exchange 2000/2003 environment as well as an Exchange 2007 organization that is in the middle of a migration. First, they can be used to control administrative access to your Exchange 2000/2003 server environment. You can set permissions on an administrative group so that only certain users can manage the Exchange 2000/2003 servers and other objects in the group. In this way, you can parcel out responsibility for managing different sets of Exchange servers to different people.

The administrative group structure of your Exchange 2000/2003 environment will probably depend to some extent on the structure of your organization. If you want a particular group, such as a department, to manage its own Exchange server environment, you would create an administrative group, put the department's Exchange server(s) in the administrative group, and assign permissions to manage the group to the appropriate Windows 2003 users or group.

Once the first Exchange 2007 server is installed in to an existing environment, a new Exchange administrative group is created that holds all of the Exchange 2007 servers regardless of the permissions necessary to manage them. This is called Exchange Administrative Group (FYDIBOHF23SPDLT); the text "FYDIBOHF23SPDLT" is a unique identifier is associated with the new administrative group name when the first Exchange 2007 server is installed to guarantee that the administrative group name is unique. The unique name for the Exchange Administrative Group (FYDIBOHF23SPDLT) administrative group's routing group is Exchange Routing Group (DWBGZMFD01QNBJR). These administrative group and routing group names are hard-coded and must not be changed.

Secret Ciphers

If you are curious about the unique identifiers DWBGZMFD01QNBJR and FYDIBOHF23SPDLT, then we will let you in a poorly kept secret. They are actually simple ciphers. Take each letter in the identifier FYDIBOHF23SPDLT and change it to the preceding letter in the alphabet and see what you get. Hint, F becomes E, Y becomes X, and so on. Conversely, with the DWBGZMFD01QNBJR identifier, take each letter in the identifier and change it to the next letter in the alphabet, so D becomes E, W becomes X. Try it and see what you get. If you are as big a fan of Exchange Server as we are, then we are sure you will agree.

Although the administrative groups do not show up in the Exchange 2007 Exchange Management Console, you can see them in the Exchange 2000/2003 Exchange System Manager console (see Figure 3.9).

Figure 3.9: Exchange System Manager after the first Exchange 2007 server is installed

Exchange 2003 Routing Group Boundaries

In Exchange 2000/2003, the routing groups defined the physical separation of Exchange servers; this separation was usually determined based on slow, unreliable, or non-full-time links. When defining Exchange 2000/2003 routing group boundaries, you should keep a couple of things in mind. First, Exchange 2000/2003 routing groups and Microsoft network domains are related. Second, all the Exchange servers in a routing group should have certain networking capabilities.

Routing groups have been replaced by Active Directory sites in Exchange 2007, but an organization that is going to have interoperability between Exchange 2007 and Exchange 2000/2003 will continue to see routing groups in Exchange System Manager. When the first Exchange 2007 server is installed, a new administrative group and routing group is created that will allow interoperability between Exchange 2000/2003 servers and Exchange 2007. Figure 3.10 shows a new unique routing group that is created in the new Exchange 2007 specific administrative group. This routing group will hold all Exchange 2007 servers.

Figure 3.10: Exchange 2007 routing group container used for interoperability with Exchange 2000/2003