In case one should desire to test year-2000 compliance on a NetWare 4.x network :
Novell strongly advises not to perform it in a production NDS Tree.
See our WEB site for more information: http://www.novell.com/year2000/

As of this writing we are seeing an increasing number of customers opening incidents with Novell Technical Support reporting problems like the following being caused by carelessness with the time on one or more servers or a time-provider in their NDS-tree.
- Various NDS synchronization problems (normal replica skulking or schema sync)
- Synthetic time

- Look for "Synthetic Time has been issued on partition xyz.whatever " messages on the server consoles
- TID 2928167 "41DSVU2.EXE - DSVIEW for NetWare version 4.1x" has a brief description of the server-based utility DSVIEW.NLM, which can be used to browse the NDS database for verifying the timestamps.

Search String -608 608 stamp years Y2K

Every time an object or property in the NDS tree is modified, its modification timestamp is updated with the time of the event. When an object is being updated on a server, which has the time set to somewhere in the future, the object will be timestamped with that time. Then when the time on the server is later set back to the actual time, synthetic time will occur while the timesync process using its mechanisms tries to close the time-gap. These mechanisms are adequate for minor time differences, but not for years-like situations.
However if the NDS schema has future timestamps, it will not trigger any alerts like the console messages for the synthetic time on partitions. This phenomenon is normally not observed until schema extensions are applied after the time is "back to normal". These changes will fail to synchronize since the timestamp which the changes (and thus the schema) will receive are older than on the other servers (who still have the timestamps from "back then" when the time was in the future).

For both of the solutions described it is critical that the latest versions of DS.NLM and DSREPAIR.NLM are used on all servers. We have seen unexpected results of these operations with older versions of these modules.
Please realize that the advanced options switch for DSREPAIR (-a) should ONLY be used when instructed directly by Novell Technical Support or when specifically asked for a purpose described in a TID.
In a case of synthetic time on one or more partitions the following procedure addresses the problem :
- Load DSREPAIR.NLM with the -a switch on the server holding the master replica of the partition in question
- Select Advanced options menu, Replica and partition operations
- Select the partition and then "Repair time stamps and declare a new epoch"
- Log in (remember to use full distinguished name like .admin.containerx.org)
This operation will set the modification timestamps of all objects in the partition (and only in that partition) to the current time and set all replicas except the master to new state. A result of this will be that all objects will be sent to the readable (RW or RO) replicas and may - depending on the partition size - cause a considerable amount of network traffic during the partition operation.

If it is future timestamps on the schema, follow this procedure.
- Load DSREPAIR.NLM with the -a switch on the server holding the master replica of the [Root] partition
- Select Advanced options menu, Global schema operations
- Log in and select Declare a new epoch
This will set the modification timestamps of the complete schema (classes, attributes, schema partition) to the current time and synchronize the schema to all servers in the tree.