by Robert Henriksen
Directory synchronization is a crucial tool in implementing your migration from Microsoft Mail. Even if you're migrating only a single MSMail postoffice to Exchange, you should plan on setting up both systems to run concurrently. This will enable you to roll the e-mail accounts over to Exchange gradually. Electronic mail has become so crucial to everyday business that it's rarely worth the risk to do a crash conversion. Directory synchronization, combined with a message-transfer agent (External or the MSMail Connector), is the tool that will enable you to conduct a controlled migration.
Setting up directory synchronization will give you the flexibility to move a few users over at a time. This gives you a few guinea pigs at the beginning, to test both the product and your Exchange configuration decisions. With only a few users migrated at first, it won't be a disaster if you decide to go back and change the foundation of your Exchange configuration (in other words, start over). Moreover, running Mail and Exchange concurrently enables you to schedule the work of conducting the migration into manageable stages, rather than attempting the crushing job of reconfiguring every mail client and conduct training for all users at once.
If you are currently using the Workgroup edition of Microsoft Mailthe copy that's bundled with Windows for Workgroups, Windows 95, or Windows NTdirectory synchronization isn't available. You'll need to use the Migration Wizard bundled with Exchange Server to create accounts en masse on Exchange from your workgroup postoffice.
The chapter starts with an overview of the directory synchronization process (DirSync from here on) for the single postoffice administrators. From there, we'll discuss the ways Exchange can be incorporated into DirSync with Microsoft Mail postoffices, then walk through the configuration of each method. You'll learn how to manually fire a DirSync cycle for testing purposes, instead of having to wait for the scheduled time. I'll be outlining the most common, straightforward configurations to get you up and running, and highlight the pitfalls and shortcuts along the way.
This book is not going to attempt to cover the exact procedure of implementing directory synchronization on the Microsoft Mail side. The Mail 3.5 Administrator's Guide covers DirSync in two different chapters. The configuration parameters for the postoffices are laid out in Chapter 9, "Global Directory Synchronization," but the configuration of the Dispatch program, which is required for DirSync to occur, isn't explained until Chapter 14, "The Dispatch Program."
Here's what I wish the Microsoft Mail documentation had laid out up front about directory synchronization:
For the administrators not already using Mail DirSync, here's the big picture. DirSync is a three-step process, typically scheduled to occur automatically each evening. All participating Mail postoffices act as DirSync requestors. One of the POs also does double-duty as the DirSync server. (Refer to Figure 16.1.) There are three steps:
Figure 16.1. Overview of the directory synchronization process.
Now, there are two choices on how to integrate Exchange Server into a Microsoft Mail DirSync routine:
I believe the clear winner is to make Exchange the DirSync server, because of the enhanced reporting and logging functions of Exchangenot to mention the overall robustness of the product. If you have only one postoffice now, it's a no-brainer. If you already have DirSync in place between multiple POs, the deciding factor will be how many requestor POs you would have to reconfigure to use Exchange as the new DirSync server for the organization. Depending upon how large your installation is, you might decide to forgo the benefits of an Exchange DirSync server for ease of integration with a large existing system. Personally, even if I had as many as 5 or 10 Microsoft Mail postoffices, I'd switch them over to use Exchange's DirSync server.
Exchange Server does not perform all the duties of the Microsoft Mail Dispatch program. You will still need to have an instance of Dispatch running to service the MSMail side of directory synchronization (steps 1 and 3, assuming you've decided to use Exchange as your DirSync server).
However, as discussed in Chapter 13, "Connecting to Other Mail Systems," you can use the MSMail Connector to perform MTA for all your MSMail postofficesnegating the need for the MSMail External program.
To configure and begin using MSMail Directory Synchronization, you must already have installed and configured the MSMail Connector; see Chapter 13. DirSync passes the directory information between postoffices via mail messages. Therefore, DirSync can't occur without functional message transfer between postoffices.
Launch the Exchange Administrator Program, and open the Site\Connectors container (see Figure 16.2).
Figure 16.2. The Exchange Administrator Connectors Container.
Now, select File | New Other | DirSync Server (see Figure 16.3).
Figure 16.3. Adding a DirSync server.
You should now have the Properties dialog box open, as shown in Figure 16.4. Type in a name for this dirsync server. Because you're likely to be configuring only a single instance of the DirSync server, go ahead and use some form of the Site name. Then select a mailbox for the DirSync Administrator. The simplest choice is to use yourself for all the various Administrator addresses, until you get settled. Then, as needed, you can move responsibilities for the various functions to other people.
Figure 16.4. The Directory Server Properties dialog box.
You should activate the Copy administrator on outgoing messages and Forward incoming DirSync messages to administrator flags. The latter gives you confirmation that the MSMail Dispatch program is performing the step 1 of the cycle, and that those T1 requests are making it to the server (the MSMail Connector MTA is working). Copy Administrator on outgoing messages lets you know that Exchange has performed its T2 function and responded to the requestors with a composite list of directory changes. Note that these status messages cover only steps 1 and 2you do not receive any confirmation on whether the Mail Dispatch program has successfully performed step 3. But, this is still a lot more information than was delivered to you under Microsoft Mail. After you've settled into a routine and are comfortable that the scheduled DirSync cycles are performing properly, you can always go back and turn these flags off.
If you're operating in a very structured environment, you might want to have a log of each DirSync cycle. One way to do that would be to turn on a high enough level of logging in Exchange Administrator to capture all DirSync-related activity in the Event Viewer's Application Log. A more focused method is the following:
Now all the status messages during each evening's DirSync cycles will be dropped into this public folder. You can also create rules about the maximum age of messages retained, or maximum folder size, to keep things from getting out of hand.
Next, Select the Schedule' property page (Figure 16.5) and select the time you wish the T2 function to occur.
Figure 16.5. The Schedule page of Directory Server Properties.
I'd suggest something simple like Table 16.1.
Job |
Suggested Time |
Responsible Program |
T1
|
8:00 p.m.
|
MSMail Dispatch program/service
|
T2
|
10:00 p.m.
|
Exchange Dirsync server service
|
T3
|
12:00 a.m.
|
MSMail Dispatch program/service |
It's possible to select multiple times each day for Exchange to perform the T2 function, but this is of questionable value with just a few postoffices. So, highlight the 10:00 p.m. bar in the Schedule page.
This is all that's required to configure Exchange as the DirSync server. Something you will definitely want to do is enable the ability to manually fire a T2 event on the Exchange Server. Without this, you'll have to wait overnight to see if your directory synchronization is functional. Another advantage to enabling manual DirSync cycles is that you can migrate mailboxes in the middle of the day, and immediately update the Mail postoffice GALs so that no mail gets bounced.
This modification is an undocumented feature of Exchange that can be found in Microsoft's Knowledge Base, article Q146738. This will require modifying the Exchange Server's registry, with all the usual dire warnings about what a risky business that can be.
Using Registry Editor incorrectly can cause serious, system-wide problems that might require you to reinstall Windows NT to correct them. No one can guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.
Open the registry editor (in Program Manager, select File | Run and enter regedt32.exe) and locate the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDX
Ensure that you've highlighted the MSExchangeDX key, and select Edit | Add Value (see Figure 16.6). Add the values as indicated in Figure 16.7 through 16.9.
Figure 16.6. Adding the Registry Key for manual T2.
Figure 16.7. Enter value name and data type as shown.
Figure 16.8. Enter Data value as shown.
Figure 16.9. The finished result.
You will need to use Control Panel...Services to stop and then restart the Microsoft Exchange Directory Synchronization service for this change to take effect. We'll use this new capability a little later, when executing a manual DirSync cycle.
Next, you'll be either setting up a new the DirSync requestor parameters on your MSMail postoffice (if you've never used DirSync before), or reconfiguring each postoffice's DirSync requestor configuration to point to the Exchange Server as its new DirSync server. The MSMail Administrator's Guide walked you through this in Chapter 9, in the section "Checklist for the Requestor Postoffice." The one thing you'll need to know is the name of the Exchange Server MSMail Connector PO. To find this, go to the Exchange Administrator, Site\Connector\MSMail Connector, and look on the Local Postoffice property page (see Figure 16.10). The default is Organization name\Site name.
Figure 16.10. Postoffice name for Exchange Server's MSMail Connector PO.
Finally, you need to tell Exchange about the MSMail requestor postoffice(s) that it will be hearing from every night. Go back to the Exchange Administrator and select the DirSync server you've created in the Site\Connectors container. Now, select File | New Other | Remote Dirsync Requestor (see Figure 16.11).
Figure 16.11. Command to define a new remote DirSync requestor.
Use the dialog box in Figure 16.12 to select the postoffice to be used with this remote requestor. Note that you need to have already defined the Microsoft Mail postoffice in the MSMail Connector properties, under the Connections page (see Figure 13.9). Otherwise the postoffice name will not appear in this list. See Chapter 13 if you have not already done this.
Figure 16.12. Select the postoffice.
After you've made your selection, the remote requestor properties dialog box will appear, as in Figure 16.13. You can use the existing MSMail postoffice name for the Name field or a label that might be more descriptive to end users. This is something to stop and think about, as you can have this name appended to the user names displayed in the Global Address List. This function can be useful to indicate in the GAL which mail accounts have not yet migrated to Exchange, and the name of their home PO. If your postoffices are serving different types of users, this could be used to label the user names with what division they work in, for instance. It's trivial to go back and change this name (unlike some other names in Exchange), so you shouldn't let yourself come to a grinding halt over this issue.
You can probably leave Password, Requestor Address Type, and Requestor Language well enough alone. Do check Export on next cycle, to ensure all the existing Exchange mail accounts get integrated into the MSMail GAL(s) when you run through the first DirSync cycle.
Figure 16.13. The remote DirSync requestor properties dialog box.
Recipient Container(s) should be thought out before creating large numbers of mailboxes and distribution lists. You cannot move mailboxes and lists from one container to the other; you must delete the item and then recreate it in the new container! See the last section of this chapter for more information.
Figures 16.14 and 16.15 show Import/Export Containers. The Import Container specifies which recipient container the incoming MSMail addresses should be added to. Because this is defined per postoffice requestor, this parameter enables you to separate the members of different postoffices into different recipient containers. Export Containers specifies which containers should be included in exportation to the MSMail postoffice GALs. The default is to throw them all into Export. Trust levels can be tinkered with later; they allow a higher level of control over what's exported in DirSync and which trust level is assigned to imported recipients; MSMail recipients have no intrinsic trust level of their own.
Figure 16.14. The Import Container property page.
Figure 16.15. The Export Containers property page.
Don't remove DirSync requestors immediately after using it to draw in MSMail custom recipient; you will instantly lose all those custom recipients if you do! The custom recipients created by directory synchronization will be lost, both from the container and from any distribution groups they've been added to. Wait until you've migrated all those users off the MSMail postoffice, then delete the corresponding remote DirSync requestor.
If you wish to populate Exchange's GAL with just the Microsoft Mail user list, without using regularly scheduled directory synchronization, use the Export/Import commands to manually populate the Exchange GAL.
OK, so far you've done the following:
Now it's time to manually step through a DirSync cycle to see if it's working properly. This can all be performed from the Exchange Server console, or from an NT Workstation with an Administrator-level logon. We'll step through the T1-T2-T3 cycle for DirSync between a single MSMail postoffice requestor and an Exchange DirSync server:
Figure 16.16. Connector MTA properties. Select the appropriate MTA service and click the Configure button.
Figure 16.17. Increase polling frequency (Check for mail every) to 1 minute.
Figure 16.18. Using Server Manager for Domains to remotely control Exchange's services.
Figure 16.19. Select the Directory Synchronization service.
Figure 16.20. Confirm the pause command.
Figure 16.21. Pausing the service.
Figure 16.22. The appropriate response from the service.
Now log into an account on this Mail postoffice, and admire the Exchange mailboxes that now appear in the MSMail GAL.
Mixed Membership in E-mail Groups
If you're currently running DirSync between multiple postoffices, you've probably run across the problem of distribution groups that contain users from different postoffices; that group can't participate in directory synchronization. In other words, that mixed-membership group cannot appear in the GAL of the other postoffices.
After completing the DirSync process with Exchange, just create a replacement distribution group on the Exchange server and add in all those users from the various postoffices. Problem solved! An Exchange distribution group can contain native Exchange mailboxes and custom recipientsthat is, MSMail accountsfrom multiple postoffices, and still participate in DirSync. Doesn't faze it a bit.
If you've decided to configure Exchange to function as a DirSync requestor, you probably already have a functioning synchronization process in place. Open the Exchange Administrator program, and select the Site\Connectors container. Now select the File | New Other | Dirsync Requestor command (see Figure 16.23).
Figure 16.23. Creating a new DirSync requestor.
First, you need to tell Exchange which Microsoft Mail postoffice is the directory synchronization server. You'll be given a list of the known postoffices to select from. This list is generated from the MSMail Connector, in the Connections page (see Figure 16.24).
Figure 16.24. Select the DirSync server postoffice.
You now have the Properties dialog box for the new Exchange requestor (see Figure 16.25). Now, enter a name for this requestor. A name based on the site is a good choiceperhaps ExcSite1req. If you choose to have this requestor name appended to the user names in the GAL, a more user-friendly name is probably called for.
Figure 16.25. General settings for the requestor.
The configuration decisions for the Import and Export pages are the same for using Exchange as for the DirSync server, discussed earlier in this chapter.
In the Settings page, shown in Figure 16.26, you'll want to stick with the default settings for the first two sections: Participation and Template information. Because your first DirSync cycle hasn't occurred yet, you should activate both check boxes in the Dirsync information section. This will ensure that both copies of the GAL (Exchange and MSMail) are fully populated with each other's directories.
Figure 16.26. Settings for the requestor.
The Schedule page is a source of some confusion. This is because, under MSMail, you had to specify a time for the execution of both the T1 cycle and the T3 cycle. Here, you need to specify only the time for the T1 to occur. When Exchange receives back the composite list of changes from the DirSync server, the Directory Synchronization service automatically processes the information into the Exchange GALin other words, the T3 occurs on demand.
When you've completed your configuration of this requestor, you should see an additional entry in the Configurations container for this requestor, similar to Figure 16.27.
Figure 16.27. The new requestor.
Now run through a DirSync cycle to make sure that the Exchange server is functioning properly as a requestor. (This procedure is also described in the Microsoft Knowledge Base, article Q148309.) The following steps are required:
The registry modification needed is exactly as already described, in "Configure Exchange as the Dirsync Server," earlier in this chapter.
To increase diagnostic logging, open the MSMail Connector, select the Diagnostic Logging page, and change MSExchangePCMTA to Maximum (see Figure 16.28).
Figure 16.28. Diagnostic settings for Directory Synchronization.
Now, step through the manual DirSync cycle.
Finally, be sure to go back and turn diagnostic logging for MSExchangePCMTA back down to "none."
Containers! This is a place to pull up short and think. Exchange installs with a single default recipients container, Recipients. The Schedule+ Free/Busy component is already installed here, along with the public folders. It's all too easy to charge forward and slam all your Exchange mailboxes, custom recipients, distribution lists, and public folders into this one containerespecially because the Microsoft documentation is all but mute on this point.
Segmenting your various user elements into different containers can make a lot of sense, and unfortunately there's no easy way to reconfigure things after you've poured a lot of mailboxes and distribution lists into Recipients. To move a mailbox between containers, you have to do the following:
Easy enough for one user, but murder for large numbers of accountsespecially when your users are pack rats, with thousands of messages.
What are the implications and advantages to multiple containers? Primarily administrative:
In this chapter you learned the ways in which Exchange Server can be integrated into Microsoft Mail directory synchronization, and the procedures for configuring both. You also reviewed the steps for manually stepping through a DirSync cycle.
Directory synchronization between Microsoft Mail and Exchange Server is a "set it and forget it" function. Included on the CD-ROM is a sample batch file, which you can customize to aid in the occasional manual directory synchronizationssuch as when migrating user accounts during the day.