Top of Page

Domain Time II Manager
Version 5.2

Discovery


Manager uses multiple methods to discover machines on the network for remote control and monitoring purposes. You can control how Manager performs these discovery tasks using settings contained on three dialog pages from the Options item on the main menu.

 

Computer List Enumeration...
If you choose Options -> Network Options -> Computer List Enumeration... from Manager's menu, you'll see a dialog with the following settings:

     Computer List Enumeration 

    Use Microsoft Networking to find domains and workgroups (can be slow and inaccurate)
    Use Active directory to find domains (accurate, but requires Active Directory membership)

        LDAP server: 

      When a computer is removed
    from Active Directory, Manager should:
        Username: 
      Tombstone the record
        Password: 
      Purge it from the cache

These options control how Manager populates the Domains and Workgroups list on the Tree pane of the display when discovering machines from domains, workgroups, and Active Directory.

    Enumeration is a two-step process. When either of these options are checked, Manager will first use the selected method(s) to find any existing domains and/or workgroups on the network. Then, if the domain or workgroup is marked to be enumerated in the Enumerate... list (see below), Manager will attempt to discover the individual computers present in the selected domain/workgroups.

    Use Microsoft Networking to find domains and workgroups... will cause Manager to examine the Windows Browse list for machines. This tends to be a slow process and can only discover machines that have NetBIOS enabled. In general you'll only want to use this method if there are machines on your network that aren't included in Active Directory (such as workgroup members).

    In most cases, you will want to choose Use Active directory to find domains, which is usually much faster and (assuming your network is correctly configured and maintained) more accurate than by examining the Browse list.

    By default, Manager will attempt to access the Active Directory LDAP server used by the domain of the Manager machine, using the credentials of the logged-on user account to connect to it. Manager will attempt to enumerate all listed domains using this server. If you prefer to use a different LDAP server for default enumeration, enter its DNS name or IP address and a user account/password with sufficient privileges to connect to the server.

    You can set individual LDAP servers and logon permissions for each domain using the Enumerate list below. Select a domain and Edit the entry to use the LDAP server and user account you prefer.

    Use the Tombstone the record and Purge it from the cache radio buttons to select how you want Manager to treat listed machines that are later removed from Active Directory.

    The Enumerate List

    Once domains and workgroups have been identified, they will appear in the Enumerate computers in the following domains and workgroups list. You can use the checkboxes to select which of these you want Manager to enumerate when the program starts, or when you manually refresh the Domains and Workgroups category in the Tree pane.

      Manager - Select domains/workgroups to enumerate
      Manager - Select domains/workgroups to enumerate   [Click for larger size]

      You may also add any domain or workgroup that is not discovered automatically

      Manager - Add domains to the Enumerate list
      Manager - Add domains to the Enumerate list   [Click for larger size]

      Enumeration can take quite some time to complete, especially on large networks, so after machines have been enumerated the first time, you may want to only re-enumerate them manually when necessary.

      Enumeration can be triggered manually for individual domains by highlighting the domain's name (category) in the Tree pane and right-clicking to choose Refresh from the context menu (or Actions -> Refresh from the main menu). Enumeration for all domains is initiated by highlighting the Domains and Workgroups category and choosing Refresh.

      Limit display by Organizational Unit (OU)
      You may further restrict the view of machines by selecting which OU's you'd prefer to display

          

        Show machines from all Organization Units (OUs)
        Limit display to machines from selected OUs
               Include machines with a blank OU field

        OU display limiting only applies to the Domains and
        Workgroups computer list, and only when "Show
        Hidden Computers" option is not enabled.

          AD Organizational Units

 

Network Discovery...
Select Options -> Network Options -> Network Discovery... from Manager's menu and the Network Discovery dialog will appear:
    The Network Discovery Dialog
    The Network Discovery Dialog   [Click for larger size]

    This dialog controls how Manager discovers currently running Domain Time components and/or NTP daemons on the local subnet and beyond.

    When enabled, Manager broadcasts and/or multicasts a special discovery packet to the network. Any machine that hears the discovery packet will then respond back via a unicast UDP packet containing its synchronization status and other data. Broadcasts/Multicasts are sent to the networks indicated on this dialog, using the protocol types selected.

    This method only discovers machines that are online and that respond to the discovery packet. Once machines are discovered, they are added to the Manager's cache list and are thereafter contacted using unicast for most operations.

      IPv4/IPv6 Multicast Discovery
      Domain Time can use multicast to discover Domain Time machines currently online over IPv4 and/or IPv6, both on the local subnet and on remote subnets. This method is preferred over the older IPv4 Broadcast Discovery method described below.

        In order to use this method, your network must be enabled for multicast. You must have multicast-enabled routers/switches configured to allow multicasts sent to port 9909 UDP to reach all of your subnets. This may also require enabling PIM (Protocol-Independent Multicasts) on all relevant interfaces. Consult your network equipment vendor(s) for configuration details necessary for your environment.

         IPv4 Multicast Discovery 

          Enabled
              All local subnets (more thorough)
              Primary subnet only (faster)

           DT2 multicast address:   
        NTP multicast address:
        IPv4 TTL:

          
         IPv6 Multicast Discovery 

          Enabled
              All local subnets (more thorough)
              Primary subnet only (faster)

           DT2 multicast address:   
        NTP multicast address:
        IPv6 Hops:

        All local subnets (more thorough)
        Primary subnet only (faster)

        These options select whether the multicast discovery packet is sent out only over the interface the operating system has designated as the primary interface or through all network interfaces, or whether it is sent to specified remote subnets.

          Sending through multiple interfaces also results in longer timeouts and processing overhead to send traffic and listen for responses on each interface. In general, you will want to send only through the primary interface unless you have machines that cannot be discovered otherwise. Also, If you have multi-homed machines visible to the Manager on multiple interfaces, sending discovery packets through all interfaces may result in duplicate responses from those machines.

        The DT2 and NTP multicast address boxes indicate the multicast address(es) Manager will send the discovery packet to. Only change these addresses if you have a compelling reason to do so. Changing these values is usually an error.

        The IPv4 TTL: and IPV6 Hops: entries set how many router hops a multicast packet must cross when propagating through your network. Choose a value that allows multicasts to reach all of your subnets.

      IPv4 Broadcast Discovery
      By default, Manager only broadcasts to the local segment. This is an efficient way to discover machines local on local subnets, and you probably do not want to disable this function entirely. However, using IPv4 Broadcasts to discover machines on remote subnets is recommended only if multicast discovery is not possible or reliable on your network.

         IPv4 Broadcast Discovery 

          Enabled
              List of custom addresses
              All local subnets (more thorough)
              Primary subnet only (faster)

                     
           Custom Broadcast Addresses  
          

        List of custom addresses
        All local subnets (more thorough)
        Primary subnet only (faster)

        These options select whether the broadcast discovery packet is sent out only over the interface the operating system has designated as the primary interface, through all local network interfaces, or whether it is sent to specified subnets.

          Sending through multiple interfaces also results in longer timeouts and processing overhead to send traffic and listen for responses on each interface. In general, you will want to send only through the primary interface unless you have machines that cannot be discovered otherwise. Also, If you have multi-homed machines visible to the Manager on multiple interfaces, sending discovery packets through all interfaces may result in duplicate responses from those machines.

          The 255.255.255.255 address is used to broadcast to the primary segment. Only change this address if you have a compelling reason to do so. Changing this value is usually an error.

          Custom Broadcast Addresses
          To discover machines on remote subnets, your routers/switches must be configured to allow broadcast traffic using port 9909 UDP to reach each subnet. You must also select the List of custom addresses radio button and specify the broadcast address for each subnet. Manager will then send directed broadcasts to the broadcast addresses specified.

          This option is provided primarily for backwards-compatibility with versions prior to version 5.1. This method does not scale well and is unreliable due to firewall/router issues with passing broadcasts between subnets. We recommend you use multicasts to reach remote subnets instead, if possible (see above).

          If you do choose to use this option, the 255.255.255.255 entry is used to broadcast to the primary segment. You should leave this entry in the list unless you have a specific reason to remove it. Then, enter the broadcast address for any other remote subnets you want to scan via IPv4 broadcast. For example, you would enter 192.168.1.255 as the broadcast address for the 192.168.1.x subnet.

        Note about Broadcast Traffic across firewalls
        Broadcast traffic typically originates from an ephemeral source port sent to the broadcast address of designated subnets intended for destination port 9909. Domain Time II components that receive the broadcast then respond via unicast from source port 9909 back to the sending IP address's ephemeral port. This broadcast discovery process is substantially the same as the process used by DHCP, TFTP, and other standard broadcast discovery methods.

        Stateful firewalls/routers will often require additional configuration to ensure broadcast discovery operates correctly, since unlike normal unicast UDP communication, the originating traffic is not sent to the same IP address from which the reply will come. Broadcast traffic is sent to the address xxx.xxx.xxx.255, but the unicast replies from that subnet may come from any (or all) addresses in the range xxx.xxx.xxx.1-254.

        Normal stateful firewall rules typically only open the firewall for replies from the same IP address to which the originating traffic was sent, so even if unicast port 9909 UDP traffic is enabled and working, broadcast traffic may still fail. Therefore, most firewalls have special rules that can be applied to allow broadcasts to function correctly, (such as ip helper-address, ip directed-broadcast and ip forward-port functions on Cisco equipment, for example). Check with your firewall manufacturer for the correct broadcast address configuration instructions for your particular systems.

      UDP & ICMP Timeouts
      UDP packets are subject to numerous possible delays, particularly on busy networks or across slower links. This can cause some machines to not respond to scans reliably. You may be able to compensate for some of these issues by increasing the UDP/ICMP Send and Receive values.

         UDP and ICMP Timeouts 

             Send: 

          ms (1 to 5000)
             Receive: 

          ms (1 to 10000)
         

          Presets:
            

        If you have configured broadcasts and multicasts correctly, and you know for certain that your routers, firewalls, and switches are configured correctly to pass the traffic, and yet you are not seeing all of your remote machines, you may need to increase your timeout settings.

        The Presets: drop-down list allows you to quickly pick recommended values for various network configurations. You can use these values as suggested starting points to adjust your timeouts.

        For troubleshooting, you may want to temporarily pick the longest timeout preset (Satellite Link) to eliminate timeouts as a connection issue. However, in production, set timeouts only long enough to receive responses from all of your systems. Setting too large of a timeout will result in scans taking an excessively long time to complete.

 

Scan Options...
If you choose Options -> Network Options -> Scan Options... from Manager's menu, you'll see a dialog with the following settings:
     Network Scans 

    Scan for Domain Time II machines on startup
    Scan for NTP servers on startup
    If a known NTP server does not respond to scan, try to contact it directly

    These items control how Manager handles discovery scanning.

      If desired, Manager can transmit a special discovery packet to the network (using Multicast and/or IPv4 Broadcast) to locate existing Domain Time components or NTP Servers. Any machine that hears the discovery packet will then respond back to Manager via a unicast UDP packet containing its synchronization status and other data. Machines responding to these discovery queries will populate the Domain Time II Machines and NTP Servers lists on the Manager Tree pane.

      You can choose have Manager run the discovery scan each time it starts. Scans can take quite some time to complete, especially on large networks, so you may want to run them manually only when needed. Scans can be triggered manually by highlighting the Domain Time II Machines or NTP Servers category in the Tree pane and right-clicking to choose Refresh from the context menu (or Actions -> Refresh from the main menu).

      The If a known NTP server does not respond to scan, try to contact it directly selection tells Manager to try a unicast time request to determine the status of an NTP machine if the original discovery attempt fails. This results in more reliable scans, at the cost of slightly more network traffic.

     

    Next Proceed to the Using Templates page
    Back Back to the How to Manage Domain Time Remotely page

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