On Tue, Aug 18, 2009 at 10:34 AM, Martin Burnicki<martin.burni...@meinberg.de> wrote: > AFAICS this means recent w32time clients in a Windows domain would never > accept reply packets from the PDC if ntpd instead of w32time is running on > the PDC, even if either of the workarounds mentioned above is being used. > Of course you could run ntpd also on the clients, which would accept the > NTP daemon running on the server as their time source.
You are correct. It is conceivable that one day ntpd will be enhanced to perform MS-SNTP signing on Windows DCs. ntpd would then also need to ensure the DC is advertised as a time source within the domain by setting the registry value or whatever. > However, the question is if other applications (e.g. databases) running on > workstations or secondary servers try to find out whether the time of the > machine they are running on is synchronized to the "network time", and > complain if this is not the case. I do not believe so. > If they do, then how do they do it? Do w32time clients also provide a > registry setting or API to let other applications find out whether the > system time is synchronized? If this is the case then it would not even > help to install ntpd both on the PDC and on other servers and workstations. > > Unfortunately I don't have access to a Windows domain, so I'd like to ask if > someone else in this group has experience with ntpd running in a domain of > recent Windows versions? I run ntpd on a _a_ DC, but not on the DC acting as PDC. The PDC is set to sync to the ntpd DC. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
