This page contains options for additional features to monitor the Domain Time service in real-time.

Note: If you see the Group Policy applied indicator in the lower-left corner of the applet, there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here. See the Active Directory page for more information on using Group Policies.

Domain Time Server and Client are designed to be centrally monitored and have their synchronization status recorded by Domain Time Audit Server. This is usually done by Audit Server in a scheduled, background data collection process.

However, Domain Time II Server and Client can send an immediate notification packet to Audit Server containing feedback on the success or failure of each time check to provide real-time monitoring and alerting. Domain Time Manager on the Audit Server machine will display the collected data on its Real-Time Alerts panel. See the Audit Server Alerts pages for more information on setting up Real-Time Alerts.

If you want this function, check the Enabled checkbox and enter the DNS name or IP address of your Primary Audit Server.

As of version 5.2, you may specify addresses for both a Primary and Secondary server for redundancy purposes. Use the radio buttons to select whether to
  send to the backup only if primary is down, or to
  send to both primary and backup servers.

This function is designed to work well with the Audit Server "Hot Spare" standby mode functionality introduced in version 5.2.

Select whether to use TCP or UDP for the notifications. In general, TCP is more reliable than UDP since delivery of TCP traffic is given priority, whereas UDP can be delayed or dropped entirely by busy network hardware. However, TCP does require more resources on the network stack of the Audit Server to handle the mechanics of building and tearing down TCP connections. If you have many machines sending lots of real-time updates using TCP, it is possible to exceed your operating system's ability to handle the number of open network connections. If you run into those limitations, you may want to consider changing your alert notices to UDP.

CAUTION:


---

If you are using notifications on many machines that are set to synchronize frequently, the feature can generate a significant amount of network traffic toward your Audit Server. You will probably want to enable instant notifications only on critical systems where an immediate alert of time sync errors is desired.

Otherwise, you should use Audit Server's normal scheduled sync log collection instead, which is much more efficient. Audit Server's sync log collection can run in a background process to gather all sync records from audited systems with much less impact on overhead than active notifications. Audit Server can be programmed to provide alerts based on that data as well.

---

Audit controls
As of version 5.2.b.20110224, you have the option to have the Domain Time service control its own inclusion in or exclusion from the Audit Server Audit list.

Always audit this machine
Never audit this machine
Do not change audited status


These options override any existing settings on the Audit Server itself. You may use these functions to ensure that machines are (or are not) audited whether or not they are discovered by Audit Server.

The Service Status Monitor section controls whether Domain Time will provide a simple text response about its current status when asked by an application.

If you need more sophisticated monitoring and status than provided above, Domain Time Server and Client (as of version 5.1) provide a documented API (Application Programming Interface) so that developers can have programmatic access to a number of Domain Time internal features. In addition to service status, the most important feature of the API is the ability to have direct access to the same high-resolution corrected system time Domain Time uses to manage the clock.

Using the pre-compiled .dlls (32-bit or 64-bit) from the SDK, programs can make a simple API call in their native language to obtain date/time accurate, monotonically-incrementing hectonanosecond-resolution timestamps without any additional programming. There's no need to design your own timing and interpolation routines or to navigate Windows' labyrinthine timer and system clock internals. The SDK includes the .dlls and sample code in a variety of programming languages so you can be up-and-running with hectonanosecond-resolution timestamps immediately.

See the Software Development Kit (SDK) page for more details and information on obtaining the SDK.

 Proceed to the Advanced page

 Back to the SNMP Traps page