Thank you!
Dimitare.

If the two sites are in different orgs, then it gets very difficult, you will need to the inter-org replication utility. That name may be wrong, it's been a while since I worked with two orgs. Alternatively you could write something to change the mailboxes from one site to be custom recipients in the other and vice versa, then schedule exports and imports accross the sites. I've used both in the past for slightly different jobs and both work quite well.

Pat.

Directory Replication Between Sites

Using the Directory Replication Connector
Using Directory Replication Between Sites on the Same Network
Setting Up Directory Replication Between Sites on Different Networks
Viewing a Site's Directory Data
Understanding Directory Synchronization
Setting Up the Directory Synchronization Requestor
Using Exchange as a Directory-synchronization Server
Creating and Configuring a Directory Exchange Server
Defining Remote Directory Synchronization Requestors
Creating a Remote Directory Synchronization Requestor
Configuring a Remote Directory Synchronization Requestor
Configuring Remote Requestors
Requestor Configuration
Starting and Stopping the Requestor
Microsoft Mail AppleTalk Requestor
Exporting Directory Information to Exchange Server
Microsoft Mail AppleTalk or Exchange Server Addresses
Removing Exchange Recipients from the Microsoft Mail AppleTalk Local Address List
Re-synchronizing Address Information
Configuring Foreign Directory Exchange Requestors
Configuring Microsoft Directory Exchange Agent (DXA) Settings
Choosing a Server to Carry Out the DXA Functions
Modifying DXA Addresses
Setting Delivery Restrictions
Mapping Templates to Exchange Server Attributes
Mapping Exchange Server Attributes to a Microsoft Mail Template
Starting Directory Synchronization
Stopping Synchronization Services

--------------------------------------------------------------------------------

This chapter assumes you have a basic understanding of Exchange's directory architecture; Exchange Server is installed and running on at least two sites; and that the external system is functional (you can send and receive messages).

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 a Site
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:

An administrator creates a new mailbox recipient, Ron Elliott, on the server SEATTLE01.

Upon creation of the user, the new directory object is a legitimate candidate for directory replication.

Within five minutes, users on Exchange Server SEATTLE02 (a server at the same site as SEATTLE01) can address Ron Elliott as a recipient, and see his name in the Global Address List.

Directory replication within a site is automatic. If you do not want Ron Elliott's name to appear in the Global Address List (GAL), you must make the mailbox hidden. This does not stop the object from replicating. The hidden mailbox will replicate to the other server to maintain an updated directory information store.
Directory Replication Between Sites
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:

Exchange sites on the same network (LAN)

Exchange sites on different networks
Using the Directory Replication Connector
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:

1. Ensure that messages can be transferred between sites.

2. Create a directory replication connector for both sites.

3. Identify the bridgehead server at each site that is responsible for transferring directory updates.

4. Establish a replication schedule to determine how often directory updates will traverse a site link.

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.

Using Directory Replication Between Sites on the Same Network
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:

The messaging link between both servers is fully functional (sending and receiving messages). Usually, you use a site connector to establish such a link between sites on the same network.

You have administrator permissions on each server with which you will be establishing a directory-replication relationship.
To set up directory replication between sites on the same network, follow these steps:

1. Open a New Directory Replication Connector from the Administrator program's File menu under New Other. The New Directory Replication Connector dialog box appears (see Figure 18.1).

2. From the Remote Site Name drop-down list, select the site to which you want to connect.

FIG. 18.1 Use this dialog box to set New Directory Replication Connector options.

3. In the Server in Remote Site dialog box, type the name of the remote server.

4. Click the radio button labeled Yes, the Remote Site Is Available on This Network.

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

5. Click the Configure Both Sites check box. This option automatically creates and configures a corresponding directory connector at the remote site.

6. Click OK to proceed to the Directory Replication Connector property pages.

--------------------------------------------------------------------------------
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:

1. Click the General tab of the Directory Replication Connector Properties page (see Figure 18.4).

FIG. 18.4 The General page of the Directory Replication Connector Properties page.

2. From the Local Bridgehead Server drop-down list, select the local server that will handle incoming and outgoing directory update requests. The default selection is the name of the Exchange server on which you are currently logged in.

3. From the Remote Bridgehead Server drop-down list, select the server at the remote site that will receive and request updated directory information.

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.

at:
If the two servers have the same organisation, case sensative, then simply create an X400 or Site connector between the two sites, then put a directory connector between them.

If the two sites are in different orgs, then it gets very difficult, you will need to the inter-org replication utility. That name may be wrong, it's been a while since I worked with two orgs. Alternatively you could write something to change the mailboxes from one site to be custom recipients in the other and vice versa, then schedule exports and imports accross the sites. I've used both in the past for slightly different jobs and both work quite well.

Pat.[/QUOTE]

Dimitare.

I hope that the following lines will describe my goal better:

Currently, I have two Exchange 5.5 in the same site.
What I am trying to achieve is a 100% uptime for the email services - in case one of the server fails, just to redirect the email to the second one. The cluster service is not a solution for me because both servers will point to the same database, and in case of it's corruption non of them will work, since both of them will use the same database.

For this reason, now I have two different servers (In the same site), with replicated Public Information Store and I need to find a way to do the same with Private Information Store. If I do that, in case one server fails and corrupt the it's database (Priv and Pub stores), I will have time between the replication occurs and would be able to switch to the second server before the corruption occurs on the second server's database.
Unfortunately, I am not able to find any information how to replicate Private Information Store.

It is true that with the initial joining of the second server to the existing site the directory replicates automatically. However, the Public and Priv Info Store don't.

Thank you,
Dimitar

What I would do is split the users accross the servers to at least minimise the imapct of any damage.

Or, and this is a much better idea, upgrade to Exchange 2000, which does sort of have the functionality you require.

Pat.

Under Exchange the Mailboxes can reside on only one server and the Mail gets routed thru the organisation to that server, for the client to access E-mail they MUST be able to connect to their
"Home" server. If their Home server is dead then so is their E-mail.

I can think of one way to get around this which would be to use a messaging gateway with two routes (of different costs) If the "home" server cannot be found it could then route to another server - maybe a Public Folder - which CAN be replicated.

Another thought - could you set up each user with a Public Folder (which you can send E-mail to) and hide it from everyone but them. This could then be replicated and maybe everything from it forwarded to a "proper" inbox via a rule (home the two on different servers and there you go - Fault tolerance).

Argon0

One 1 meg attachment to 100 users would take up 100 meg of space rather then just over 1meg.

The solution is in Exchange 2000, I'm not too clear on how at the moment, but I'm fairly certain the mailboxes can be multi-homed in such a way that if a "home server" goes down, another server will step in accept the messages for the out-of-service mailboxes and allow the out-of-service users to read them. However, messages delivered prior to the crash will be unavailable untill the "home server" comes back.

Couple this feature with front end back end servers and you've got a good fault tolerant service.

Pat.

argon0,
In regard of the "Notes background..." comment, if I was such a Exchange expert and knew the answer, I wouldn't post the question here. It just does not look logical to me that you could replicate the Public folders but not mailboxes, since the backend is the same .edb database files.

Also, since you question my credibility - I have several years of networking behind me, with number of completed and working projects. I will be more than glad to provide you with more information. If you need it, just let me know.

Thank you.
Dimitar

There is another option using alternate delivery, but that will become an admin nightmare.

Pat.

I too have been having the same problem and am astounded that this functionality has not been included in Microsoft Exchange. However I may have a solution.

On the Backoffice Resource Kit their is a utility which should answer your problem. Instead of replicating mailboxes to another mailboxes it replicates mailboxes to a public folder. With this functionality all you would have to do in the event of a disaster is recreate blank mailboxes and copy the data back into them from the public folders. If you do scheduled exports of the exchange directory to a csv file then recreating the mailboxes on a server should take no more than a couple of minuites.

Send me your email address and when I have the full solution I will mail it to you.

PS - If you have already got a solution could you let me know as it would save me a lot of work.

Don

quote:

---

Originally posted by dimitare:
Hi,
I need to replicate some mail boxes on two different Exchange 5.5 Servers. Unfortunately,
I am not able to find any information at Microsoft.com or anywhare on the web.
I would greatly appreciate any information that could help me to solve this problem!

Thank you!
Dimitare.

---