Top of Page

Domain Time II Manager
Version 5.2

Other Management Tools


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  - Multi-purpose Utility
    .   NTPCheck  - NTP Server Test
    .   PTPCheck  - PTP Messages Test Utility
    .   DTClean  - Complete Removal Tool
    .   DTTest  - Time Server Test Utility
    .   LMCheck  - Simple Variance Check
    .   DTSync  - Sync Trigger
    .   DTRCPL  - Remote CPL
    .   DTSlew  - Manual Slew Utility
    .   DTLockDN  - Security Lockdown 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 specification 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
    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 IEEE1588-2008 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.

 

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.

    To test a time server:

    1. Enter the server name or IP address of the time server you want to test in the Server field.
    2. 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).
    3. 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

    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.

    Note: 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. Also, LMCheck cannot measure any systems not running Microsoft Networking (with NetBIOS enabled).

    Generally, you will only want to use LMCheck to obtain a quick snapshot of the time variance on networks where Domain Time is not yet installed.

    Although it is included as part of the licensed Domain Time II Management Tools, LMCheck itself is freeware, and can be downloaded separately and freely distributed as long as the program is unmodified.

    *Target machines must be running Microsoft Networking (with NetBIOS-enabled) and respond to NetRemoteTOD queries.

     

 

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:

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

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

  • Who needs it?

    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

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

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

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

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

  • Syntax

      dtlockdn [service="Service Display Name"] [options...]

      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.

      Examples


      dtlockdn /full=Administrator /read=Administrators /replace

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

      dtlockdn /full="Domain Admins" /full=Administrator /read=Administrators /replace /restart=1000 /password="nzlwOOFm_#gadlob88$" /yes

        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.

 

Previous Back to the Previous 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.