Companies that deploy more than 50,000 mailboxes face difficult challenges. An especially complicated problem confronts large organizations that want to let independent autonomous sites manage Exchange Server decentrally but want the Global Address List (GAL) to encompass the entire organization. Some companies have thousands of users in several Exchange organizations that the companies haven't been able to connect because of organizational and technical problems.
In this article, I'll present techniques that organizations have used to successfully configure and implement Exchange Server in independent autonomous sites. (Several consulting companies call these sites franchised sites.) I'll describe architectural and implementation guidelines that many organizations use to assist in their implementations. Typically, these guidelines are a document that lays out the best practices for integrating autonomous sites to achieve a manageable global implementation. Companies frequently post the document on a Web site for easier dissemination. A group that has responsibility for the global architecture and organizationwide GAL typically creates and disseminates the guidelines.
What Is an Autonomous Site?
An autonomous site generally is self-governing, or independent. An autonomous Exchange site within a larger organization
- Is responsible for creating all Windows NT accounts and Exchange mailboxes for the site
- Is responsible for controlling configuration of the Exchange site and connections to other sites
- Has no NT security integration with the larger organization outside the site
- Must obtain GAL information from the larger organization
- Has complete independent authority to configure Exchange, including authority to implement third-party products
These sites frequently exist as almost separate entities from the larger organization. The common GAL and messaging connectivity are often the only shared service or configuration between these sites. Government—the US government in particular—Exchange implementations often have autonomous site configurations.
The Guideline Document
The purpose of a typical guideline document is to help autonomous sites integrate with the larger organization more easily. Although the guidelines don't dictate how a particular site must configure every aspect of its Exchange implementation, in some cases each site must follow a certain configuration to be able to connect to the larger organization. In a very large implementation, however, establishing rules that every site can agree to is difficult.
If you're part of the team responsible for the global architecture, the guidelines can be a useful tool for communicating best practices. The guideline document typically includes best practices in the following areas:
- Naming conventions
- Connectors
- Directory replication
- Public folders
- Address Book Views (ABVs)
I'll discuss each of these areas and their typical configurations.
Naming Conventions
People often have trouble agreeing on naming conventions. However, naming conventions are necessary to ensure that the GAL is useful across your entire company. Thus, you need to decide on the naming conventions and include them in your guideline document. Here are some considerations for naming conventions for each object.
Organization name. To support Exchange site replication, the Organization name must be the same for all sites. Therefore, select a generic name that all sites will be willing to use. In many cases, I have seen Organization used as the organization name. Other useful names are Exchange and Email.
Site name. The site name must be unique in the organization. A good choice is a short name (or abbreviation) that describes the geographic location of the site (e.g., Seattle). Functional names (e.g., departments) that are prone to change are usually not good choices, because you can't change site names. Organizational names (e.g., Manufacturing Division) are terrible choices for site names, because they're subject to change as the organization grows and changes structure.
Mailbox display name. Always start the mailbox name with the user's last name. People disagree about what follows the last name, but as long as the mailbox always starts with the last name, you can find the mailbox you're looking for in the GAL.
Distribution list (DL) display name. DLs are hard to control; a large organization can have hundreds of DLs. Most sites use a convention for display names to group together all the lists for a site and to make the DLs appear at the top or the bottom of the GAL. For example, the display name #Site_Name - DL Name will group DLs by site at the top of the GAL, and ZZSite_Name - DL Name will group DLs by site at the bottom of the GAL.
Another technique for making DLs easier to find is to create your lists in a separate recipient container called Distribution Lists. Users can go straight to this container when they're searching for a DL. You can administer a DL only in the site where you create it; however, the sites in this example are independent and autonomous, so users won't need DLs from another site in the organization.
Connectors: Site, X.400, or IMS?
Deciding which connector to use can be difficult. Microsoft provides the following rules of thumb:
- If you have sufficient bandwidth, always use the Site Connector. You often read that 56Kbps to 128Kbps of available bandwidth is sufficient. However, factors such as the impact of messaging on the link affect the amount of available bandwidth. For example, a 56Kbps connection to a remote office might be sufficient if the remote office has only 50 users, whereas an office with 500 users might have a huge effect on the connection. In the latter case, you probably would decide not to use the Site Connector.
- If you have low bandwidth or no NT domain integration, use the X.400 Connector.
- If you're connecting sites over the Internet, use the Internet Mail Service (IMS).
Despite these guidelines, however, a particular situation might call for a different configuration. The Site Connector uses remote procedure calls (RPCs) and NT security to make the connection to a remote site, so you must have some level of NT integration (trusts or duplicate accounts) to initially set up the connector. After you install the initial connector, you can specify an account to make the connection and remove the trust or duplicate account. However, you must maintain the account you use to connect to the remote site to match what exists in the remote domain. Independent autonomous sites don't integrate NT domains between sites; therefore, you must use either the X.400 or the IMS, because you don't need NT integration to use these connectors.
In most cases, the X.400 is the better choice for connecting sites in a large organization. However, Microsoft has made many improvements to the IMS in Exchange Server 5.5, so the IMS is now a viable alternative to the X.400 connector for connecting independent autonomous sites in a large organization. Usually, the X.400 is better for connecting sites in a centrally administered organization, and the IMS is a better alternative for connecting independent autonomous sites in a decentrally administered site. The sidebar "Which Is Better: the X.400 Connector or the IMS?" outlines the advantages and disadvantages of each type of connector.
Another good guideline for connectors is to use address space restrictions to limit propagation of address spaces. This restriction simplifies and controls message routing. ("Fine-Tune Exchange Connections," April 1998, describes address space restrictions.)
Directory Replication
The guidelines must contain recommendations for a default replication schedule. Depending on the size of the organization and number of sites, this schedule can vary from 15 minutes every 3 hours (the default) to 15 minutes once a day. The crucial factor is to control the number of messages you allow into the messaging infrastructure for replication without affecting user message throughput. An interval of 15 minutes once a day generates fewer overall replication messages in the system. Controlling the schedule of the directory replication connectors reduces the number of messages but results in replication changes taking longer to get through the system. In an organization with autonomous sites, this replication latency usually isn't a problem.
Another guideline that sites find useful is to point out that sites can control what user information they export out of the site with directory replication. This setting doesn't affect replication performance or the messaging infrastructure, but it prevents replication from exporting potentially sensitive information (e.g., phone numbers). Screen 1 shows how you can select the attributes that Exchange can replicate between sites.
Public Folders
The first guideline for public folders is to configure the default security of a site's top-level public folders so they're invisible to all users outside the site. In Screen 2, the default permissions are None, and the Folder Visible checkbox is clear. You can configure the proper defaults for your site and assign them to the Site All Users DL for your users.
With these permissions as the default, only users within your site (i.e., members of the Site All Users DL) can see the folder. In addition, if the other sites also restrict their public folder visibility to their local site's Site All Users DL, your users won't have to sift through all the other sites' top-level folders to use public folders.
The second public folder guideline is to change the configuration to minimize the number of public folder hierarchy messages that your site will have to process. (Mark Ott explains public folder hierarchy messages in "The Care and Feeding of Public Folders," June 1998.) First, establish dedicated public folder servers. Second, delete the public Information Store (IS) from the remaining servers in the site: Highlight the server from which you want to delete the public IS, highlight the public IS, and click Delete. This configuration restricts public folder hierarchy changes to the public folder servers.
ABVs
Although ABVs are a useful feature for organizing the GAL, they require careful coordination among all sites within an organization to agree on which attributes to use for the ABVs. Unless you can establish rules that define exactly how to use ABVs, they usually aren't feasible in a large organization with independent autonomous sites.
An Interesting Twist
In some large implementations, two sites within the organization don't want to share their GAL address information, even though a third site shares address information with both of the other sites. If all sites have the same Organization name and use Exchange directory replication, you can't prevent replication of address information among all sites. However, you can use InterOrg Synchronization, a tool in the Microsoft BackOffice Resource Kit (BORK). Microsoft has modeled this tool architecturally after the Microsoft Mail Directory Synchronization process but has updated it to use Microsoft Access (by default) or Microsoft SQL Server and has integrated it into the Exchange Server directory. You can use InterOrg to exchange SMTP address information between sites in the same or different organizations.
In this scenario, you can configure InterOrg (based on recipient containers) to receive SMTP address information from both organizations but export only the local site information that the other organizations require. InterOrg can handle only SMTP address information; you can't use it for features such as public folder replication.
InterOrg can be difficult to configure and troubleshoot and might not be appropriate for large-scale use in sites that want to synchronize more than 30,000 entries. Many other commercially available directory products might be more appropriate for handling large-scale directory integration. A sidebar "The LDAP Directory Synchronization Utility" on the Exchange Administrator Web site (http://www.winntmag.com/newsletter/exchange) describes a product that Compaq used to merge Digital Equipment's GAL with Compaq's when the two companies merged.
Organizational and Technical Challenges
Many technical and organizational challenges can make large Exchange Server implementations difficult. A document and a Web page of guidelines can help communicate best practices to make it easier to deploy and maintain a complex product in complex organizations.
