Microsoft KB Archive/147161

= PC DirSync: How to Stop a Second NSDA -S Process =

Article ID: 147161

Article Last Modified on 10/30/2006

-

APPLIES TO


 * Microsoft Mail for PC Networks 3.2
 * Microsoft Mail for PC Networks 3.2a
 * Microsoft Mail for PC Networks 3.5

-



This article was previously published under Q147161



SYMPTOMS
When you review the Dispatch log created by the Directory Synchronization (Dir-Sync) process, and two entries indicate NSDA -S on the same day that the Dir-Sync server is to process updates (T2 time), it is possible that two servers are configured to be a Dir-Sync server.



CAUSE
When you move a Dir-Sync server to another postoffice (PO) (from ADMIN.EXE, Config, DirSync, Options "Make this Postoffice the Directory Server" and selecting NO on an original Dir-Sync server), the PROCESS.GLB file is NOT modified to exclude the original T2 times that were setup when this PO was made the Dir-Sync server. The entries in this PROCESS.GLB can be seen and may be processed by the Dispatch program.

It is not possible to modify server T2 Dir-Sync schedule on the former Dir- Sync server from ADMIN.EXE program via Config, DirSync, Server, Schedule as the server option will no longer exist.



RESOLUTION
You can replace the PROCESS.GLB using one of the following methods:  Copy the PROCESS.GLB from another requestor. Create a dummy PO and copy the blank PROCESS.GLB file from the dummy PO. Change the requestor back to the Dir-Sync server via the Options menu and set the time values back to null by using the Home key. Be sure to change the server back to a requestor, and also recheck the registration via Config, Dir-Sync, Requestor, Registration. Reset the PROCESS.GLB using debug, as follows:

debug process.glb 

-rcx 

xxxx


 * 200 

-w 

-q <ENTER>

</li></ul>

In all cases, you will need to run ADMIN.EXE, Config, Dir-Sync, Requestor, Schedule, and enter the correct times for T1 (send updates) and T2 (process updates).

<div class="moreinformation_section">

MORE INFORMATION
The Dispatch log is created by adding the LogSession[=path\filename] entry to the DISPATCH.INI or /Logsession[=path\filename] or -L[=path\filename] to the command line when you run Dispatch.

The following is a sample log:

INST-1 02/05/96 16:04 Checking the process table on NET1\PO1

INST-1 02/05/96 16:04 Running "NSDA -S"

INST-1 02/05/96 16:25 "NSDA -S" terminated normally with exit code 64

INST-1 02/05/96 16:26 Checking the process table on NET3\PO3

INST-1 02/05/96 16:26 Running "NSDA -S"

INST-1 02/05/96 16:59 "NSDA -S" terminated normally with exit code 64

To determine which server is acting as the Dir-Sync server, look at the entry before the lines NSDA -S for the Network/Postoffice names. If two T2s are running, one of these names will be the actual Dir-Sync server, and the other will be a supposed requestor postoffice.

This problem can be due to an entry in the PROCESS.GLB file that contains information on T2 times for Dispatch to run NSDA -S(SRVMAIN -R and SRVMAIN -T) residing on the incorrect postoffice.

This problem can also occur if two postoffices have been set as the Dir- Sync Server through ADMIN.EXE Config, Dir-Sync, Options, Yes.

For additional information, please see the following article in the Microsoft Knowledge Base:

136487 PC DirSync: Err Msg: Fatal [161] Server Configuration Busy

96004 PC DirSync: Error and Status Messages #120 - 249

142841 PC DirSync: No Updated Address lists if Multiple T2 Cycles

Additional query words: 3.20 3.20a 3.50

Keywords: KB147161

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.