Documentation\Installation\Recommended Configurations
|
This page describes how to deploy Domain Time II 4.1 across your enterprise, from the simplest
situation (one machine) to a multi-domain mixed environment. Follow these simple steps to
ensure successful installation.
- Decide on time sources
Domain Time II is designed to obtain time from trusted time sources such as GPS receivers,
cesium clock cards, known good public Internet time servers, etc. Choosing accurate and reliable time sources
is the first implementation decision you need to make.
Wherever possible, you should choose to use multiple time sources to provide redundancy, increase the accuracy of your time, and to prevent
wild time from being served should any of your time sources have an error. The best accuracy and redundancy is achieved by using four reliable
time sources with Domain Time's
Analyze all listed servers and choose the best... feature enabled.
Time sources should be as close physically and topographically to your Domain Time Servers and Clients as possible. A symmetrical, low-latency
network connection between time sources, Servers, and Clients will provide the most accurate time. One excellent configuration
would be to have at least two GPS time servers located on a local LAN with two additional stable public servers included.
If you want to obtain time from public time servers, please refer to the list of
public time sources and abide by the published rules for each time source.
If you will be using Domain Time II Server as a time source anywhere on your network, either as a stand-alone server or as part of a
time distribution hierarchy (see the Time Distribution Model section below), it is essential that you choose
to install the Server software on systems that can provide sufficient performance, hardware, and OS stability to serve time reliably.
The quality of the time sync on your network can only be as good as the accuracy of the time servers themselves.
- Choose the right machine(s)
Review the Software Requirements for Domain Time II.
Due to how the system clock on operating systems are maintained, some systems are unsuitable for keeping accurate time. The quidelines
below apply to both time servers and clients, however they are of particular concern to any machine you want to use as a time server.
A good candidate machine for accurate timekeeping will have sufficient processor power, memory, and network hardware to be able to service
the operating system and applications without hitting bottlenecks under load that cause delays in servicing interrupts, packets, and threads
in a smooth and timely fashion. A heavily-used machine will typically have more clock-drift problems than a lightly-used system, so
be sure that your machines are not experiencing bursty periods of excessively-high load or other performance problems.
Some system motherboard designs, BIOS and firmware issues, multi-processor implementations, system/video/network drivers, or other system
components can cause problems with servicing the system clock correctly and may require updates from the manufacturer. Be sure to
check with your vendor(s) to be sure you are up-to-date with all necessary patches.
Virtual Machines
In addition to the problem with heavily-loaded systems mentioned above,
so-called virtual server environments (VMWare, Microsoft Virtual Server/Hyper-V, Xen etc.) have significant issues in servicing the clock in their guest operating
systems in a timely manner, making them inappropriate for use as time servers in production environments.
- Prepare your network to pass time sync traffic
Domain Time can use many different time protocols to synchronize time. Your network routers, switches, and firewalls must be able to pass
the proper traffic based on the protocols you choose to use. Here are some basic guidelines:
- Domain Time II uses the Domain Time II protocol to communicate both time sync and control messages between Servers, Clients, and the
Management Tools. You should always configure your internal network to pass port 9909 UDP traffic, even if you will be using a different protocol to
sync the time.
- If you want Domain Time II components to automatically discover each other across subnets (such as allowing Manager and Audit Server to be
able to find machines on other subnets) you should also allow port 9909 UDP broadcasts across your internal network. (if this is not possible, Manager
and Audit Server can add machines using other methods).
- Your internal network should have correctly configured and functioning DNS, WINS, and Windows Network browsing.
- Some functions of Domain Time components (such as installation/upgrade using Manager or Update Server, or log file collection using Audit Server) require Windows Networking file access through administrative shares.
Those programs or services must be run under a user account with sufficient administrative privileges to make such connections.
- ICMP traffic (esp. PING) should be permitted to all machines.
- If you will be using time servers outside your network, you will need to configure your firewall to pass the necessary traffic to the Domain Time Master server
(i.e. port 123 UDP for NTP). If your network policies don't permit direct connections through firewalls, you can configure Domain Time II to get time through web proxies.
Read these pages for more detailed information on firewalls, time protocols and ports, automatic discovery, etc.
- Choose the Time Distribution Model that Fits your Network
Find the example below that most closely matches your network. Then, follow the simple Installation Plan instructions indicated
for your network model to quickly and successfully install Domain Time II. If you are in an industry that has regulations regarding
time synchronization, you'll also want to see the Regulatory Compliance pages.
Stand-Alone Single Machine Model
A machine that is not part of a domain.
Domain Time II running on any stand-alone machine must be manually configured to get its time from an external trusted network source.
Installation Plan: (click the link to get detailed instructions for each component listed)
- Install Domain Time II Server or Full Client.
- Configure it to get time from your chosen time source(s).
Workgroup Model
For networks without a Windows domain controller.
In a small workgroup without a Windows domain, one machine should run Domain Time Server. It
will be installed in the Independent time server role,
and should be configured to get its time from a trusted source and distribute it to clients on the network.
All other machines on the network should run Domain Time II Client if one is available for that platform.
Any other time-capable machines and devices should be configured to get their time from the Independent Server using
whatever time protocol they use (i.e. Macs and Novell servers using NTP, routers and hubs that use TIME/ITP, etc.)
Installation Plan: (click the link to get detailed instructions for each component listed)
- Install Domain Time II Server on a Windows machine.
- Configure the Server to get its time from your chosen time source(s).
- Install Clients:
- Configure any third-party clients or devices on the network to get their time from the Domain Time II Server .
Single Domain Model
Networks with a single Windows domain (or single Active Directory Tree)
The Primary Domain Controller (the FSMO PDC-emulator on Active Directory) and any other Domain Controllers
should run Domain Time Server.
The PDC fills the Master role, and the DCs are configured as Slaves to it.
This provides redundancy and efficient distribution of time. See the Why Have Slaves?
discussion for more info.
Ideally, a Domain Time Slave should be present on each IP network subnet where Clients are in order to enable automatic server discovery.
If neither the PDC nor any DCs are present on a subnet, you have several options:
- Install Domain Time II Server on a machine on that subnet and set it to the
Slave role.
- If there is a DHCP server on the subnet, enter the IP address of the Domain Time II Server
into the DHCP Time Server options. Domain Time Clients will then
automatically get the address of the server to use and contact it directly, even if it is on a different subnet.
- Use Full Client in manual configuration mode to specify a Domain Time Slave server on an adjacent subnet.
- Configure each client's broadcast addresses to allow it to broadcast to the server's subnet to enable automatic discovery on remote subnets (not recommended)
Any server running Windows RAS to accept dial-in connections should also run Domain Time Server and be configured as a
Slave, whether or not it is a DC. Remote users running Domain Time Client will then automatically sync to the RAS server when they connect.
Other workstations and servers on the network should run Domain Time Thin Client or
Full Client (with
Automatic Configuration
enabled) if a client is available for the platform -- Windows, UNIX/Linux systems, etc.
If you are planning on running any machines using only the Windows Time Service (W32Time), you must read the
Co-existing with the Windows Time Service page.
Any other time-capable machines and devices should be configured to get their time from the nearest Domain Time Slave Server
using whatever time protocol they use (i.e. Macs and Novell servers using NTP, routers and hubs that use TIME/ITP, etc.)
Installation Plan:
- Use Setup to install the Management Tools on any Windows domain member you want to use as your management
workstation. Your user account must have sufficient administrative privileges to install software on your domain.
- Use Domain Time II Manager to perform each of the following steps from your management workstation:
- Install Domain Time II Server on the PDC/FSMO (It will assume the Master role).
- Configure the Master to get its time from your chosen trusted time source(s).
- Install Domain Time II Server on all other DCs (They will automatically assume the Slave role).
- Install Domain Time II Server on any RAS machines (If the machine is not a DC, select the Slave role).
- If you have subnets that do not have a Domain Time II Server on them, choose one of the following:
- Install a Domain Time II Server on each subnet and set it to the
Slave role.
- Configure option 042 of a DHCP server to provide the IP address of a Domain Time II Server on an adjacent subnet reachable by TCP/IP.
- Install Full Client on each machine in the subnet (see below).
- Install Clients:
- For Windows machines that are on the same network subnet as the Domain Time II Server,
install Thin Client
(or Ultra Thin Client if
Broadcast Time is needed).
- For Windows machines are not on the same subnet as the server, install Full Client and enter the DNS name or IP
address of the Server as the Time Source.
- Install the Domain Time domtimed daemon on any Linux/Solaris/FreeBSD machines.
- Configure any non-Domain Time client machines or devices to get their time from the nearest Slave Server.
- Use Manager to install the Monitor Service and
Update Server to automatically monitor your network and keep it updated.
- Install Audit Server on any machine running Domain Time II
Server to raise out-of-sync alarms and keep an audit trail of your network's time sync.
Multi-Domain Model
Networks with multiple Windows domains or Active Directory Forests with multiple trees.
The Single Domain Model described above should be implemented on each individual domain (tree), except that the master
time server (the PDC, or PDC emulator) for each resource domain needs to be configured to get its time:
- By manually configuring it get the time directly from a trusted external source (good).
- By manually configuring it to get time from the main domain's PDC (better), or
- As an automatic foreign Slave of the main domain (best).
You can configure each domain's Master to get its own time in the various ways described below:
Multi-Domain Model where each PDC gets its own time from an external trusted time source
The main disadvantages to this configuration are:
- You must manually configure each Domain Time Server with the address of the time source.
- You may have security policy restrictions about allowing multiple machines access to a public time server.
- There will be some additional minor discrepancies in time between the various domains (as compared to either
of the multi-domain model options described below).
- The overall accuracy of the entire network cannot be controlled centrally.
In the second configuration option, the PDC for the master domain gets its time from a trusted external source, while
the PDCs for each of the resource domains are manually configured to use the master domain's PDC as their external time source.
Multi-Domain Model where resource domain PDCs get their time from the main domain's PDC using manual configuration
The main disadvantages to this configuration are:
- You must manually configure each Domain Time Server with the address of the time source.
- Time cascade messages cannot propagate from the overall master to the resource domains.
- The overall accuracy of the entire network cannot be controlled centrally.
The final configuration shown below represents the optimum configuration for using Domain Time across multiple domains or for an Active
Directory forest.
Multi-Domain Model where resource domain PDCs are set as foreign Slaves of the main domain's PDC
There a number of advantages to setting resource domain PDCs as foreign Slaves:
- Time cascade messages propagate properly throughout the entire network.
- The overall accuracy of the entire network can be controlled centrally. Configuration settings for Masters, Slaves and Clients are replicated
automatically to all domains.
- The network is more robust. Domain Time Servers adjust automatically to changes in the availability of any Master or Slave, as well as server
role changes on either the main or resource network.
- Masters acting as Slaves to the main domain have additional code to maintain extremely tight synchronization with the overall master, so the overall
accuracy for a large network is much improved.
Read a more complete discussion of Foreign Slaves here.
Installation Plan:
- Use Setup to install the Management Tools on any Windows domain member you want to use as
your management workstation. Your user account must have administrative privileges on all domains to which you want to
install. If not, you must also install the Management Tools on a machine in each of the untrusted domains and perform installations
to those domains from there.
- Perform all of the tasks in Step 2 of the Single Domain Model Installation Plan above on each domain (tree), starting with the top-level domain.
- Use Manager to configure the Master time servers (PDCs) of each resource domain as Foreign Slaves of the main domain.
- Use Manager to install the Monitor Service and
Update Server to automatically monitor your network and keep it updated.
Remember, Manager and the other Management tools are licensed per machine.
- Install Audit Server on any machine running Domain Time II Server to raise out-of-sync alarms and
keep an audit trail of your network's time sync. Install additional Audit Servers if you want to audit different types of machines on multiple schedules or to
keep separate audit data for individual domains/companies.
Proceed to the Upgrading to Domain Time II page Back to the Installation Index page
|