Top of Page

Domain Time II Audit Server
Version 5.2

Data Collection


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.

    Audit Result Record Details
    Audit Result Record Details   [Click for larger size]

    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 Data Viewer
    Audit Data Viewer   [Click for larger size]

    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.

      Synchronization Configuration Dialog
      Synchronization Configuration Dialog   [Click for larger size]

      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.

          CSV File Expansion
          CSV File Expansion   [Click for smaller size]

            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:

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

      1. Never keep more than n records
        If selected, Audit Server will periodically prune the earliest records from each .dt file.

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

        The Drift Graph
        The Drift Graph   [Click for smaller size]

        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.

      Audit Server Daily Report Configuration Dialog
      Audit Server Daily Report Configuration Dialog   [Click for larger size]

      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

      \nline feed
      \rcarriage return
      \ttab 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
      %AverageInfo%List of servers used for averaging (if available)

 

Next Proceed to the PTP Monitor page
Back Back to the Alerts and Audit Groups page

Domain Time II Software distributed by Microsemi, Inc.
Documentation copyright © 1995-2024 Greyware Automation Products, Inc.
All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.