共用方式為

Planning Exchange and Directory Server Placement

  • 發行項

 

Because Exchange uses Active Directory, it is crucial that you consider your Windows Server network topology as you plan your Exchange deployment. In general, for best performance, you should make sure you have at least one global catalog server in each Windows site where Exchange is installed. Although Windows Server 2003 allows users to log on even without a local global catalog server, Exchange still requires a local global catalog server. In addition, using multiple domain controllers within domains distributes the lookup traffic and provides redundancy if a domain controller fails.

For more information about planning Windows sites, domains, and domain controllers, see the Windows Server documentation (https://go.microsoft.com/fwlink/?LinkId=34153).

Active Directory Server Placement

The following list summarizes the recommendations for placement of Active Directory domain controllers and global catalog servers to support your Exchange organization:

  • Ensure that DNS is correctly configured at the hub site and all branches. Ensure that name resolution and DNS functionality are both operating correctly.

  • Ensure that the server assigned the infrastructure master role is not a global catalog server.

  • In branch offices that service more than 10 users, one global catalog server must be installed in each location that contains Exchange servers. Deploying two global catalog servers for redundancy is ideal. If a physical site does not have two global catalog servers, you can configure existing domain controllers as global catalog servers.

  • Exchange requires WINS.

This topic provides information about where to place global catalog servers and domain controllers.

Domain Controllers

In most deployment scenarios, you should not run Exchange 2003 on computers that also function as Windows domain controllers. Instead, you should configure Exchange servers and Windows domain controllers as separate computers because if Exchange is running on a domain controller, it uses only that domain controller. If the domain controller fails, Exchange cannot fail over to another domain controller. Furthermore, if your servers running Exchange do not have to perform domain controller tasks in addition to serving Exchange client computers, the performance of those servers under heavy user loads improves.

To help ensure the safety of your Active Directory information, store the information on more than one domain controller. In the event that one of the servers experiences a problem, you should have at least two domain controllers to help secure your Active Directory information.

In addition, ensure that you have a solid backup plan for your domain controllers. In Exchange 5.5, by backing up the Dir.edb file, you were backing up a server's directory information. With Exchange 2000 and Exchange 2003, however, Exchange information is held in Active Directory, and domain controller backups are critical. Ensure your Windows infrastructure supports backup and reliability of this information.

For more information about backup and restore, see the Exchange Server 2003 Disaster Recovery Operations Guide (https://go.microsoft.com/fwlink/?LinkId=47570).

Global Catalog Servers

Global catalog servers are required for logon because they contain information about universal group membership. This membership grants or denies user access to resources. If a global catalog server cannot be contacted, a user's universal membership cannot be determined and log on access is denied.

Note

Although Windows Server 2003 provides features that do not require a local global catalog server, you still need a local global catalog server for Exchange and Outlook to use. The global catalog server is critical for Exchange services (including log on, group membership, store services) and access to the global address list (GAL). Deploying global catalog servers locally to both servers and users makes address lookups more efficient. Contacting a global catalog server across a slow connection increases network traffic and impairs the user experience.

Consider the following when placing global catalog servers:

  • All Exchange servers and users should have fast access to a global catalog server.

  • At least one global catalog server must be installed in each domain that contains Exchange servers.

  • There should generally be a 4:1 ratio of Exchange processors to global catalog server processors, assuming the processors are similar models and speeds. However, depending on your situation, higher global catalog server usage, a large Active Directory, or large distribution lists can necessitate more global catalog servers.

Exchange Servers

Determining where to place Exchange servers depends on whether your messaging system is centralized or distributed. Use the information you have gathered about service level agreements, user requirements, and the versions of software that you will deploy in the organization to determine whether users need access to a local Exchange server.

Mailbox Servers

For remote locations connected by slow or unreliable network connections, you need to determine how any interruptions in service affect the business and to what extent interruptions are acceptable. If access to updated Exchange data at all times is critical, you need to place Exchange servers in the remote locations. If, after weighing the costs of deploying additional servers against cost savings of a more centralized model, you decide that a certain level of service interruption is acceptable, you may be able to deploy all Exchange servers in a data center. Recall that in this case, if you want to take advantage of features such as Cached Exchange Mode and RPC over HTTP to improve the experience for remote users, you may need to also consider upgrading to Windows Server 2003 and Outlook 2003.

Public Folder Servers

As discussed previously, if your organization is made up of multiple remote locations, you can place public folder replicas on local Exchange servers so that each location has a replica of public folders from other locations. Or, you may want to consider storing all public folder information in a central server in the data center or hub so that you maintain a single, accurate source of data. This decision is based on the balance between accuracy and convenience and depends on user requirements and usage patterns.

Free/Busy Servers

One of your main considerations is access to free/busy information. Without a local copy of free/busy folder data, users may experience a delay in receiving other users' free/busy information when scheduling meetings. Consider how users in your organization schedule meetings. The requirements surrounding access to updated scheduling information can vary among companies. If it is critical that users always have access to up-to-date scheduling information, you need to host free/busy folders in a centralized location. If the need for up-to-date information is not as critical as the need for fast access, you can deploy local Exchange servers to host free/busy information, recognizing that delays in receiving updated free/busy information over the network may occur. You should determine what level of delay is acceptable to your business.

If you decide to host free/busy information on local Exchange servers, the other consideration is whether to place copies of other free/busy information from other locations on the local server. If users in different locations rarely schedule meetings with each other, you do not necessarily have to keep local replicas of free/busy information from other locations. However, if you decide to keep local copies of public folders from other locations, note that the replication schedule defined for a public folder determines when its changes are propagated. If replicas of free/busy information are maintained across multiple locations, it may take time for changes in one location to propagate to the other locations. Thus, a user might consult the local free/busy data while scheduling a meeting, but the free/busy data is out of date because schedule changes made in another location have not yet replicated.

Offline Address List Servers

Exchange 2003 uses Active Directory to provide offline address list services. The address list files that Exchange generates are stored in a public folder. Users working offsite can connect to Exchange and download these offline address lists remotely to retrieve information about other users in the organization.

When you generate an offline address list, address lists specified for the offline address list are converted to a single data file and stored in a system public folder. When users download the offline address list, this data file is used as the source of information.

You must choose an appropriate server to generate and update offline address lists. The more address lists contained in an offline address list, the harder the server chosen for the offline address list must work.

If you use Cached Exchange Mode, you should consider the impact on the server when users download offline address lists. This impact could be significant, not only the first time users download offline address lists, but on a daily basis. You may want to consider setting up one or two servers to handle offline address books.