Anyone who has worked with Novell NetWare 4.x or 5 servers knows the importance of time synchronization between the servers in your tree. NDS uses timestamps to keep track of changes made to objects’ properties, the creation or deletion of objects, replica splits, moves, joins, and so forth. Mess up time sync, and you’re likely to end up with a messed-up NDS tree as well. And if you try to manually change the time on your servers by using the SET TIME command, you can end up with lots of Synthetic time being issued on replica…messages.

This type of message indicates that your server’s NDS replica has timestamps in it that are in the future, not in sync with the server’s current time.

If you’ve set time way into the future and then back again, you’ll have to load DSREPAIR –A and select Advanced Options | Replica And Partition Operations | Repair Time Stamps And Declare A New Epoch to fix the problem. If the time is only a few minutes or even hours off, you can let the servers run until time catches up. However, you may not be able to add, move, or delete objects, change users’ passwords, and perform similar tasks until the current network time gets ahead of those “future” timestamps.

In this article, I’ll show you how to set up time synchronization in your NDS tree. I’ll also discuss NTP time sources available on the Internet.

Who has the time?
Unless you’re using “configured sources,” where you edit the TIMESYNC.CFG file on each server to point it to its time source (which could be one or more servers in the same or a different NDS tree), you have two options for setting up time sync in your NDS tree:

  • Use the default setup for NDS time sync to designate the first server installed into the NDS tree as a Single Reference time server and all the rest as Secondaries. You change this by editing the line near the top of your server’s AUTOEXEC.NCF file that reads SET TIMESYNC TIME = time server type. The Single Reference time server is basically the “God of Network Time”; whatever time it has IS the correct time for the NDS tree. Nobody else (i.e., no other server) has a vote; if they’re not within two seconds (by default) of the time on the Single Reference time server, they’re out of sync. This scenario is most often used for smaller trees with only a few servers. Of course, you’ll want to make sure that your Single Reference time server has an accurate clock so that your network’s time doesn’t drift too far from the “real world” time. This could cause problems if you’ve put Login Time Restrictions in place and your users can’t log in and work when they’re supposed to be able to.
  • Designate one server as a Reference time server, two to 15 other servers as Primary time servers, and all the rest as Secondaries. The Reference server’s time carries a weight of 16 (it gets 16 votes as to the correct network time), while the Primaries get only one vote each. (Secondaries get zero votes.) This approach allows the network time on all servers in the tree to be synced to the Reference server’s clock fairly quickly. (Remember to include the SET TIMESYNC RESTART FLAG=ON line in the AUTOEXEC.NCF file after making any changes to your server’s time setup.) The main purpose of the Primaries is to provide a reliable time source in case the Reference time server can’t be contacted (for example, if the Reference server is down or the WAN link that connects another server to it is down). You could designate one server at your headquarters site as the Reference time server and another one there as a Primary (as a backup), and then designate other Primaries at a few strategically located sites across the WAN. With this setup, all of your servers can contact a reliable time source that is only a few router hops away.

Speaking of routers, one thing to watch out for when synchronizing time across WAN links is that the TIMESYNC.NLM for NetWare 4.x servers communicates over IPX using only SAP type 026B. If the routers on the WAN filter out this SAP type, your servers will not be able to sync their time across the WAN links. The new TIMESYNC.NLM in use on NetWare 5 servers can use both IPX with SAP type 026B or TCP/IP using UDP port 524, depending on which protocols are enabled on the NetWare 5 servers.
This document appears courtesy of TechRepublic’s TechProGuild, the subscription Web resource for IT administration and support professionals. Among other great benefits, TechProGuild offers in-depth technical articles, e-books, and weekly chats moderated by industry experts on hot topics such as the latest OS developments and career advancement. For more information, sign up now for a FREE 30-day trial of our TechProGuild service.
Does anybody really know what time it is?
Aside from relying on the internal clocks on your Single Reference or Reference time servers, is there any other way to keep accurate network time? Glad you asked. The Internet has become a great source of information for all of us, and one of the useful but not-so-well-known Internet protocols that is available to those sites with full-time Internet connections is NTP—the Network Time Protocol as defined by RFC 1305. It specifies the use of port 123 over TCP/IP for the exchange of NTP requests and responses in UTC (Universal Time Coordinated) format (the number of seconds since 1-1-1900). You can get more information on NTP from the Time Synchronization Server Web site .

If all of your servers and hosts (NetWare, UNIX, Linux, NT, etc.) could use NTP to set their time to a reliable time source on the Internet, they would all have their clocks in sync. Files would have an accurate creation or modification timestamp, batch jobs would run exactly when they’re supposed to run, login time restrictions could be set up and enforced across a variety of platforms, and life would be good (or at least some things would be on time).

Well, guess what—this is your lucky day! There are a number of highly accurate NTP time sources available on the Internet, such as the atomic cesium clocks run by the Navy, the National Institute of Standards and Technology (NIST), NASA, MIT, and similar groups. A list of these reliable (is plus/minus one microsecond per year good enough?) Internet time sources is available at the NIST Web site.

Here’s even more good fortune—there are a couple of NTP client NLMs available for your NetWare 3.1x, 4.1x, and 5 servers. NetWare 5 includes the NTP.NLM, which can act as both an NTP client and an NTP server. To configure a NetWare 5 server to use NTP, edit the server’s SYS:ETC\NTP.CFG file; uncomment or add a line that reads
server ip address

or
server hostname
Then type LOAD NTP at your Reference or Single Reference server’s console (and add it to its AUTOEXEC.NCF file so that it loads right after the IP protocol is bound to your server’s network card). For example, you could point your NTP.NLM to get its time from the U.S. Naval Observatory’s atomic clock with the following line in NTP.CFG:
server ntp2.usno.navy.mil

(NOTE: Use this line only if your server can use DNS to resolve the name to the NTP server’s IP address. Also, your Internet routers must allow IP traffic on port 123 in and out of your network.)
This article originally appeared in TechRepublic’s TechProGuild, the subscription Web resource for IT administration and support professionals. Follow this link to sign up now for a FREE 30-day trial of our TechProGuild service.
How about an RDATE?
For NetWare 3.1x or 4.1x servers, you can download a freeware NTP client called RDATE.NLM from the MurkWorks Web site. The RDATE.NLM is configured at load time to use NTP to request the time from one or more specified time sources. For example, I set up a Reference time server to use RDATE to poll the NIST cesium clocks in Boulder, CO, with the following command:
LOAD RDATE /P 720 /V 2 /U 132.163.135.130 132.163.135.131

The /P 720 configures RDATE to poll the time server every 720 minutes (twice a day); /V 2 will keep RDATE from changing the server’s clock unless there is more than two seconds’ variance with the NTP server it polled; /U tells it to use UDP (rather than TCP); and the IP addresses are those NTP servers you want to poll for their time. If you put more than one IP address in the command, it will try the first one, and, if it cannot make contact, it will try the second one, and so on.

Of course, if you are among the “Internet Challenged” and don’t have a full-time Internet connection available, you could sync your server’s time to an in-house NTP time server if you consider it reliable enough.

The first time I used RDATE, I set it to poll an in-house UNIX host running an NTP server daemon. When they changed the time on the UNIX host to correct for Daylight Saving Time, they entered the wrong time; our NetWare 4.1 server changed its time accordingly, and we started getting Synthetic time messages. We tracked down the UNIX support folks the next Monday morning when we noticed the problem and got them to correct it ASAP! Just in the nick of time.

Dave Green began working in the computer industry in 1979. As a CP/M and WordStar OEM, he built 64-KB machines that increased user productivity one brick at a time. He then worked as a systems designer before moving into IT strategic planning and jumping on the Macintosh bandwagon. In 1996, Dave founded what has become iPlan, and he continues to contribute to the success of his clients as they look to the Internet and the future of a digital economy. Dave lives in the Silicon Crescent, which is centered in Boise, Idaho.

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.To comment on this article, please post a comment below or send us a note .