Issues with w32tm on AD network - NTP

This is a discussion on Issues with w32tm on AD network - NTP ; Hi, I have had issues keeping accurate time on W32tm using an Active Directory based network with just Windows servers. I have a Linux workstation, and NTP on that workstation keeps loosing the time, and going to Stratum 16. Similarly, ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 42

Thread: Issues with w32tm on AD network

  1. Issues with w32tm on AD network

    Hi,

    I have had issues keeping accurate time on W32tm using an Active
    Directory based network with just Windows servers. I have a Linux
    workstation, and NTP on that workstation keeps loosing the time, and
    going to Stratum 16. Similarly, there are Cisco routers on the
    network, which also do likewise.

    I am using the NTP pool, but have done this for years on a Linux
    system with no problems.

    Should I think about switching to NTPD on Windows, and if I do this,
    will it cause an issue with both this and W32tm running at the same
    time?

    Are there any GPS systems I could hook up to the Windows domain
    controller, and configure W32tm to use this?

    Thanks.
    Andrew.hook

  2. Re: Issues with w32tm on AD network

    Andrew Hodgson wrote:
    > Hi,
    >
    > I have had issues keeping accurate time on W32tm using an Active
    > Directory based network with just Windows servers. I have a Linux
    > workstation, and NTP on that workstation keeps loosing the time, and
    > going to Stratum 16. Similarly, there are Cisco routers on the
    > network, which also do likewise.
    >
    > I am using the NTP pool, but have done this for years on a Linux
    > system with no problems.
    >
    > Should I think about switching to NTPD on Windows, and if I do this,
    > will it cause an issue with both this and W32tm running at the same
    > time?
    >


    Yes. w32time needs to be disabled, you cannot run both. The Meinberg
    installer does this for you and if you choose to uninstall NTP I believe
    it will reenable it.

    > Are there any GPS systems I could hook up to the Windows domain
    > controller, and configure W32tm to use this?
    >


    Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
    are built for Windows. I cannot tell you much about them but the code is
    built for them.

    Danny
    > Thanks.
    > Andrew.hook
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  3. Re: Issues with w32tm on AD network

    Danny Mayer wrote:
    []
    > Yes. w32time needs to be disabled, you cannot run both. The Meinberg
    > installer does this for you and if you choose to uninstall NTP I
    > believe it will reenable it.

    []
    > Danny



    FYI, that's at:

    http://www.meinberg.de/english/sw/ntp.htm

    Cheers,
    David



  4. Re: Issues with w32tm on AD network

    Andrew,

    Andrew Hodgson wrote:
    > Hi,
    >
    > I have had issues keeping accurate time on W32tm using an Active
    > Directory based network with just Windows servers. I have a Linux
    > workstation, and NTP on that workstation keeps loosing the time, and
    > going to Stratum 16. Similarly, there are Cisco routers on the
    > network, which also do likewise.
    >
    > I am using the NTP pool, but have done this for years on a Linux
    > system with no problems.
    >
    > Should I think about switching to NTPD on Windows, and if I do this,
    > will it cause an issue with both this and W32tm running at the same
    > time?


    Though it's normally preferable to run ntpd rather than w32time, there is a
    limitation if you run ntpd on a domain controller:
    The domain members (workstations) will stop detecting the domain controller
    automatically as their primary time source, so you'll have to configure the
    domain controller explicitely as times source on every client.

    If you also run any Linux or other *ix server then a better approach would
    be to let the *ix machine synchromize to the pool servers, and configure
    the *ix machine as "internet time source" for w32time on the domain
    controller.

    You should not let real NTP clients use w32time as time source, though.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  5. Re: Issues with w32tm on AD network

    On Feb 22, 2:31*am, Martin Burnicki
    wrote:

    > Though it's normally preferable to run ntpd rather than w32time, there is a
    > limitation if you run ntpd on a domain controller:
    > The domain members (workstations) will stop detecting the domain controller
    > automatically as their primary time source, so you'll have to configure the
    > domain controller explicitely as times source on every client.
    >


    Configuraing all the clients takes about 30 seconds using Windows
    Group Policies on any of your domain controllers. There is an
    administrative template for the WIndows Time service, and you can
    configure time sources, poslling intervals, and many other parameters
    for w32time.

    See: http://technet2.microsoft.com/window....mspx?mfr=true

    Say what you will about w32time's accuracy... it *is* extremely
    managable in large windows networks.

  6. Re: Issues with w32tm on AD network

    On Fri, 22 Feb 2008 09:31:38 +0100, Martin Burnicki
    wrote:

    >Andrew,
    >
    >Andrew Hodgson wrote:
    >> Hi,
    >>
    >> I have had issues keeping accurate time on W32tm using an Active
    >> Directory based network with just Windows servers. I have a Linux
    >> workstation, and NTP on that workstation keeps loosing the time, and
    >> going to Stratum 16. Similarly, there are Cisco routers on the
    >> network, which also do likewise.
    >>
    >> I am using the NTP pool, but have done this for years on a Linux
    >> system with no problems.
    >>
    >> Should I think about switching to NTPD on Windows, and if I do this,
    >> will it cause an issue with both this and W32tm running at the same
    >> time?

    >
    >Though it's normally preferable to run ntpd rather than w32time, there is a
    >limitation if you run ntpd on a domain controller:
    >The domain members (workstations) will stop detecting the domain controller
    >automatically as their primary time source, so you'll have to configure the
    >domain controller explicitely as times source on every client.


    Yes, I have found this in a previous life, plus it caused some other
    issues for us as well, which is why I would like to keep W32tm if
    possible.
    >
    >If you also run any Linux or other *ix server then a better approach would
    >be to let the *ix machine synchromize to the pool servers, and configure
    >the *ix machine as "internet time source" for w32time on the domain
    >controller.


    Unfortunately the Debian box I have is a laptop that is not on
    continuously, so no good. I do have an ASA firewall and a Cisco
    router however, which at present are set to get time from the Windows
    box, but I could set one up as an NTP server perhaps?

    Thanks.
    Andrew.

  7. Re: Issues with w32tm on AD network

    On Fri, 22 Feb 2008 02:51:07 GMT, mayer@ntp.isc.org (Danny Mayer)
    wrote:

    >Andrew Hodgson wrote:


    [...]>

    >> Are there any GPS systems I could hook up to the Windows domain
    >> controller, and configure W32tm to use this?
    >>

    >
    >Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
    >are built for Windows. I cannot tell you much about them but the code is
    >built for them.


    Do these work with W32tm or NTPD for Windows?

    Thanks.
    Andrew.

  8. Re: Issues with w32tm on AD network

    > >> Are there any GPS systems I could hook up to the Windows domain
    > >> controller, and configure W32tm to use this?
    > >>

    > >
    > >Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
    > >are built for Windows. I cannot tell you much about them but the code is
    > >built for them.

    >
    > Do these work with W32tm or NTPD for Windows?


    I didn't think (the Meinberg build of) NTPD for windows supported any of the
    refclocks? Or maybe they support the refclocks but no PPSAPI?

  9. Re: Issues with w32tm on AD network

    Martin Burnicki wrote:

    > Though it's normally preferable to run ntpd rather than w32time, there is a
    > limitation if you run ntpd on a domain controller:
    > The domain members (workstations) will stop detecting the domain controller
    > automatically as their primary time source, so you'll have to configure the
    > domain controller explicitely as times source on every client.


    Really? Why would it do that? Is this documented somewhere?

    Danny

  10. Re: Issues with w32tm on AD network

    Andrew Hodgson wrote:
    > On Fri, 22 Feb 2008 02:51:07 GMT, mayer@ntp.isc.org (Danny Mayer)
    > wrote:
    >
    >> Andrew Hodgson wrote:

    >
    > [...]>
    >
    >>> Are there any GPS systems I could hook up to the Windows domain
    >>> controller, and configure W32tm to use this?
    >>>

    >> Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
    >> are built for Windows. I cannot tell you much about them but the code is
    >> built for them.

    >
    > Do these work with W32tm or NTPD for Windows?
    >


    NTPD only which was all I was referring to. w32tm doesn't know a
    refclock from a hole in the wall.

    Danny

    > Thanks.
    > Andrew.


  11. Re: Issues with w32tm on AD network

    Jason Rabel wrote:
    >>>> Are there any GPS systems I could hook up to the Windows domain
    >>>> controller, and configure W32tm to use this?
    >>>>
    >>> Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
    >>> are built for Windows. I cannot tell you much about them but the code is
    >>> built for them.

    >> Do these work with W32tm or NTPD for Windows?

    >
    > I didn't think (the Meinberg build of) NTPD for windows supported any of the
    > refclocks? Or maybe they support the refclocks but no PPSAPI?


    I don't think that Meinberg touches the config.h file when creating
    their builds. The refclocks that are to be supported are defined there.

    Danny

  12. Re: Issues with w32tm on AD network

    Danny Mayer wrote:
    > Jason Rabel wrote:
    >>>>> Are there any GPS systems I could hook up to the Windows domain
    >>>>> controller, and configure W32tm to use this?
    >>>>>
    >>>> Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
    >>>> are built for Windows. I cannot tell you much about them but the code
    >>>> is built for them.
    >>> Do these work with W32tm or NTPD for Windows?

    >>
    >> I didn't think (the Meinberg build of) NTPD for windows supported any of
    >> the refclocks? Or maybe they support the refclocks but no PPSAPI?

    >
    > I don't think that Meinberg touches the config.h file when creating
    > their builds. The refclocks that are to be supported are defined there.


    Right. The config.h file is left untouched, so whatever is included by the
    source code distribution is included by the binaries.

    However, I don't know how the PPS API should be supported under Windows,
    except that the Windows port would come with an own kernel driver which
    evaluated a PPS input signal.

    The remaining question is whether it would make much sense at all to write a
    such a driver since the resolution of the Windows clock is limited to ~16
    milliseconds (1 ms under Vista, AFAIK).

    We have sometimes requests from customers who think they can just install a
    GPS PCI card in their Windows machine so their applications will get the
    Windows system time wit better than 1 microsecond accuracy.

    However, though some of the Windows API calls provide a resolution of 100
    nanoseconds those API calls return exactly the same time stamps betwween 2
    timer ticks, and then the returned time steps by the amount of the timer
    tick interval.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  13. Re: Issues with w32tm on AD network

    Ryan Malayter wrote:
    > Configuraing all the clients takes about 30 seconds using Windows
    > Group Policies on any of your domain controllers. There is an
    > administrative template for the WIndows Time service, and you can
    > configure time sources, poslling intervals, and many other parameters
    > for w32time.
    >
    > See:
    >

    http://technet2.microsoft.com/window....mspx?mfr=true
    >
    > Say what you will about w32time's accuracy... it *is* extremely
    > managable in large windows networks.


    That's why I mentioned that w32time may sometimes be the preferred solution.

    I'm not familiar with W2k domain management, so I wonder whether the group
    policied could also be used if ntpd was running on the PDC.

    Please see also my reply to Danny.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  14. Re: Issues with w32tm on AD network

    Danny Mayer wrote:
    > Martin Burnicki wrote:
    >> Though it's normally preferable to run ntpd rather than w32time, there is
    >> a limitation if you run ntpd on a domain controller:
    >> The domain members (workstations) will stop detecting the domain
    >> controller automatically as their primary time source, so you'll have to
    >> configure the domain controller explicitely as times source on every
    >> client.

    >
    > Really? Why would it do that? Is this documented somewhere?


    We have tried it with a small test setup and found that w32time domain
    members did identify their PDC as time source when w32time was running on
    the PDC, but not when ntpd was running on the PDC.

    I have recently received a note from someone who seemed to be very familiar
    with Active Directory. That person told me whn w32time starts it makes an
    entry in the LDAP directory which tells the clients at logon that this
    server is also their time server.

    I assume if ntpd would do the same thing then domain clients would also
    detect and accept ntpd running on the PDC.

    Unfortunately I don't have the original note handy right now, so I'll have
    to investigate.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  15. Re: Issues with w32tm on AD network

    Andrew,

    Andrew Hodgson wrote:
    > On Fri, 22 Feb 2008 09:31:38 +0100, Martin Burnicki
    > wrote:
    >>Though it's normally preferable to run ntpd rather than w32time, there is
    >>a limitation if you run ntpd on a domain controller:
    >>The domain members (workstations) will stop detecting the domain
    >>controller automatically as their primary time source, so you'll have to
    >>configure the domain controller explicitely as times source on every
    >>client.

    >
    > Yes, I have found this in a previous life, plus it caused some other
    > issues for us as well, which is why I would like to keep W32tm if
    > possible.


    Do you remember which kind of issues that were?

    >>If you also run any Linux or other *ix server then a better approach would
    >>be to let the *ix machine synchromize to the pool servers, and configure
    >>the *ix machine as "internet time source" for w32time on the domain
    >>controller.

    >
    > Unfortunately the Debian box I have is a laptop that is not on
    > continuously, so no good. I do have an ASA firewall and a Cisco
    > router however, which at present are set to get time from the Windows
    > box, but I could set one up as an NTP server perhaps?


    I don't know the ASA firewall, but I've heard several times that routers
    don't do a good job as NTP servers.

    Maybe you have another Windows server on which you can install NTP. That
    server could get the time from the pool servers, and the root PDC could run
    w32time and get the time from the server running ntpd.

    This is a good basic configuration if you want to use a built-in radio clock
    or GPS receiver as time source, which come with their own driver software.

    The reason is because it's hard to tell w32time that it does not need to
    have an upstream time source configured and thus not touch the system time,
    because the system time is already disciplined by another driver, and
    w32time just had to distribute that synchronized time on the network.

    With ntpd this configuration is pretty easy: just configure the local clock
    as ref time source with stratum 0.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  16. Re: Issues with w32tm on AD network

    > We have tried it with a small test setup and found that w32time domain
    > members did identify their PDC as time source when w32time was running on
    > the PDC, but not when ntpd was running on the PDC.
    >
    > I have recently received a note from someone who seemed to be very

    familiar
    > with Active Directory. That person told me whn w32time starts it makes an
    > entry in the LDAP directory which tells the clients at logon that this
    > server is also their time server.
    >
    > I assume if ntpd would do the same thing then domain clients would also
    > detect and accept ntpd running on the PDC.


    I *believe* you can also tell the PDC (via some w32time command) that the
    primary time source is another machine, and all clients will use that. Of
    course that means another machine to manage rather than just installing ntpd
    on it.

    If you search the MS website for words like "NTP Domain Controller" there's
    a lot of info that pops up.

    Jason

  17. Re: Issues with w32tm on AD network

    I'm pretty sure that it's possible to run both NTP and W32TIME at the
    same time on the same Windows system provided that only NTP is used to
    keep the clock under discipline and W32TIME is used solely to provide
    the time for the domain workstations.

    In order to do this, the NTP service is added to the dependency list
    of the W32TIME service through the Platform SDK utility SC:

    sc config w32time depend= NTP

    It's also necessary to disable W32TIME from trying to discipline the
    clock using the registry editor (REGEDIT) under HKLM\CurrentControlSet
    \Services\w32time:

    [TimeProviders\NtpClient]
    InputProvider=DWORD:0
    [TimeProviders\NtpServer]
    InputProvider=DWORD:0

    This will cause NTP to start before W32TIME and thus NTP will take
    over disciplining the Windows DC clock and the domain workstations
    will still communicate with W32TIME.

    HTH

  18. Re: Issues with w32tm on AD network

    Evandro Menezes wrote:
    > I'm pretty sure that it's possible to run both NTP and W32TIME at the
    > same time on the same Windows system provided that only NTP is used to
    > keep the clock under discipline and W32TIME is used solely to provide
    > the time for the domain workstations.
    >


    No, this is untrue. They both use the 123/UDP port. You cannot have more
    than one application listening on the socket. Furthermore they cannot
    both discipline the clock.

    Danny

    > In order to do this, the NTP service is added to the dependency list
    > of the W32TIME service through the Platform SDK utility SC:
    >
    > sc config w32time depend= NTP
    >
    > It's also necessary to disable W32TIME from trying to discipline the
    > clock using the registry editor (REGEDIT) under HKLM\CurrentControlSet
    > \Services\w32time:
    >
    > [TimeProviders\NtpClient]
    > InputProvider=DWORD:0
    > [TimeProviders\NtpServer]
    > InputProvider=DWORD:0
    >
    > This will cause NTP to start before W32TIME and thus NTP will take
    > over disciplining the Windows DC clock and the domain workstations
    > will still communicate with W32TIME.
    >
    > HTH


  19. Re: Issues with w32tm on AD network

    Evandro Menezes wrote:

    >
    > This will cause NTP to start before W32TIME and thus NTP will take
    > over disciplining the Windows DC clock and the domain workstations
    > will still communicate with W32TIME.


    If this works, I suspect it is ntpd that is serving the time and all
    that w32time is doing is maintaining the active directory entry. In
    that case, Microsoft could always fix w32time so that it doesn't declare
    itself available if it is unable to serve time.

  20. Re: Issues with w32tm on AD network

    David Woolley wrote:
    > Evandro Menezes wrote:
    >
    >>
    >> This will cause NTP to start before W32TIME and thus NTP will take
    >> over disciplining the Windows DC clock and the domain workstations
    >> will still communicate with W32TIME.

    >
    > If this works, I suspect it is ntpd that is serving the time and all
    > that w32time is doing is maintaining the active directory entry. In
    > that case, Microsoft could always fix w32time so that it doesn't declare
    > itself available if it is unable to serve time.


    Agreed.

    Though it may currently work I don't think that's a proper solution.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast