Top of Page

 Documentation\Installation\Recommended Configurations
 
Install Domain Time II
    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.

    1. 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.

    2. 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.

      • Domain Time Server should not be used to serve time from virtual machines. This configuration is not supported. Also, any tools that calculate comparative time variances (such as Domain Time II Audit Server, Domain Time II Monitor Service, the Domain Time II Manager variance report, DTCheck utility, etc.) cannot be relied upon to provide accurate results when executed from a virtual OS. These should be run on physical machines.

      • Domain Time Clients may be run on an OS in a virtual machine guest, although you should be aware that regardless of the time service configuration, the clock will still have inherent inaccuracies. Any time-critical system should run directly on physical hardware.

        See this article from our knowledgebase for more information on use with virtualization systems.

    3. 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.

    4. 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.

        Single Machine Model 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)

        1. Install Domain Time II Server or Full Client.
        2. Configure it to get time from your chosen time source(s).

       
      Workgroup Model


      For networks without a Windows domain controller.

        Workgroup Model 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)

        1. Install Domain Time II Server on a Windows machine.
        2. Configure the Server to get its time from your chosen time source(s).
        3. Install Clients:
        4. 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)

        Single Domain Model 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:

          1. 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.
          2. Use Domain Time II Manager to perform each of the following steps from your management workstation:
            1. Install Domain Time II Server on the PDC/FSMO (It will assume the Master role).
            2. Configure the Master to get its time from your chosen trusted time source(s).
            3. Install Domain Time II Server on all other DCs (They will automatically assume the Slave role).
            4. Install Domain Time II Server on any RAS machines (If the machine is not a DC, select the Slave role).
            5. 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).
            6. 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.
            7. Configure any non-Domain Time client machines or devices to get their time from the nearest Slave Server.
            8. Use Manager to install the Monitor Service and Update Server to automatically monitor your network and keep it updated.
          3. 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 Good
          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 Better
          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 Best
          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:

          1. 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.
          2. 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.
          3. Use Manager to configure the Master time servers (PDCs) of each resource domain as Foreign Slaves of the main domain.
          4. 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.
          5. 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.

       

      Next Proceed to the Upgrading to Domain Time II page
      Back Back to the Installation Index page

    Domain Time II Software distributed by Microsemi, Inc.
    Documentation copyright © 1995-2018 Greyware Automation Products, Inc.
    All Rights Reserved
    All Trademarks mentioned are the properties of their respective owners.