On Thu Jan 18 10:52:55 2024 Sonic <sonicsmith at gmail.com>
wrote:>
> I'm with Luis in thinking that the fault is with the DC and not the
> clients. I recently switched from using a GPO to set the time source to
> using the "natural" time sync with the DC at one site due to the
fact that
> I was running the DC in a container which due to age could not run a modern
> enough Chrony that uses the -x flag.
> I had one stubborn system that would not start using the DC for time sync
> even though that specific GPO was removed (all of the others cheerfully
> started using the DC) and I needed to reset the time service to get it to
> work as intended.
> Do this in an elevated prompt:
> =========================> net stop w32time
> w32tm /unregister
> w32tm /register
> net start w32time
> =========================>
> There was also a snag with the DC after the upgrade. I was following my own
> post from the past -
> https://lists.samba.org/archive/samba/2021-March/235228.html - but the DC
> was not acting as a time source for the Windows clients. Reason was
(I'm
> using Debian packages now) the socket was not readable by Chrony. I
noticed:
> =========================> ls -al /var/lib/samba/ntp_signd/
> drwxr-x--- 2 root root 4096 Jan 14 11:14 .
> =========================> And as Chrony runs as the user _chrony on
this version of Debian it could
> not use the socket directory.
> So a simple:
> =========================> chgrp _chrony /var/lib/samba/ntp_signd/
> =========================> fixed that and now all is good.
>
> Chris
Chris - thanks for that detailed message. I've tried with and without a GPO.
I've tried your suggested "net stop ... etc." several times, in
several cases
restoring the Windows machine from image backup. I've tried both ntpd and
chrony
on the DC verifying that both time servers could be reached from the Windows
member
using "w32tm /stripchart".
I've also eliminated the DC as a variable by specifying 0.pool.ntp.org in
"w32tm /config /manualpeerlist", so not even trying to sync with the
DC.
I've been trying every combination of commands and registry settings I can
think
of or have been suggested in this thread, in Windows forums and in numerous web
postings. I've been trying things for a month. Nothing works.
It would be nice if I could simply go into the registry and set a couple of key
attributes like time source and have it work (which I've also tried), but as
I
said in another message, Windows time sync settings are scatter-shotted in
hundreds of key attributes throughout the Registry.
This problem seems to happen when I use RegistryFinder to change Registry
settings from the old current DC and realm name mail.ohprs.local to
dc1.hprs.locl. Before doing that the time source points to mail.hprs.local.
After
doing that it points to "Local CMOS Clock" and nothing I can do seems
to change
that; nor can I find that source in the Registry (probably a bit setting).
My current plan is to forget about changing the domain name and stick with the
current mail.hprs.local, which has worked for the past 20+ years, starting with
Small Business Server, migrated to Samaba4 10 years later. Since the Windows
domain members come up with the correct time source after un-joining the current
and joining the new DC, I think I might be OK.
Working on that idea now.
--Mark