Hyper-V DC als Zeitserver

[Dutch_OnE 39]

Hallo,

 

ich habe einen virtuellen Windows 2008R2 DC als Zeitserver in meinem Netz konfiguriert. Dieser holt sich seiner Zeit von meinem Router, der mit einem NTP Zeitserver verbunden ist. Alle Workstation bekommen ihre Zeit vom DC.

Als Gast Sytem wird ebenfalls ein W2k8 Server verwendet.

 

Problem:

Die Uhrzeit beim Server läuft zu schnell. Mit der Zeit geht die Uhr dann mehrere Minuten vor.

 

Nun habe ich mehrere Meinungen zu diesem Problem gelesen und würde das hier gerne mal ansprechen, um zu sehen was richtig ist.

 

- Muss in den Integrationsdiensten die Zeitsynchronisation an oder aus?

- Es wird in einer Quelle behauptet, dass die zu schnelle Zeit, aufgrund der Belastung des Server kommt.

One thing that you should be aware of here: the rate at which the time in a virtual machine drifts is affected by the total system load of the Hyper-V server. More virtual machines doing more stuff means time drifts faster.

- Ist es überhaupt sinnvoll einen virtuellen DC als Zeitserver zu verwenden?

 

Gruß

DO

[Necron 71]

Hi,

 

kannst du die Quelle für die Aussage angeben?

 

Prinzipiell würde ich für einen virtuellen DC und auch für alle anderen VMs die Zeitsynchronisation in den VM Einstellungen deaktivieren.

 

Hier gibt es aber unterschiedliche Meinungen im Netz. Ein sehr interessanter Blogartikel gibt es von Ben Armstrong dazu: Time Synchronization in Hyper-V - Virtual PC Guy's Blog - Site Home - MSDN Blogs

[Sunny61 807]

ich habe einen virtuellen Windows 2008R2 DC als Zeitserver in meinem Netz konfiguriert. Dieser holt sich seiner Zeit von meinem Router, der mit einem NTP Zeitserver verbunden ist. Alle Workstation bekommen ihre Zeit vom DC.

Als Gast Sytem wird ebenfalls ein W2k8 Server verwendet.

 

Problem:

Die Uhrzeit beim Server läuft zu schnell. Mit der Zeit geht die Uhr dann mehrere Minuten vor.

 

Welche Zeit läuft zu schnell? Die vom 2008R2 DC oder vom W2008? Es sollte die Zeitsynchronisation zwischen Host und Gast nicht mit den Tools der Virtualisierungssoftware hergestellt werden.

 

Weshalb holt der DC nicht gleich seine Zeit von einem NTP Zeitserver? Somit könntest eine Fehlerquelle gleichzeitig ausschliessen.

[NilsK 2.957]

Moin,

 

den Artikel von Ben kenne ich auch, aber aus meiner Sicht ist er erstens in sich widersprüchlich und wird zweitens von der Praxis widerlegt.

 

Daher:

faq-o-matic.net » Virtuelle DCs: Zeitprobleme vermeiden

 

Gruß, Nils

[Dutch_OnE 39]

@Necron - Aus Deiner Quelle habe ich auch die Aussage.

@Sunny61 - Der virtuelle DC läuft zu schnell und verteilt somit diese falsche Zeit an alle anderen Geräte. Der Router, den ich als Zeitserver verwende, funktioniert einwandfrei. Deswegen habe ich ihn als ZS für den Server verwendet.

[GuentherH 61]

Hi.

 

Kleine Zwischenbemerkung..

 

Der Router, den ich als Zeitserver verwende

 

Und du bist dir sicher, dass dieser auch als NTP Server dienen kann. Ich kenne ganz wenige Standard Router, die diese Funktion anbieten.

 

LG Günther

[Dutch_OnE 39]

Ich habe mich dann nicht gut ausgedrückt.

 

Wir verwenden ein Gerät von Bintec, welches sich von einem NTP Server die Zeit holt.

 

GRuß DO

[GuentherH 61]

Hi.

 

welches sich von einem NTP Server die Zeit holt

 

Das heißt aber dann noch immer nicht, dass dieser in der Lage ist dem DC tatsächlich als Zeitgeber zur Verfügung zu stellen.

Ich würde daher den DC einmal korrekt mit einem externen Zeitserver konfigurieren. Hier eines der besten HowTo zu diesem Thema - http://www.gruppenrichtlinien.de/index.html?/HowTo/Zeitserver_per_GPO.htm

 

LG Günther

[Dutch_OnE 39]

Hallo Günther,

 

das werde ich prüfen. Wenn der Router dem DC das nicht bereitstellen kann, habe ich ja sozusagen keinen NTP Sync.

 

In der Ereignisanzeige, kann ich auch nur Informationen über manuelles Eingreifen in Bezug auf das Stellen der Uhrzeit finden.

 

Das spricht definitiv für Deine Vermutung.

 

Gruß DO

[59cobalt 10]

Du kannst mit "w32tm /query ..." den Status der Synchronisation überprüfen (Peers, Offset, letzte erfolgreiche Synchronisation, ...). Generell empfehle ich, die Systemzeit entweder per NTP oder über die Integration Services mit dem Hypervisor zu synchronisieren. Andernfalls hat man gern mal das Problem, dass die per NTP synchronisierte Zeit gleich wieder übersteuert wird.

 

Wenn du dich für NTP entscheidest, wähle das Synchronisationsintervall nicht zu groß. Ist der Offset erst mal zu groß, funktioniert die Re-Synchronisation nicht mehr. Die Einstellungen für Intervall, max. Abweichung, etc. machst du per Gruppenrichtlinie. Wenn die Systemuhr immer noch Drift zeigt, kannst du dort auch Einstellungen zur Korrektur des Drifts vornehmen.

[NorbertFe 2.061]

Du kannst mit "w32tm /query ..." den Status der Synchronisation überprüfen (Peers, Offset, letzte erfolgreiche Synchronisation, ...). Generell empfehle ich, die Systemzeit entweder per NTP oder über die Integration Services mit dem Hypervisor zu synchronisieren.

 

Bei einem DC würde ich letzteres nicht empfehlen.

 

Andernfalls hat man gern mal das Problem, dass die per NTP synchronisierte Zeit gleich wieder übersteuert wird.

 

Genau deswegen läßt man den DC auch nicht mit dem Hypervisor synchen.

Wohingegen andersrum gar kein Problem darstellt.

 

Bye

Norbert

[PadawanDeluXe 75]

Mal ein anderer Ansatz zu dem Thema: Warum trägst du nicht einfach deinen Router dort ein als Zeitserver für dein Nezt, dann bist du doch aus allem fein raus?

[59cobalt 10]

Mal ein anderer Ansatz zu dem Thema: Warum trägst du nicht einfach deinen Router dort ein als Zeitserver für dein Nezt, dann bist du doch aus allem fein raus?

Weil in Windows-Domänen die Zeitsynchronisation normalerweise über die Domänenhierarchie läuft, und davon ausgeht, dass die zentrale Zeitquelle der Inhaber der FSMO-Rolle "PDC Emulator" ist.

[Dukel 455]

Weil in Windows-Domänen die Zeitsynchronisation normalerweise über die Domänenhierarchie läuft, und davon ausgeht, dass die zentrale Zeitquelle der Inhaber der FSMO-Rolle "PDC Emulator" ist.

 

Außer wenn man das konsequent durchzieht und dann überall anpasst (z.B. per GPO / DHCP).

 

Ist dann aber aufwändiger als der Default Weg. Wichtig ist in jedem Fall, dass alle die selbe Quelle haben.

[59cobalt 10]

Verwendung der Domänenhierarchie für die Synchronisation ist im Regelfall die bessere Wahl, aus mehreren Gründen:

 

- funktioniert out-of-the-box

 

- man muss nichts zusätzlich konfigurieren, und kann daher auch nicht vergessen, etwas zu konfigurieren

 

- wenn nicht alle Systeme virtualisiert sind und ihre Zeit vom Hypervisor beziehen, muss man zwei Synchronisationsmechanismen verwalten

 

- ist die Domäne über mehrere Standorte verteilt, versuchen die Clients zunächst erst mal die Synchronisation mit einem lokalen Domänencontroller, und erst wenn das nicht möglich ist mit einem off-Site DC