PC DirSync: Directory Synchronization (Dir-Sync)

• Microsoft Mail for PC Networks, versions 3.0, 3.2, 3.5

SUMMARY

TABLE OF CONTENTS

MORE INFORMATION

INTRODUCTION

HISTORY

<Graphic deleted>

<Graphic deleted>

GENERAL DESCRIPTION OF DIRECTORY SYNCHRONIZATION

QUICK SETUP GUIDE

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.

STEPS FOR CHOOSING DIR-SYNC TIMES

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.

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 document for the technical reasons why the External Mail program is needed.

A. STANDARD CONFIGURATION

Server           Requestor 1

      \\              // 
       \\            // 
        \\          // 
         ------------
         | External |
         ---------------
            | Dispatch |
            ------------
         //            \\ 
        //              \\ 
       //                \\ 


   Requestor 2      Requestor 3
 

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

dispatch /instancename=Normal

B. DYNAMIC DRIVE MAPPING

Server           Requestor 1

      \\              // 
       \\            // 
        \\          // 
         ------------
         | External |
         ---------------
            | Dispatch |
            ------------
          /            \ 
         /              \ 
        /                \ 

   Requestor 2      Requestor 3 

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

dispatch /instancename=Dynamic

C. MODEM CONNECTIONS

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

 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

• 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 

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:



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

• 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 TIMEZONE 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 DIR-SYNC PROCESS

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.

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.

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

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.

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.

THE DIR-SYNC PROTOCOL

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. 

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.

DIR-SYNC UTILITIES

DSSCHED.EXE

dssched admin -ppassword -ddrive [-ifile] [-xfile] [-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

listds admin -ppassword -ddrive [-s or -r [-z]] [-v] [-?]

Parameter    | Description
---------------------------------------------------------------------
admin        | The Administrator account for the postoffice
             | (required).
-P<password> | The administrator's password (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. 

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

listq admin -ppassword -ddrive -ffile [-t] [-c] [-?]

Parameter    | Description
---------------------------------------------------------------------
admin        | The Administrator account for the postoffice
             | (required).
-P<password> | The administrator's password (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. 

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

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

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.



On the server:
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.

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

PROBLEM 3: FATAL ERROR 161: SERVER CONFIGURATION BUSY ON A 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 -ppassword -dm -xfile.txt

dssched admin -ppassword -dm -ifile.txt

PROBLEM 4: ERROR 203: GAL REBUILD PROBLEM ACCESSING FILES

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

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

listds admin -ppassword -dm -s

PROBLEM 7: ERROR 133 INVALID SERVER REQUEST

PROBLEM 8: ERROR 150

type nul > filename

PROBLEM 9: DIR-SYNC SERVER RESTORED FROM BACKUP COPY

import admin -ppassword -ddrive -s -y

import admin -ppassword -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.

[Dispatch-Normal]
DrivesDirectPO=mp   ; Use drive connections M through P.
IdleProcess = "external /instancename=Normal"

[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" 

[External]
; Global settings for External
DriveHomePO=m    ; Assumes the home postoffice is on drive M.
MinKDiskFull=500 ; Stop delivering mail if space is less than 500K.
MinKDiskNotFull=1000 ; Start delivering mail when space is above 1000K.
(Continues from previous line)
;              These two are OPTIONAL.
LogSession          ; Log external.
LogReceive          ; Save received mail.
LogSent             ; Save sent mail.

[External-Normal]
CommDisable         ; Don't need the modem.
DrivesDirectPO=mp   ; Set up for drives M through P.

[External-Dynamic]
CommDisable         ; Don't need the modem.
DrivesDirectPO=mn   ; Only two static connections.
; Use ONE of the following dynamic connections:
DrivesDynamic=op    ; Needs the Dynadmin table set up first.
; or directory.
DrivesNovell=server4/volume:\maildata ; Example of a Novell dynamic
connection. (Continues from previous line)

[External-Modem]
DrivesDirectPO=mn        ; Two drives needed in this example.
CommScript=scriptname    ; Script file for External.
AsyncCommPort=COM1  ; Assumes COM1.
; External needs to have Admin set up the parameters for connecting to
the other postoffices (Continues from previous line)
; before this instance will work!

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

[External-Indirect2]
DrivesDirectPO=mn   ; Only two drives needed.
CommDisable         ; We aren't using the modem. 

GLOSSARY

TO OBTAIN THIS DOCUMENT

Wa0725.exe

http://www.microsoft.com/downloads/search.asp

Additional query words: 3.00 3.20 3.50 wga appnotes

Keywords : kbfile MailPCDirSync
Version : WINDOWS:3.0,3.2,3.5
Platform : WINDOWS
Issue type : kbinfo