Build Your Skills: Share Exchange calendars without merging servers

Learn how to make the calendars on two Exchange servers use each others Free/Busy information for scheduling.

The merger or acquisition of another company often presents a challenge to Microsoft Exchange administrators when the combined organizations want to maintain separate servers and yet share their Global Address Lists (GALs) and calendaring information.

Many companies don’t even attempt to keep their servers separate and simply migrate the smaller or older of the two Exchange servers into the larger or newer one, but that approach comes with a high price. The process can be extremely labor intensive and cause a big productivity hit when one organization being migrated loses all of its calendaring and contact information.

However, a migration is unnecessary if both organizations are going to maintain network administrative staffs. “Once you synch the directories and you do the Free/Busy information, you really don’t need to do a migration,” said Mike Laun, TechRepublic’s Exchange administrator.

In “Case study: Exchange directory sync,” we described how to keep the GALs of two Exchange servers synchronized. Now, Laun will take us through the second part of the puzzle: making the calendars on two Exchange servers use each other’s Free/Busy information for scheduling.

Still think migrating two servers into one is easier?
To get a feel for what an Exchange migration entails, see the articles in a two-part series: In these articles, TechRepublic’s Exchange administrator Mike Laun explains what he went through during the migration process.

Working from the outside in
Before you attempt to make two separate Exchange servers share your calendaring information, it’s important to understand that Microsoft did not design that capability into Exchange. Exchange is designed so that the top level of organization is sacrosanct; it then allows branching down to different groups and users.

That being said, Microsoft does provide the utilities to synchronize the GAL and Free/Busy information—it just doesn’t support these utilities if something goes wrong. This is complicated by the fact that the appropriate information describing how to use these utilities is difficult to find.

Let’s assume that you have managed to get your Exchange directories synchronizing on a regular basis and now you need to get two Exchange servers to share Free/Busy data. One part of the organization is located on the East Coast and the other on the West Coast. There is no constant VPN connection between the two, which are maintaining their own domain names.

If you’ve heard the expression, “Think globally, act locally,” now is the opportunity for you to do so. Before we get into the intricacies of the solution, we have to understand that these Exchange servers are passing secure information over the Internet from servers that are behind firewalls at either end of the transaction.

The transfer of information will be from one server on each network. Each server will have a Publisher, which uses its network domain name and security information, and a Subscriber, which uses the same type of information from the other network’s Publisher.

The firewalls at each end of this transaction will have to be configured to translate IP addresses so that the remote servers can talk to the private address server behind the firewall. The firewalls will also have to allow remote procedure call (RPC) traffic through specific ports when this traffic comes from expected IP addresses.

Thinking locally when it comes to details
Once we have the firewalls configured to allow the appropriate traffic to flow between the two Exchange servers on each end of the information transfer, we will find that Exchange doesn’t allow for this.

“By default, Exchange uses random port assignments for RPC data,” Laun said. So you have to set fixed ports for this data exchange via a Registry hack on the Exchange servers. Obviously, the port numbers you use for these RPC services must be the same at each end.

Laun chose the following port numbers:
  • TCP Port 135 is already a fixed port assignment for RPC Location Services.
  • TCP Port 1445 for DS exchange (Directory Services)
  • TCP Port 1447 for IS Exchange (Information Store)
  • TCP Port 1449 for SA Exchange (System Attendant)

As usual, you are going to want to use caution when you hack Registry settings. Microsoft TechNet Knowledge Base article PSS ID# Q148732 provides a detailed explanation of the hacks for each of the services.

In the Registry, you will essentially be making TCP/IP port settings as DWORD values and the RADIX set to decimal. The Knowledge Base article gives you location information; you supply your own port numbers.

Technically, you need to do this hack only on the Publisher machine, but in our example, both servers need to exchange Free/Busy information and each will function as a Publisher (and a Subscriber) in order to do so. When in client modes, each will be picking up the port assignments for the services from the RPC Location Service.

Once the ports are set, there’s only one other preliminary setting to worry about: You must include the remote server in your LMHOST and HOST files. Of course, you’ll need to put your address in the same files on the remote system.

For example, if your gateway address is and the remote’s address is, in the LMHOST file, you would add:      server name     #DOM:NTDomainname    #PRE

In the HOST file, you would add:     server name

At this point, you are ready to configure the Exchange servers.

Getting down to business
Now it’s time to begin working on the actual Exchange administration. While we will be describing an overview of the process on one end of the Publisher pairs, the configuration must be done on both ends.

For the down and dirty details of the following discussion, which describes this process for Microsoft Exchange Server, version 5.5 with Service Pack 2, refer to Microsoft TechNet Knowledge Base article PSS ID# Q238573. The article describes the Microsoft Exchange Server InterOrg Replication utility, which consists of two programs, Exscfg.exe and Exssrv.exe. These programs are available on the Service Pack 3 CD.

These three steps will get our Free/Busy calendaring connections working:
  • Preparing the Publisher and Subscriber
  • Creating the configuration file
  • Setting up the replication service

Preparing the Publisher and Subscriber
Security for an Exchange server comes from the network’s user permissions. To begin the process, you must first create an NT or Active Directory account, as well as an associated Exchange server mailbox for the configuration utility to use as a service account.

The Publisher on one organization will be the Subscriber on the other organization, so they’ll use the same account information. Laun deviates from the instructions in the Knowledge Base article in that he uses the Exchange Administrator program to prepare the client permissions because it shows the complete system folder tree, which Outlook doesn’t. You will be able to see the Schedule+Free Busy System Folder that is installed by default with Exchange for its built-in calendaring functions.

Next, you create a mailbox called something like InterOrg Free/Busy and associate it with your NT or Active Directory service account. This has to be done on both servers; however, only one mailbox and service account is needed per organization.

Then, you will use Outlook to create a public folder called ExchsyncSecurityFolder in the root public folder. Go back into the Exchange Administration tool and grant Folder Visible permission (but not Default Editor or Anonymous permissions) to the service account mailbox for ExchsyncSecurityFolder. Also, set the permissions to your InterOrg Free/Busy mailbox to Folder Visible and Default Editor and set Anonymous to None.

Next, go into the System Folder/Schedule+Free Busy folder and then into each site you have listed there in subfolders and set the client permissions to Folder Visible, Default Editor, and Anonymous None and add your service account (in our example, InterOrg Free/Busy). Now, go into the System Folder/Schedule+Free Busy folder and then into each site you have listed there in subfolders and set the client permissions to Folder Visible, Default Editor, and Anonymous None and add your service account (in our example, InterOrg Free/Busy).

Before you go any further, you will need to create a working directory for your two utility programs and copy them into this directory from the CD.

The configuration file
The configuration utility (Exscfg.exe) will allow you to make configuration files for both Free/Busy information and for public folder replication, but we’ll concentrate on the Free/Busy function because it is the most popular.

After double-clicking on Exscfg.exe, you need to follow the eight steps outlined in the Knowledge Base article to create the configuration file. In this file, you will be specifying such things as the frequency of information replication between the servers, whether you want a log file, and the settings for your Publisher and Subscriber information and NT security.

The only really tricky part of the configuration is understanding what it wants you to put in the Maximum Task Number box. A note in the Knowledge Base article explains that the number of threads to be used for replication should be equal to or less than the number of sites you’re replicating Free/Busy information for. In our case, this number would be 1 because that’s how many Publisher/Subscriber pairs will be in use.

Starting the service
After you have saved your configuration file, you can set up the replication service file and start the service. The first time you click on Exssrv.exe, you need to click Install. This will allow you to type in your NT account name and password for the service account and mailbox you created during your preparations and to set the service to start automatically when the server is started.

Clicking Start launches the service. You will need to do this for both the Publisher and Subscriber services.

Summing up
Although this is not a simple process, it is usually much more efficient and effective than simply merging Exchange servers. The intense consolidation going on in the IT industry and other sectors of the economy has led to a lot of merged organizations. If multiple companies are running Exchange before they merge, this solution can offer tremendous benefits in bringing together calendaring functionality.

Have you done this?
Our impression here at TechRepublic is that few organizations have actually done a GAL synchronization or Free/Busy replication. Have you done it in your shop? How did it work? Were there parts of the process you found difficult or confusing? Send us a note or post a comment in the discussion below.


Editor's Picks