Synchronizace času doménových klientů

[ZAJDAN]

Ahoj...
na doménovém serveru jsem nastavil čas synchronizací z veřejných serverů:
1) net stop w32time
2) w32tm /config /syncfromflags:manual /manualpeerlist:”tik.cesnet.cz, tak.cesnet.cz”
3) w32tm /config /reliable:yes
4) net start w32time
5) w32tm /query /configuration
zkracený výstup:

Kód: [Vybrat]

[Configuration]
......
[TimeProviders]
....
Type: NTP (Local)
NtpServer: tik.cesnet.cz, tak.cesnet.cz (Local)
....
VMICTimeProvider (Local)
DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\Windows\system32\w32time.DLL (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)
....
na jednom z klientů v doméně jsem pustil:
net time \\server.moje-domena.work /set /y
čas se zesynchronizoval, ale během půl hodiny se na klientovi rozhodí až o 2 minuty!

poradil by někdo jak korektně zadrátovat klienty k synchronizaci na server?
díky

[Reklama]

[M.]

Protože tím manuálním net time jsi to možná celé rozbil....
Pokud je windows počítač členem AD domény, provádí automaticky pomocí podepsaného NTP synchonizaci proti doménevému řadiči, co najde a hlásí stav, že je reliable (první instalovaný PDC si reliable nahodí automaticky sám), pokud jsi manuálně nesahal do konfigurace w32tm na klientech.
Takže bych se podíval na klientovi, zda si odněkud bere čas: w32tm /query /status
Tím se dozvíš, odkud bere aktuálně čas kdy ho vzal naposledy, s jakou chybou, jak často se dotazuje, ...
Případně aktuální stav času proti všem řadičům (chvíli trvá): w32tm /monitor

[ZAJDAN]

nevidím jedinej duvod proc bych to mel robít, pokud si šáhnu na čas ke stejnému zdroji, ale i tak provedl jsem restart klienta zavolal na něm:

net time \\LOCALHOST
Current time at \\LOCALHOST is 3/6/2018 10:12:29 AM
The command completed successfully.

net time /DOMAIN:moje-domena.work
Current time at \\SERVER is 3/6/2018 10:10:08 AM
The command completed successfully.

w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0625000s
Root Dispersion: 8.0479121s
ReferenceId: 0xC0A80106 (source IP:  192.168.1.6)
Last Successful Sync Time: 3/6/2018 10:09:33 AM
Source: server.moje-domena.work
Poll Interval: 10 (1024s)

w32tm /query /source
server.moje-domena.work

w32tm /monitor
Getting AD DC list for default domain...
Analyzing server.moje-domena.work  (1 of 1)...
delayoffset from server.moje-domena.work
Stratum: 2

Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.
     
server.moje-domena.work  *** PDC ***[192.168.1.6:123]:
    ICMP: 2ms
    NTP: +0.0000000s         RefID: tak.cesnet.cz [195.113.144.238]

proč se tedy čas i po restartu, časový zdroj správně, liší o 2 minuty?

[M.]

Protože w32tm běžící nějakým způsobem zpomalí/zrychlí běh lokálního času, pokud mu do toho sáhneš skokovou změnou net time, tak to zblbne.
A jak sed ta chyba vyvíjí v čase?
Obecně, pokud je při startu Win klienta čas serveru pozadu do 2 minut, tak klient zpomalí svůj čas tak, aby ty 2 minuty cca dorovnal za 20 minut, pokud je odchylka víc jak 2 minuty, měl by to skokově dorovnat po startu a prvotním kontaktu serveru.
Má na to případně dost vliv, zda server nebo klient je virtuál.
Jak se to vyvíjí v čase se dá pozorovat pomocí w32tm /stripchart /computer:192.168.1.6

[Trhan72]

Není ten stroj náhodou virtualizovaný? Ve výchozím stavu se přebírá čas z "podhoubí" a pak se to tluče.

[Reklama]

[ZAJDAN]

Není ten stroj náhodou virtualizovaný? Ve výchozím stavu se přebírá čas z "podhoubí" a pak se to tluče.

ano jsou virtualy oba, ale jak zminoval M on se ten cas postupne spravuje, ja bych ocekavl, ze si to spis checkne cas a jednim uderem ho spraví

ale prikaz vise co jsem uvedl jasne ukazal ze klient si cas bere ze spravneho serveru, debilni je jen to ze si to srovnava plynule a ne jednou jebou

[ZAJDAN]

a ted jsem si vsiml, ze jiny klient(nativni na zeleze) ve stejne domene co uz bezi vice jak den si nebyl schopnej cas srovnat, pricemz status ukazuje ze ma spravny zdroj k serizeni casu a to domenovy server...nevim...zacinam si myslet ze v tech windows to nefunguje uplne v poradku

[M.]

Ano, w32tm je taková specifická implementace S/NTP (když to beru z pohledu, že řešívám spíše nutnost jednotného času a frekvence na nanosekundy), ale pro běžnou kancelařinu OK, pokud mi nevadí chyba do cca 1 sekundy (od 2016 serveru je podpora pro přesnější časy v ms měřítku).

Pokud to jsou virtuály a navíc VM hostitel případně do času uvnitř virtuálu štouchá vlastníma postupy, tak to bude pořád nějak plavat. Ohledně počáteční sync platí, co jsem psal, pokud je klient 0 až 2 min před serverem, dojde k plynulému dorovnání času jeho zpomalením na klientu, v ostantích případech se dorovná při startu skokem.

Pokud ten nativní klient běžel ještě před tím, než jsi aktivoval a korektně syncnul ten server, tak pokud tím čas na serveru nečekaně někam poskočil o minuty, tak klient jej bude již ignorovat, protože jej vyhodnotil jako nespolehlivý. Skokově dorovná až po rebootu nebo možná w32tm /resync, který mu vymaže statistiky.

[ZAJDAN]

Ano, w32tm je taková specifická implementace S/NTP (když to beru z pohledu, že řešívám spíše nutnost jednotného času a frekvence na nanosekundy), ale pro běžnou kancelařinu OK, pokud mi nevadí chyba do cca 1 sekundy (od 2016 serveru je podpora pro přesnější časy v ms měřítku).

Pokud to jsou virtuály a navíc VM hostitel případně do času uvnitř virtuálu štouchá vlastníma postupy, tak to bude pořád nějak plavat.

ja stále nechápu jak host do guesta muze šťouchat, když přeci sam guest ukazuje jaký má zdroj času viz:
w32tm /monitor
Getting AD DC list for default domain...
Analyzing server.moje-domena.work  (1 of 1)...
delayoffset from server.moje-domena.work
Stratum: 2

Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.
     
server.moje-domena.work  *** PDC ***[192.168.1.6:123]:
    ICMP: 2ms
    NTP: +0.0000000s         RefID: tak.cesnet.cz [195.113.144.238]

jak já jako admin se tedy dozvím, koho ta mašina poslouchá? hosta co ji virtualizuje nebo servery nastavene ve w32tm ?

[M.]

Mašina nikoho neposlouchá. :-(
Služba w32tm monitoruje čas v systému a čas DC serveru a nějakým způsobem dorovnáná ten lokální čas v OS a předpokládá, že jednak nikdo jiný na ten čas v OS nesahá a čas v OS běží navíc rovnoměrně tempem, co určila (což ne vždy ve virtuálu je pravda). Pokud ti v systému běží ještě něco jiného, co případně s časem manipuluje, například VMware tools, tak se pak vzájemně ty nástroje přetahují a jen si v tom vzájemně vyrábí chybu.
Ty víš, jakou virtualizační platformu používáš, víš jak ji máš nastavenu ohledně udržovánbí času ve virtuálech, jaké služby a k čemu tam máš nacpané, co ne/umí a dle toho se zařídit. :-)

[Lol Phirae]

Prosímtě, nechceš se na to adminování Woken vysrat? Dle záplavy začátečnických dotazů za poslední týden to zjevně nebude tvoje parketa.

PDC se synchronizuje s nějakým veřejným zdrojem času, ostatní DC se synchronizují s ním, pracovní stanice v doméně se synchronizují s těmi DC. Krom nastavení toho PDC není normálně třeba nic dělat.

Pokud máš DC jako virtuály, tak synchronizaci s HyperV v integration services vypni.

Je úplně šumák, o kolik minut je to rozházené vůči zbytku světa, podstatné a účelem snažení je, aby to bylo synchronizované mezi sebou a fungovaly Kerberos tickety.

[Lol Phirae]

K předchozímu viz např. zde bod 5.

[ZAJDAN]

Ty víš, jakou virtualizační platformu používáš, víš jak ji máš nastavenu ohledně udržovánbí času ve virtuálech, jaké služby a k čemu tam máš nacpané, co ne/umí a dle toho se zařídit. :-)

díky za podporu, vypínám tedy službu pro syncTime primo na virtualizaci hostu:
VBoxManage setextradata "domain-server" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1

[Hans]

Je dobrým pravidlem mít první dc na fyzickém stroji, noboť když je to na virtuálním tak se tam mlátí časy mezi sebou a děla to neplechu, neboť dc si při startu bere čas s z biosu a také se ho tam aktualizuje, když je to na virtualizaci tak nemá pravou upravovat čas v biosu a cele se to taky rozkazuje. Tak hlavní dc nať na samotnou masinu a na klienty nesahat sami si pak srovnání čas s dc

[ZAJDAN]

K předchozímu viz např. zde bod 5.

díky za článek