locked
Converting old server time check batch file to PowerShell RRS feed

  • Question

  • Hi Guys,

    I have batch file that checks the offset between our time servers and two external ones.  This batch file works in XP, but not in Windows 7 pro.  Where it breaks down is it doesn't display the offset correctly.  Can this batch be converted to Powershell, so that it would be compatible?  Here is the batch code:

    CLS
    @ECHO OFF
    @ECHO.
    @ECHO.
    @ECHO ************************* Time Checking Script *************************
    @ECHO *** Check the offset between government time server, our internal 
    @ECHO *** time server and domain controllers.
    @ECHO.
    @ECHO *** time.nist.gov:
    @w32tm  /monitor /computers:time.nist.gov /domain:cooley-dickinson.org |FIND "offset"
    @ECHO.
    @ECHO *** time.cooley-dickinson.org:
    @w32tm  /monitor /computers:tock.usno.navy.mil /domain:cooley-dickinson.org |FIND "offset"
    @ECHO.
    PAUSE
    @ECHO.
    @Net Time \\server1 | find "Current"
    @Net Time \\server2 | find "Current"
    @Net Time \\server3 | find "Current"
    @Net Time \\server4 | find "Current"
    @Net Time \\server01 | find "Current"
    @Net Time \\server02 | find "Current"
    @Net Time \\server03 | find "Current"
    @Net Time \\server04 | find "Current"
    @Net Time \\server05 | find "Current"
    @Net Time \\server06 | find "Current"
    @Net Time \\server07 | find "Current"
    @Net Time \\server08 | find "Current"

    Below is the output we get from the batch file in Windows 7.  Where it says delayoffset, is normally where the offset is in seconds.

    *** time.nist.gov:
    Analyzing:Analyzing:Analyzing:Analyzing:Analyzing:delayoffset from DC01.coole
    y-dickinson.org
    delayoffset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org

    *** time.cooley-dickinson.org:
    offset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org
    delayoffset from DC01.cooley-dickinson.org

    The rest of the script displays the date/time for individual servers correctly.  If this could be converted to powershell, it would be a whole lot easier to deal with.

    Thank you!

    Larry

    Sunday, December 29, 2013 9:53 PM

Answers

  • Why?  It serves no purpose in a domain.  Just retrieve the sync records from the PDC in the Event log. It will give you all offsets and any adjustments.

    All member hosts will sync continuously to the PDC.  THe PDC should be set to sync with a time server.  THe Eventlog will tell you if there are sync issues.  All of this has been built into NT since NT 3.5.  In W2K the configuration was added to GP.

    Search for KB and blog articles on how domain time works and how to set it to lock to an Internet time source.

    When joined to a domain all hosts will time sync to the PDC.  Setting the PDC time service to sync to NIST ot time.windows.com locks the domain to UTC high resolution time.  It is guaranteed to be less than .5 milliseconds off at any time.  To get higher reolution use a WWVB radio source at the PDC and time can lock to better than 5 microseconds.

    If you want a report of lock that use w32tm to run a tape. Just output to the report.  The event log records will tell you that the servers are all syncing.  This is a more reliable method of determining quality.

    1. Current sync on PDC within 48 hours. 
    2. No sync loss on member servers in event log.

    You can also use WMI to test time difference.

    Get-WmiObject Win32_UTCTime -computername server1


    ¯\_(ツ)_/¯

    • Marked as answer by LEKnowlton Tuesday, December 31, 2013 1:49 PM
    Monday, December 30, 2013 2:52 PM

All replies

  • The correct way to manage time in a domain is to use the domain time.  We then use the built in NTP client on the domain controller to sync to NIST or any other NTP time source.

    Using NET TIME is not only obsolete but it is very inaccurate.

    On stand alnoe machines you can set the NTP client to sync automatically. 

    At a prompt type "w32tm /?"

    In a domain NET TIME will not sync the time.  It will just get rest to the domain time.  Domains require that all clients take time from the DC.

    Here is one article on setting up a dts: http://support.microsoft.com/kb/131715


    ¯\_(ツ)_/¯


    • Edited by jrv Sunday, December 29, 2013 11:04 PM
    Sunday, December 29, 2013 11:04 PM
  • More  on time service availability and use: http://blogs.msdn.com/b/w32time/archive/2009/08/07/net-time-and-w32time.aspx


    ¯\_(ツ)_/¯

    Sunday, December 29, 2013 11:06 PM
  • There is another issue.  time.nist.gov is not using the same NTP format as Windows in Vista and later.  time.windows.com does work when it is available.

    The following works on Windows 7 and 8

    C:\scripts>w32tm  /monitor /computers:tock.usno.navy.mil |FIND "offset"
    offset from local clock

    C:\scripts>w32tm  /monitor /computers:time.nist.gov /domain:cooley-dickinson.org |FIND "offset"

    C:\scripts>w32tm  /monitor /computers:time.nist.gov |FIND "offset"
    delayoffset from local clockf 1)...


    ¯\_(ツ)_/¯

    Sunday, December 29, 2013 11:18 PM
  • Here is the response from the requested time service format:

    time.nist.gov[128.138.141.172:123]:
        ICMP: 69ms delay
        NTP: -2.2270260s offset from local clock
            RefID: 'ACTS' [0x53544341]
            Stratum: 1

    In all cases you cannot sync a domain member with anything but the PDC.


    ¯\_(ツ)_/¯

    Sunday, December 29, 2013 11:23 PM
  • Here is the response from the requested time service format:

    time.nist.gov[128.138.141.172:123]:
        ICMP: 69ms delay
        NTP: -2.2270260s offset from local clock
            RefID: 'ACTS' [0x53544341]
            Stratum: 1

    In all cases you cannot sync a domain member with anything but the PDC.


    ¯\_(ツ)_/¯

    Hi jrv,

    I'm not sure how you got the above and I wasn't trying to sync just view the offsets in seconds.

    Thank you!

    Larry

    Monday, December 30, 2013 12:53 PM
  • There is another issue.  time.nist.gov is not using the same NTP format as Windows in Vista and later.  time.windows.com does work when it is available.

    The following works on Windows 7 and 8

    C:\scripts>w32tm  /monitor /computers:tock.usno.navy.mil |FIND "offset"
    offset from local clock

    C:\scripts>w32tm  /monitor /computers:time.nist.gov /domain:cooley-dickinson.org |FIND "offset"

    C:\scripts>w32tm  /monitor /computers:time.nist.gov |FIND "offset"
    delayoffset from local clockf 1)...


    ¯\_(ツ)_/¯

    Hi jrv,

    None of these work as you can see by the response underneath each line of code. Am I missing something?

    Thank you!

    Larry

    Monday, December 30, 2013 12:55 PM
  • Hi jrv,

    We're slowly transitioning away from XP and 2003.  Unfortunately, there are applications that still require their use.  I leave the syncing to the system engineers.  I'm just trying to get a script to work on Windows 7 for daily monitoring purposes. 

    Thank you!

    Larry

    Monday, December 30, 2013 1:03 PM
  • Why?  It serves no purpose in a domain.  Just retrieve the sync records from the PDC in the Event log. It will give you all offsets and any adjustments.

    All member hosts will sync continuously to the PDC.  THe PDC should be set to sync with a time server.  THe Eventlog will tell you if there are sync issues.  All of this has been built into NT since NT 3.5.  In W2K the configuration was added to GP.

    Search for KB and blog articles on how domain time works and how to set it to lock to an Internet time source.

    When joined to a domain all hosts will time sync to the PDC.  Setting the PDC time service to sync to NIST ot time.windows.com locks the domain to UTC high resolution time.  It is guaranteed to be less than .5 milliseconds off at any time.  To get higher reolution use a WWVB radio source at the PDC and time can lock to better than 5 microseconds.

    If you want a report of lock that use w32tm to run a tape. Just output to the report.  The event log records will tell you that the servers are all syncing.  This is a more reliable method of determining quality.

    1. Current sync on PDC within 48 hours. 
    2. No sync loss on member servers in event log.

    You can also use WMI to test time difference.

    Get-WmiObject Win32_UTCTime -computername server1


    ¯\_(ツ)_/¯

    • Marked as answer by LEKnowlton Tuesday, December 31, 2013 1:49 PM
    Monday, December 30, 2013 2:52 PM
  • There is another issue.  time.nist.gov is not using the same NTP format as Windows in Vista and later.  time.windows.com does work when it is available.

    The following works on Windows 7 and 8

    C:\scripts>w32tm  /monitor /computers:tock.usno.navy.mil |FIND "offset"
    offset from local clock

    C:\scripts>w32tm  /monitor /computers:time.nist.gov /domain:cooley-dickinson.org |FIND "offset"

    C:\scripts>w32tm  /monitor /computers:time.nist.gov |FIND "offset"
    delayoffset from local clockf 1)...


    ¯\_(ツ)_/¯

    Hi jrv,

    None of these work as you can see by the response underneath each line of code. Am I missing something?

    Thank you!

    Larry

    The output format of the command has changed and the find command does not work correctly on Unicode outputs.

    I recommend abandoning the project because it duplicates facilities built into Windows.  Why re-invent the wheel?


    ¯\_(ツ)_/¯

    Monday, December 30, 2013 2:57 PM
  • The following works on XXP, WS2003, W7 and W8.

    w32tm  /monitor /computers:time.nist.gov | FIND  "NTP:"


    ¯\_(ツ)_/¯

    Monday, December 30, 2013 3:01 PM
  • Here is what your sync looks like:

    time.nist.gov [69.25.96.13]:
        ICMP: 85ms delay.
        NTP: +0.0111562s offset from ALPHA.sec.local
            RefID: 'ACTS' [65.67.84.83]
    ALPHA.sec.local *** PDC *** [192.168.2.1]:
        ICMP: 0ms delay.
        NTP: +0.0000000s offset from ALPHA.sec.local
            RefID: nist1-chi.ustiming.org [216.171.120.36]

    Note that it fist gets offset and delay from NIST then shows you the delay to the PDC.  The NET TIME stuff is pointless as it does not tell us the network delay.  Only yhr event log records can tell you if the time Is locked.  The NTP: +0.00000s will always be zero in a domain unless there are DC sync issues.  ADDiag will tell you that more accurately and completely.

    Note that in this test there is an 85ms delay to NIST and NIT reports an approx. 85s offset.  (+0.0.1111...)  the extra is because the delay is jittery.  w32time service on the PDC resolves this on the scan interval and reports it to the eventlog.  YOu can also set tehservice to gernerate a detailed sync report log to a file.

    I recommend taking the domain admin course to learn how Windows time in a domain is used and managed.  This course is available onvideo and in many good books.  It will save you from a lot of unnecessary work.  Once a The time sync service monitors and reports on itself.  ADDiag cross checks sync issues and address issues on a domain.  It will tellyou if time sync is failing across all DCs.  THe event logs will tell youif the member servers are failing to sync.


    ¯\_(ツ)_/¯

    Monday, December 30, 2013 3:20 PM
  • Hi jrv,

    We're slowly transitioning away from XP and 2003.  Unfortunately, there are applications that still require their use.  I leave the syncing to the system engineers.  I'm just trying to get a script to work on Windows 7 for daily monitoring purposes. 

    Thank you!

    Larry

    Again.  Just query the eventlog for sync failures if that is important.  You can only check against PDC. 

    The NET TIME requests can never be accurate.  Mixing w32tm and NET TIME is meaning less.  You are either in sync or not.  What you want to know is if the PDC has lost sync.  For QC purposes just query the PDC for sync  The one w32tm call effectively does that.

    In any case this version will work on all systems:

    w32tm  /monitor /computers:time.nist.gov | FIND  "NTP:"


    ¯\_(ツ)_/¯

    Monday, December 30, 2013 3:31 PM
  • I agree with jrv. This sounds suspiciously like an XY problem. This is where you have problem X, and you think a solution might be Y, but instead of asking about X, you ask about Y.

    It sounds like the underlying question is: What is causing time drift on your machines? More importantly, why aren't domain machines syncing time with domain controllers? Correct time configuration has long been critical in AD design ever since its inception. This isn't a scripting problem or question but rather a system architecture/design question about proper setup and configuration of Windows time services.

    Bill

    Monday, December 30, 2013 5:55 PM
  • Hi jrv,

    I do appreciate your responses.  I am not the system admin for our domain, I am but a humble help desk tech/operator.  The system engineers take care of the syncing and I'm sure have a grasp on it.  My goal is to try to help rid ourselves of our xp machines and only deal with windows 7. So, the more tasks we can do on Win 7 the better.  The script we run daily is essentially an early warning for the sys admin, but, as you say, it has become outdated and perhaps not needed.  I will put forth the suggestions that you have recommended.  On the other end of this, if I can manipulate the output of your WMI code to create a similar report, I'd find it more of a good programming exercise.

    Thank you!

    Larry

    Tuesday, December 31, 2013 1:47 PM
  • I also posted the solution as a simple change to your batch file.

    The syncing of systems is the responsibility of the network people.  They have the tools and I am sure they are using them.  I cannot see where your probing will assist them in any way.  Network time quality has been a fundamental part of Windows since the beginning.  We in computer engineering have been managing high quality computer time resolution since the 1970s across nearly all systems.  Computer systems were getting time sync from the phone system (all DDS and T-1 lines tranmit time code) before the Internet.  The Internet has allowed us to get time code dynamically from many sources.

    Time quality is a network function and, as Bill has pointed out, is necessary for proper functioning of NT in a domain.

    The simple answer to your question is to match on "NTP:" which will give you the same output on both XP and Windows 7.

    w32tm  /monitor /computers:time.nist.gov | FIND  "NTP:"

    Again I warn you that what you are doing is producing incorrect results because you are no factoring in the network delay.  No method here is compensating for that.  You would need to use a different query type to test compliance correctly.


    ¯\_(ツ)_/¯

    Tuesday, December 31, 2013 2:01 PM
  • Hi Bill,

    My main concern is getting a means script-wise to mimic the functionality of the batch I posted.  The syncing has never been an problem for our engineers (that I know of).  The batch is but a task we can only run on xp, so I wanted to be able to try to migrate the task over to windows 7.  If the task is outdated and unnecessary, as I told jrv, I'll suggest that it is to the sys admin.  To me it is a scripting question, I'm a programmer at heart and look to find ways of automating tasks with code.  I'm new to Powershell and not experienced with system architecture design. 

    Thank you!

    Larry

    Tuesday, December 31, 2013 2:10 PM
  • Hi Bill,

    My main concern is getting a means script-wise to mimic the functionality of the batch I posted.  The syncing has never been an problem for our engineers (that I know of).  The batch is but a task we can only run on xp, so I wanted to be able to try to migrate the task over to windows 7.  If the task is outdated and unnecessary, as I told jrv, I'll suggest that it is to the sys admin.  To me it is a scripting question, I'm a programmer at heart and look to find ways of automating tasks with code.  I'm new to Powershell and not experienced with system architecture design. 

    Thank you!

    Larry

    Again - there is no way to do what you are asking. w32tm is the only utility that matches time but you are not using it correctly.  You are reporting the offset but not the delay.  The only accurate way to test sync quality is by running a tape.  This is a function of w32tm.   THe tape will show you the variance over time.  The other way I have used is to set the time service to generate a log and scan the log.

    Win32_UTCTime will tell you the time at remote servers but it cannot tell you the network delay.

    If you are only interested in matching seconds then you can use it as well as the w32tm query that returns network time.  These can be extracted and converted into time objects.

    As an exercise to learn PowerShell this could be useful.  Just capture the output of w32tm and parse it in PowerShell.

    See the "Learning" resources on this site for examples.

    You should also use your search engine to learn more about what is available and how it is used.

    A simple search for me returned this: http://gallery.technet.microsoft.com/scriptcenter/Get-Network-NTP-Time-with-07b216ca

    There are many more things available including GUIs that report in real time.

    You desktop guys need to get out more often.  Learn to use computers.  They can be very helpful.  Stop plating with hardware.  Desktop support will be gone within a few years as we move to the cloud.  Only application support will remain.  The classic PC and member server are pretty much obsolete.


    ¯\_(ツ)_/¯

    Tuesday, December 31, 2013 2:38 PM
  • Here is the output using the native stratum 2 servers and a comparison using NIST stratum 1 servers. They usually disagree by a hundredth.

    PS C:\scripts> get-ntptime
    
    
    NtpServer           : pool.ntp.org
    NtpTime             : 12/31/2013 9:40:36 AM
    OffsetSeconds       : -1.48
    NtpVersionNumber    : 3
    Mode_text           : server
    Stratum             : 2
    ReferenceIdentifier : 209.51.161.238 <clock.nyc.he.net>
    
    
    
    PS C:\scripts> get-ntptime -Server time.nist.gov
    
    
    NtpServer           : time.nist.gov
    NtpTime             : 12/31/2013 9:41:29 AM
    OffsetSeconds       : -1.361
    NtpVersionNumber    : 3
    Mode_text           : server
    Stratum             : 1
    ReferenceIdentifier : ACTS
    

    The values are returned as n object and can be used with other commands.


    ¯\_(ツ)_/¯

    Tuesday, December 31, 2013 2:44 PM
  • WMI timecodes:

    $tm=gwmi win32_utctime -Computer MyServer1
    $dater=@{
         Year=$tm.year
         Month=$tm.Month
         Day=$tm.Day
         Hour=$tm.Hour
         Minute=$tm.Minute
         Second=$tm.Second
         Millisecond=if($tm.Milliseconds){$tm.milliseconds}else{0}
    }
    Get-Date @dater
    

    Now all you have to do is learn how to put it together.

    Resolution will never be greater than +- 1 second


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, December 31, 2013 2:57 PM
    Tuesday, December 31, 2013 2:56 PM
  • Here is the correct command to monitor multiple servers against network time.  This method searches fro a high quality network clock and matches the domain and all specified servers.

    w32tm  /monitor /domain:testnet /computers:"ws701.testnet.local,ws702.testnet.local,ws703.test-net.local"

    You can make the computer list as long as you want.  You will get a comprehensive list of offsets to UTC by computer name.  The firewall must be open to allow the servers to respond to the time probe,

    Here is a sample output:

    sbs01.kahlnet.local[[fe80::b91c:cdf8:c3be:4dbe%10]:123]:
        ICMP: 0ms delay
        NTP: +0.0000000s offset from SBS01.KAHLNET.local
            RefID: nist1-lv.ustiming.org [64.250.229.100]
            Stratum: 2
    ws701.kahlnet.local[192.168.1.12:123]:
        ICMP: 0ms delay
        NTP: +0.0000000s offset from ws701.KAHLNET.local
            RefID: nist1-lv.ustiming.org [64.250.229.100]
            Stratum: 2
    ws702.kahlnet.local[192.168.1.13:123]:
        ICMP: 1ms delay
        NTP: +0.0000000s offset from ws702.KAHLNET.local
            RefID: nist1-lv.ustiming.org [64.250.229.100]
            Stratum: 2
    ws703.KAHLNET.local *** PDC ***[[fe80::b91c:cdf8:c3be:4dbe%10]:123]:
        ICMP: 0ms delay
        NTP: +0.0000000s offset from ws703.KAHLNET.local
            RefID: nist1-lv.ustiming.org [64.250.229.100]
            Stratum: 2
            RefID: nist1-lv.ustiming.org [64.250.229.100]
            Stratum: 2
    


    ¯\_(ツ)_/¯

    Tuesday, December 31, 2013 3:14 PM
  • This is the correct way to check a remote system for domain time sync.  It gives you all elements of the sync status.

    w32tm /query /computer:ws703 /status

    This tells you everything about the client sync state and quality:

    Leap Indicator: 0(no warning)
    Stratum: 3 (secondary reference - syncd by (S)NTP)
    Precision: -6 (15.625ms per tick)
    Root Delay: 0.1092377s
    Root Dispersion: 0.1070607s
    ReferenceId: 0xC0A80102 (source IP:  192.168.1.2)
    Last Successful Sync Time: 12/31/2013 9:58:17 AM
    Source: SBS01.TESTNET.local
    Poll Interval: 15 (32768s)

    Note that this gives you the long time quality information (dispersion)


    ¯\_(ツ)_/¯

    Tuesday, December 31, 2013 3:21 PM
  • Hi Jrv,

    Wow, all that code was worth your deprecating help desk remarks!

    Thank you again!

    Larry

    Friday, January 3, 2014 12:47 AM
  • Hi Jrv,

    Wow, all that code was worth your deprecating help desk remarks!

    Thank you again!

    Larry

    Why do all of you kids do that.  Criticism is not deadly.  You need to learn to take criticism and predictions of the demise of the dinosaurs did not make old T-Rex and less popular.

    My point is that you need to look deeper and guard your ass.  Things are changing.  Only the sharpest knife in the drawer will be considered.  You can be replaced by a robot.  We all can.,


    ¯\_(ツ)_/¯

    Friday, January 3, 2014 1:42 AM
  • Hi jrv,

    (sigh)  I didn't see the constructive part in some of your 'criticisms', so I thought I'd 'criticize' that.  Oh and the BORG hasn't taken over, nor has SkyNet been launched.  I got your point...                                                        

    Thank you!

    Larry

    Friday, January 3, 2014 11:52 PM
  • Hi jrv,

    (sigh)  I didn't see the constructive part in some of your 'criticisms', so I thought I'd 'criticize' that.  Oh and the BORG hasn't taken over, nor has SkyNet been launched.  I got your point...                                                        

    Thank you!

    Larry

    I am really trying to antagonize you into antagonizing your controllers (supervisors maybe?) and try and change things for the better. It might get you some good attention.

    Time is critical to AD.  It needs to be monitored centrally and not at the desktop.  Resources and production apps neeed a service agreement with domain admins and network admins. 

    Yes. You can monitor but you will need to become much more knowledgeable or you will actually be giving out incorrect information.  w32tm is designed to generate a report.  It does not need a batch file or any reformatting.  It does what it needs to do correctly and accurately.  You are placing a wrapper around it that is just removing all accuracy and information.

    Just run the report to a file and email it to admins when any parameter is bad.  Parse text in PowerShell to get quality numbers.


    ¯\_(ツ)_/¯

    Saturday, January 4, 2014 12:06 AM