Just for a quick review, each Exchange Server retains a copy of the organization's directory. This directory is an X.500-based directory of Exchange objects including addresses, mailboxes, public folders, distribution lists, and configuration information about sites. Directory replication is the process by which Exchange Servers insure that they have a current copy of the stored directory information. This process occurs between servers in an Exchange site, as well as between servers in different sites throughout your organization. The following sections describe the steps you will use to set up replication between your Exchange servers.
Directory replication within an Exchange Server site is automatic. The replication function is handled by the directory service and is always in operation while that service is running. This process requires no maintenance other than making certain that the servers in a site can exchange standard messaging information.
Mean time between replication requests is approximately five minutes, depending on when you made your last change. When a change has been made to the directory, the directory service waits five minutes from the last change before sending a notification, so that changes can be replicated in batches.
The following is an example of how a directory change propagates through an Exchange site:
Replicating directory information between two Exchange sites is the second logical step in maintaining a cohesive directory structure within your organization. This section covers replication between the following:
The principal tool used to set up directory replication is the directory replication connector. The replication connector does not transfer directory information to other sites; it only defines a logical path for the directory replication topology. One of the intersite connectors is required between sites to transfer mail messages unless two sites are connected via another site. A directory replication connector could be established between sites that are not directly connected, therefore, as long as they are connected indirectly. As the administrator, you need only provide the site names and the names of the appropriate bridgehead servers to establish a replication connector.
Setting up replication between two Exchange sites involves four steps:
The following sections provide details about configuration for specific situations; however, the general steps for setting up directory replication are the same for all types of networks.
This section describes the procedure for using directory replication between two Exchange sites physically connected on the same local area network. Typically, this means high-bandwidth links between groups of servers in close geographical proximity. In the real world, this can be two distinct corporate divisions in the same building. Whatever the case, your Exchange servers will be able to communicate with each other over your standard network connections and will not require the use of any additional transport mechanism.
The following is a list of requirements to meet before setting up replication between sites on the same network:
To set up directory replication between sites on the same network, follow these steps:
FIG. 18.1 Use this dialog box to set New Directory Replication Connector options.
TIP: You almost always choose this option when both sites are on the same LAN because the option saves you time and reduces configuration errors. Only external situations, such as administrative security restriction within a company, might require separate configuration of such directory replication connectors. For example, an Administrator on one site may not be given sufficient administrative privileges of the remote site to establish a connection alone.
NOTE: Because both servers are on the same LAN, Exchange can locate the site and communicate with the remote server via remote procedure calls. You need to specify only the remote site's name in the New Site Connector dialog box.
To facilitate the interchange of directory data between sites, you must designate replication bridgehead servers. These servers process directory update requests from other bridgehead servers and also generate their own requests for updates. A one-to-one relationship must exist between bridgehead servers for sites that exchange directory information.
Following are a few example situations:
Example 1: You want to establish directory replication between the sites GARLAND and SEATTLE. GARLAND01 and SEATTLE01 are the selected bridgehead servers. These servers will be the only replication point for Exchange directory information between the Garland and Seattle sites. You make no allowances for the use of multiple directory replication connectors to balance server load, link traffic, and so on.
In directory replication, you must designate a local bridgehead server and a remote bridgehead server when you set up a directory replication connector. Local and remote are relative terms. When you configure a directory replication connector between sites, the General page of each connector shows different information for each end of the connection.
The GARLAND Directory Replication Connector's General page displays the following information:
Local bridgehead server GARLAND01
Remote bridgehead server SEATTLE01
The SEATTLE Directory Replication Connector's General page displays the following information:
Local bridgehead server SEATTLE01
Remote bridgehead server GARLAND01
Example 2: This example discusses the use of multiple directory replication connectors in a site. In this case, GARLAND is the site that has multiple connectors. The Seattle bridgehead server (SEATTLE01) replicates directory information with the bridgehead server GARLAND01 (see Figure 18.2).
FIG. 18.2 Directory replication across multiple bridgehead servers.
Simultaneously, the LOSANGELES site replicates information to the GARLAND site. LOSANGELES01 is the bridgehead server for the LOSANGELES site. LOSANGELES01 links to a second bridgehead server at the GARLAND site: GARLAND02.
A smaller organization could manage by setting up multiple directory replication connectors on one server. This procedure is not generally recommended but is an option for sites that have few users, infrequent directory updates, or a limited number of servers. In this case, both SEATTLE01 and LOSANGELES01 can be bridgehead servers linked to GARLAND01 (see Figure 18.3).
FIG. 18.3 Setting up multiple directory replication connectors.
In the preceding examples, directory information between the SEATTLE and LOSANGELES sites is synchronized automatically by the sites' common link, GARLAND. When three sites are joined with a connector and directory replication is configured between them, connections between the two distant sites (Los Angeles and Seattle) becomes transitive. Therefore, a directory replication connector is not required between the Los Angeles site and the Seattle site since changes made in either Exchange site will be replicated via the Garland site. Microsoft Exchange will not enable you to create a directory replication connector between sites when the connection is already transitive.
You set up bridgehead servers in the Exchange Administrator program. To designate bridgehead servers, follow these steps:
FIG. 18.4 The General page of the Directory Replication Connector Properties page.
After you establish a directory replication connector, you can change the local bridgehead server for that connector, but make sure you update the remote connector to reflect the change. Usually, it is best not to make such changes and to plan in advance for a situation that might require you to change this information. If you must change the local bridgehead server, this change will prompt Exchange to reinitiate the replication cycle.
Sites located on different logical LANs can share directory information almost as easily as sites on the same LAN. You cannot use a site connector to link bridgehead servers; however, you must configure a custom connector to that site.
The following conditions must exist before you set up directory replication between sites on different LANs:
To set up directory replication between sites on different networks, follow these steps:
The following sections define the contents of the property pages for the directory replication connector required when connecting sites on different networks.
The Addressing Page When you configure replication between two sites that are not on the same network, you must supply the e-mail address of the bridgehead's server directory. Follow these steps:
The Schedule Page Directory updates transmitted between bridgehead servers are executed according to an administrator-defined schedule. You need to evaluate the following elements before you decide on an appropriate replication schedule:
The first three items are related. If replication traffic is heavy between the two sites (if directory objects are frequently added, deleted, or modified, for example), this will affect available bandwidth. Sometimes you must have a frequent replication schedule to maintain an accurate global address list.
Scheduling constraints arise due to the type of site link used. This is especially the case when using part-time connections.
The site link between GARLAND and GARLAND LAW, for example, is established by a Dynamic RAS Connection. Three times a day, a modem connection to the GARLAND01 site is established; the connection is maintained for 30 minutes and then closed. You must configure the directory replication connector to transmit data when the network connection is up; otherwise, the connector may attempt to transfer directory updates through a nonexistent link.
To configure the replication schedule, follow these steps:
FIG. 18.5 Schedule page of the Directory Replication Connector Properties page.
Following are two general recommendations on scheduling replication time:
After you configure both directory replication connectors and establish directory replication between two sites, you can view all sites with which you are exchanging directory data. This is the case because the local site receives directory updates from the immediately connected remote site, as well as from every other remote site with which that site is replicating data.
To view inbound and outbound sites, click the Sites tab of the Directory Replication Connector dialog box. Inbound sites are those from which the local site receives directory updates. Outbound sites are those to which directory updates are sent.
Earlier we created, as an example, a directory replication connector from SEATTLE to GARLAND, from FRANKFURT to GARLAND, and TOYKO to GARLAND. After the first successful replication request, you see the site names displayed in the Sites page on the GARLAND replication connector to SEATTLE, as shown in Figure 18.6.
SEATTLE is displayed in the Inbound Sites list. The Outbound Sites list displays FRANKFURT, GARLAND, and TOKYO, since directory changes made in SEATTLE will be sent to those sites.
You also can use the Sites page to request directory updates from selected inbound sites. You might need to request a directory update in the following situations:
FIG. 18.6 The Directory Replication Connector Sites Properties page shows which sites are sharing directory information.
To request a directory update, follow these steps:
Directory synchronization is the process by which an Exchange server shares address information with foreign messaging systems. Dirsync in Exchange is based on the Microsoft Mail directory synchronization protocol, which is widely supported by many messaging systems.
This section covers the setup and configuration of dirsync between Exchange and Microsoft Mail, as well as between Exchange and foreign systems that support the Microsoft Mail dirsync protocol.
Before you begin, you must verify the following information about your Exchange setup:
Following is a brief review of how directory synchronization works and of the tools that you use to set up dirsync in Exchange.
The Microsoft Mail dirsync protocol has two principal elements:
Exchange Server includes one principal component--the Directory Synchronization Agent (DXA)--that operates directory synchronization. The Exchange DXA can act as either a dirsync server or requestor. In standard Microsoft Mail dirsync, the dirsync server maintains a server address list. Exchange uses the Global Address List to replace the server address list.
NOTE: When Exchange receives external addresses that are imported during synchronization, the addresses are stored in the directory as custom recipients.
Generally, there is just one directory synchronization server that receives directory updates from multiple requestors. Because directory replication maintains the Microsoft Mail addresses for all users in the Exchange organization, only one directory synchronization requestor is required for the entire Exchange organization.
Follow these steps to create a connection to Microsoft Mail:
Follow these steps to create an Exchange requestor:
FIG. 18.7 This is the new Directory Exchange Requestor dialog box.
Now you must set up properties in each of the available pages, as described in the following sections.
The General Page The General page enables you to name and configure the basic dirsync requestor properties. Follow these steps to configure the location from which to request directory updates and select the address types supported by this requestor:
FIG. 18.8 The Dirsync Requestor General Properties page lets you set the basic options for a dirsync requestor.
NOTE: The $SYSTEM Microsoft Mail account should already be in the Dirsync Address field if the directory synchronization server is a Microsoft Mail Post Office. If the directory synchronization server is not a Microsoft Mail Post Office, you must first create a Custom Recipient for the dirsync server with which this requestor will be exchanging dirsync messages. That custom recipient can be any Microsoft Mail or compatible directory synchronization server in your organization. See Chapter 15, "Information Store Configuration," for information about creating custom recipients.
The Import Container Page An import container is the recipient container that receives imported information from a dirsync server. This page enables you to assign trust levels to the imported directory objects.
Because trust levels are exclusive to Exchange Server, any imported recipients will not have trust levels assigned by the foreign system. The import container setting gives that object a trust level that Exchange uses to determine synchronization security. As in any other case of trust level use, only objects that have a trust level equal to or lower to the trust level of the next site are synchronized.
Suppose that you are using Exchange servers GARLAND01 and GARLAND02 as requestors to two Microsoft Mail network dirsync servers and that you do not want the Microsoft Mail networks to share recipient information. You set each requestor to import to a different recipient container in the GARLAND site, each with different trust levels. When synchronization occurs, each list of recipients is imported into its own container (with its own trust level). The information is not mixed and is not synchronized to the other Microsoft Mail server because of the trust level settings.
The following steps describe how to configure the Import Container page:
FIG. 18.9 The Import Container page.
CAUTION: After you choose a directory import container, you are stuck with it. The only way to alter where directory information is stored is to delete the requestor and set up a new one.
The Export Containers Page An export container holds the directory data that an Exchange requestor sends out during synchronization. By default, a requestor does not send out any containers. If you need to export directory information via a requestor, follow this procedure:
FIG. 18.10 Specify where you want incoming recipients to be stored.
FIG. 18.11 The Export Containers page.
The Settings Page The Settings page enables you to set advanced properties for a directory-synchronization connector.
To configure the Settings page, follow these steps:
FIG. 18.12 The Settings page.
The Schedule Page The Schedule page enables you to set the time when update messages are transmitted to the directory synchronization server.
NOTE: The verification messages or updates from the dirsync server are handled automatically.
To set the requestor's schedule, follow these steps:
FIG. 18.13 The Schedule page.
So far, this chapter has covered all the available options for configuring a Directory Exchange Requestor. You must now configure the Microsoft Mail dirsync server to accept your new Exchange requestor. There are two primary settings to configure:
Another way to integrate Exchange into directory synchronization with Microsoft Mail- compatible networks is to set up a directory synchronization server (also called a dirsync server) on Exchange. Then you can use standard Microsoft Mail requestors on remote machines to participate in directory synchronization.
Following are the general steps for setting up Exchange as a dirsync server:
NOTE: Although you can have multiple Exchange dirsync servers in your organization, you can have only one for each Exchange site.
Each of the steps will be covered in the sections that follow.
When you create a new directory exchange server, it automatically gets an e-mail address based on the Microsoft Mail address type for the local site. Because you can have only one directory exchange server per site, no addressing conflicts can exist.
To create a new directory exchange server in the Administrator program, choose File, New Other, Dirsync Server. If you have already set up another directory synchronization server in this site, the new Dirsync Server option is not available.
To configure an existing server from the Administrator program, follow these steps:
The following sections cover configuration of the dirsync server's property pages.
The General Page The general property page enables the administrator to name the DXA, select a DXA administrator account, view synchronization messages, and select the Exchange Server that will run the Exchange directory synchronization service.
To set general properties, follow this procedure:
FIG. 18.14 The General page of the DXA Properties page.
NOTE: By default, neither Copy Administrator on Outgoing Messages nor Forward Incoming Dirsync Messages to Administrator is selected. Typically, you would choose these options only for troubleshooting purposes.
The Schedule Page The Schedule page defines when the directory synchronization server sends updates to its requestors. Server updates are independent of the schedule under which the requestors send their updates to the server. Directory updates are sent to requestors at the beginning of the scheduled hour.
To set the schedule, follow these steps:
Just as you do with a standard Microsoft Mail directory synchronization server, you must identify and define each remote requestor that will be communicating updates to the local Exchange dirsync server. Setting up each remote requestor involves two steps:
These two steps make your Exchange directory synchronization server aware of its re- questors. Review the following section to verify that a remote requestor is properly configured and able to communicate with the local Exchange dirsync server.
To create a new remote dirsync requestor, follow these steps:
NOTE: The New Remote Dirsync Requestor command is unavailable until you set up an Exchange directory synchronization server.
The following sections describe the pages that you configure for a remote dirsync requestor.
The General Page The general property page enables the administrator to name the DXA, select the directory synchronization address and password on the foreign system, and export all Exchange addresses to the foreign system.
To set general properties, follow these steps:
NOTE: You must first create a custom recipient for each remote dirsync requestor to provide address information about the requestor.
The Import Container Page Much as you do in setting up directory exchange requestors, you use import containers to assign trust levels to objects that are being imported.
Because trust levels are exclusive to Exchange Server, any imported recipients will not have trust levels assigned by the foreign system. The import container gives that object a trust level that you set in the Import Container page. As in any other case of trust level use, only objects that have a trust level equal to or lower than the next site's trust level are replicated. The following steps cover Import Container page configuration:
FIG. 18.15 Choose the container in which imported recipients will be stored.
NOTE: You cannot modify import containers after you create them. If you must change where information is placed, you must delete the existing container and create a new one.
The Export Containers Page The Export Containers page specifies what information is sent out to the remote requestor during directory synchronization. By default, no information from the local site is exported. To configure data export, follow these steps:
FIG. 18.16 The Export Containers page.
The final step in establishing directory synchronization between an Exchange directory synchronization server and remote requestors is configuring the remote requestors on Microsoft Mail or compatible systems.
The following sections provide general recommendations on configuring directory synchronization requestors on the following types of remote systems:
Directory Synchronization Requestor for Microsoft Mail for PC Networks The requestor that you are most likely to set up is one for a Microsoft Mail for PC network. Standard Microsoft Mail requestor programs connect to Exchange directory synchronization servers through the Microsoft Mail connector as though the requestor were of the standard Microsoft Mail type. You need to configure the requestor from within your Microsoft Mail Administrator program. Consult your Microsoft documentation for the procedure.
TIP: You can test the operation of a Microsoft Mail connection by entering the address of your recipient manually in the to line of the Exchange client.
Before you configure the requestor, make sure that you have met all of the following conditions:
Directory Synchronization Requestor for Microsoft Mail for AppleTalk Networks This section is dedicated to a discussion on address list sharing between Exchange and a Microsoft Mail for AppleTalk network. These solutions, though functional, are a poor substitute for the direct use of a Macintosh Exchange client. Primarily, these solutions will be used as a stopgap in preparation for an eventual complete migration to Exchange. Existing Microsoft Mail AppleTalk servers can act as requestors to standard Microsoft Mail (PC) dirsync servers. By pointing the Macintosh dirsync requestor to an Exchange dirsync server, your Mac servers can begin sharing address lists with your Exchange organization.
The Exchange Client for MAC 5.0 can act as a direct client to Exchange Server 5.0. Strategies are now different for the migration of MAC clients. It is important, however, to understand how Exchange and Microsoft Mail for AppleTalk networks behave and are configured. Microsoft will continue to support the Macintosh Gateway by loading it onto the client CD that is MAC friendly.
The first part of this section covers the set up of a Directory Exchange Requestor in a Microsoft Mail for AppleTalk network.
The directory synchronization requestor for Microsoft Mail AppleTalk is installed with the Exchange connection gateway.
Before you configure the Microsoft Mail AppleTalk requestor, confirm the following situations:
CAUTION: If you do not set the requestor to receive messages in MSA format, duplicate entries are created in the Microsoft Mail AppleTalk address list.
If you have met all the preceding conditions, you are ready to continue setting up the directory synchronization requestor. If you have been looking at a Windows screen layout all day, the following steps could be a nice change of pace.
When you set up directory synchronization, you need to configure three principal requestor options. You must log in as the network manager on your Microsoft Mail AppleTalk server to make all configuration and administrative functions available. The following sections describe how to make these settings:
General Requestor Settings Complete the following steps to configure the Macintosh Microsoft Mail Server directory requestor to exchange addresses with Exchange:
If you are configuring this requestor for the first time, the Gateway dialog box appears.
NOTE: If this is not your first time configuring this requestor, then choose Select Gateway from the Configure menu.
In this dialog box, you must select a gateway. This is the passage through which messaging data will reach the Exchange server. By default, this is the connection gateway. Choose your preferred gateway and then click the Select button.
Address Filters Address filters enable you to specify the address types that you want to receive from the Exchange server.
To configure address filtering, follow these steps:
Complete the following steps to start and stop the directory requestor on the Macintosh Microsoft Mail Server:
NOTE: The status display refreshes when the system receives directory update messages.
If the requestor is not given the network manager name and password, or if you are not currently logged in as a Network Manager, then the request will run as a foreground application, locking the desktop and preventing you from running other applications. If you have given the password or are logged in as the Network Manager, however, then the application runs in the background.
To stop the requestor, choose File, Quit.
It is convenient to make the Macintosh dirsync requestor a startup item so you do not need to manually launch the application every time you restart the system. To make the requestor a startup item, follow these steps:
As network manager, you may want to execute a few maintenance tasks as part of administrating Exchange directory synchronization from the Microsoft Mail AppleTalk end. Those tasks are importing a complete list of addresses, exporting a complete local address list, and re-synchronizing that information.
To import a complete list of known addresses, follow these steps:
NOTE: To verify that imports have proceeded correctly, you need to start Microsoft Mail AppleTalk manually and choose Mail, Gateway Recipient. A dialog box appears that lists the new recipients. All requested information should be available in this list after you receive an import confirmation message from the dirsync server.
The previous section described how to get Microsoft Mail AppleTalk to receive addresses from Exchange. The following section describes how to update the Exchange address list with changes made on the Microsoft Mail AppleTalk server. You will do this by telling the Exchange Connection software to export its contents to the Exchange dirsync server. The following steps describe the steps necessary to accomplish this:
After the Exchange server processes these update requests, it sends a confirmation message and a status report to the network manager's mailbox.
Another option is to export the local Microsoft Mail AppleTalk addresses into a text-file format that the Microsoft Mail (PC) import utility can read. Use this alternative when other methods are not operational.
To export the addresses (also called the word list) manually, follow these steps:
You can open the exported file with any text editor. All your addresses should be in that file, displayed in the following format:
A 30_character_alias MSMAIL:address
Microsoft Mail is the address type of this entry.
Sometimes you need to remove all Microsoft Mail for AppleTalk recipients from the Exchange address list, and vice versa. This situation occurs when Microsoft Mail AppleTalk users become full-fledged Exchange clients.
To remove Microsoft Mail AppleTalk recipients from the Exchange server address list, follow this procedure:
NOTE: If you suddenly realize that you really need the addresses, you must import them to restore the entries. Subsequent directory synchronization cycles do not replace deleted entries.
Follow this procedure to delete Exchange recipients from Microsoft Mail AppleTalk:
As directory synchronization occurs, updates are exchanged, and the network manager receives periodic messages confirming that the process is operational and that changes have been incorporated.
Sometimes this process does not operate smoothly. In such cases, the requestor gives you the option of forcing re-synchronization of the entire system manually.
If you believe that your system is out of sync, follow these steps:
The requestor receives the global address list from the Exchange server and resets the send/receive cycle.
If you get a message stating that the directory synchronization cycle is out of phase, you should initiate a complete directory refresh (import and export) between both systems. As described in the preceding sections, you should import the Exchange global address list and export the local address list to the Exchange dirsync server.
The Microsoft Mail AppleTalk directory exchange requestor keeps a log of all its activities. This log is a text file stored inside the Preferences folder (in the System folder). Any standard text editor displays this file.
NOTE: This file logs all directory Exchange requestor activities, so the file could be very large if it is heavily used. Make sure that you delete or clear the file on a periodic basis. Confirming that synchronization is functional before you delete any log entries is a good idea.
Any foreign system that conforms to the Microsoft Mail 3.x directory synchronization protocol can connect to an Exchange dirsync server. You probably need to consult your appropriate documentation for the process, but here are some general recommendations to follow before you configure synchronization with foreign systems:
The DXA is the Exchange component that actually runs the dirsync server and requestor. By default, the DXA is configured to enable both server and requestor processes to run. You can modify general settings for the DXA, as described in the following sections. The DXA is configured through an object named Directory Synchronization on each Exchange server in your site.
See Chapter 12, "Using the Administrator Program," for more information on configuring all directory services on Exchange.
The Directory Synchronization General page enables you to choose the server that carries out the DXA functions. Any server at the site is eligible, but always take into consideration other functions that a server is performing. To choose a server, follow these steps:
The e-mail addresses are used to send and receive synchronization update messages. You will need the E-mail Addresses Properties page to create, modify, or delete these addresses. By default, Exchange server automatically generates Microsoft Mail (PC), X.400, and SMTP addresses for each DXA. Several services, such as dirsync requestors and servers, use these addresses for communication with the DXA.
To create or modify Microsoft DXA addresses, follow these steps:
CAUTION: Many other Exchange services use these addresses. If you plan to change or delete them without appropriate consideration of such services, directory synchronization will fail.
This page is useful because it prevents messages that are unrelated to directory synchronization from being sent to the DXA. You also can set up delivery restrictions to allow messages to be sent only by specified senders. In the Delivery Restriction page, you select specific addresses from which the DXA will reject or allow messages. By default, the DXA accepts messages from all senders. Such an open door could cause errors and delays in proper directory synchronization.
To set delivery restrictions, follow these steps:
TIP: Entering specific accepted senders is the most fault-tolerant approach to this setup. Be aware, however, that if you set up a new requestor without modifying the page, all of that requestor's messages will be rejected.
Incoming Templates are Address templates that take incoming address information and map it for specified Exchange server directory recipient attributes.
An address imported through synchronization with a Microsoft Mail network, for example, could have the occupation and telephone attributes. For consistency, you would want to map the occupation tag to the Exchange Title attribute.
To map templates to Exchange server attributes, follow these steps:
NOTE: All mapping strings must match the incoming strings.
Outgoing template mappings are the inverse of the preceding function. You can map Exchange server directory recipient attributes to outgoing Microsoft Mail-compatible template information.
FIG. 18.17 Define Incoming Templates for synchronized addresses.
To map Exchange server attributes to a Microsoft Mail template, follow these steps:
FIG. 18.18 Outgoing Template Mappings translate Exchange attributes to a user-defined string.
As soon as you activate the directory exchange requestor for the first time, it exports a complete local address list to its Exchange directory synchronization server. Also, the requestor sends out a request for entries in the Exchange address list. The Exchange dirsync server returns a confirmation message saying that it received the requestor's transmission; then that server sends all the data in the export container to the dirsync requestor.
Subsequent transmissions between dirsync requestor and server consist only of updates to the address lists. You can force the import or export of directory information manually, as well as from the appropriate connector pages.
Be aware that directory synchronization updates sent by the Exchange dirsync server are in the form of messages sent to the network manager's mailbox. From that mailbox, the messages are picked up by the Exchange connection and synchronized into the local address list. These messages should not be modified or deleted; altering those messages interrupts the synchronization process and could produce data loss.
NOTE: Large imports (several thousand entries) from the directory exchange server are known to take up to several hours. Be aware of such time requirements. Also be aware that during that time, no other messages will pass the Exchange connection gateway.
After you meet the preceding requirements, you can start the directory synchronization service. Follow these steps:
FIG. 18.19 Exchange services running under Windows NT.
NOTE: If you set a specific time for directory synchronization that occurred while the service was stopped, a delay may occur until the first sync cycle actually begins. You can force immediate execution of a replication cycle in the property pages of the appropriate connector supporting synchronization.
To stop the synchronization services, complete the following steps:
NOTE: Remember from earlier discussions that when the synchronization is shut off, there are no updates and changes of Exchange Servers Directory Services. It is a good idea to notify fellow administrators and users that the synchronization services have stopped.