Using Time Provider Groups in NetWare 5.x
Having the correct time on the servers means more than knowing when it's time to go home: It means the health and consistency of the data on the network.
For Novell NetWare and NDS administrators, time is an important commodity. Having the correct time on the servers means more than knowing when it's time to go home: It means the health and consistency of the data on the network. In this article, we will look at some factors that affect NetWare and NDS time synchronization and examine the steps necessary to create a custom time synchronization structure.
Why Time Matters
NetWare's Time System
The time system in NetWare is called TIMESYNC. The functionality is provided by an NLM of the same name, which is automatically loaded on all servers. In an IPX-only network, the servers listen for time information in Service Advertising Protocol (SAP) packets. In a pure IP or a mixed IP/IPX environment, the time information is received by TIMESYNC through the Network Time Protocol (NTP). If you are operating in a mixed environment, you must use NTP. It is important to understand that in both cases TIMESYNC issues time to serversSAP and NTP are simply the mechanisms used to deliver the time.
NetWare servers can be configured to receive their time from external sources such as Internet time providers, atomic clocks, or radio clocks. If it's practical to do so, configuring your servers to receive time from external sources provides for a reliable and relatively low-hassle approach. If it is not possible to configure your NetWare servers this way, another option is to use time provider groups that allow just a few servers to receive the time and provide that time information to other servers on the network.
NetWare achieves consistent time across the network by letting you configure certain file servers as time servers. Time servers, depending on their configuration, receive and/or supply time to other servers and clients. In a default NetWare installation, the first server in the NDS is configured as a Single Reference time server, and each subsequent server is configured as a Secondary time server. In relatively small networks this approach is more than adequate and often doesn't need any further configuration.
If your network is more complex or spans multiple locations, the default configuration is not as practical, because it can lead to the propagation of time parameters across slow or expensive wide area network links. If this is the case, you probably should investigate a custom time synchronization structure.