PC DirSync: WA0725: Directory Synchronization (Dir-Sync)

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.

NOTE: This step is not required for the Dir-Sync server; it is automatically registered when you perform step 2 above.

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

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.

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

                      TYPICAL DIR-SYNC SCENARIOS
                      ==========================

   IMPORTANT: When a gateway is used to transfer the Dir-Sync
   messages, the External Mail program must be run in order to
   properly process the Dir-Sync messages. See "The Dir-Sync Process"
   section later in this Application Note for the technical reasons
   why the External Mail program is needed.

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.

  Server           Requestor 1
      \\              //
       \\            //
        \\          //
         ------------
         | External |
         ---------------
            | Dispatch |
            ------------
         //            \\
        //              \\
       //                \\
   Requestor 2      Requestor 3

   dispatch -dmp -i"external -dmp -a"

   dispatch /instancename=Normal

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

   Server           Requestor 1
      \\              //
       \\            //
        \\          //
         ------------
         | External |
         ---------------
            | Dispatch |
            ------------
          /            \
         /              \
        /                \
   Requestor 2      Requestor 3

   dispatch -dmn -f -i"external -dmn -fop -a"

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:

   dispatch /instancename=Dynamic

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.

  Server           Requestor 1
      \\              //              ______
       \\            //              /modem \
        \\          //              /        \
         --------------            /      --------------
         | External 1 |           /       | External 2 |
         -----------------       /        -----------------
            | Dispatch 1 |      /            | Dispatch 2 |
            --------------     /             --------------
                     \        /             //            \\
                      \______/             //              \\
                       modem             //                \\
                                      Requestor 2      Requestor 3

   dispatch -dmn -i"external -dmn [<any modem specific options>]"

   dispatch /instancename=Modem

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.

  Server           Requestor 1
      \\              //
       \\            //
        \\          //
         --------------                  --------------
         | External 1 |                  | External 2 |
         -----------------            -----------------
            | Dispatch 1 |            | Dispatch 2 |
            --------------\\          --------------
                           \\        //            \\
                            \\      //              \\
                             \\    //                \\
                           Requestor 2            Requestor 3

   dispatch -dmo -i"external -dmo -a"

   dispatch -dm -i"external -dmn -a"

   dispatch /instancename=Indirect1

   dispatch /instancename=Indirect2


                      GATEWAY NAMES AND DIR-SYNC
                      ==========================

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.

• 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 -p<password> -e -f<filename>
  

  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.

• 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 -p<password> -x -g<gatewaytype> -f<filename>
  

  where -X specifies that Import is to extract addresses and -G specifies that gateway names defined under the <gatewaytype> are 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 command(s), 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
  

                      MOVING THE DIR-SYNC SERVER
                      ==========================

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:

   a. Run the following MS-DOS command in the MBG directory:

            type nul > system.mbg
   
      b. 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
               ===============================================
   
   

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.

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

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.

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:

Command                            | Explanation

No TZ setting                      | Times are adjusted by 1 hour at
                                   | both the start and the end of
                                   | DST.

SET TZ=<xxxnn>DST                  | Times are adjusted by 1 hour at
                                   | both the start and the end of
                                   | DST.


                         THE DIR-SYNC PROCESS
                         ====================

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

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.

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/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
                               ================
    
    

   IMPORTANT: Manual Dir-Sync is intended as a debugging and
   verification procedure when problems with Dir-Sync are encountered
   or suspected, and NOT as the primary means for performing Dir-
   Sync. There are several internal error messages that are processed
   only by Dispatch, and a manual Dir-Sync cycle does not pass these
   error messages to the Administrator program or to MS-DOS.

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 -d<drive>
   

   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 -d<driverange>
   

   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.

      external -0 -d<driverange>

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.

      nsda -s -d<drive>

Alternatively, you can enter the two commands that comprise NSDA - S:

      srvmain -r -d<drive>
      srvmain -t -d<drive>

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.

      external -0 -d<driverange>

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.

I=I#      | The number of imports requested to date by the requestor.
## sent   | The number of updates sent back to the requestor.

      external -0 -d<driverange>

This delivers the updates to the requestor postoffices. If a gateway is used as the MTA, type the appropriate command to deliver the messages.

      reqmain -r -d<drive>
      import admin -p<password> -q -y -d<drive>
      rebuild -f -d<drive>

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

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:

Sync number      | Location             |Description

ReqSync          | Requestor:           | Cumulative total of all
                 | REQCONF.GLB          | updates sent to the server.
SrvSync          | Requestor:           | Cumulative total of all
                 | REQCONF.GLB          | updates received from the
                 |                      | server.
Transaction sync | Requestor:           | Individual sync numbers for
numbers          | REQTRANS.GLB         | each transaction waiting to
                 |                      | be sent to the server.
                 |                      | Always equal to or greater
                 |                      | than ReqSync.
Sync             | Server: SRVCONF.GLB  | Last known record position
                 |                      | in the MSTTRANS.GLB file.
ReqSync          | Server: SRVCONF.GLB  | Server copy of the
                 |                      | requestor's number of
                 |                      | updates. Used to
                 |                      | determine if the update
                 |                      | from the requestor is
                 |                      | valid.
SrvSync          | Server: SRVCONF.GLB  | Server copy of the
                 |                      | requestor's server updates.
                 |                      | Used as acknowledgment of
                 |                      | requestor's receipt of
                 |                      | updates.
Transaction sync | Server:              | Individual sync numbers for
numbers          | MSTTRANS.GLB         | each transaction. Used to
                 |                      | control which transactions
                 |                      | are sent to the requestors.

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.

   NOTE: If you delete and then re-create the REQTRANS.GLB file, you
   must reset Dir-Sync on that postoffice so that the updates will be
   accepted. On a requestor, this is not difficult because the Dir-
   Sync utilities will reset the REQCONF.GLB file; however, for a
   server, this problem is very difficult to correct. In this case,
   it is best to call Microsoft Product Support Services for
   assistance.

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

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 Application Note. For more information, see the "Directory Synchronization with Foreign Mail Systems" manual.

                          DIR-SYNC UTILITIES
                          ==================

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

 dssched admin -p<password> -d<drive> [-i<file>] [-x<file>] [-v] [-?]

   Parameter    | Description

   admin        | The administrator for the postoffice (required).
   -P<password> | The administrator's password (required).
   -D<drive>    | The postoffice drive. This can be a drive letter or
                | a full path to the database. The default value is
                | drive M.
   -I<file>     | Import the times in <file> to set the process
                | times.
   -X<file>     | Export the process times to <file>.
   -V           | Verbose mode (displays additional information to
                | the console).
   -?           | Displays the Help and About screens.

   dssched admin -ppassword -xmytimes.txt

   Microsoft Mail for the PC v3.2, DSSched v3.2
   (C) Microsoft Corp. 1993-1994. All rights reserved

   Examining POLYNOMIAL/MONTGOMERY Dir-Sync process times

      Record number 1
   Requestor sends updates (Dispatch runs NSDA -RT)
   Current time to run NSDA -RT: Sat Feb 26 13:45:00 1994

      Record number 2
   Requestor processes updates (Dispatch runs NSDA -RR)
   Current time to run NSDA -RR: Mon Feb 28 15:00:00 1994

      Record number 3
   Server process (Dispatch runs NSDA -S)
   Current time to run NSDA -S: Mon Feb 28 14:55:00 1994

   T1 Sat 13:45
   T3 Mon 15:00
   T2 Mon 14:55

   T<x> <Day> <HH>:<MM>

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

   listds admin -p<password> -d<drive> [-s or -r [-z]] [-v] [-?]

Parameter    | Description

admin        | The Administrator account for the postoffice
             | (required).

-D<drive>    | The postoffice location. This can be a drive letter
             | or a full path to the database. The default value is
             | drive M.
-S           | Show the contents of SRVCONF.GLB.
-R           | Show the contents of REQCONF.GLB.
-Z           | Reset the configuration file. This functions only for
             | the requestor's postoffice.
   -V        | Verbose mode (displays additional information).
   -?        | Display the Help screen.

Example 1

   listds admin -ppassword -s

   Microsoft Mail for the PC v3.2, ListDS v3.2
   (C) Microsoft Corp. 1993-1994. All rights reserved

   Examining POLYNOMIAL/MONTGOMERY Server Configuration Record
   Highest SrvSync is 80, Current Dirsync Cycle is 11

        Server Requestor Record #1
   Requestor name: PCM:POLYNOMIAL/MONTGOMERY
   ReqSync = 17, SrvSync = 80, Last Cycle = 11
   Last update received Fri Feb 18 13:11:58 1994

        Server Requestor Record #2
   Requestor name: PCM:POLYNOMIAL/NOVEMBER
   ReqSync = 18, SrvSync = 0, Last Cycle = 9
   Last update received Thu Feb 17 08:52:45 1994

        Server Requestor Record #3
   Requestor name: PCM:POLYNOMIAL/OCTOBER
   ReqSync = 12, SrvSync = 71, Last Cycle = 9
   Last update received Thu Feb 17 08:52:45 1994

   Field              | Description

   Highest SrvSync    | The current maximum SrvSync. This is the
                      | number for the last entry in the
                      | MSTTRANS.GLB file.
   Current Cycle      | The current Dir-Sync cycle number.
   PCM:xx/xx          | The requestor postoffice for this record.
   ReqSync            | The requestor's synchronization number.
   SrvSync            | The requestor's current server
                      | synchronization number.
   Last Cycle         | The last Dir-Sync cycle that requestor
                      | participated in.

   listds admin -ppassword -r

   Microsoft Mail for the PC v3.2, ListDS v3.2.0.2
   (C) Microsoft Corp. 1993-1994. All rights reserved

   Examining POLYNOMIAL/MONTGOMERY Requestor Configuration Record

   Dir-Sync Server: POLYNOMIAL/MONTGOMERY
   ReqSync = 17, SrvSync = 80

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

   listq admin -p<password> -d<drive> -f<file> [-t] [-c] [-?]

Parameter    | Description

admin        | The Administrator account for the postoffice
             | (required).

-D<drive>    | The postoffice location. This can be a drive letter
             | or a full path to the database. The default value is
             | drive M.
-F<file>     | Dump the specified file.
-T           | Display the transaction date stamp.
-C           | Calculate and verify transaction checksum.
-?           | Display the Help screen.

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

   listq admin -ppassword -c -t -freqtrans

   Microsoft Mail for the PC v3.2, LISTQ v3.2.0.1
   (C) Microsoft Corp. 1993-1994. All rights reserved

   Examining POLYNOMIAL/MONTGOMERY Dirsync transaction file: REQTRANS

   Checking CRC...

   CRC  Date stamp               Sync#  Transaction
   FB16 Thu Apr 07 12:13:52 1994 000001 R PCM:POLYNOMIAL/MONTGOMERY
   B4A2 Thu Apr 07 12:13:52 1994 000002 A able is he who knows his
   limit<tab>PCM:POLYNOMIAL/MONTGOMERY/able
   2FC1 Thu Apr 07 12:13:52 1994 000003 A apple
   <tab>PCM:POLYNOMIAL/MONTGOMERY/apple
   D2CD Thu Apr 07 12:13:52 1994 000004 A Paul
   <tab>PCM:POLYNOMIAL/MONTGOMERY/paul
   6D23 Thu Apr 07 12:13:52 1994 000005 A Bryan
   <tab>PCM:POLYNOMIAL/MONTGOMERY/bryan
   16F9 Thu Apr 07 12:13:52 1994 000006 A Mark
   <tab>PCM:POLYNOMIAL/MONTGOMERY/mark

   Field          | Description

   CRC            | The checksum value for the entry, as computed by
                  | LISTQ.
   Date stamp     | The date when the entry was placed in the file.
   Sync #         | The transaction's internal counter.
   Transaction    | The transaction. The format is that of an Import
                  | file, which is described in the "Import Utility"
                  | section of the Microsoft Mail "Administrator's
                  | Guide."


                       TROUBLESHOOTING DIR-SYNC
                       ========================

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.

  NOTE: Because Dir-Sync is time and network dependent, it is
  important that you do not assume that Dir-Sync has failed if a
  requestor misses a cycle. Because Dir-Sync is fault-tolerant, any
  updates that are missed will be recovered in the next Dir-Sync
  cycle. You should only take preventative action if a problem
  persists across several Dir-Sync cycles.

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:

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

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

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

   d. 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 SORT<xxxx>
         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:

   a. To reset the sync numbers on the requestor postoffices,

         generate the RESYNC.GLB file. On the server postoffice, run the
         following command:
   

            import admin -p<password> -s -d<drive>
   
         This will create a file in the server postoffice's GLB
         directory called RESYNC.GLB.
   
      b. 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).
   
      c. On the requestor postoffices that contain the RESYNC.GLB file,
         run the following commands:
   
            import admin -p<password> -q -y -d<drive>
            rebuild -f -d<drive>
   
         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.

   On the server:

   a. Delete the requestor record. From the Administrator program,

         select Config, Dir-Sync, Server, Requestors, Delete, and select
         the requestor postoffice.
   

   b. Re-create the same requestor postoffice. This will reset that

         postoffice's record in the SRVCONF.GLB file.
   

   On the requestor:

   c. Reset the REQCONF.GLB file by running the following command:

            listds admin -p<password> -d<drive> -r -z
   
      d. Verify that the REQCONF.GLB file is reset by running the
         following command:
   
            listds admin -p<password> -d<drive> -r
   
         The ReqSync and SrvSync numbers should both be zero (0).
   
      e. 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.
   
      f. Select Config, Dir-Sync, Requestor, Export to reexport the
         address list. If confirmation is requested, respond Yes.
   
      g. 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:
   
      a. 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.
   
      b. Reset the REQCONF.GLB file on the Dir-Sync server by running
         the following command:
   
            listds admin -p<password> -dm -r -z
   
      c. Verify that the REQCONF.GLB file is reset properly by running
         the following command:
   
            listds admin -p<password> -dm -r
   
          The ReqSync and SrvSync numbers should both be zero (0).
   
      d. Enable the Dir-Sync server by running the Administrator program
         and selecting Config, Dir-Sync, Options, Yes.
   
      e. Select Config, Dir-Sync, Server, Requestors, Create to redefine
         all the requestors.
   
      f. 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.
   
      g. Select Config, Dir-Sync, Requestor, Export to send the list to
         the other postoffices.
   
      On each requestor postoffice:
   
      h. Reset the REQCONF.GLB file by running the following command:
   
            listds admin -p<password> -dm -r -z
   
      i. Verify that the REQCONF.GLB file is reset properly by running
         the following command:
   
            listds admin -p<password> -dm -r
   
         The ReqSync and SrvSync numbers should both be zero (0).
   
      j. 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.
   
      k. Select Config, Dir-Sync, Requestor, Export, to send the list to
         the other postoffices.
   
   

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
   

   dssched admin -p<password> -dm -xfile.txt

   dssched admin -p<password> -dm -ifile.txt

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:

   listds admin -p<password> -dm -s

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:

   type nul > <filename>

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:

   import admin -p<password> -ddrive -s -y

   import admin -p<password> -ddrive -q -y

        APPENDIX: .INI FILE SETTINGS FOR DISPATCH AND EXTERNAL
        =======================================================

[Dispatch] ; Global settings for all instances DriveHomePO=m ; Home postoffice is assumed on drive M. IdleTime=1800 ; Let dispatch cycle every 1800 seconds = 30 minutes.

LogSession    ; Keep track of Dir-Sync's progress.

DrivesDirectPO=mp   ; Use drive connections M through P.

[Dispatch-Dynamic] DrivesDirectPO=mn ; Get the two static connections. ; Use ONE of these options, not both! DrivesDynamic ; Needs the Dynadmin table set up for the postoffices. ; ; or use DrivesUNC=\\server3\po3\maildata ; Assumes postoffices are in the MAILDATA directory. (Continues from previous line) DrivesNovell=server4/volume:\maildata ; Example of a Novell dynamic connection. (Continues from previous line) IdleProcess="external /instancename=Dynamic"

[Dispatch-Modem] ; Note that both Dispatches use the same instance. DrivesDirectPO=mn IdleProcess="external /instancename=Modem"

[Dispatch-Indirect1] ; Note also that each postoffice is touched by only ONE copy of Dispatch, not two. (Continues from previous line) DrivesDirectPO=mn IdleProcess="external /instancename=Indirect1"

[Dispatch-Indirect2] ; Note the only difference between the indirect instances is which instance of External is run. (Continues from previous line) DrivesDirectPO=mn IdleProcess="external /instancename=Indirect2"

The EXTERNAL.INI file settings can contain the following:

[External] ; Global settings for External

DriveHomePO=m    ; Assumes the home postoffice is on drive M.

;              These two are OPTIONAL.
LogSession          ; Log external.
LogReceive          ; Save received mail.
LogSent             ; Save sent mail.

CommDisable         ; Don't need the modem.
DrivesDirectPO=mp   ; Set up for drives M through P.

CommDisable         ; Don't need the modem.
DrivesDirectPO=mn   ; Only two static connections.

DrivesDynamic=op    ; Needs the Dynadmin table set up first.

[External-Modem]

DrivesDirectPO=mn        ; Two drives needed in this example.
CommScript=scriptname    ; Script file for External.

[External-Indirect1]

DrivesDirectPO=mp   ; Note that we need three drive letters here.
CommDisable         ; We aren't using the modem.

DrivesDirectPO=mn   ; Only two drives needed.
CommDisable         ; We aren't using the modem.


                               GLOSSARY
                               ========

Directory           The automatic process of transferring address
synchronization     lists from one postoffice to another
(Dir-Sync)          postoffice.

Dispatch            The program that controls the Dir-Sync
                    process.

External            The program that delivers mail between
                    postoffices.

GAL                 See "Global Address List."

GAL.NME             The actual file for the GAL. This file is in
                    the NME subdirectory of the Mail database.

GALINDEX.GLB        The index to the GAL. This file is meant to
                    decrease the time that the GAL is searched for
                    a name. It is located in the GLB directory of
                    the Mail database.

GALNETPO.GLB        The list of all external user addresses added
                    in the Dir-Sync process.

(GAL)               addresses participating in Dir-Sync.

Import              A utility that allows for batch processing of
                    user and gateway names. It is used to
                    incorporate gateway names into the Dir-Sync
                    cycle.

Message transfer    The External Mail program or a gateway that
agent (MTA)         delivers mail from one postoffice to another.

MSTTRANS.GLB        The master list of all addresses that are
                    participating in Dir-Sync. It is maintained by
                    the Dir-Sync server postoffice.

MTA                 See "message transfer agent."

NSDA                Name Service Directory agent. It is spawned by
                    the Dispatch program to run the appropriate
                    step of the Dir-Sync cycle.

PROCESS.GLB         The storage file for the times defined in the
                    Administrator program for Dir-Sync to send,
                    process, and receive updates to the GAL.

Rebuild             The utility that re-creates the GAL from the
                    local postoffice list, external postoffice
                    lists, and gateway name files.

REQCONF.GLB         The requestor configuration record file.

REQMAIN             The primary requestor process. It creates and
                    receives mail messages that contain the
                    updates to the GAL.

REQTRANS.GLB        The requestor transaction file. It contains a
                    record of the current updates that need to be
                    sent to the Dir-Sync server for incorporation
                    into the MSTTRANS.GLB file and the external
                    postoffice GALs.

Requestor           A postoffice that sends and receives Dir-Sync
                    requests but does not maintain the master Dir-
                    Sync files.

Server              A postoffice that sends, receives, and
                    maintains the database of address lists.

SRVCONF.GLB         The server configuration record file.

SRVMAIN             The server process. It accepts the updates
                    from the requestors, maintains the
                    MSTTRANS.GLB file, and creates mail messages
                    containing updates to the requestors' GALs.

SRVTRANS.GLB        The server transaction file. It is a temporary
                    storage place on all requestors and is used in
                    the processing of updates from the Dir-Sync
                    server.

SYSTEM.MBG          The mailbag that receives the Dir-Sync mail
                    messages.

TO OBTAIN THIS APPLICATION NOTE

The following self-extracting file is available for download from the Microsoft Software Library:

 ~ Wa0725.exe (size: 116093 bytes) 

   ARTICLE-ID: Q119591
   TITLE     : How to Obtain Microsoft Support Files from Online Services