Audit Server can collect a variety of data from audited systems. It can then present this data to you in different ways to help monitor the health of your network time,
interface with other systems, and for regulatory compliance purposes.
Audit Data Types
Audit Server collects two main types of data from audited systems. You can view any type of data collected by Audit Server by clicking on the "Audit Server" category in the left-hand column of Manager's interface
Audit Results Records - a snapshot record of information about the audited system taken at the time of the audit.
It contains information such as current time on the target, it's last time source, etc. Daily Reports can be generated
based on the Audit Result Records during each audit run to summarize and/or export data.
Synchronization (Drift) logs - a running log of time deltas (either reported or measured, depending on the type of audited time client and protocol).
Ouput
Domain Time can output collected data in several formats. Collected Synchronization logs may be viewed using the Drift Viewer and/or converted to CSV or text formats.
The Audit Logs from audit runs can be output to Syslog servers. And, the Daily Reports function allows you to create a customized report of your audit runs and results.
You may also send email summaries of audit runs.
Audit Results Records
Audit Results Records are highly compact collections of data collected from audited systems during an audit run.
Audit Results records can be gathered from
— Domain Time systems on Windows
— domtimed daemons running on 'nix systems
— From machines running NTP daemons that respond to time request packets
— From machines running PTP (IEEE 1588-2008/2019) that respond to management messages via PTP Monitor
Domain Time machines will provide more complete statistics on their operation than do NTP sources, but both contain enough
data for auditing/alerting purposes.
The data from all audited machines during an audit run are collected into audit results files kept in the Audit Data Cache folder.
The folder location is specified on the Audit Server -> Advanced -> Data Folders... menu (by default, C:\Program Files\Domain Time II\Audit Data Cache).
Each audit run results in a new file.
Disk requirements
Although each individual audit record file is small, the
size of each individual audit results file depends on how many machines are included. If unattended (and unlimited by the Audit Tasks setting described above), the folder can grow to contain a very large amount of data.
You should plan to regularly archive this data off to your normal archival storage.
Please see the Audit Disk Space Estimator page to calculate your disk space requirements for storing audit data.
You may configure Audit Server to limit the growth of the Audit Data Cache by deleting all Audit Results Records over a certain age.
This setting is found on the Audit Server -> Audit Tasks menu item.
Audit Results Records are viewed using a utility program called Audit Data Viewer (DTREADER.EXE-launched automatically when you view results through Manager).
The DTReader utility is associated with files having the extension .dtad (DT Audit Data) during the installation of Audit Server. However, it can be used to view Audit Record Results files on other systems.
Simply copy the program to any machine from which you'd like to view audit records.
Note: DTREADER.EXE does not function on Windows Server Core systems.
To view sync logs collected by Audit Server on Server Core systems, you must copy the DTREADER.EXE utility to a non-Core system and use it from there to view the .dtad audit records through a network share on the Core machine.
Synchronization (Drift) Logs
Audit Server can collect or generate several types of synchronization logs from audited machines into a central location
where they can be reviewed, maintained, or archived off for data retention purposes.
Logs collected from Domain Time Servers and Clients:
Domain Time II Synchronization logs - a running log of the results of each successful DT2 or NTP time synchronization
(or sample aggregation if using PTP) by the Domain Time Server or Client.
Domain Time II Synchronization logs are only available from Domain Time Clients or Servers.
The logs are kept locally on each Server or Client, but are copied and appended to to the Audit Server data store
during an audit run. The time deltas contained in these records show the results of time corrections applied by Client or Server
to match its configured time source(s). This information is reported by the audited machine itself and reflects its
perspective of time accuracy as compared to its sources.
Machines selected to be audited on either the Domains and Workgroups or Domain Time Nodes lists in Manager
will collect this type of sychronization log. Domain Time Synchronization log filenames begin with the Domain Time Serial Number and have the file extension .dt
Domain Time II PTP Offset Synchronization logs - a running log of the reported offset between the Domain Time Slave and its PTP Master (using the PTP protocol).
Domain Time II PTP Offset Synchronization logs are only available from Domain Time Clients or Servers.
The logs are kept locally on each Server or Client, but are copied and appended to to the Audit Server data store
during an audit run. The time deltas contained in these records show the results of time corrections applied by Client or
Server to match its PTP master. This information is reported by the audited machine itself and reflects its
perspective of time accuracy as compared to its sources.
Machines selected to be audited on either the Domains and Workgroups or Domain Time Nodes lists in Manager
will collect this type of sychronization log (if also enabled on the Synchronization Log configuration dialog).
Domain Time PTP Offset Synchronization log filenames begin with the Domain Time Serial Number and have the file extension _ptp.dt
Notes:
Domain Time II Synchronization Logs can only be collected from Domain Time II Server and Clients version 3.1 and later.
Domain Time II PTP Offset Logs may only be collected if all components (Audit Server/Manager and Client/Server) are version 5.2.b.2015037 or later.
Both of these logs are limited in size on the Client or Server and older data scrolls off over time. Using Audit Server to collect this information allows you to preserve this data for audit trail and archival purposes. Note, in order to have a complete central record,
you must Audit the machines often enough to collect the data before it scrolls off on the individual machines.
Connecting to Domain Time versions prior to 5.2, the Audit Server must use credentials with sufficient rights to connect to the
administrative shares on the remote systems to collect drift logs. Current versions obtain the data using direct communication over Port 9909 UDP/TCP.
Drift Logs generated by tracking other systems:
NTP Server Drift logs - a running log of the time deltas of audited NTP machines measured at the time of each audit run
or collected on a set polling schedule.
NTP Server Drift logs can be collected from any machine that can be configured to respond to standard NTP time requests (such as ntpd or chrony on Linux). Drift files for
each audited NTP machines are created/appended to during audit runs or on a set polling schedule. The time deltas contained in these records show the
measured difference between the NTP timestamp replies and Manager's configured Reference Time source(s).
Machines selected to be audited on Manager's NTP Nodes list will collect this type of sychronization log.
NTP Server Drift log filenames begin with NTP Server and end in _ntp.dt
PTP Node Drift logs - a running log of the deltas (either reported or measured) of audited PTP Nodes.
As of Domain Time version 5.2.b.20170101, PTP Node Drift logs can be collected from any machine that is discovered
by PTP Monitor. Drift files for each audited node are created/appended to during audit runs.
When collecting PTP master data, the delta reported is the measured difference between the Master's announced time and
Manager's configured Reference Time source(s).
When collecting PTP slave data, the delta reported is the reported offset between the slave and
its master. See the Offset measurement section of the PTP Monitor documentation for details.
Machines selected to be audited on the PTP Nodes list
will collect this type of sychronization log (if also enabled on the Synchronization Log configuration dialog).
Note:
The auditing of PTP Nodes is a separate function from other types Audit Server auditing. The "Audited"
setting's column in Manager's display for PTP Monitor is independent of the "Audited" settings
on the Domains & Workgroups, NTP Nodes, Domain Time Nodes, or Real-Time Alerts displays.
Enabling/Disabling auditing on the PTP Monitor display will not change the audit settings on the other pages, and vice versa.
PTP Nodes Drift log filenames begin with PTP Node and end in _ptp.dt
Synchronization Log Collection Settings
Use the Audit Server -> Synchronization Logs -> Configure menu item to bring up the Synchronization Configuration Dialog.
Alternately, you may right-click the Audit Server\Synchronization Logs item in Manager's Tree and choose Configure... from the context menu.
Foreground - collection must finish before audit completes Background - collection finishes independent of scheduled audits Run background collection periodically, not just at audit time
These choices determine whether Audit Server will collect the sync logs in a separate thread from the audit run itself.
Collecting sync logs from each audited machine can take an extended amount of time, particularly if you have a large
number of machines to audit. Choosing Background allows collection of the basic audit data very quickly,
and then the collection of the sync logs can complete in the background. Running the collection in the background periodically
can make collection even more efficient.
Collect NTP drift on same schedule as other drift records Collect NTP drift every seconds (range 10-3600)
These settings (new as of v5.2.b.20171113) allow you to set a schedule of how often audited NTP Nodes are polled for their
offset data, allowing you to create NTP sync logs with more data points than would normally be collected from regularly scheduled
Audits alone. This can present a more comprehensive picture of NTP Node synchronization.
Collect PTP sample data from audited Domain Time machines
Available on version 5.2.b.20150307 or higher. If the target machine is synchronizing using PTP, its PTP offset logs
can be collected at the same time as the regular drift synchronization logs.
PTP offset log collection is subject to the same limits and schedule as regular drift log collection.
Collect PTP node data from audited PTP Monitor masters
Available on version 5.2.b.20170101 or higher. If enabled, PTP masters selected to be audited on the
PTP Nodes list in Manager will have a drift file created for them.
PTP master node offsets are calculated with each received Sync or Sync/Followup (typically once per second). Data is buffered
internally by Audit Server server before being written to the file. Log collection is therefore more or less continuous
for PTP master nodes, but it still subject to the same limits as regular drift log collection.
Collect PTP node data from audited PTP Monitor slaves
Available on version 5.2.b.20170101 or higher. If enabled, PTP slaves selected to be audited on the
PTP Nodes list in Manager will have a drift file created for them. A new data point is generated with each
commanded or scheduled sweep (typically once every 30 seconds), and are buffered internally by Audit Server before
being written to the file. Log collection for PTP slaves is subject to the same limits as regular drift log collection,
but does not follow the same schedule.
Conversions
As of version 5.2.b.20180303, Audit Server has two options for auto-converting binary .dt sync logs into text formats
suitable for import into other database or analysis programs: CSV or TXT conversion. Note, the TXT method is now deprecated and should be avoided.
CSV - save drift records in Daily Drift .csv files
Due to the limitations of .txt file conversions, most notably the lack of
data points for offline nodes and the high CPU/disk usage required for
conversion, Domain Time now supports a Daily Drift CSV file as the preferred
alternative to expanding individual .dt files to .txt files.
A Daily Drift file is named Daily Drift yyyy-mm-dd.csv. As the name
implies, Audit Server creates one Daily Drift file per day. You may configure
Audit Server to keep Daily Drift files forever, or to keep only the last n
days' worth of files. Each file is organized as a comma-separated value file,
with each row representing a single data point.
Include field name header row as the first line of each file
If enabled, each Daily Drift file will begin with a header:
RowID, DateTime, UTC, NodeType, NodeName, NodeIP, CheckReason, TimeSource, SourceStratum, PTPDomain, Delta, ErrorNumber, ErrorText
(spaces after commas added in this file so word-wrap can occur; there are no spaces after commas in the .csv file itself).
The exact syntax and meaning for each column is described fully on Manager's CSV settings dialog. Click the
button to see the full definition of the columns.
Use local time for .csv filenames
If selected, Audit Server will use local time for the yyyy-mm-dd part of the filename.
If not selected, Audit Server will use UTC for the yyyy-mm-dd part of the filename.
Audit Server switches to a new file at midnight, either local time or UTC, based on this
option. Additionally, this option controls the value of the DateTime field and the
value of the UTC field within the .csv file. The default format for the DateTime field is
yyyy-mm-dd hh:mm:ss. If you are using local time, the DateTime field will be
local time, and the UTC field will be N. If using UTC, the DateTime field will
be UTC, and the UTC field will be Y.
Use ISO 8601 format for the DateTime field.
If selected, the DateTime field format will be either yyyy-mm-ddThh:mm:ssZ if
using UTC, or yyyy-mm-ddThh:mm:ss±HH:MM if using local time.
You may configure the data sources for the Daily Drift file:
DT2: Include drift records from audited Domain Time Nodes
If selected, drift records from audited Domain Time nodes will be
included. This is the data you see on any individual machine when
you click the button on the Control Panel
applet. Domain Time generates one drift record at each check interval,
so, for example, if you are checking the time once a minute, Domain
Time will generate 1440 data points per day.
DT2: Include PTP sample data from audited Domain Time Nodes
If selected, PTP sample data from audited Domain Time nodes will be
included. Domain Time nodes generate one data point per PTP sync, so
this category can produce a large amount of data. This data you see
on any individual Domain Time machine when you click the Graph
link on the Control Panel applet. If your PTP master is sending one sync
per second, Domain Time will generate 86,400 records per day.
NTP: Include drift records from audited NTP nodes
If selected, drift data from audited NTP nodes will be included. A row
will be added for each audited NTP node at each NTP drift collection
period. If an audited NTP node is offline, a row will be added with
the appropriate error number and description.
PTP: Include PTP data points from audited PTP Monitor nodes
If selected, and if PTP Monitor is enabled, drift data points from
audited PTP nodes will be included. For PTP masters, this is one data
point for each Sync. For PTP slaves, this is one data point for each
PTP sweep. The interval between sweeps is configurable. This category
can produce a very large number of records. For example, if you are
sweeping the network once per minute, each slave will generate
1440 data points per day. If you are monitoring two PTP masters,
each sending Syncs once per second, each master will generate
86,400 records per day. As with NTP nodes, a non-responding PTP node
will generate a record with the appropriate error number and
description. A record is also generated when a PTP master downgrades
its time quality, changes its leap second advertisement, or goes offline.
Audit: Include drift data from audits
If selected, one record will be generated for each audited node, regardless
of type, immediately after an audit completes. This information is essentially
the same as the audit summary, but configured to match the format of
the other data sources. If a node is offline, or exceeds your chosen
tolerance, the record will include an error code and description.
Only include error records - omit all records within defined tolerances
Introduced in version v5.2.b.20190701, this option only includes synchronization log events that exceed
the Post-Audit Alert tolerances specified in each audit group
(see Alerts and Audit Groups).
Use this option with care, since all other synchronization events will be omitted from the Daily .CSV file.
Daily Drift CheckReason Entries
The CheckReason field of the Daily Drift contains information about why each time check occurred. Here are possible entries:
CheckReason
Explanation
AuditSignal
Triggered by Audit Server
ClockChange
Sync because another user or process has changed the clock
ControlPanel
Triggered from the Domain Time applet
DT2BCast
Time received by DT2 protocol broadcast
DT2MCast
Time received by DT2 protocol multicast
Heartbeat
Triggered by a broadcast/multicast heartbeat
IndieSignal
Triggered by a Domain Time Server in the Independent Server Role
LeapSecond
Triggered after a leap second adjustment
MasterSignal
Triggered by a Domain Time Server in the Master Role
NewIPAddress
Sync due to the OS signal of a change in the IP address stack
NTPBCast
Time received by NTP protocol broadcast
NTPMCast
Time received by NTP protocol multicast
PowerResume
Sync due to the OS signal of a resume from sleep/hibernation
PTP
Time received by PTP
PTPFirstTS
Time set to match the first received PTP timestamp
PTPMaster
Sync due to a change of PTP Master
PTPSlave
Sync due to becoming a PTP Slave
PTPSweep
Sync triggered by a PTP Monitor sweep
Scheduled
Sync occurred as scheduled by the applet
SlaveSignal
Triggered by a Domain Time Server in the Slave Role
Startup
Sync due to startup of the Domain Time service
SyncTrigger
Triggered by a command from a Domain Time component
TimezoneChng
Sync due to a signal from the OS of a change to the timezone
Training
Sync occurred during an accelerated clock training sequence
VeracityCheck
Response when auditing an NTP Node
Daily Drift Error Codes
An error code of zero means no error. Otherwise, the error code represents
the reason for failure, and the error text describes the problem. If the
error code is non-zero, the Delta field will always be 0.0000000 (no delta
information available), and the TimeSource field will be "" (an empty quoted
string). When you are processing the .csv file, make sure that you don't
accept the delta of 0.0000000 as valid if the error code is non-zero.
All error codes are standard Microsoft error codes, and you may look them
up online if you are not familiar with them. For example, 10064 is
the Winsock error WSAEHOSTDOWN ("Host is down") and will usually appear with the
error text "Node offline."
A special case is error code 1246, which translates to Microsoft's ERROR_CONTINUE
("Continue with work in progress"). This code is used for informational messages
when a PTP master upgrades its quality of service or changes its leap second
flags. The error text will describe the change, but 1246 should not be considered
an error.
Daily Drift CSV Operation
Audit Server caches records internally, then flushes them to disk
approximately once every two minutes. The current Daily Drift file
is held open by Audit Server during the entire 24-hour period of
data collection. Other processes may read from, but not modify,
an open Daily Drift file.
By default, Audit Server creates a symbolic link in the drift folder
named Today (with no file extension). This is a soft link
pointing to the current day's file. You may disable this functionality
by unchecking the checkbox on the Daily Drift CSV settings dialog.
The Today link is primarily useful for automated processes that
import the .csv file into a dbms or other storage and that only
want today's information.
If you are importing Daily Drift files into your dbms or other
system throughout the day, use the RowId field to know whether
or not a record has already been imported. The RowId field begins
at 1 and increments by 1 for each row.
If you are collecting DT2 drift, or DT2 PTP sample data, be aware
that the collection schedule may affect the previous day's Daily
Drift file. For example, if you are collecting data once per hour,
the data collected at 12:15am will contain records from the previous
day. Audit Server will put yesterday's records in yesterday's file,
and today's records in today's file. Audit Server will open and
close the Daily Drift files as required.
Audit Server normally requests only new records from audited
Domain Time nodes. It remembers the last collection, and asks
for records newer than that. When you change an unaudited Domain
Time node to audited, or when you add a node that has never been
audited before, Audit Server will request all existing records.
The returned data may span several weeks, depending on how often the
Domain Time node is configured to check the time. This can create
a proliferation of Daily Drift .csv files from the recent past.
The RowId field will continue from when each Daily Drift file
was last extended, even if the Daily Drift file itself has since
been deleted.
Best Practices
You should set the drift folder to a local disk with sufficient
storage to hold all the .dt files and the .csv files. A Daily Drift
.csv file may be hundreds of megabytes. The default location is
C:\Program Files\Domain Time II\Synchronization Logs. You may
reconfigure the location from within Manager. Use the Audit Server
menu, Advanced, Data Folders dialog to change the location.
Manager will create the new folder(s) as necessary, and move
the data from the old folder(s) to the new one(s). Manager
briefly stops Audit Server to ensure that all data is flushed
to disk and no files are held open, performs the move, and then
restarts Audit Server.
For your dbms to consume the .csv information, we recommend that
you run your import procedure against each Daily Drift .csv file
(file mask "Daily Drift ????-??-??.csv") in the drift folder,
using the RowId to determine if any row for a particular day is
new. You may delete (or archive) old .csv files after
importing them. If Audit Server needs to recreate a deleted
Daily Drift file, the RowId field will continue from where the
deleted file left off.
You cannot delete the current day's Daily Drift file. Audit Server
allows the current file to be read, but not modified or deleted.
Before appending new records, Audit Server locks the portion of the
file beyond the current end, writes the new data, and then releases
the lock. If this locking behavior interferes with your import
procedure, you may disable it by unchecking the checkbox on the
Daily Drift CSV setting dialog.
TXT - expand each binary .dt file to a text file (deprecated)
Enabling this function will cause Audit Server to create a text file version of the binary sync log collection file(s). The text files will be named
and formatted according to the settings indicated. This function is deprecated as of v5.2.b.20180303.
Note: This process is very expensive in both disk and processing overhead. You can easily end up with gigabytes of textual data, taking excessively long times
to add even a single new data point. You should only use this option if you require a text file be kept for a specific purpose, since the text files are
dramatically larger than the binary files. Normally, you would use the View Logs function described below to view the binary files in a more
friendly graphical format and generate a text file only if necessary by clicking the button on the Drift Graph display.
IMPORTANT: As of v5.2.b.20171113, Audit Server will no longer attempt to create textual versions of drift files with more than 64K
records (approximately 6MB). If this occurs, a warning message will appear in Audit Server's log. To avoid issues, you should ensure your
sync logs do not exceed this number of records (see Limit size of collected Synchronization Logs section above). Consider archiving off
the sync logs (and any .txt expansions) to another location on a regular basis.
In more recent versions (as of v5.2.b.20180303), you may use the DTDRIFT.EXE program to edit the size of or repair the .dt binary drift logs.
See the Viewing/Managing Collected Logs section below.
Limit size of collected Synchronization Logs
You should restrict log size by limiting the number of records kept per machine (older records are rolled off to make room for new entries), and/or
by deleting all records over a certain age.
Audit Server provides two ways to limit the size of .dt files.
Never keep more than n records
If selected, Audit Server will periodically prune
the earliest records from each .dt file.
Delete records older than n days
If selected, Audit Server will periodically examine
each .dt file and discard records older than n days
You may use both 1. and 2. together, or neither of
them. If you use neither, the .dt file will keep growing as new
data points are added. In versions of Domain Time prior to 5.2.b.20171113,
there was no cap on the size. Starting with version 5.2.b.20171113,
Audit Server enforces a cap of 604,800 records (enough for one data
point per second for a full week). When a .dt file grows beyond this
size, Audit Server archives the oldest records by placing them in the
\Synchronization Logs\Archives subfolder, allowing the original .dt file to begin growing again.
Disk requirements
Although the binary synchronization logs files are quite efficient at recording individual delta events,
the overall disk space needed depends on how many machines are being collected and how often events are being
recorded in each type of file.
Domain Time II Synchronization Logs
A data point is written for each successful time synchronization (or PTP aggregation). The overall schedule for these
is set by the "Timings" settings on the Server or Client, however, other events can trigger additional synchronizations.
Examine a representative sample of machines in normal operation to determine the number of records you'll require.
Domain Time II PTP Offset Logs
A data point is written for each received Master sync packet. The schedule for this is determined by the PTP Master sync
schedule (often 1/sec).
NTP Drift Logs
A data point is written each time an audit is run. The schedule for this is set by Audit Server.
PTP Nodes Drift Logs
A data point is written each time an audit is run. The schedule for this is set by Audit Server.
IMPORTANT:
As of v5.2.b.2017113, the graphical viewer for synchronization logs will not open files larger than 604800 records.
You should limit the size of these files and regularly archive them to ensure they stay under this limit.
As of v5.2.b.20171113, the maximum number of records kept by Audit Server is 604800, enough for one data point per
second for one full week (just over 12MB of binary data). If you have disabled the size limit for drift files, a file that
grows larger than the maximum will be moved into an "Archives/yyyymmdd" subfolder, and then the file restarted. A warning
message will appear in Audit Server's text log. If the file cannot be archived, an error message will appear in the text
log and the older data will be lost.
If unattended (and unrestricted by the Limit size of collected synchronization logs setting),
the folder can grow to contain a very large amount of data. You should plan to regularly archive this data
off to your normal archival storage. "Regularly" may mean several times a day, depending on your data collection rates.
Please see the Audit Disk Space Estimator page to calculate your disk space requirements for
storing synchronization logs.
Log filename format::
Sets the way sync log filenames are constructed. The default format is
Serial - Name
Viewing/Managing Collected Logs
You may view collected Synchronization logs by expanding the Audit Server item in the Manager tree
and clicking on the Synchronization Logs item. You may also choose the Audit Server ->
Synchronization Logs -> Open Containing Folder menu item.
Synchronization logs are collected in the folder specified for them on the Audit Server ->
Advanced -> Data Folders... menu item.
View the collected logs in graphical format by choosing Audit Server -> Synchronization Logs
-> View Drift Graphs... from the menu. Filenames for PTP records will end in "_ptp",
otherwise they are standard drift log files.
Synchronization Logs are viewed using a utility program called DTDRIFT.EXE (launched automatically
when you view results through Manager). The DTDrift utility is associated with files having the
extension .dt during the installation of Domain Time Server, Client, and/or Audit Server.
However, it can be used to view Synchronization Log files on other systems. Simply copy the program
to any machine from which you'd like to view audit records.
Note: The DTDRIFT.EXE program does not function on Windows Server Core systems. To view sync logs
collected by Audit Server on Server Core systems, you must copy the DTDRIFT.EXE utility to a
non-Core system and use it from there to view the .dt synchronization logs through a network share
on the Core machine.
As of v5.2.b.2017113, the graphical viewer for drift graphs will not open files larger than 604800
records. Ensure you are limiting your Sync logs to less than this size.
The DTDRIFT.EXE program can also run as a command-line
program. Use DTDRIFT -help from the command line to see
all of the options. One of the things DTDRIFT.EXE can
do is convert binary .dt files to their .txt equivalents, just as
if you had opened the files in the graphical viewer and clicked
the button. As of v5.2.b.20180303, it can
also be used to chop large binary .dt files in to manageable chunks or
repair damaged .dt files.
Added as of v5.2.b.20180101:
-convert [-localtime] filespec.
-localtime is optional. If not supplied, UTC will be used.
filespec may be either a fully-qualified path and filename, or a path with *.dt (no other
file extensions are supported). If the path or filename has spaces, you must enclose it in
quotation marks. For example, dtdrift -convert "C:\Program Files\Domain Time II\Synchronization Logs\*.dt"
will convert each .dt file in the named folder to its .txt equivalent. The original .dt file is not
altered.
Added as of v5.2.b.20180303:
-chop command-line parm. It must be followed by the full
path to a .dt file, or use the wildcard path\*.dt (much the same as for -convert). While -convert will
read a .dt file and create the corresponding text version, -chop will split the .dt file into chunks
named foo_Part001.dt, foo_Part002.dt, etc.
-repair command-line parm. It must be followed by the full
path to a .dt file, or use the wildcard path\*.dt. The -repair switch examines the file(s) for invalid
entries and removes them. Note: This is a prophylactic function; no .dt file has ever become corrupted.
-csv command-line parm. This switch is only valid with
-convert, and may optionally be combined with -noheader. The
switches must be followed by the full path to a .dt file, or use the wildcard path\*.dt. Example:
dtdrift -convert -csv -noheader "d:\drift files\*.dt" or dtdrift -convert -csv C:\myfile.dt.
The .csv file(s) will be created in the same folder as the .dt file(s).
Hint: Double-click on any part of the graph to bring up limit markers handy for seeing the range of deltas displayed. Note you need to be zoomed in enough to see actual variations in the graph.
Click the button to see the underlying statistical data and individual records used to create the graphical display.
If you have chosen to expand the binary logs to text files (see the configuration option above), you can view the text versions by choosing Audit Server -> Synchronization Logs -> View Text Reports... from the menu.
Daily Reports
Daily Reports are summary results files using a user-specified format, created during each audit run from audit record data.
They are particularly useful for exporting audit data to external programs.
You set up Daily Reports using the Audit Server -> Daily Reports -> Configure menu item.
When enabled, Audit Server will create a special summary log of audit records each day in the folder specified for Daily Reports on the
Audit Server -> Advanced -> Data Folders... menu item. Click the Audit Server -> Daily Reports -> View menu item
to browse through the existing reports.
Notes:
Daily Audit Summary Logs only include information from audit records; they do not include information from the Synchronization Logs.
The View Logs button displays the contents of the Daily Report Summary collection folder using the Explorer shell which does not function
on Windows Server Core systems. Use Notepad to view the files manually or view them from a remote machine using any text reader.
A new summary log file will be created each day. Any audits performed during that day will be appended to the log.
Daily Reports are particularly useful if you are using your own log file collection and analysis program and need the audit record information to appear in a particular
format to be imported correctly.
You may specify the date format and extension to be used in creating filenames. The default extension is .txt, however, as of version 5.2.b.20160922, you may specify
.htm or .html which will wrap the output in minimal HTML tags sufficient for viewing with a browser.
The Daily Report Format section is where you specify how data will appear in the log. You can specify the format of the header used
before the records as well as the format of the records themselves.
The format string entered in the text field indicates the
order of data variables (keywords surrounded by the % character) which represent specific data collected from the audited machine,
special characters (such as \r representing
a carriage return), and delimiters (if any) used to create each line of the log file. You can preview the effect of your settings by clicking the Show Example
button.
For example the format string:
%Status%,%MachineName%,%IP%,%DST%,%TimeZone%\r\n
results in a log file entry with this format:
#
# Audit results from audit performed at 17:00:00 UTC
#
# Status,MachineName,IP,DST,TimeZone\r\n
OK,DC_2,172.10.1.12,Y,Central Daylight Time
OK,PDC,172.10.1.10,Y,Central Daylight Time
OK,NTP Server,192.43.244.18,?,Unknown
Note that the entry for the NTP server in the example above shows ? in the DST and Unknown in the TimeZone fields. This information
is only available from Domain Time II components.
These are the items that can be included in the format string:
Delimiters
You may specify any text you want to use between variables in the format string.
Special Characters
\n
line feed
\r
carriage return
\t
tab character
\\
backslash character
%%
percent sign character
Data Variables
%Status%
Whether or not the machine was audited successfully Returns OK or Err
%AuditStampVersion%
Audit stamp version number
%ContactFailures%
Number of consecutive contact failures
%SecsSinceLastSet%
Number of seconds since time was last set
%Variance%
Variance from reference at time of audit
%LastContact%
Time this machine was last contacted
%SerialNumber%
Machine's serial number
%LastProtocol%
Name of last time protocol used to set the time
%LocalTime%
Local time (adjusted for timezone and dst) at time of audit
%UTC%
UTC time at time of audit
%LastVariance%
Variance last time machine corrected its time
%Corrections%
Number of time corrections since last startup
%Checks%
Number of time checks (whether or not correction made) since startup
%Errors%
Number of times machine encountered an error while checking the time
%InstallDate%
Time this machine's client was installed
%UnixTime%
Time (in seconds) at time of audit (usually matches LocalTime)
%LastSet%
Time machine last corrected its time
%LastStartup%
Time machine last started the time service
%LastSource%
Most recently-used time source
%TimeZone%
Time zone (for example, "Eastern Standard Time")
%Version%
Version number of time software on machine
%MachineName%
Machine's NetBIOS name
%DNSName%
Machine's DNS name (if available)
%IP%
Machine's last-known IP address
%DST%
Y if machine is known to be applying Daylight Savings Time correction N if machine is known to NOT be applying DST correction ? if machine's treatment of Daylight Savings Time is unknown
%Role%
Machine's Domain Time II role (client, server, etc)
%Registered%
Y if software is registered N if software is an evaluation copy (or not a Domain Time component)
%OS%
Name of architecture, operating system, and OS version
Proceed to the PTP Monitor page
Back to the Alerts and Audit Groups page