The Domain Time II Management tools include many useful diagnostic and utility programs.
Many of these utilities are installed automatically when Manager is installed, and are located in
the Domain Time II Program Folder (usually C:\Program Files\Domain Time II).
Others are installed when Server or Client are installed and found in the \System32 folder.
Some are not installed by default, but only found in the original distribution file folders.
Click a link to jump to the description for the tool:
DTCheck
This multi-purpose utility can check statistics, trigger Domain Time synchronizations, check clock accuracy, open firewall ports for Domain Time II use, generate high-accuracy variance reports, and more.
This tool is installed in the /System32 folder on Server, Client, and Manager.
Run DTCheck /? from a command prompt to see a list of all the available parameters and options.
You can examine the statistics (sample) of any
Domain Time II server or client, force the synchronization of a particular
machine (or of the entire time hierarchy), and generate a system-wide variance report
(sample).
Note: DTCheck's variance reporting is much more accurate than LMCheck utility, since it
uses higher accuracy protocols and sampling methods from installed Domain Time II components.
Use this utility for variance reports on networks that have Domain Time Servers and Clients installed.
DTCheck can add Windows firewall exemptions for time protocols, view PTP Masters and display PTP traffic,
act as an SNMP listener, and much more. See the Help (run with the /? switch) for details.
DTCheck can also be used to test your machine's clock for reliability. Run
DTCheck /test to test your machine. You will need to reboot the
OS after reliability testing, since parameters changed during the test can only be reset at boot-time.
NTPCheck
A utility for testing NTP/SNTP time servers.
Use this utility if you need to save NTP server tests to a file, or want to run regular tests in a batch file. This tool is installed in the /System32 folder on Server, Client, and Manager.
NTPCheck provides clock test information similar to that of DTCheck, but uses the NTP/SNTP
protocol to query servers instead of the Domain Time II protocol. It is useful for determining whether or not a
particular server is reachable and operating, and for comparing the time reported by
multiple servers.
NTPCheck is also useful for demonstrating the limits of NTP/SNTP accuracy. With the -raw option, you can see the results
of other information derived from the NTP packets.
For example, here are two actual sample reports
generated by querying time.nist.gov. The first query shows the standard NTPCheck response; the second
query shows the results of the -raw option.
PTPCheck
A utility for viewing the available PTP protocol messages (in particular, management messages) visible from any PTP node.
This tool is installed in the /System32 folder on Server, Client, and Manager (as of v5.2.b.20171101).
You may copy the PTPCheck.EXE to any Windows machine to run the tests, whether Domain Time is installed or not. This gives you the
ability to see what messages are available across various routers, boundary clocks, and subnets.
Why do I need this tool?
PTP management messages are optional in the PTP IEEE 1588-2008/2019 specifications and implemented differently by different vendors and services.
The Domain Time PTP Monitor function of Domain Time Audit Server
relies on management messages to collect variance and audit data, so it's important to know if (a) any particular node or device is able
to respond to management queries, and (b) if those replies are visible throughout your network.
Configuring a scan
You can start PTPCheck either by running PTPCHECK.EXE directly or by launching the program by right-clicking and selecting to scan from the context menu in Manager's PTP Monitor section.
PTPCheck can scan for various message types across all available PTP domains using both multicast and unicast tests. You can (and should)
restrict your scans to only domains and subnets you know exist, as well as choosing to scan using IPv4 and/or IPv6 traffic based on your network
configuration. This speeds your test and cuts down on spurious traffic across your network.
Use the PTP Domains, Muticast TTL, and Boundary Hops settings to set the scope of your tests. Set the PTP Domains
to the domain number(s) you know are in use. You may list them (comma-separated) or set a range if there are several. The TTL value
specifies how many routers the packet can cross. The boundary hops setting is used by PTP-aware switches to limit traffic. You must
set the TTL to a sufficiently high number to cross all routers (including VLANs). Keep in mind that the responding node's TTL must also
be set high enough for the replies to make it back. Set the boundary hops to 1 more than the number of boundary clocks between the machine
running PTPCheck and the target machine. (There is no corresponding boundary hops to set on the receiving machine).
Note, even if you set the hop counts properly, many boundary clocks and PTP-aware switches prevent the passage of management messages
not only to other subnets, but even to other ports on the same switch. Use PTPCheck on multiple machines to see if your switches are
actually passing managment traffic. If your switch is not passing management messages, contact the manufacturer for a patch.
Configure the Discovery Options
Choose Edit -> Discovery Options from the PTPCheck menu. This displays all of the available message types PTPCheck can scan for.
Note, this is not an exhaustive list of all available PTP messages. It is meant to focus on managment messages using in monitoring, although
several other standard message types may be selected. PTPCheck only sends GET requests and listens passively for Announces and Syncs; it
cannot set variables on PTP nodes. Overheard Announces and Syncs are useful for discovering master nodes, and PTPCheck disassembles some
of the information for you, but it cannot analyze packets it has not received. Use a protocol analyzer like Wireshark for
detailed troubleshooting of PTP synchronzation.
Click the Defaults link to reset the selections to the default message types used by PTP Monitor.
This is the most useful selection for testing compatibility with Audit Server. You may, of course, add or subtract from the default
selections to gather more information from your devices/nodes.
Each node/device takes a discrete amount of time to respond to requests, and there are often delays in its ability to respond to
sequential requests of different types. You can set the amount of delay between sending requests and also how long PTPCheck waits to
hear a response (the Pause for Observation value). The Pause for Observation time is most useful for overhearing Announces and
Syncs. Many master clocks do not respond to management messages, so the only way to detect them is by listening to them talk to the
network. You will need to experiment with your particular nodes to choose the optimal settings that give you consistent results.
Run a Scan
You can run a network-wide scan based on the configuration settings you made above by clicking the
button. Scans send multicast messages to the wildcard portIdentity (AllClock.AllPorts). Responding machines will send back multicast packets
directed to PTPCheck. The list of nodes is then filled with responders. PTPCheck cannot tell you anything about a node that does not respond at all
to wildcard multicasts. A red indicator bulb means the node was detected, but did not respond to any management messages (this almost always means it
is an overheard master that doesn't handle management messages). A yellow indicator bulb means the node was detected, but either didn't respond to all
queries, or responded to one or more with an error response. A green indicator bulb means that the node correctly responding to all management messages
sent by PTPCheck.
You can test a single IP or DNS name (either IPv4 or IPv6) by using the Unicast Test field. Click the
button to send your configured list of management messages to the selected IP. Note that PTP requires a targetPortIdentity, even when messages are
unicast directly to a particular node. PTPCheck uses the wildcard portIdentity in the unicast test. Some interpretations of IEEE 1588-2008/2019 forbid
nodes from responding to unicast requests if the targetPortIdentity is a wildcard, so devices that respond to multicast queries may or may not
respond to unicast queries.
Another convenient way to send multicast or unicast messages to an individual machine is to first run a Scan, which will display
all visible nodes, then then right-click on any node in the list and choose to send either multicast or unicast requests directly to that node.
(If the node is a master, you may also test the delay request-response cycle.) Unlike the Scan and Test buttons, right-clicking a node sends
a message with the targetPortIdentity set to the node's actual portIdentity instead of a wildcard. If you are testing unicast and the node
has more than one IP, you may choose to which IP the requests should be sent.
View the Results
The node list will show the intial summary results of the scan. The number of messages sent and successful replies received is shown in the Replies column.
The Errs column shows the number of messages to which a node replied, but with an error message instead of a management reply. For example,
if you send six management queries, and a node responds to all of them, the Replies column will show "6 of 6" and the indicator bulb will be green,
unless one or more replies were errors -- in that case, the Errs column will show how many of the replies were error messages, and the indicator bulb
will be yellow.
To view the detailed results of a scan or an individual test, double-click on the the node name in the node list. All messages types
sent (as configured on the Discovery Options dialog above) will be listed. Failed types will be in red.
You can expand each green item to see the detailed contents of the replies received. Domain Time's PTP Monitor combines
a number of these messages to provide the information displayed on its readout. This can help you determine if your device is
providing correct and sufficient information. Recall that each manufacturer determines which messages to support and how, so
you cannot expect every device to provide all messages.
As mentioned above, the Default settings on the Discovery Options page reflect the message types used by PTP Monitor, so
pay particular attention to those items.
You can save your test results to a text file by clicking the button.
Here's a sample of the output. Tech Support may request this file when troubleshooting PTP issues.
Master Monitor
Introduced in v5.2.b.20190701, Master Monitor shows all current masters and their sync timestamps, regardless of PTP domain they use.
This is very useful to determine if there is more than one active master is on your network, and if they are serving roughly the correct time-of-day.
This tool derives the delta values from the announce, sync, and sync followup packets from each master, but it doesn't perform any delay measurement.
Therefore, the displayed delta will not be as accurate as you would see from a slave synchronized to the Master. However, it does provide a good eyeball glance
at the state of your masters.
Domain Time Removal Tool (DTClean)
DTClean is a utility that completely removes all traces of Domain Time II programs and registry settings from your system. This tool is included with Server, Client, and Manager.
With Server and Client the tool is located in the distribution file folders; with Manager it is located in the Program Files\Domain Time II folders
DTClean should be used with care, since it removes all configuration settings as well as program executables. If you are upgrading to
a newer version of Domain Time, you should use the Setup program or
Domain Time II Manager instead.
DTClean keeps a log of the components it removes, and you may save a copy of the log file for troubleshooting purposes or to supply to technical
support if requested.
DTTest
Use this utility to test the clock stability of any time server. Use it to determine which servers to use as time sources,
or to troubleshoot accuracy issues.
Enter the server name or IP address of the time server you want to test in the Server field.
Use the Proto drop-down list to select the time protocol to use for the test (this protocol must be running on the server being tested).
Click the Start Button to begin the test.
You may also want to adjust how many times and how rapidly to test each server by adjusting the Poll Interval and Number of Tests items.
Different poll rates affect can affect how much detail you see in the server's response characteristics. You may want to compare a very rapid sample rate
to the results from a fairly slow sample to see if the server has resolution or response issues when under rapid load.
Hint: If you will be testing against a Domain Time II Server, you will want to temporarily disable the Denial-of-Service protection on the Server. If you don't,
Server will interpret rapid test rates as a Denial-of-Service attack and stop responding to your tests.
The test will show a running list and a real-time graph showing of the amount of latency detected in the network connection, and also how large a variance exists between
your local system clock and the server being tested.
Since both the local machine and the remote system clocks and protocols have some built-in
inaccuracies, the values displayed will fluctuate occasionally. However, you should be able to see an overall trend in multiple tests -
stable clocks will show a fairly consistent variance, unstable clocks will have constantly varying values.
You can adjust the scale of the graph to show the graph in proper perspective to the accuracy you are expecting to achieve.
LMCheck
Use LMCheck to obtain a quick variance report and save the results to a file. Use this tool to do a quick & dirty check of network synchronization
on a network that doesn't already have Domain Time II installed.
Nothing to install -- remote machines only have to be running Windows (XP or later) Just run the 32-bit or 64-bit version of LMCHECK.EXE from any Windows machine.
Notes:
— Target machines must be running Microsoft Networking (with NetBIOS-enabled) and respond to NetRemoteTOD queries.
NetBT is disabled by default on most current versions of Windows and must be re-enabled to use LMCheck.
— On recent versions of Windows, you must run the program as Administrator (right-click and choose Run As Administrator from the context menu).
— The variance report generated by LMCheck cannot be as detailed or as accurate as
variance reports provided by the Domain Time II Manager,
the Monitor Service, the
DTCheck utility, or Domain Time II Audit Server,
each of which use much more accurate time protocols and
sampling methods to measure the time differentials.
The Domain Time LMCheck test tool lets you roughly assess the current time of Windows machines on your network
quickly and easily. It uses the built-in LAN Manager NetRemote TOD (Time of Day) function to check the time on all the
machines in the browse list.
Click the Start button to perform the scan. Click the Save Results button to
pull the results up in Notepad so that you may save them wherever you wish.
Time variances from the machine on which you run LMCheck are calculated and displayed,
taking into account any network latencies. You may select the domain you wish to scan
from the drop-down list.
Although it is included as part of the licensed Domain Time II Management Tools, LMCheck itself is unsupported freeware, and can be
freely distributed as long as the program is unmodified.
Domain Time II Remote CPL (DTRCPL)
Use the Remote CPL utility to quickly connect to a Domain Time II Server or Full Client and change its Control Panel Applet settings. This is a useful utility
when all you need to do is change a control panel applet setting and you don't need the full power of Domain Time II Manager.
Choose a machine running Domain Time II Server or Full Client from the drop-down list, browse list, or enter its IP address, DNS name, or NETBIOS name
into the Machine field. If the connection is successful, you will be presented with a locally-running version of the remote machines' Domain Time II Control Panel Applet.
You will then be able to make all the configuration changes you would if you were actually using the remote machine (with the exception of running Time Source tests).
The DTRCPL utility is subject to the same requirements as Domain Time II Manager in order to connect to and control a remote system:
Your network must be a correctly-configured Windows network, i.e. configured with working name resolution
(DNS, WINS, NetBIOS, etc.), correct and functioning Active Directory (if used), working inter-domain trusts, etc.
Your network must pass both UDP and TCP network traffic sent to destination port 9909. Switches and firewalls
must pass this traffic bi-directionally, since traffic will originate either from Manager or the remote machines.
Your network must pass this traffic, regardless of what time protocols are used to actually synchronize the time.
Note: As of Version 5.2.b.20150821, Domain Time supports automatic management of the Windows Firewall to allow access to the required time protocol and control ports.
See Auto-Manage Windows Firewall Settings for detailed information.
The remote machine must respond to PING requests from the connecting machine.
The connecting Domain Time program, utility, or service must be run using credentials with sufficient privileges
to connect to and write files to the administrative shares on the remote machine using Microsoft Networking (Domain
Admin if the target is a domain member, Local Machine Administrator if the target is in a workgroup).
The Remote Registry Service must be running on the remote systems and its registry keys must be accessible to the
connecting program.
DTSync
Use this utility to trigger a sync on specified machines from the command line.
Run DTSync from a command prompt to see a list of all the available parameters and options.
DTSync allows you to specify timeouts and to set the ERRORLEVEL variable so you can create robust batch files to reliably trigger
synchronization, even across WAN links.
DTSlew
This utility allows you to smoothly slew the local clock by large amounts.
Use this utility to move the local clock forward or backward by the amount you specify. The clock will be advanced or retarded using slewing,
so you can make the change smoothly with no clock stepping or backwards clock movement.
This is useful if you have to manually change the time on machines running critical services that must have smooth forward clock movement at
all times. DTSlew also allows you to make larger changes than would normally be possible by Domain Time Server or Client.
The rate of change is limited to the maximum amount of slewing possible by the hardware on the motherboard. DTSlew will not allow you to
select a rate that is outside of these limits.
Note: You will need to stop the Domain Time Server or Client service before running DTSlew in order to prevent conflicts over clock '
control.
Do NOT attempt to serve time from a machine running DTSlew, this will cause unpredictable results on your clients as they
attempt to track with the time server (such as unexpected stepping).
Domain Time Lockdown (DTLockDN)
Domain Time Lockdown is a command-line tool for system administrators to use to help secure (harden) their Domain Time installations.
Domain Time Lockdown is useful to system administrators as part of an overall
company-wide security policy.
What does it do?
Domain Time Lockdown lets you set permissions for
The Domain Time service object
The service object is the handle presented by the operating
system to programs wanting to control the service. Just like
files or other objects, the service object may have permissions
associated with it. Service object permissions control who is
allowed to stop, start, query, or configure the service.
The operating system's services database
The operating system maintains an internal database of
service objects, including their current status, their
permissions, and their settings. Most of this information is stored
in the registry under HKLM\System\CurrentControlSet\Services. Ordinary
users do not have permission to modify these settings. This area is
where the operating system keeps the name of the service executable file,
the restart on failure options, the startup type, and so forth.
The Domain Time parameters stored in the registry
Domain Time keeps its configuration in HKLM\Software\Greyware\product,
where product may be either Domain Time Client or Domain Time Server.
Information in this area controls what Domain Time does once it is running
as a service (time sources, how often to check, system timings, logging
options, and all other settings).
The Domain Time service executable (domtimec.exe or domtimes.exe)
The main service executable lives in the system32 directory. Administrators
(and often users) have rights in both the containing folder and the individual
files. If users have the right to add or delete files in the folder, they can
also delete or rename the service executable, even if the executable file itself
is restricted to read-only or has a specific deny ACE protecting it from deletion.
The only way to prevent a user who has delete rights for the folder from deleting
an individual file is to add a null ACE (effectively remove all permissions).
Therefore, unlike the other objects, when you set a user or group to have only
READ access, the program will actually remove all access from the executable
file for that user or group.
Aren't the default permissions sufficient?
In most circumstances, yes. Non-administrative users typically don't have
the ability to stop, remove, or even install services. They may have limited
abilities to control what the running service does, or trigger it to take
certain actions—these options vary by the service, and Microsoft and other
vendors typically use sensible defaults to help ensure that only administrators
can change vital settings.
However, home users (and even some business users) may use an administrative
account as their primary logon. Security experts strongly discourage this
practice, and Microsoft's own UAC has taken steps to help mitigate the dangers
of logging on this way, but nevertheless it is not uncommon for ordinary
users to find themselves with full administrative control over their machines,
perhaps without even realizing it.
Other accounts or groups sometimes have unintended privileges. On regular
workstations, the Power Users group typically has additional control over services.
On Domain Controllers, the Server Operators group has similar privileges. Individual
accounts or other groups may also be configured to have extended privileges using
system or domain policies.
How does it work?
Domain Time Lockdown edits or replaces the
access control lists to restrict control access and optionally enable auditing. It can also set the service to
restart automatically if killed. (The Microsoft property page for service control only allows setting the restart
time on the order of minutes; Domain Time Lockdown lets you set a restart time in milliseconds.)
Domain Time Lockdown only supports READ or FULL permissions. READ permissions are required in order for
users to query the service, see the current settings, and operate the computer normally. FULL permissions
include all READ permissions plus the ability to stop, remove, upgrade, or configure the service.
For example, you could use Domain Time Lockdown to grant FULL permissions to the built-in Administrator
account while granting only READ permissions to the built-in Administrators group. This would allow anyone
logged in as the local built-in Administrator to control the service, while other members of the Administrators group
(including Domain Admins if the machine is a member of a domain) could only view the settings.
There is no predefined hardening for a service, because what access you need to restrict and what access
you need to allow is dependent on your network's policies and configuration.
Options containing embedded spaces must be enclosed in quotation marks.
If you do not specify service= and a service name, the
program will look for either Domain Time Client or Domain Time Server (whichever)
is installed. If you do specify a service name, it may be any installed service
on the machine. We do not support using this program on services other than Domain
Time Client or Domain Time Server.
Options
/Show
Show current settings; do not make any changes.
/Restart=nnn
Set service to auto-restart if killed after nnn milliseconds.
/NoRestart
Set service to not auto-restart if killed.
/Audit
1
Enable auditing of unauthorized access.
/NoAudit
Disable auditing of unauthorized access.
/Full="Account"
2
Grant "Account" full control of the service.
/Read="Account"
2
Restrict "Account" to read-only access to the service.
/Revoke="Account"
2
Remove "Account" from the service's access control list.
/Replace
3
Replace permissions instead of merging them.
/ServiceOnly
Apply security only to the service object and executable.
/RegistryOnly
Apply security only to the registry objects.
/Yes
Do not ask for confirmation before making changes. You may
use either /Yes or /Y.
/Password="password"
4
Set password to lock out subsequent changes. If a password is set,
you must provide exactly the same password in the future, or the program
will refuse to perform. The only way to clear a password once it has been
set is by issuing the /Reset command with the
correct password.
/Reset
4
Reset the service and registry to default access (read for ordinary users,
full control for administrators and the system). If you have set a password
using the /password option, you cannot reset the
service without providing the correct password again.
1
Enabling auditing with this program sets the appropriate bits in each object's
SACL to allow the system to record failed access in the system's security log.
If your machine's policy does not have failure auditing enabled for object
access, then no entries will appear in the security log.
2
You may specify a username or a group name for Account. If the name
contains embedded spaces, you must enclose it in quotation marks. You may use
plain names, such as Users, "Power Users", Administrator,
or Joe to refer to accounts or groups on the local machine. You may
also refer to domain users or groups this way. If there is any chance of
account name duplication throughout your domain or forest, you should specify
the full names: BUILTIN\Administrator, "BIGCORP\Domain Admins" or
other fully-qualified names. In some circumstances, depending on your active
directory configuration, you may be able to use the joe@bigcorp.com form
to specify individual accounts.
3
The program will ensure that the special SYSTEM account always has full control.
It is an error to specify SYSTEM as an account on the command line. The program will also ensure that
ordinary users and administrators will have the ability to read values they
should read, even if you try to /Revoke those permissions,
or use /Replace without specifying all the necessary
accounts.
4
Exercise caution when using the optional /password option.
Once you enter a password, you must provide it again exactly the
same way in order to use the program again. For example, MyPassword,
mypassword, and MYPASSWORD are three different passwords. If
your password contains embedded spaces, you must enclose it in quotation
marks. The best password contain a mixture of upper-case and lower-case letters,
numbers, and punctuation marks. Passwords are stored using one-way encryption,
so we cannot help you recover your password if you forget.
Once a password is set, you must provide it for each use of the program
thereafter. The only way to clear a password is to use the /Reset
command, but you must provide the current password to do so. After a reset,
you may then set a different password if desired.
This example allows the built-in Administrator account to control the service, but
blocks all other members of the Administrators group. Any permissions granted by
inheritance or prior operations will be replaced.
dtlockdn /restart=1000
This example changes only the service's auto-resetart time. If the service dies unexpectedly,
or is killed using Task Manager or another tool, it will restart in 1000
milliseconds (one second).
This example is similar to the first example, but also grants the group Domain Admins full
control, sets the service to restart automatically if killed, sets a password, and suppresses
the prompt before executing.
dtlockdn /reset /password="nzlwOOFm_#gadlob88$"
This example recovers control after permissions have been locked down. The security will be
reset to generic defaults, and the password will be removed. Note that if a password hadn't
been set, any user with full administrative rights on the machine could have issued the
/Reset command and then reconfigured the security and perhaps have
added a different password.
