PC DirSync: Directory Synchronization (Dir-Sync)

TABLE OF CONTENTS

Introduction
History
General Description of Directory Synchronization
Quick Setup Guide
Steps for Choosing Dir-Sync Times
Typical Dir-Sync Scenarios
Gateway Names and Dir-Sync
Moving the Dir-Sync Server
Automatically Creating Postoffices via Dir-Sync
The TimeZone Variable
The Dir-Sync Process
Manual Dir-Sync
The Dir-Sync Protocol
Dir-Sync Utilities
Troubleshooting Dir-Sync
Appendix: .INI File Settings for Dispatch and External
Glossary

INTRODUCTION

This document is designed for the Mail administrator and outlines the procedures directory synchronization (Dir-Sync) performs during normal operation. The network administrator can use these procedures to examine Dir-Sync files, to reset these files, or to perform a manual Dir-Sync process to fully synchronize the postoffice address lists (POLs). This document is a supplement to the Microsoft Mail Administrator's Guide.

HISTORY

In versions of Microsoft Mail for PC Networks earlier than 3.0, Dir- Sync was accomplished manually: each time a change was made to the address list, each Mail administrator performed an External-Admin, Export. As a result, many large messages would be sent to all the postoffices as *SPECIAL messages. This was inefficient; the External Mail program could be fully occupied with delivering and incorporating the address changes instead of delivering user messages.

To perform synchronization with versions of Mail earlier than 3.0, the number of system messages is N * (N - 1), where N is the number of postoffices in your network. For example, with six postoffices, you would have 6 * 5 = 30 system messages. With Dir-Sync, the number of system messages is 2 * N. In mathematical notation, versions 3.0 and later of Mail performs an O(N2) operation, whereas Dir-Sync performs an O(N) operation, which is much more efficient. For versions 2.x of Mail, doubling the number of postoffices quadruples the number of messages; however, for Dir-Sync the messages are only doubled. Thus, the number of messages that need to be exchanged is substantially reduced. In addition, the sizes of the messages are smaller because Dir-Sync only sends the changes to the address list, not the full address list, as required by External-Admin, Export. This means that with Dir-Sync, the External Mail program is not occupied with delivering complete directories, nor are you forced to manually send your address list to the other postoffices when a single user is added or deleted.

GENERAL DESCRIPTION OF DIRECTORY SYNCHRONIZATION

Dir-Sync is a method of propagating local postoffice address list changes to other postoffices that are participating in the Dir-Sync process. Dir-Sync is meant to be invisible to both administrators and users; the changes are distributed automatically after the administrator has configured Dir-Sync.

To accomplish synchronization, one postoffice is defined as the directory server. This "server" postoffice maintains the master list of all changes from the "requestor" postoffices. When a change is made to a requestor's address list, the change is sent to the Dir-Sync server, which incorporates the change into the master list and sends updates to the requestors. These updates have only the changes a postoffice needs to update its Global Address List (GAL).

QUICK SETUP GUIDE

NOTE: For efficient and complete configuration of Dir-Sync, it is highly recommended that you designate a global administrator, who has access to all the postoffices. Although Dir-Sync does not require this, it will make administration much easier.

To initialize Dir-Sync easily and quickly, complete the following nine steps in the order listed:

NOTE: These steps are expanded below. Perform all the steps on the Dir-Sync server, and perform steps 1 and 5-9 on all the requestors.

1. Ensure that mail can be sent between the postoffices.
2. Designate one postoffice as the Dir-Sync server.
3. Register all other postoffices as requestors with the server.
4. Set up the server's process time.
5. Register the server with all the other postoffices participating in Dir-Sync.
6. Set up the two times for the requestors' processes.
7. Export the user lists to the server by selecting Config, Dir- Sync, Requestor, Export (not External-Admin, Export).
8. Turn on the Global Address List (GAL).
9. Run the Dispatch program and run the External Mail program or a message transfer agent (MTA).
10. Ensure that mail can be sent from each postoffice to all other postoffices that will be participating in Dir-Sync, by sending mail from each postoffice's Administrator account to every other postoffice's Administrator account. This step is required because Dir-Sync uses the mail system to transfer the address list updates, so regular mail must be able to be sent and received before Dir-Sync will function.
    
    NOTE: Do not assume that because messages can go from one postoffice to another, the reverse is true. Be sure to test both sides of the connection before proceeding.
11. Decide which postoffice will be the Dir-Sync server. On that postoffice, run the Mail Administrator program and select Config, Dir-Sync, Options, Yes to make that postoffice the Dir-Sync server. There can only be one Dir-Sync server in your mail system. For more assistance in selecting the Dir-Sync server, see the Microsoft Mail Administrator's Guide.
12. Select Config, Dir-Sync, Server, Requestors, Create to register each requestor postoffice on the server postoffice. These external postoffice definitions must have been created on the postoffice via External-Admin, Create before you register the requestor(s). You can leave the Requestor Password field blank; it is an extra security feature that is not related to any other password used by Mail. If you decide to use this password, the requestors must have the same password as well.
13. Select Config, Dir-Sync, Server, Schedule to schedule the time for the server to process the updates into the master list. For the Dir-Sync server only, skip step 5 and go to step 6.
14. For each requestor, select Config, Dir-Sync, Requestor, Registration to designate the server postoffice. Specify the same postoffice that was designated in step 3 so that the requestor knows which postoffice to send the updates to. This external postoffice definition must have been created via External-Admin, Create before you can register it. If the Dir-Sync server has a password for the requestor's configuration, type the same password in the Requestor Password field (see step 3 above).
    
    NOTE: This step is not required for the Dir-Sync server; it is automatically registered when you perform step 2 above.
15. On each postoffice, run the Mail Administrator program and select Config, Dir-Sync, Requestor, Schedule to set the Send Requests and Process Updates times. The requestor sends updates to the server at the specified Send Requests time, and it processes updates coming from the server at the Process Updates time. Make sure the requestor sends its requests to the server prior to the server's scheduled time to process requests, and make sure the requestor processes updates after the server's scheduled time to send updates. Also, when setting the schedule for the requestor, add the additional time the MTA (such as the External Mail program or a gateway) needs to deliver the Dir-Sync mail. For more information, see the "Steps for Choosing Dir-Sync Times" section below.
16. Select Local-Admin, Modify and select the postoffice users who will be participating in Dir-Sync. When the option appears for participating in Dir-Sync, select Yes or No as appropriate. Then select Config, Dir-Sync, Requestor, Export to send the address list to the server postoffice. The server will build the master list and send all the postoffice lists to the participating postoffices. This step is a "kick-start" to get the lists up to the server quickly.
17. Select Config, Global-List, Yes to enable the GAL.
18. To create the Dir-Sync mail and update the GAL automatically, the Dispatch and External Mail programs must be running and must be able to access each postoffice participating in Dir-Sync. The Dispatch program polls each postoffice. When the designated time for Dir-Sync to run has passed, the Dispatch program will create a mail message that contains the directory changes as an attachment. The External Mail program must be running on the requestor postoffice to move the Dir-Sync message into the proper outbound postoffice queue, then either the External Mail program or a gateway MTA can deliver the message from the requestor to the server postoffice. The Dispatch program creates the update message, but the External Mail program or MTA must deliver it.

You can run the Dispatch program and the External Mail program or MTA on the same computer by using the Idle (-i) option of the Dispatch program. By using the External MTA as the idle process, you can deliver mail and perform Dir-Sync from one computer. The two executables share time on the computer because the Dispatch program starts the External Mail program with a Break Relative time. When the External Mail program exits, the Dispatch program can poll the requestors for Dir-Sync process times, and either run the Dir-Sync processes or restart the External Mail program. For more information, see the Microsoft Mail Administrator's Guide.

STEPS FOR CHOOSING DIR-SYNC TIMES

In general, setting the process times for Dir-Sync requires that you analyze your network and determine how long it will take the Dispatch program to cycle through the postoffices participating in Dir-Sync, and how quickly the External Mail program or MTA can deliver mail between postoffices.

To determine how long Dir-Sync will take on your network, start the Administrator program and select Config, Dir-Sync. Then perform the following steps:

1. Configure the Send Requests and Process Updates times for all requestors so that they are four hours apart (for example, if the "Send Requests" time is 2 A.M., make the Process Updates time 6 A.M.). To configure these times, select the Requestor Schedule option.
2. On the Dir-Sync server, set the Process Updates time halfway between the Send Requests and Process Updates times for the requestor (in this example, at 4 A.M.).
   
   NOTE: Process Updates for the server is not the same as Process Updates for the requestors. The former is located under Config, Dir-Sync, Server, Schedule; the latter under Config, Dir-Sync, Requestor, Schedule. Because of the identical names given the two distinct times, this is a point of confusion for many people.
3. Enable the SENT.LOG and RECV.LOG files by running the External Mail program with the -MS and -MR options.
4. Let the Dispatch program complete one cycle overnight.
5. Examine the DISPATCH.LOG file on the Dir-Sync server. Search for the line Running "NSDA -RT". This is the Send Requests time for the postoffice whose name is shown on the line directly above the "NSDA -RT" line. There will be two lines for each requestor postoffice. Record each time NSDA -RT runs.
6. Search for the line Running "NSDA -S". This is the server's Process Updates time and must occur only on the Dir-Sync server. Record this time.
7. Search for the lines Running "NSDA -RR". These are the Process Updates times for each requestor. Record this time for each requestor.
8. Examine the SENT.LOG and RECV.LOG files for $SYSTEM messages. These are the Dir-Sync updates being exchanged. For each postoffice, record the time the $SYSTEM message was transmitted to the Dir-Sync server, when the Dir-Sync server sent a reply message, and when the update was received by the requestor.
9. For the Dir-Sync server, each $SYSTEM message must arrive at the Dir-Sync server before the Process Updates time for the server. For each requestor, the $SYSTEM message must arrive before the Process Updates time for each requestor. If any of the messages do not satisfy these criteria, you need to adjust the Process Updates times.

Alternatively, run the Dispatch program for two cycles and then examine the CENTRAL.LOG file. This log file contains the previous status of Dir-Sync on each requestor. It is one cycle late because it uses the status messages the requestors send to the Dir-Sync server, and these messages are sent at the Send Requests time of the next cycle; thus the CENTRAL.LOG file shows what happened in the previous cycle. The benefits of this method are that each requestor is summarized in a single location and you can easily view the Dir-Sync times. The drawback is that the file is old, and, therefore, two cycles of the Dispatch program are required.

For an example of the log files, see Appendix B of the Microsoft Mail Administrator's Guide.

TYPICAL DIR-SYNC SCENARIOS

This section is a guide for setting up an efficient Dir-Sync configuration involving the postoffice, the MTA, and the Dispatch program. In the following scenarios, assume that drive mappings start with the Dir-Sync server at drive M, and that the Dispatch program and the MTA are run from the same computer.

A. STANDARD CONFIGURATION

The following scenario shows multiple requestors sending directories to the Dir-Sync server. The Dispatch program and the External MTA can have direct access via LAN or WAN to each postoffice. The command line for the computer running the Dispatch and External Mail programs is: For Dispatch 3.2 and External 3.2, the corresponding .INI files are included in the Appendix of this document. The command line for Dispatch 3.2 and External 3.2 is: If you use a gateway as the MTA, this command line will change. See the administrator's guide for the gateway you are using to determine the best approach for running the Dispatch program and the gateway MTA together. Also, it is important that you still run the External Mail program to process the Dir-Sync messages.

B. DYNAMIC DRIVE MAPPING

In the following scenario, dynamic drive mappings connect Requestors 2 and 3 to the Dir-Sync server. Both the Dispatch and External programs from Mail 3.0x use the same dynamic drive table, so any postoffice the External Mail program delivers mail to should be included in Dir-Sync. Mail 3.2 handles dynamic connections differently, and the Dispatch program does not need to use the same Dynadmin table (although it can if you want to use the same table). The command line for the computer running Dispatch and External is: Note that the Dispatch program does not need to designate which drives to use for the dynamic connections because it uses the first available drive designation; however, the External Mail program does need this information. Thus, the Dispatch program requires the -F option, while the External Mail program requires -FOP (for example) to use drives O through P for dynamic connections. This configuration is not possible when you use a gateway as an MTA because gateways do not use dynamic drives.

The corresponding .INI files for Dispatch 3.2 and External 3.2 are included in the Appendix. For Dispatch 3.2 and External 3.2, the command line is:

C. MODEM CONNECTIONS

In the following scenario, modems are used to connect two networks. Because the Dispatch program cannot run over the modem connection, two copies of the Dispatch program must be running simultaneously. Dispatch 1 controls the server and one requestor, while Dispatch 2 controls the other two requestors. Note that there is still only one Dir-Sync server, not two. The command line for running Dispatch and the External MTA on both networks is the same for both computers: The corresponding .INI files for Dispatch 3.2 and External 3.2 are included in the Appendix. For Dispatch 3.2 and External 3.2, the command line is:

D. INDIRECT ROUTING

In the following routing, Requestor 3 is indirect via Requestor 2. As with the modem connection scenario, the Dispatch program cannot process the indirect postoffices unless the Dispatch program is configured to connect directly to the requestor postoffice. In this case, the routing of messages is indirect but the Dispatch program processes the postoffice directly. If Dispatch 1 cannot reach Requestor 3 (as in the diagram below), a second copy of the Dispatch program must be running in order for Dir-Sync to work. The command line for the computer running Dispatch 1 and External MTA 1 is: The command line for the computer running Dispatch 2 and External MTA 2 is: The corresponding INI files for Dispatch 3.2 and External 3.2 are included in the Appendix. For Dispatch 3.2 and External 3.2, the command line for Dispatch 1 is: For Dispatch 2, the command line is:

GATEWAY NAMES AND DIR-SYNC

You can use Dir-Sync to distribute gateway names to all the requestor postoffices. However, this is not as simple to do as it is with Mail postoffices.

To begin, each requestor postoffice must have either the gateway or the access (also known as downstream) component of the gateway installed. When this is done, use the Administrator program to accept gateway addresses by selecting Config, Dir-Sync, Requestor, Types. Normally, the Types option has only Microsoft Mail enabled, but installing the gateway places the gateway type in the Types list with that type set to No. Select the gateway and respond Yes; the gateway names will be accepted by the requestor postoffice for inclusion in the gateway address list and in the GAL.

At this point, the requestors will accept gateway names; however, there is no process to get these names into the Dir-Sync cycle. There are three ways to do this:

• Register the gateway on the Dir-Sync server as a requestor, then write an application that will send the gateway address changes to the Dir-Sync server. The format for Dir-Sync mail is published in" Directory Synchronization with Foreign Mail Systems", which is available from Microsoft Customer Service. -or-
  
  
• Manually generate a text file that contains the gateway address changes to be entered in Dir-Sync. Use the import format described in "The Import Utility" section of the Microsoft Mail Administrator's Guide. On any requestor postoffice, run the Import utility as follows:
  import admin -ppassword -e -ffilename
  The -E option makes the Import utility add the names in filename to the REQTRANS.GLB file instead of to the gateway address list, as would occur without the -E option. The next Dir-Sync cycle will take these names, as it does with regular Mail for PC Networks names, and send them to the Dir-Sync server and hence to the requestors. -or-
  
  
• Add the new names and delete the out-of-date names via the Administrator program's Gateway List menu, then extract the gateway address list by using the Import utility as follows:
  import admin -ppassword -x -ggatewaytype -ffilename
  where -X specifies that Import is to extract addresses and -G specifies that gateway names defined under the gatewaytypeare to be extracted. This list cannot be used by Dir-Sync without a slight modification, however. The list as generated contains all Add commands, and none of the Delete or Modify commands. To make this list usable so that the deleted names are deleted from the other postoffices and modified names are modified, you must add the following line at the beginning of the file to tell Dir-Sync to replace the existing gateway list with the new gateway list:
  R gatewaytype:
  Note that some gateways (for example, PROFS(R)) need several such lines, one for each node. Once you add the Replace lines to the beginning of the gateway list, use the IMPORT -E line given above to send the file to the Dir-Sync server. You can easily incorporate this process into a batch file: create a file that contains the R commands, copy this file to a temporary file, use Import to extract the gateway list to the temporary file, and then send the file to the Dir-Sync server. Therefore, the batch file would look like the following:

        copy start.txt temp.txt
        import admin -p<password> -x -g<gatewaytype> -ftemp.txt
        import admin -p<password> -e -ftemp.txt
        del temp.txt
  						

Run this batch file before the time when the requestor postoffice sends its updates to the server, or the gateway list will not be incorporated into the GAL until the next Dir-Sync cycle is run.

MOVING THE DIR-SYNC SERVER

Moving the Dir-Sync server from one postoffice to another involves several steps that maintain the database integrity:

1. Select which postoffice will be the new Dir-Sync server postoffice.
2. If this postoffice is not registered as a requestor on the current Dir-Sync server, run the Administrator program on the current Dir- Sync server and register the new postoffice as a requestor.
3. Make the postoffice the new Dir-Sync server via the Administrator program, by selecting Config, Dir-Sync, Options, Yes.
4. Save a copy of the PROCESS.GLB file from the GLB directory on the new server postoffice. Copy the PROCESS.GLB file from the old Dir- Sync server to the GLB directory on the new server. This will maintain the current schedule of server processes. Alternatively, use the Administrator program and schedule the T2 time by selecting Config, Dir-Sync, Server, Schedule. If this postoffice has not participated in Dir-Sync, schedule the T1 and T3 times as well, under Config, Dir-Sync, Requestor, Schedule.
5. Copy the SRVCONF.GLB and MSTTRANS.GLB files from the current Dir- Sync server's GLB directory to the new server's GLB directory, overwriting the existing (new) files.
6. Turn off the old server via the Administrator program, by selecting Config, Dir-Sync, Options, No.
7. Copy the PROCESS.GLB file you saved in step 4 to the GLB directory of the old (inactive) server. This will ensure that no scheduled server processes will be remaining on the inactive server.
8. Compress the mailbags on the old (inactive) server via the Administrator program, by selecting Local-Admin, Storage, Compression. Check the size of the SYSTEM.MBG file on the inactive server. If it is not zero bytes, complete the following steps to clear out any Dir-Sync messages:
   1. Run the following MS-DOS command in the MBG directory:
      type nul > system.mbg
   2. Go to the KEY directory and run debug system.key. At the dash prompt, type the following and press ENTER after each line:
      F,100,L 230,0
      W
      Q
      This will flush out any Dir-Sync messages that did not get processed. Dir-Sync will recover from the missing messages as part of its fault tolerance.
9. Register the old server (now a requestor) with the new server, and change the registration of all the requestors to the new Dir-Sync server via the Administrator program, by selecting Config, Dir- Sync, Requestor, Registration.

AUTOMATICALLY CREATING POSTOFFICES VIA DIR-SYNC

When Dir-Sync receives an address from a postoffice that isn't currently defined on the requestor postoffice, Dir-Sync will automatically create that postoffice. However, the Dir-Sync server cannot do the same because the server must know the requestor's name before it can accept address updates from that postoffice.

This feature is very handy for the administrator because the main problem with adding postoffices is ensuring that the spelling is correct. However, there is one caveat: Dir-Sync uses the same routing for the automatically created postoffice as that used to route messages to the Dir-Sync server. This may not be the correct routing for the new postoffice. It is likely that the new postoffice is routed differently, but you must correct the routing manually. Dir-Sync has no foreknowledge of the structure of your mail system, so it uses the only information it has when automatically creating a postoffice.

For example, if the Dir-Sync server's route is via a modem, all automatically created postoffices will be routed via modem as well. If the Dir-Sync server is routed indirectly via a hub postoffice, then all automatically created postoffices will be routed indirectly via the same hub postoffice.

Therefore, there are two scenarios where Autocreate will function without your having to make any changes:

• All postoffices are routed directly. Because the Dir-Sync server is routed directly as well, the routing for all postoffices will be correct.
• All postoffices are routed indirectly via a hub postoffice. Because the Dir-Sync server is routed indirectly as well, the requestor already knows that the hub postoffice is routed directly and the Dir-Sync server is routed indirectly. All other postoffices will be created as routing indirectly via the hub postoffice.

The optimal setup is to manually create all directly routed postoffices (unless the first case above applies), route the Dir-Sync server indirectly via a hub postoffice, and automatically create the other indirectly routed postoffices via the hub postoffice.

NOTE: When a requestor's name is changed on the requestor and on the Dir-Sync server, and autocreate Postoffice is enabled, duplicate entries will be created in all the other requestors because Dir-Sync does not know how to rename a postoffice. It will create the new postoffice name without deleting the existing name, and will build a GAL with duplicate entries. You must manually remove the obsolete postoffice via External-Admin, Delete, or rename the postoffice via External-Admin, Modify, prior to Dir-Sync processing the change.

THE TIMEZONE VARIABLE

The TimeZone (TZ) variable is used to adjust the Dir-Sync times to what the Dispatch computer is using. This sounds more awkward than what actually happens. An example is the best approach to explaining TZ:

Assume that the Dispatch computer is in St. Louis (the Central U.S. time zone EST6) and that the postoffice is in Sydney, Australia (so the time zone is aus14, since TZ considers locations west of Greenwich to have positive time offsets). The format for the MS-DOS TZ environment variable is SET TZ=xxx-]nnyyy, where xxx is a designation for the time zone (any three characters will work--they are not checked for validity); nn is the time from Greenwich calculated as the number of hours difference, where moving westward is positive and eastward negative; and yyy is for daylight saving time; and any character after the hours (nn will adjust the time by one hour.

When TZ is set, several MS-DOS time functions are updated to the current time zone. When the administrator sets the Dir-Sync times, the TZ variable is incorporated into the time written to the PROCESS.GLB file. Dispatch reads this time and adjusts it according to the local TZ variable on the computer running Dispatch. This time is used to schedule Dir-Sync. Therefore, it is important that you set TZ on both the computer running the Administrator program and on the computer running the Dispatch program, or the correct offsets will not be used.

For example, let the time be 3 A.M. (03:00) in Australia. When the Dispatch program reads the PROCESS.GLB file, it takes the set time (03:00), adds the stored time zone (14) to convert to Universal Time, then subtracts its own time zone (6) to convert the time into local time. Thus the Dispatch program sees the process time as 03:00 + 14 - 6 = 11:00, and that is the local time when the Dir-Sync process will be run in Australia. The time in Australia will still be 03:00.

When the administrator in Australia views the Dir-Sync schedule, the time will be 03:00. If the administrator from the Dispatch machine views the same schedule, the time will reflect the change in time zone and so will be 11:00. This can be confusing to the administrators, but it is perfectly normal behavior.

There are five scenarios that involve the TZ variable:

• All postoffices are in the same time zone, and the Administrator and Dispatch programs are run from this time zone. TZ is not needed.
• Postoffices are in different time zones, but the Administrator and Dispatch programs are run from one time zone. TZ is not needed because the stored times are all using the same TZ offset.
• Postoffices are in different time zones and the Administrator program is run from different time zones, but the Dispatch program is run in only one time zone. TZ is helpful in this setup because the offsets are calculated automatically. Set the TZ variable on the computer running the Administrator program and on the computer running Dispatch. If you are using Dispatch 3.0, set the TZ variable from the MS-DOS prompt. If you are running Dispatch 3.2, use the DISPATCH.INI file's TimeZone option.
• Postoffices are in different time zones, and multiple copies of both the Administrator and Dispatch programs are run from different time zones. This scenario is awkward; TZ will not really help in this case because each copy of Dispatch will be reading TZ offsets, and there is no way to coordinate several Dispatches.
• The Administrator program is run from one time zone, and Dispatch is run from another time zone. TZ will not help in this case: Dispatch will incorrectly adjust the time set by the Administrator program because Dispatch believes the postoffice is located in the same time zone as the Administrator program.

The alternative to TZ is to manually adjust the times for the difference. If the time zones are close to one another (less than three hours' difference), TZ may not be of help and manual adjustment may be easier.

One situation that can cause difficulties (although it is not directly related to the TimeZone variable) arises with daylight saving time (DST). When Dispatch updates the time to run the next Dir-Sync process, it does so by adding one week's worth of seconds to that day's time. It maintains a complete weekly list of Dir-Sync times, along with the next time to run, and simply copies the next time to run into the place for the current time to run. The problem occurs when Dispatch runs a process in the week before DST takes effect. When it adds the week's worth of seconds, MS-DOS compensates for the impending arrival of DST by interpreting the stored time to have one extra hour in it. Thus the time recorded in the PROCESS.GLB is one hour greater than before. The opposite is true when DST ends; the extra hour is removed.

Dispatch continues to add the week's worth of seconds, so the change in time propagates until DST ends. This is NOT the fault of Dispatch. It knows nothing about the change; it compares the time to run with what MS-DOS reports. Because the two are off by one hour, Dir-Sync occurs one hour later (or earlier, depending on DST) than expected.

The solution is simple: always set the TZ variable on the machine that sets the process times (be it ADMIN.EXE or DSSCHED.EXE, described below). When TZ is set, MS-DOS does not add the extra hour when DST occurs. Note that you don't want to use SET TZ=PST8DST, or MS-DOS will add the extra hour when the change to or from DST occurs. Therefore, the three cases are:

THE DIR-SYNC PROCESS

Dir-Sync can be divided into four distinct times. Time 0 (T0) is when the postoffice administrator uses the Administrator program to create or modify a user or group that is participating in Dir-Sync, or when Import is used to add names to the Dir-Sync process. When these changes are made, a record is added to the REQTRANS.GLB file. The REQTRANS.GLB file is the entry point for all Dir-Sync names.

Time 1 (T1) is the Send Updates time, when the requestors create mail messages for the Dir-Sync server. These messages contain the status of the requestor and any updates of the requestor's address list that are sent to the server.

Time 2 (T2) is the Process Updates time for the server, when the server takes all the updates from all the requestors, adds them to the master transaction list, and creates mail messages that are sent to the requestors with the updates each requestor needs to have an updated GAL.

Time 3 (T3) is the Process Updates time for the requestors, when each requestor takes the updates from the server and incorporates them into its local GAL.

To ensure that a Dir-Sync process will not run long after it is scheduled to (as would be the case if DISPATCH.EXE did not connect to the postoffice for some reason, such as a server that is down), there is a "window" of time in which the Dir-Sync process will be run, and after which it will not. This is the run window for the process. For version 3.0 of the Administrator program the run window is four hours, and for version 3.2 of the Administrator program it is eight hours. If this amount of time passes and Dispatch then connects to the postoffice and reads the scheduled processes, a "Process name missed its run window" error is generated and is placed in the DISPATCH.LOG file (where Process Nameis either NSDA -RR, NSDA -S, or NSDA -RT, corresponding to T1, T2, and T3). When this error occurs, you should determine if Dispatch could not connect to the server in question, or if Dispatch is running out of time because it is running Dir-Sync on too many postoffices. The first condition is temporary; the second will occur frequently. The solution is to either have more copies of Dispatch running on different sets of postoffices (so that only one copy of Dispatch can perform Dir-Sync on a postoffice), or increase the amount of time between T1, T2, and T3.

In more detail, the exact steps Dir-Sync follows are: TIME 1 (T1)

T1 steps are:

1. Dispatch polls the PROCESS.GLB file at each postoffice to determine when to proceed with Dir-Sync.
2. When T1 has been reached or exceeded, dispatch spawns NSDA -RT.
3. The NSDA program in turn spawns REQMAIN -T to transmit the updates.
4. The REQMAIN program opens the REQCONF.GLB file to get the requestor's current synchronization numbers.
5. The REQMAIN program creates a mail message and an attachment, which contains the previous Dir-Sync status of the requestor, and places the message header in the P1 directory for the server.
6. The REQMAIN program reads the REQTRANS.GLB file to see if any additions or changes to the requestor's address list are waiting to be sent to the server.
7. The REQMAIN program creates a second mail message with the requestor's commands to the Dir-Sync server, creates an attachment to the message that contains the contents of the REQTRANS.GLB file (if any updates need to be sent to the Dir-Sync server), and places the message header in the P1 directory.
8. The REQMAIN program writes the status of the sent updates to the DIRSYNC.LOG file.

Because the mail messages for the server are in the P1 directory, the External MTA must run to first move them into the mailbag for the Dir- Sync server and then actually deliver them to the Dir-Sync server. Because gateways do not use the P1 directory, External is required even on postoffices that only use a gateway to communicate with other Microsoft Mail postoffices. For assistance on how to properly use a gateway as the MTA, contact Microsoft Product Support.

TIME 2 (T2)

T2 steps are:

1. Dispatch polls the PROCESS.GLB file.
2. When T2 has been reached or exceeded, Dispatch spawns NSDA -S for the Dir-Sync server only.
3. The NSDA program spawns SRVMAIN -R to receive the updates.
4. The SRVMAIN program reads the Dir-Sync mail messages (the mailbag for the Dir-Sync mail is SYSTEM.MBG) and incorporates them into the MSTTRANS.GLB file. MSTTRANS.GLB is the master list of all updates that are sent to the Dir-Sync server. This list is routinely purged of old directory entries, which you configure via the Administrator program by selecting Config, Dir-Sync, Server, Options, Keep Updates.
5. After incorporating the updates into the MSTTRANS.GLB file, SRVMAIN updates the SRVCONF.GLB file to reflect the current status of the Dir-Sync process for each requestor.
6. The NSDA program spawns SRVMAIN -T to transmit updates to the requestors. Only those postoffices that send an update at the T1 time (and were successfully received by the Dir-Sync server) are sent an update.
7. For each requestor, SRVMAIN reads the SRVCONF.GLB and MSTTRANS.GLB files and creates Dir-Sync messages that contain the entries in MSTTRANS.GLB that are numbered greater than the sync number stored in SRVCONF.GLB for that requestor. If templates are exchanged, SRVMAIN reads the various .TPL (template) and .INF (information) files and incorporates the information into the attachments. SRVMAIN places these messages, like the ones during T1, in the P1 directory for later delivery to the requestors.

The External MTA is again required to transfer the Dir-Sync messages from the P1 directory to the outbound queues for the requestor postoffices and then to deliver the mail to the requestors.

TIME 3 (T3)

T3 is the most complex step in the entire Dir-Sync cycle. It is at T3 that the Dir-Sync updates are received and the GAL and the GALINDEX.GLB file are rebuilt from scratch. This step is complex because of the time required to rebuild the various files. For large GALs (for example, more than 100,000 names), the rebuild process can take several hours. Even for small GALs (about 10,000 names) the rebuild process can take almost an hour to complete, depending on the type of computer used to run the Dispatch program. The faster the computer running Dispatch, the more quickly the process will complete.

T3 steps are:

1. Dispatch polls the PROCESS.GLB file again.
2. When T3 has been reached or exceeded, Dispatch spawns NSDA -RR on each postoffice.
3. NSDA in turn spawns REQMAIN -R to receive the updates.
4. REQMAIN reads the SYSTEM.MBG file for Dir-Sync mail, reads the attachments and transfers the names to the SRVTRANS.GLB file, and then exits.
5. NSDA spawns the Import program to move the names in the SRVTRANS.GLB file into the various .USR files (the address lists for each postoffice). The Import program does this by reading the SRVTRANS.GLB file and then sorting the names into three separate queues (USRTRANS.GLB, NMETRANS.GLB, and GWTRANS.GLB). USRTRANS.GLB holds names that are network or postoffice type names (SNADS, PROFS, OfficeVision(R)). NMETRANS.GLB holds Mail for PC Networks names that are to be deleted or modified. GWTRANS.GLB holds gateway names.
6. If template exchange is enabled, each postoffice template and information file is modified. If templates are enabled but no templates have been sent to the requestor postoffice, a warning is generated that states there are no templates. This is a very common warning, but it is not critical to Dir-Sync.
7. The Import program combines the names from the temporary queues and the templates into the .USR or .NME files. Then it clears the queues and exits.
8. NSDA spawns REBUILD -F.
9. Rebuild reads the local postoffice list (ADMIN.NME), each gateway's NME list, the network list, and each external postoffice's USR list into a temporary GAL. This temporary file is sorted and a temporary GAL index is built. This step is by far the most time-consuming part of the process.
10. Rebuild deletes the old GAL and GAL index files, renames the temporary GAL index to GALINDEX.GLB, and renames the temporary GAL to GAL.NME.
11. Rebuild places all external postoffice and gateway names in the GALNETPO.GLB file. This file is used to speed up the time required to resolve an external name to a corresponding mailbag.
12. Rebuild exits, NSDA exits, and the Dir-Sync cycle is complete.

MANUAL DIR-SYNC

At times it may be necessary to check on the status of Dir-Sync and verify that all parts and executable programs are running correctly. A manual Dir-Sync cycle can accomplish this. Manual Dir-Sync follows the same process as the Dispatch program follows, so similar notation is used below.

Turn off all MTAs, if possible. Investigating the status of Dir-Sync will be much easier if no External Mail programs or MTAs are running during the manual Dir-Sync cycle.

Add or modify a user on each postoffice so you can follow the flow of Dir-Sync mail from the requestors to the server and back again.

1. On every postoffice involved in Dir-Sync, including the server postoffice, type the following command:
   reqmain -t -ddrive
   This step generates the outgoing Dir-Sync mail message and places it in the P1 directory.
2. On the computer that all the postoffices are mapped to, type the following command:
   external -0 -ddriverange
   NOTE: The -0 option is a zero, not the letter O.
   
   IMPORTANT: This step is required even if a gateway is used to deliver the mail because External is required to move the Dir-Sync message from the P1 directory to the outbound mailbag. Gateways do not examine the P1 directory, so Dir-Sync messages will be stranded and Dir-Sync will not take place without External.
   
   This step transfers the mail into the outbound queue for the Dir- Sync server. Use the Administrator program on each requestor postoffice to check the queue for the Dir-Sync server postoffice. There should be at least two $SYSTEM messages in the queue. One will be a status report, the other will have a subject line that looks like the following
   $SYSTEM ReqTx R=R# (was r#), S = S#, I = I# ## sent
   where:

   Message      | Description
   ---------------------------------------------------------------------
   
   ReqTx        | Indicates this is the requestor update to the
                | Dir-Sync server.
   R=R#         | The current requestor sync number from REQTRANS.GLB.
   (was r#)     | The old requestor sync number from REQCONF.GLB.
   S=S#         | The requestor's server sync number from REQCONF.GLB.
   I=I#         | The number of imports requested to date from
                | REQCONF.GLB.
   ## sent      | The number of address updates contained in the
                | attachment.
   
   						

   NOTE: If another External Mail program or MTA is still active, the mail may have been delivered before the queue was checked.
3. On the computer that all the postoffices are mapped to, type the following command:
   external -0 -ddriverange
   This invocation of the External Mail program actually delivers the outgoing Dir-Sync mail. If you are using a gateway as the MTA, type the appropriate gateway command to deliver the message.
4. On the Dir-Sync server, type the following command:
   nsda -s -ddrive
   Alternatively, you can enter the two commands that comprise NSDA - S:
   srvmain -r -ddrive
   
   srvmain -t -ddrive
   The SRVMAIN -R command receives the updates and places them in the MSTTRANS.GLB file. The SRVMAIN -T command reads the SRVCONF.GLB file, determines which updates need to be sent to each requestor postoffice, reads the MSTTRANS.GLB file to create the updates, generates a mail message back to each postoffice that sent a request to the server, and places this outgoing mail in the P1 directory.
5. On the computer that all the postoffices are mapped to, type the following command:
   external -0 -ddriverange
   This command again moves the mail to the outbound queues. The server's queues for the requestor postoffices should show the following $SYSTEM message
   $SYSTEM SrvTx R=R# S=S# (was s#) I = I# ## sent
   where:

   Message   | Description
   SrvTx     | Indicates this is the server's update to the requestor.
   R=R#      | The requestor sync number that was sent from the
             | requestor. This is an acknowledgment of the updates
             | received by the server.
   S=S#      | The new server sync number for the requestor.
   (was s#)  | The old server sync number for the requestor.
   I=I#      | The number of imports requested to date by the requestor.
   ## sent   | The number of updates sent back to the requestor.
   						

6. On the computer that all the postoffices are mapped to, type the following command:
   external -0 -ddriverange
   This delivers the updates to the requestor postoffices. If a gateway is used as the MTA, type the appropriate command to deliver the messages.
7. On every postoffice involved in Dir-Sync, type the following command:
   reqmain -r -ddrive
   
   import admin -ppassword -q -y -ddrive
   
   rebuild -f -ddrive
   The REQMAIN -R command receives the updates and moves them into the SRVTRANS.GLB file.
   
   The IMPORT command takes the SRVTRANS.GLB records and moves them into the temporary transaction files depending on what types of addresses they contain. Then the Import command moves the names into the .USR and .NME files. The -Q option tells Import to use the SRVTRANS.GLB file for the update, and the -Y option tells Import to run without asking for permission to continue.
   
   The REBUILD -F command takes the network names, the .NME files, and the .USR files to build the GAL and the GAL index file. The -F option is the same as the -Y option for import. This concludes the manual Dir-Sync cycle.
   
   It is important that you run all three commands on all postoffices participating in Dir-Sync, especially the Dir-Sync server, or errors may occur the next time Dispatch is run because of the Dir- Sync requests waiting to be processed.

WARNING: If you run the Rebuild utility when Mail users are active, Rebuild may fail with Error 203 because the GAL.NME file may be open for address resolution at the time Rebuild is run. If this error occurs under version 3.0 of the Rebuild utility, messages may be misdirected because the GALINDEX.GLB file will not match the correct GAL.NME file. With Mail 3.0, you should only perform manual Dir-Sync when users are not signed in to Mail. Rebuild 3.2 uses a different algorithm to delete the GAL files, and messages cannot be misdirected if Error 203 occurs.

THE DIR-SYNC PROTOCOL

Dir-Sync uses seven numbers in four files to control the updates sent to a requestor postoffice. Both the requestor and the server have sets of stored numbers. The requestor stores its copy of ReqSync (requestor sequence number, also known as ReqSeq, which is the cumulative total of all updates sent to the server) and SrvSync (server sequence number, also known as SrvSeq, which is the cumulative total of all updates received from the server) in the REQCONF.GLB file. The requestor also stores the ReqSync number in the REQTRANS.GLB file. This copy of ReqSync records the last update sent to the server, as well as any additional changes since the last update. The ReqSync number in the REQTRANS.GLB file must be equal to or greater than the ReqSync number stored in the REQCONF.GLB file, or Dir-Sync will ignore the updates in the REQTRANS.GLB file.

For the Dir-Sync server, the SRVCONF.GLB file stores Sync (the last known position in the MSTTRANS.GLB file), and copies of ReqSync and SrvSync for each requestor. Also, the MSTTRANS.GLB file stores sequence numbers for each transaction sent to the Dir-Sync server.

The following table summarizes the important Dir-Sync numbers: One consequence of the protocol (and a very easy test of Dir-Sync's status) is that the requestor's ReqSync number is always less than or equal to SrvSync. This is because the sequence numbers are cumulative totals: because more than one postoffice is (usually) involved in Dir- Sync, more updates will be received by the requestors than are sent to the server from any one requestor.

In explaining the protocol, the same terminology that describes the Dir-Sync flow will be used, starting at time T0:

T0:

The administrator adds, deletes, or modifies a user, and includes the change in Dir-Sync. The ReqSync stored in the REQTRANS.GLB file is incremented, and the entry is added to the REQTRANS.GLB file.

T1:

The REQMAIN program reads the ReqSync number in the REQCONF.GLB file and compares it to the numbers in the REQTRANS.GLB file. Any updates that have sequence numbers less than that stored in the REQCONF.GLB file are rejected as obsolete transactions. Any updates that have sequence numbers greater than that stored in the REQCONF.GLB file are placed in a mail message as an attachment, and the body of the message contains the Dir-Sync transaction. The exact format of the Dir-Sync message can be found in the Directory Synchronization with Foreign Mail Systems manual. T2:

On the server, the incoming message is read and the sequence numbers for the transactions are compared to the SRVCONF.GLB file's stored sequence numbers. Any transactions that are numbered less than the stored ReqSync number are rejected as old information, and the remaining transactions are added to the MSTTRANS.GLB file. The Sync number in the SRVCONF.GLB file is updated to reflect the new size of the MSTTRANS.GLB file. These steps are done for each Dir-Sync message sent to the server.

During the transmit stage of T2, the updates from the SrvSeq number (sent in the requestor's message) to the Sync number (at the end of the MSTTRANS.GLB file) are placed in an attachment, and the message is sent as a reply to the requestor. The text of the message contains the new SrvSync number (which is equal to the Sync number), and it also echoes back to the requestor the ReqSync number sent to the server. These new sequence numbers are stored in the SRVCONF.GLB file for the next Dir-Sync cycle.

The implication of this method is that only those requestors whose messages were received by the server by time T2 will receive an update. Requestors whose messages were delayed will not receive an update in the current Dir-Sync cycle, but will receive the updates in the next Dir-Sync cycle.

If the requestor sends a message with ReqSync = 0 and SrvSync = 0, the server assumes the requestor needs all address lists and generates an Import Reply message. You can request an import by selecting Config, Dir-Sync, Requestor, Import from the Administrator program. When the server receives an Import Request message, the process is slightly different. The server scans all of its current address lists, as well as the MSTTRANS.GLB file, and sends these addresses to the requestor. This has two major effects: 1) The Dir-Sync message sent to the requestor can be very large, and 2) Any existing address list on the requestor postoffice is replaced by the update.

NOTE: If the requestor Admin has created his or her own gateway address list, and then sets that gateway type to Yes for Dir-Sync and asks for an Import, the addresses will be lost when Dir-Sync replaces the old list with the new list.

T3:

The requestor processes the updates in much the same manner as the server processed its updates. The message is examined for the sequence numbers. If the ReqSeq number in the message matches the ReqSync number stored in the REQCONF.GLB file, the requestor knows the server received its updates and processed them correctly. At that point, the REQTRANS.GLB file is cleared of the old transactions and a dummy transaction is placed at the last position, in order to keep the ReqSync number current. The SrvSeq number is stored for the next Dir-Sync cycle, so the server will be informed that the update was received. The transactions are moved from the attachment to the SRVTRANS.GLB file for further processing by the Import and Rebuild utilities. These processes do not affect the sequence numbers, only the address lists, so they will not be covered further in this document.

This protocol is fault-tolerant: the information (either the updates themselves or the need for updates) is not changed until the acknowledgment is received. Thus the requestor does not remove updates until the server notifies it that the updates were received, and the server does not delete updates until the requestor confirms it has received them as well.

Foreign requestors work somewhat differently and are beyond the scope of this document. For more information, see the Directory Synchronization with Foreign Mail Systems manual.

DIR-SYNC UTILITIES

There are three utilities (DSSCHED.EXE, LISTDS.EXE, and LISTQ.EXE) included with this document that are designed to aid you in controlling Dir- Sync. These utilities are intended only for administrators and are not useful for any other user.

DSSCHED.EXE

Summary

The DSSCHED utility lists the PROCESS.GLB file and displays the various processes and the times when they are to be run. It can also save the times in a formatted file, and use that file to set the process times.

Syntax Where: Example Sample output: In this example, the file MYTIMES.TXT contains the following entries: The format of the output file, which is also used when DSSCHED is used to change the Dir-Sync times, is as follows: where <x> can be 1, 2, or 3 (corresponding to the notation for Dir- Sync processes T1, T2, and T3), <Day> is the day of the week (in the format of Sun, Mon, Tue, Wed, Thu, Fri, or Sat), and <HH>:<MM> is the hour and the minute for the process (based on a 24-hour clock, thus 11 P.M. is 23:00). Only the Dir-Sync server will accept T2 times; requestors will ignore these times if they are in the file.

LISTDS.EXE

Summary

The LISTDS utility displays the server configuration file (SRVCONF.GLB) and the requestor configuration file (REQCONF.GLB). It can also reset the REQCONF.GLB file for the requestors, but not for the Dir-Sync server because this option is not valid for the server.

Syntax Where: Example 1 Sample output for the SRVCONF.GLB file: The various fields (as described in "The Dir-Sync Protocol" section of this document) are as follows: Example 2 Sample output for the REQCONF.GLB file:

LISTQ.EXE

The LISTQ utility shows the Dir-Sync queue files. This utility will show any file in the GLB directory that ends with TRANS, as well as the RESYNC.GLB file (created with the IMPORT.EXE utility). View these files to see the effects of adding users, to monitor the inclusion of names, and to pinpoint problems with the queue files.

Syntax The -T option displays the date stamp for the entry. Dir-Sync uses the date stamp to know when to purge transactions from the MSTTRANS.GLB file. Normally, examining the date stamp is not helpful, but it is in LISTQ for compatibility with earlier versions of the utility.

The -C option calculates the checksum for each Dir-Sync transaction in the file and compares it to the stored checksum. If they do not match, an error message is displayed. This option can be helpful when you are looking for corrupt transactions in the file, but mainly it is in LISTQ for compatibility with earlier versions of the utility.

Example Sample output: The various fields in the transaction queues are as follows:

TROUBLESHOOTING DIR-SYNC

Troubleshooting Dir-Sync begins with examining the DIRSYNC.LOG and DISPATCH.LOG files. The DIRSYNC.LOG file is located on each postoffice and reflects the status of Dir-Sync on that postoffice only. The DISPATCH.LOG file is located only on the Dir-Sync server and reflects the status of all postoffices that have sent updates to the server.

In general, the log files can point you to any problems with Dir-Sync. Microsoft Product Support Services will ask you to send them the log files, so it is best to enable the DISPATCH.LOG file when you suspect a problem with Dir-Sync. Several problems can arise with Dir-Sync; the following list of common problems is designed to help you quickly troubleshoot and fix the problem.

PROBLEM 1: THE GAL ON A POSTOFFICE DOES NOT HAVE ALL OTHER POSTOFFICE ADDRESS LISTS

When updates are not being added to the GAL, you must troubleshoot the Dir-Sync process to determine where the problem lies. Follow the troubleshooting guidelines below to quickly isolate the problem. Be sure to stop after each procedure to determine if the problem has been solved. There is no need to do more work than necessary!

1. Verify that no problems exist with the general Dir-Sync process
   
   Open the Administrator accounts on the server postoffice and the requestor postoffices to see if any error messages have been sent to you. If an error message stating "requestor not registered" is present, verify that the server is registered with the requestor and vice versa. Other error messages may indicate a temporary condition that will be corrected by continuing with these troubleshooting steps.
   
   Enable the log files for Dir-Sync if this is not done already. Examine the CENTRAL.LOG (on the Dir-Sync server only) and DIRSYNC.LOG files for the status of Dir-Sync on all the requestor postoffices. Verify that each postoffice is participating in Dir- Sync, that updates are being sent and received, and that the GAL is being rebuilt. If these steps are not occurring on a postoffice, verify that Dispatch can reach the postoffice and that the External Mail program or MTA can deliver mail to it from the server postoffice. Examine the DISPATCH.LOG file to verify that NSDA -RT and NSDA -RR complete successfully on the requestors, and that NSDA -S completes successfully on the server. Verify that the time for the requestor's NSDA -RT is before the server's NSDA -S, and that the requestor's NSDA -RR is after the server's NSDA -S. Be sure to allow time for the External Mail program or MTA to transfer the Dir-Sync messages between the requestors and the server.
   
   Determine which postoffices do not have the full GAL:
   1. If a single requestor postoffice does not have all other postoffice address lists, run the Administrator program on that postoffice and select Config, Dir-Sync, Requestor, Import to have the server send down the complete list of addresses. Note that this replaces all address lists on the requestor with the ones from the server, including gateway lists. If the local administrator has created a special Fax address list and the server has its own Fax list, and the requestor last asked for Fax updates, then the requestor's Fax list will be deleted and will be replaced by the server's list.
   2. If the server does not have the complete address list, determine which requestor postoffice is not in the server's list. From the Administrator program on that requestor postoffice, select Config, Dir-Sync, Requestor, Export to send the address list to the server.
   3. If the requestors don't have a single postoffice's address list, run the Administrator program on the missing postoffice and select Config, Dir-Sync, Requestor, Export to send the address list to the Dir-Sync server.
   4. On all postoffices, delete these temporary files if they are present in the GLB directory: IGWTRANS.GLB, INMETRAN.GLB, IUSRTRAN.GLB, SRVUPDS.GLB, REQUPDS.GLB, and any SORTxxxx files, where xxxx is a number. Verify that SRVTRANS.GLB, GWTRANS.GLB, NMETRANS.GLB, and USRTRANS.GLB are zero bytes in length. If not, truncate these files by deleting the file(s) and running the following MS-DOS command
      type nul > filename
      where filename is the name of the file to be truncated.
   Wait for Dispatch to run the Dir-Sync cycle. If this does not clear up the problem, the sync numbers may be invalid.
   
   
2. Reset the requestor sync numbers.
   
   If step 1 is unsuccessful, one of the requestor postoffices may be out of sync. Examine the ReqSync numbers on the requestor by running LISTDS -R and LISTQ -FREQTRANS. If the ReqSync number in the REQCONF.GLB file is greater than the one in the REQTRANS.GLB file, reset the requestor's ReqSync numbers by performing the following steps:
   1. To reset the sync numbers on the requestor postoffices, generate the RESYNC.GLB file. On the server postoffice, run the following command:
      import admin -ppassword -s -ddrive
      This will create a file in the server postoffice's GLB directory called RESYNC.GLB.
   2. Copy this RESYNC.GLB file to the postoffices that do not have the full GAL, and delete it from the server postoffice (otherwise, Import will generate an error message when it tries to process the file on the server).
   3. On the requestor postoffices that contain the RESYNC.GLB file, run the following commands:
      import admin -ppassword -q -y -ddrive
      rebuild -f -ddrive
      Import looks for the RESYNC.GLB file and processes it before any other Dir-Sync mail. The RESYNC.GLB file contains new sync numbers for the requestor that reflect what the server has recorded in the SRVCONF.GLB file. This will clear any sync number conflicts.
   Wait for the Dispatch program to run the Dir-Sync cycle. The sync numbers should be correct now and Dir-Sync will proceed on that postoffice. Occasionally, the RESYNC.GLB file will not reset the sync numbers. If this occurs, create a zero-length REQTRANS.GLB file by typing the following MS-DOS command in the GLB directory:
   type nul > reqtrans.glb
   Regenerate the RESYNC.GLB file, move it to the requestor's GLB directory, and wait an additional Dir-Sync cycle. If this step still does not correct the problem, you may need to reset the Dir- Sync files.
   
   
3. Reset the Dir-Sync files.
   
   If the RESYNC.GLB file is unsuccessful in resetting the ReqSync numbers, use the LISTDS utility to reset the REQCONF.GLB file by following the steps below. These steps collectively are called a "local reset."
   
   CAUTION: Do not perform this procedure on the Dir-Sync server--you will not be able to recover from the damage to the server's REQCONF.GLB file! If the Dir-Sync server (acting as a requestor) is not being propagated, proceed to the global reset section below.
   1. Delete the requestor record. From the Administrator program, select Config, Dir-Sync, Server, Requestors, Delete, and select the requestor postoffice.
   2. Re-create the same requestor postoffice. This will reset that postoffice's record in the SRVCONF.GLB file. On the requestor:
   3. Reset the REQCONF.GLB file by running the following command:
      listds admin -ppassword -ddrive -r -z
   4. Verify that the REQCONF.GLB file is reset by running the following command:
      listds admin -ppassword -ddrive -r
      The ReqSync and SrvSync numbers should both be zero (0).
   5. Reset the types of names propagated by Dir-Sync by selecting Config, Dir-Sync, Requestor, Types. This step is necessary only if gateways are installed and gateway names are included in Dir-Sync.
      
      If you use an older version of the LISTDS utility, the Dir-Sync server's name will be reset as well. If this is so, reregister the Dir-Sync server by selecting Config, Dir-Sync, Requestor, Registration.
   6. Select Config, Dir-Sync, Requestor, Export to reexport the address list. If confirmation is requested, respond Yes.
   7. Wait for the Dispatch program to carry out the Dir-Sync cycle.
   If the server postoffice must be reset, or if Dir-Sync is not working for all postoffices involved, a "global reset" may be needed. This should only be done after the previous troubleshooting steps have been performed, and only after consultation with Microsoft Product Support Services. This procedure entails a substantial amount of work on the Dir-Sync administrator's part that may be unnecessary if one of the above procedures fixes the problem.
   
   On the server postoffice:
   
   
   1. From the Administrator program, select Config, Dir-Sync, Options, No, and reply Yes to the warning. This step deletes the SRVCONF.GLB and MSTTRANS.GLB files from the server. Once you complete this step, you must complete all the other steps below.
   2. Reset the REQCONF.GLB file on the Dir-Sync server by running the following command:
      listds admin -ppassword -dm -r -z
   3. Verify that the REQCONF.GLB file is reset properly by running the following command:
      listds admin -ppassword -dm -r
      The ReqSync and SrvSync numbers should both be zero (0).
   4. Enable the Dir-Sync server by running the Administrator program and selecting Config, Dir-Sync, Options, Yes.
   5. Select Config, Dir-Sync, Server, Requestors, Create to redefine all the requestors.
   6. Select Config, Dir-Sync, Requestor, Types to reset the types of names propagated by Dir-Sync. This step is only necessary if gateways are installed and gateway names are included in Dir- Sync.
   7. Select Config, Dir-Sync, Requestor, Export to send the list to the other postoffices. On each requestor postoffice:
      
      
   8. Reset the REQCONF.GLB file by running the following command:
      listds admin -ppassword -dm -r -z
   9. Verify that the REQCONF.GLB file is reset properly by running the following command:
      listds admin -ppassword -dm -r
      The ReqSync and SrvSync numbers should both be zero (0).
   10. Select Config, Dir-Sync, Requestor, Types to reset the types of names propagated by Dir-Sync. This step is only necessary if gateways are installed and gateway names are included in Dir- Sync.
       
       If you use an older version of the LISTDS utility, the Dir-Sync server's name will be reset as well. If this is so, reregister the Dir-Sync server by selecting Config, Dir-Sync, Requestor, Registration.
   11. Select Config, Dir-Sync, Requestor, Export, to send the list to the other postoffices.

Now all the Dir-Sync files will be reset. Wait for Dispatch to complete the Dir-Sync cycle.

PROBLEM 2: NAMES IN GAL WHEN ADMINISTRATOR HAS SPECIFIED NOT TO INCLUDE THEM

The most common cause of this problem is when External-Admin, Export is selected from the Administrator program. This command places a complete address list, regardless of any Dir-Sync settings, in the other postoffice's .USR file for that postoffice. Dir-Sync reads this file as part of the T3 step and the names will be in the GAL. To restore the GAL, go to the postoffice whose names are incorrect, run the Administrator program and select Config, Dir-Sync, Requestor, Export. After the next Dir-Sync cycle, the GAL will contain the correct names. If this procedure is unsuccessful, perform a Config, Dir-Sync, Requestor, Import on the requestors that have the bad address list.

PROBLEM 3: FATAL ERROR 161: SERVER CONFIGURATION BUSY ON A REQUESTOR POSTOFFICE

This error occurs when a server postoffice was turned into a requestor while Dir-Sync mail was still waiting to be processed, or when a requestor sends Dir-Sync updates to another requestor. Although the message states this is a fatal error, the Dir-Sync process is fine.

To clear the error from the requestor postoffice:

1. Set the SYSTEM.MBG file to zero bytes by running the following command:
   type nul > m:\mbg\system.mbg
2. Clear the SYSTEM.KEY file by running the DEBUG utility:
   debug m:\key\system.key
   At the hyphen (-) prompt, type the following and press ENTER after each line:
   -F, 100,L 230, 0
   -W
   -Q

This may not be sufficient to clear the problem if the requestor was once a server. The PROCESS.GLB file may contain a deferred server process time. Check the DIRSYNC.LOG file on the requestor postoffice for an error of "NSDA -S missed its run window." If this occurs, reset the PROCESS.GLB file by running the DSSCHED utility: Examine FILE.TXT and delete any T2 entries, then import the file back to the postoffice:

PROBLEM 4: ERROR 203: GAL REBUILD PROBLEM ACCESSING FILES

This error occurs when the GAL.NME or GALINDEX.GLB file is locked open and the Rebuild utility attempts to replace it with the updated GAL. Unlock these files and run the Rebuild utility to restore the GAL. This must be done as soon as the error occurs; otherwise, one of the files may be replaced but not the other, which will lead to misdirected mail.

One cause of the GAL.NME file being held open is that the Windows client is running with MSSFS.DLL version 4046 through 4061. These versions of MSSFS.DLL resolved a problem with duplicate names in the Personal Address Book; however, this fix resulted in the GAL.NME file being held open after sending mail to an external user. Version 4062 of the DLL fixes this problem. To find the version number, run MSD 2.0 or later and press ALT+F, Find File, and search the Windows SYSTEM subdirectory for the MSSFS.DLL file. The version number is displayed as 3.2.0.xxxx.

Because Mail can find older versions of the DLL and use them, this problem can reoccur. To resolve the problem of MSSFS.DLL holding open the GAL.NME file, all Windows clients must have MSSFS.DLL version 4062 placed in their Windows SYSTEM subdirectory and all other versions of MSSFS.DLL must be deleted from the workstation.

PROBLEM 5: DIR-SYNC REPORTS "REQUESTOR NOT REGISTERED," YET THE REQUESTOR IS THE DIR-SYNC SERVER

This problem occurs when version 3.2 or earlier of the Administrator program corrupts the SRVCONF.GLB file. This corruption occurs only on workstations with certain network cards (notably, NE2000's and EtherExpress(TM) 16's). Another symptom of this problem is when the SRVCONF.GLB file does not grow by 1K after another requestor is added.

Versions 3.2.2 and later of the Administrator program do not corrupt the file, but they also do not fix the file. To add the server as a requestor, follow these steps:

1. Go to another postoffice, run the Administrator program, and make the postoffice a temporary Dir-Sync server by selecting Config, Dir-Sync, Options, Yes.
2. Exit the Administrator program and go to the real Dir-Sync server. Copy the SRVCONF.GLB file from the real Dir-Sync server's GLB directory to the temporary Dir-Sync server's GLB directory.
3. Run the Administrator program again and register the real Dir-Sync server with the temporary Dir-Sync server, by selecting Config, Dir-Sync, Requestor, Registration.
4. Exit the Administrator program and copy the SRVCONF.GLB file from the temporary server to the real Dir-Sync server's GLB directory.
5. Run the Administrator program again on the temporary server and make it a requestor, then register the real Dir-Sync server on it.
6. Let Dir-Sync cycle.

PROBLEM 6: ERRORS 157 AND 161 TOGETHER

This error occurs only with certain network cards and network protocols, most often with EtherExpress 16's with the Ethernet_II protocol. This problem relates to corruption in the SRVCONF.GLB file caused by version 3.0.4 or earlier of the SRVMAIN utility. To verify the problem, run the LISTDS utility: If the SRVCONF.GLB file is corrupt, LISTDS will alert you to the problem. At this point, call Microsoft Product Support Services for assistance because the circumstances of the corruption must be identified and eliminated before Dir-Sync can be performed successfully.

PROBLEM 7: ERROR 133 INVALID SERVER REQUEST

This error occurs when the server is running the NSDA -S process at time T2, but there is a T3 ReqTx message waiting to be processed. The most likely cause of this problem is an incomplete manual Dir-Sync cycle. The second most likely cause is incorrect times for T1 and T2. To resolve the problem, you must reset the SYSTEM.KEY and SYSTEM.MBG files as described in Problem 3 above.

PROBLEM 8: ERROR 150

This problem can occur for several reasons: corrupt files, lack of disk space, or improper access rights to the postoffice.

To determine if corrupt files are the cause, ensure that the USRTRANS.GLB, NMETRANS.GLB, and GWTRANS.GLB files in the GLB directory are zero (0) bytes in length. If any are not zero bytes, run the following MS-DOS command to set them to zero bytes: Ensure also that the IUSRTRAN.GLB, INMETRAN.GLB, IGWTRANS.GLB, REQUPDS.GLB, and SRVUPDS.GLB files are not present in the GLB directory. These are temporary files that should not normally exist if Dir-Sync is not active on that postoffice.

Space problems can be harder to find, especially on Novell(R) networks, because the amount of free space is misleading. Novell saves files that are deleted and this space is not reported as used, but REQMAIN can return the Error 150 when the "true" amount of free space is too low. As a rule of thumb, Dir-Sync can use up to three times the amount of disk space than what the update size is, for all the temporary files that are created during the REQMAIN process. To recover enough space for REQMAIN, run the PURGE command on the Novell server and permanently remove all deleted files.

Proper access rights for the account that Dispatch uses to access servers must allow for Read, Write, Create, and Delete rights on all directories and subdirectories of the postoffice. For Novell servers, the rights are RWCEM; for UNIX, the permissions on the entire directory structure should be world, group, and user rwx.

PROBLEM 9: DIR-SYNC SERVER RESTORED FROM BACKUP COPY

When the Dir-Sync server is restored from a backup copy that does not contain the latest Dir-Sync cycle, problems arise because the SRVCONF.GLB file (where the requestor's status is stored on the server) does not match the requestor's stored information (in the REQCONF.GLB file). Worse still, the sync numbers in SRVCONF.GLB are less than the sync numbers on the requestors, and the MSTTRANS.GLB file does not have the updates that occurred later than the backup. When SRVMAIN -R is processed, the current updates from the requestors are processed successfully; however, when SRVMAIN -T occurs, the server attempts to send updates numbered from SrvSync to Sync, and these updates don't exist in the MSTTRANS.GLB file. Thus the server reports two error messages, Fatal 138 and Fatal 139, that together report the missing sync number. Normally, a missing sync number is not a problem because the requestor's SrvSync number is less than the lowest position in the MSTTRANS.GLB file, and the server can send the updates available. With the requestor's SrvSync number greater than the maximum in the MSTTRANS.GLB file, the server cannot send any updates to the requestor, and so the requestor receives no updates until its SrvSync number is less than the maximum in the MSTTRANS.GLB file. If the disparity in numbers is large (for example, the backup is an old one), address updates will not be received by the requestor for a long time, and when they are received, there will be missing transactions that were never sent.

To update Dir-Sync with the new configuration, run the Administrator program and select Config, Dir-Sync, Requestor, Export on each requestor postoffice. Let Dir-Sync cycle to completion, then run the Import utility to generate a RESYNC.GLB file by running the following MS-DOS command: Then copy the RESYNC.GLB file from the Dir-Sync server's GLB directory to all the requestors' GLB directories, delete the RESYNC.GLB file from the server's GLB directory, and run Import to process the updates: This will update the address lists and update the REQTRANS.GLB and REQCONF.GLB Dir-Sync configuration files, and Dir-Sync will operate properly.

APPENDIX: .INI FILE SETTINGS FOR DISPATCH AND EXTERNAL

The DISPATCH.INI file can contain the following: The EXTERNAL.INI file settings can contain the following:

GLOSSARY

TO OBTAIN THIS DOCUMENT

The following file is available for download from the Microsoft Download Center:
For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base: Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.