NTP servers met verschillende tijd zones

[battler]

Wij hebben hier twee NTP servers. 1 met UTC en 1 met LT (local time).
Nu wil ik graag dat alle servers (2008 R2) op UTC draaien en alle clients op LT (Windows 7). Volgens mij is dat niet mogelijk vanwege kerberos en het verschil in tijd (machines in een domein). Maar misschien is het wel mogelijk om de clients twee verschillende klokken te laten weergeven 1 met UTC en 1 met LT. Daarentegen kan ik nergens vinden op het internet hoe er twee tijd servers ingesteld kunnen worden (met uit elkaar liggende tijden).

Toevoegen van meerdere klokken is mogelijk:link
Configureren van een NTP server: link

[Tijntje]

NTP is onafhankelijk van de tijdzone. Dat is nu juist het idee.
Door de time zone in de regional settings wordt bepaalt hoe groot de offset is van de tijd.
Zie Wikipedia: Network Time Protocol

[battler]

De offset bepalen moet dus centraal gebeuren. Dat betekent dat dus dat de twee tijd servers een andere tijd uitsturen.

[Ethirty]

Je hebt maar 1 NTP server nodig. De basis tijd is altijd gelijk. Vervolgens stel je op servers en clients verschillende tijdzones in.

Je zou dit centraal kunnen regelen via een GPO: http://www.techrepublic.c...-zone-using-group-policy/

[battler]

Dan is het niet mogelijk om de tijd te wijzigen via de NTP server, deze heeft een hardware interface. En dit laatste is wel vereist. Maar als ik het goed begrijp is er dus geen oplossing.

[Ethirty]

Van wat ik begrijp wil je afwijken van hoe NTP en tijd in het algemeen werkt, al leg je niet uit wat je precies wil en waarom. Dan zal je iets anders moeten verzinnen ben ik bang.

[ Voor 15% gewijzigd door Ethirty op 21-08-2013 12:46 ]

[Rmg]

battler schreef op woensdag 21 augustus 2013 @ 11:31:
Wij hebben hier twee NTP servers. 1 met UTC en 1 met LT (local time).
Nu wil ik graag dat alle servers (2008 R2) op UTC draaien en alle clients op LT (Windows 7). Volgens mij is dat niet mogelijk vanwege kerberos en het verschil in tijd (machines in een domein). Maar misschien is het wel mogelijk om de clients twee verschillende klokken te laten weergeven 1 met UTC en 1 met LT. Daarentegen kan ik nergens vinden op het internet hoe er twee tijd servers ingesteld kunnen worden (met uit elkaar liggende tijden).

Daar heb je gewoon timezones voor...

Dat is het hele idee... ik snap niet waarom je de tijd van je ntp server wilt veranderen wat UTC = UTC

[ Voor 5% gewijzigd door Rmg op 21-08-2013 12:47 ]

[Red Cell]

Nee, zie het als volgt. Alle OS'en (clients en servers) gebruiken intern UTC tijd. Echter voor jou als gebruiker omdat jij als mens UTC niet snapt telt je computer je offset erbij op die je insteld heb en geeft dit weer in je tray. (de local time)
Je weet wel, die vraag van in welk land woon je tijdens de installatie, dat stelt de offset in. (voor ons dus GMT +1)

Dus als je de servers voor jou UTC wil laten weergeven moet je de offset op 0 uur zetten. Simple as that.

(edit: dit laatste pas dus alleen aan hoe jij als user de tijd ziet/ervaart, niet wat de daadwerlijke tijd is)

[ Voor 11% gewijzigd door Red Cell op 21-08-2013 12:49 ]

[battler]

Het wijzigen van time zones op individuele basis is niet te doen, zelfs door middel van een GPO is te veel werk. Het zal maandelijks door een niet technisch persoon gewijzigd moeten worden. Daarom is er een aparte NTP server met een gemakkelijke interface.

[Ethirty]

Je maakt nog steeds niet duidelijk waarom je dat wil of wat het nut is van het aanpassen van je klok. De hele wereld werkt op basis van UTC, je kan niet zomaar die tijd laten afwijken

De tijd van de DC is leidend in je netwerk, alle servers en computers moeten +/- 5 minuten van deze tijd blijven anders krijg je inderdaad problemen met Kerberos.
Hou er bijvoorbeeld ook rekening mee dat in de zomer onze huidige tijd +2 UTC is, in de winter +1 UTC.

Je kan ook in W7 tijd instellingen zien dat je voor het aanpassen van de klok admin rechten nodig hebt (aanpassen basis tijd, die overal gelijk is) en dat de tijdzone zelf aan te passen is. Hiervoor hoef je dus allerminst technisch te zijn.

[battler]

UTC gebruiken we voor non-end user equipment. Local time (UTC+Time zone) voor end-user equipment. Time zones zijn prima maar het aanpassen van time-zones is teveel werk. Daarom wil ik dat er een tweede tijd server is die tijd uitdeelt die al in de juiste tijd zone zit. Het is voor op een boot dus het zal continu van tijdzone wijzigen.

[ Voor 9% gewijzigd door battler op 21-08-2013 13:53 ]

[Hero of Time]

Battler, het hele idee met NTP is dat je 1 tijd hebt, zoals zo vaak hier al is gezegd. Met tijdzones heb je offset voor zover dat nodig is. Om je een idee te geven, de UNIX tijd die ik net heb opgevraagd was 1377086439 UTC. Dit is hier, maar ook in Australië, Japan, VS en Hawaï. Er is geen afwijking hiervan, terwijl er 7 uur verschil is met Japan (GMT +8) en Nederland (GMT +1).

Computers verhuizen niet of iig niet dagelijks, dus net als de rest hier snap ik je hele probleem niet. Je maakt een probleem van iets wat er niet is.

Owja, Kerberos maakt gebruik van de UNIX tijd, niet wat je klok weergeeft.

[ Voor 6% gewijzigd door Hero of Time op 21-08-2013 14:04 ]

[Ploink]

Het NTP protocol kent geen tijdzones, kan dus ook geen tijd uitdelen "in de juiste tijd zone".
Ik ken de details niet, maar hoogstwaarschijnlijk gaat kerberos ook uit van UTC en houdt er zodanig rekening mee dat een client of server in een andere tijdzone kan staan.

Je mag alle tijdzones dus instellen zoals je wil en net doen alsof ze in het buitenland staan, het zal prima werken met maar 1 NTP server en kerberos.

Wat je echter NIET moet doen is een machine die in UTC staat vertellen dat het nu 14:05 is, want dan loopt zijn klok 2 uur voor.

[Orion84]

Hero of Time schreef op woensdag 21 augustus 2013 @ 14:03:
Computers verhuizen niet of iig niet dagelijks, dus net als de rest hier snap ik je hele probleem niet. Je maakt een probleem van iets wat er niet is.

battler schreef op woensdag 21 augustus 2013 @ 13:51:
Het is voor op een boot dus het zal continu van tijdzone wijzigen.

Dat is zijn probleem. In dit geval verhuizen de PC's dus wel dagelijks.

[ Voor 30% gewijzigd door Orion84 op 21-08-2013 14:08 ]

[battler]

Bedankt Orion84:)

[Ethirty]

Of computers nu dagelijks verhuizen of niet, de interne tijd blijft altijd UTC. De tijdzone moet de gebruiker zelf aanpassen, een pc kan niet zomaar detecteren in welke tijdzone die zit (mobiele devices kunnen dat wel via GSM of GPS).

Je kan met Windows 7 meerdere klokjes op de de desktop laten zien met de tijd in verschillende zones of er een specifieke applicatie voor zoeken.

Kijk hier eens naar: http://www.godotandco.com
Op basis van je interrnet verbinding kan dit tooltje je tijdzone detecteren en wijzigen.
Of stap over op OS X, die schijnt dit out-of-the-box al te kunnen.

[ Voor 21% gewijzigd door Ethirty op 21-08-2013 14:23 ]

[Ploink]

Misschien kan zoiets uitkomst bieden?
http://www.godotandco.com/time-traveller-features.aspx

[DukeBox]

Om hoeveel werkstations gaat het ?

Nu is het al weer een tijdje geleden, maar hardware in boten gebruikten wij ook altijd UTC zonder tijdzone (voor logging e.d.) Daarnaast werd middels een netwerk GPS ntp bron en automatische tijdzone aanpassing gedaan op de werkstations via een deamon (die niet allen in een AD stonden). Uiteraard was dit niet exact op het moment dat je een tijdsgrens overging, maar met een afwijking van niet minder dan 5kilometer werkte dat perfect. Overigens werden de (AD) servers ook middels die GPS op tijd gezet alleen stond de zone altijd fixed.

meer info: http://www.spectracomcorp...r/tabid/1526/Default.aspx

@hierboven, dergelijke oplossingen hebben wij ook naar gekeken, maar niet alles had/heeft internet (toegang).

[ Voor 18% gewijzigd door DukeBox op 21-08-2013 14:31 ]

[battler]

Ik kan de tijd van de desktops niet wijzigen omdat hij anders niet meer in sync is met de DC (tijdzones verhaal is niet te doen). Vandaar dat ik dus hoopte dat het mogelijk was om twee klokken te hebben beiden via een andere NTP server. 1 in sync met de DC en 1 met de LT.

[ Voor 92% gewijzigd door battler op 21-08-2013 14:38 ]

[Ploink]

battler schreef op woensdag 21 augustus 2013 @ 14:32:
Het is dus de bedoeling dat tijd wordt gegeven door de NTP server. Daardoor hoeft de eindgebruiker geen tijdzone aan te passen.

Daar zit nou juist het probleem. Als je de tijd zelf gaat aanpassen en niet de timezone, dan loopt de interne UTC klok op de clients niet meer gelijk. Dat gaat problemen geven met alle protocollen en websites waar een correcte tijd op de client vereist is.

Kerberos werkt niet meer, http caching gaat mis, de ontvanger van jouw email denkt dat je het al een uur eerder hebt verstuurt. Je online banking site vertrouwt het niet meer, etc, etc.

De enige goede oplossing is dus wel steeds op alle clients de tijdzone aan te passen. Dit is vast wel te automatiseren op de een of andere manier.

battler schreef op woensdag 21 augustus 2013 @ 14:32:
Ik kan de tijd van de desktops niet wijzigen omdat hij anders niet meer in sync is met de DC (tijdzones verhaal is niet te doen). Vandaar dat ik dus hoopte dat het mogelijk was om twee klokken te hebben beiden via een andere NTP server. 1 in sync met de DC en 1 met de LT.

Ehh.. Je zegt dat je de tijd van de dektops niet kan wijzigen, maar toch wil je de tijd van de desktops wijzigen via een aparte NTP server? Nogmaals, NTP doet niet aan tijdzones en spreekt uitsluitend UTC.

[ Voor 38% gewijzigd door Ploink op 21-08-2013 14:51 ]

[battler]

Ivm Kerberos e.d dacht ik dus NTP 1 te gebruiken die in sync. loopt met de DC. En alleen voor de user clock NTP2. Helaas begrijp ik dus dat dit geen functionailteit is die Windows biedt.

[Ethirty]

Nogmaals, dat ligt niet aan Windows. Dat kan niet, period. UTC==UTC

[DukeBox]

battler schreef op woensdag 21 augustus 2013 @ 14:32:
Ik kan de tijd van de desktops niet wijzigen omdat hij anders niet meer in sync is met de DC

Precies.. en dat wil je ook helemaal niet.

(tijdzones verhaal is niet te doen).

Waarom niet ? Dat is juist dé manier om je tijd aan te passen 'cosmetisch', op de achter grond blijft alles gewoon op dezelfde tijd lopen.

Buiten dat gaan ook veel SSL/TLS dingen niet werken met een te grote tijds afwijking.

[ Voor 12% gewijzigd door DukeBox op 21-08-2013 15:42 ]

[Brahiewahiewa]

Jouw manier van omgaan met dit topic is een beetje vervelend, eigenlijk.
Je poneert een probleem en telkens als er een suggestie komt, reageer jij met: "kan niet" en weer een klein stukje info.[/nfi]

[on topic]Je zoekt feitelijk een time-zone server; een device in het netwerk dat bepaalt in welke time-zone het netwerk zich bevindt. NTP is hiervoor niet gemaakt en het daarvoor toch gebruiken is vragen om problemen. De time-zone server kan een apparaat zijn wat automatisch (GPS) de time-zone bepaalt, maar het kan ook gewoon en PC zijn waarop handmatig de time-zone ingesteld wordt.

Met "GPO" bedoelt Ethirty niet dat er telkens bij het passeren van een tijdgrens iemand de GPO in kwestie wijzigt en distribueert, maar juist een volautomatisch proces wat met zekere regelmaat de time-zone server uitleest en de lokale machine met die info update. In totaal heb je het over twee scriptjes van elk tien regels, ofzo

[battler]

Brahiewahiewa schreef op woensdag 21 augustus 2013 @ 16:01:
Jouw manier van omgaan met dit topic is een beetje vervelend, eigenlijk.
Je poneert een probleem en telkens als er een suggestie komt, reageer jij met: "kan niet" en weer een klein stukje info.[/nfi]

Noted, excuses

Met "GPO" bedoelt Ethirty niet dat er telkens bij het passeren van een tijdgrens iemand de GPO in kwestie wijzigt en distribueert, maar juist een volautomatisch proces wat met zekere regelmaat de time-zone server uitleest en de lokale machine met die info update. In totaal heb je het over twee scriptjes van elk tien regels, ofzo

Dit zou wel een oplossing kunnen zijn. Tijd uit NTP2 lezen en de offset als Time-zone distribueren.

[consolefreak]

misschien is het handig dat je toelicht waarom die machines persee de lokale tijd moeten hebben? Als het puur voor de gebruikers gaat is het klokjes op de desktop systeem prima. Maar je geeft erg weinig informatie eigenlijk behalve dat het op een boot zit..

[Ethirty]

Mijn laatste poging: heb je wat aan een GPS NTP server?
http://www.spectracomcorp...r/tabid/1526/Default.aspx

Je zal zelf de docu even moeten doorbladeren, wellicht kan deze NTP server de timezone meegeven aan de clients, gezien de tijd van GPS sattelieten komt en dus wellicht ook locatiebepaling ondersteund.

Jouw oplossing om NTP1 en NTP2 verschillende tijden te laten hebben gaat niet werken, aangezien je dan aan de basis UTC tijd rommelt. Zoals eerder vermeld gaat dat waarschijnlijk allerlei onverwachte problemen geven.

[BCC]

Out of the box oplossing : deze kopen http://www.theverge.com/2...date-price-pictures-video

En voor conversie van lat/long naar Timezone (wat niet rekenkundig kan, omdat de lijnen meestal netjes om landsgrenzen heen liggen), koop je deze library: http://askgeo.com

[ Voor 38% gewijzigd door BCC op 21-08-2013 18:43 ]

[Wim-Bart]

Wat een zinloze discussie. In een Windows Domein is het gewoon heel erg simpel.

Regel 1: Je PDC emulator altijd syncen aan een ntp server die UTC geeft en altijd syncen met een interne hardware klok. Virtualisatie heeft wat andere eisen/wensen, maar daarover zo meer.
Regel 2: De rest van je domein gewoon default houden en gewoon Windows zijn werk laten doen.

Bij virtualisatie is het iets complexer als je geen fysieke PDC emulator hebt.

1. Tegen iedere best practice in, je PDC emulator altijd met de host clock van je Hyper-V of VMWare server laten syncen in combinatie met een reliable NTP Source.
2. Je ESX/Hyper-v hosts altijd laten syncen met de zelfde bron als je PDC emulator.

Java apps in je omgeving. Dan de default refresh policies aanpassen, standaard is dat per 3600 seconden syncen geloof ik, maar breng het maar terug naar 900 of zelfs 300 seconden. Wanneer je applicatie en database servers gevirtualiseerd zijn, dan mag je die best een twee sporen beleid geven, a) via je AD domein (syncen aan de PDC) en b) Syncen met de host.

Dan tijdzone probleem. Dat is met GPO op te lossen. En niet via domein GPO's maar via site GPO's. Dus zolang je sites en services goed hebt ingericht en netjes sites hebt gemaakt van je LAN/WAN segmenten dan kan je de tijdzone per site regelen. Overigens syncen de clients en servers altijd met de DC waar ze zich aanmelden. Dus Sites goed definieeren is de basis.

Wanneer je afwijkt van de structuur, door bijvoorbeeld een fake UTC te maken krijg je de volgende problemen:

• SSL problemen;
• Kerberos problemen;
• Syncronisatie problemen binnen je domein;
• Databases met tijden die niet kloppen;
• Logging klopt niet;
• Transactie problemen in databases en applicaties;
• Spontane account lockouts, ook client/server accounts die locked out raken.

Dat is nog maar een kleine lijst.

Overigens waar je ook rekening mee moet houden:
Wanneer de tijd synchronisatie niet goed is (door verschillende bronnen bijvoorbeeld) zal Windows bij een te grote afwijking niet corrigeren. Dus in jouw geval, NTP domein is UTC, NTP werkstations is UTC+x dan zullen de Windows clients gewoon zeggen: Bekijk het maar, ik vertrouw mijn interne hardware klok en zal nooit meer gelijk lopen, met alle ellende van dien.

[ Voor 9% gewijzigd door Wim-Bart op 22-08-2013 00:43 ]

[Verwijderd]

battler schreef op woensdag 21 augustus 2013 @ 16:41:

Dit zou wel een oplossing kunnen zijn. Tijd uit NTP2 lezen en de offset als Time-zone distribueren.

Van welke server je de tijd ophaalt hoort niet uit te maken. De tijd hoort overal (bijna) precies gelijk te lopen. Stap af van het idee dat je servers iets met twee tijden doen. Het maakt niet uit met welke server je synct. Het zou zelfs niet heel veel uit moeten maken als je een willekeurige timeserver op het internet pakt, want jouw systemen horen niet veel af te wijken. Maar qua netwerkinstellingen, VPN's en dat soort zaken is het handig vanuit je eigen domein te updaten.

Het enige dat ooit kan uitmaken is de timezone. Focus je daarop en realiseer je dat de weergegeven tijd alleen maar een representatie is.

[Megamind]

Ik weet niet hoe groot je schip is, maar op ons schip hadden we gewoon een tooltje geschreven die de timezone bepaalde voor het hele schip. De OOW moet toch om 2:00 de klok een uur vooruit, of achteruit zetten en past dan ook direct met dit tooltje de tijd van de PC's aan.

De servers worden hierbij wel overgeslagen en blijven gewoon op (UTC) Coordinated Universal Time staan, de workstations worden via een GP geupdate zodra ze inloggen.

[battler]

consolefreak schreef op woensdag 21 augustus 2013 @ 16:50:
misschien is het handig dat je toelicht waarom die machines persee de lokale tijd moeten hebben? Als het puur voor de gebruikers gaat is het klokjes op de desktop systeem prima. Maar je geeft erg weinig informatie eigenlijk behalve dat het op een boot zit..

Inderdaad, puur voor op de gebruikers.

Ethirty schreef op woensdag 21 augustus 2013 @ 18:05:
Mijn laatste poging: heb je wat aan een GPS NTP server?
http://www.spectracomcorp...r/tabid/1526/Default.aspx

Je zal zelf de docu even moeten doorbladeren, wellicht kan deze NTP server de timezone meegeven aan de clients, gezien de tijd van GPS sattelieten komt en dus wellicht ook locatiebepaling ondersteund.

Er is al een (vrij dure) tijd server, deze heeft op dit moment geen GPS module.

BCC schreef op woensdag 21 augustus 2013 @ 18:41:
Out of the box oplossing : deze kopen http://www.theverge.com/2...date-price-pictures-video

En voor conversie van lat/long naar Timezone (wat niet rekenkundig kan, omdat de lijnen meestal netjes om landsgrenzen heen liggen), koop je deze library: http://askgeo.com

Bedankt, de vraag was niet zozeer hoe kom ik aan de tijd maar hoe krijg ik verschillende tijden binnen een domein.

Wim-Bart schreef op donderdag 22 augustus 2013 @ 00:40:

Bedankt, duidelijk verhaal.

Megamind schreef op donderdag 22 augustus 2013 @ 01:24:
Ik weet niet hoe groot je schip is, maar op ons schip hadden we gewoon een tooltje geschreven die de timezone bepaalde voor het hele schip. De OOW moet toch om 2:00 de klok een uur vooruit, of achteruit zetten en past dan ook direct met dit tooltje de tijd van de PC's aan.

De servers worden hierbij wel overgeslagen en blijven gewoon op (UTC) Coordinated Universal Time staan, de workstations worden via een GP geupdate zodra ze inloggen.

Dat gaat hem dus worden. Niet de oplossing die ik voor ogen had maar hopelijk goed genoeg.