On Wed Jan 17 13:09:53 2024 Luis Peromarta via samba <samba at lists.samba.org> wrote> > Have you tried a bare installation of Win10 ? > > On Jan 17, 2024 at 18:09 +0100, Mark Foley <mfoley at novatec-inc.com>, wrote: > > > > This is definitely a problem on the Windows endNo I have not. While that would probably work, that would be a last resort as I would then have to scratch-install Windows on all office Windows domain members, re-establish users on domain members, re-install all apps, favorites in browsers, etc. What I'm going to try first is re-provisioning the DC reverting back to mail.hprs.local. I'll post results. --Mark
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