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.
Click a link to jump to the discussion about each page:
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:
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.
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.
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.
Network Discovery...
Select Options -> Network Options -> Network Discovery... from Manager's menu and the Network Discovery dialog will appear:
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 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.
Custom Broadcast Addresses
This field allows you to specify IPv4 broadcast addresses to which Manager will send directed broadcasts.
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.
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
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.
All local subnets (more thorough)
Primary subnet only (faster)
These options select whether the discovery packet is sent out only over the interface the operating system has designated as the primary interface
or through all interfaces.
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 IPv4 TTL: and IPV6 Hops:
entries set how many router hops a multicast packet should make when propagating through
your network. Choose a value that allows your multicasts to reach all of your subnets.
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 Send and Receive values.
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:
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.
Settings in these sections control what type of packets are used by Manager to run network scans and how broadly they propagate.
The TTL (Time-to-live), called Hops in IPv6, value sets how many router hops a multicast should make when propagating through
your network. Choose a value that allows your multicasts to reach all of your subnets.
Primary subnet only (faster)
All local subnets (more thorough)
This selection applies only to machines with multiple network interfaces. They determine whether broadcasts are sent only to the
subnet visible on the primary interface or to all subnets visible through the secondary interfaces.
Manager uses UDP packets for various purposes (such as scanning), and also sends ICMP packets when querying machines for remote control.
UDP and ICMP packets are subject to numerous possible delays, particularly on busy networks or across slower links. This can cause
unreliable behavior when working with machines across these links. You may be able to compensate for some of these issues by adjusting
the timeout values used by Manager when sending and receiving these packets.
You can select from suggested values for the timeout periods by choosing a preset from this list. They are listed in order of timeout
length from the shortest (Fast LAN) to the longest (Satellite Link).
Set timeout values only long enough to reliably receive responses from all of your systems. Setting excessive timeouts will result in queries
taking an unnecessarily long time to complete.
Proceed to the Using Templates page
Back to the How to Manage Domain Time Remotely page