Jump to content

Timesynchronization out of space


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Frage an alle AD Professionals.

 

Ich will ein Problem hier im Vorfeld lösen.

Da ich in den Tiefen der AD noch nicht so drin stecke eine Frage.

 

Letzte Woche zollte ein Member Server(Microsoft) der wärme Tribut und lebte ab.

Der Techniker verbaute und neues Mainboard und fuhr ihn mit Bios Datum 1.1.80 an.

Die EreignisIDs waren sehenswert und die Informix Datenbank nahms auch Übel,

war aber nicht das Problem da kenne ich mich aus.

 

Da ich ein Novell Mensch bin kenne ich bei Netware die "synthetic time" und wie

ich zu reagieren habe.

 

Habe daneben seit 1 Jahr eine AD Landschaft 9 DCs mit Site Replication laufen.

 

Und nun die Frage:

Was würde passieren, wenn der erste DC ein neues Board bekommt und mit Datum 1.1.80 hochkommt.

Ich halte das jetzt mal spontan für eine gute Idee das NICHT auszuprobieren.

 

Konnte jemand damit schon einmal Erfahrungen sammeln oder gibt es dazu eine Microsoft Strategie.

 

Vielen Dank in voraus

________

thorgood

Link zu diesem Kommentar

Zunächst würde Windows beim Anmelden sofort eine Warnmeldung ausgeben, das Datum und Zeit nicht stimmen, und man diese Korrigieren solle, sofern man 1980 eingestellt hat. wo der BreakPoint liegt, dass er keinen Verdacht schöpft weiss ich nicht, vielleicht hat es mit dem Installationszeitpunkt zu tun, den er sich irgendow in die Registry geschrieben hat.

Nun, in einer größeren ADS mit mehrern DCs, vielleicht auch mehreren Domänen und Sites würde es natürlich zunächst Probleme mit der Replikation oder auch Clientanmeldungen an diesem DC geben. Wahrscheinlich am betsen, sobald man den Fehler feststellt, das Netzwerk an diesem DC unterbrechen, und dann richten, damit zwischenzeitlich nicht andere DC ihre Zeit mit ihm synchronisieren.

Es ist aber nichts, was nicht gerichtet weden kann. Ein sehr ausführliches Whitepaper zum Zeitdienst unter Windows 2000 und Tools zum Eingreifen findest du hier:

http://www.microsoft.com/windows2000/techinfo/howitworks/security/wintimeserv.asp

 

grizzly999

Link zu diesem Kommentar

@grizzly999

Erst mal schönen Dank,

 

aber ich meine ja genau den DC der die FSMO Rolle hält.

An dem meldet sich eigentlich nie jemand an.

 

Die anderen DC synchronisieren sich sowieso nicht bei einer Zeitdifferenz von über 24 Stunden.

 

Das Papier dazu habe ich schon gelesen schweigt sich aber genau über diesen Fall aus, alle anderen Fälle sind gut beschrieben.

 

Auch MCSEs die ich gefragt haben, hielten das für ein echtes Problem wussten aber keine Antwort.

Link zu diesem Kommentar
An dem meldet sich eigentlich nie jemand an.

Das wäre ja sehr merkwürzig, wenn jemand ein neues Board einbaut, oder auch einen Forest mit einem solchen Board neu aufsetzen würde, ohne sich anzumelden.

 

Die anderen DC synchronisieren sich sowieso nicht bei einer Zeitdifferenz von über 24 Stunden

Das kann ich leider nirgends finden. Meines Wissens nach wird ab einer Zeitdifferenz von 5 Minuten (Kerberos default Delta) nicht mehr repliziert. Oder meinstest du die Zeitsynchronisation? Die funktioniert aber bei jedem DC wie bei einer Workstation, d.h. der DC müsste beim Feststellen des Vorgehens der Uhr um mehr als 15 min. seine zeit auf die seines massgeblichen Zeitservers stellen.

Ich sehe hier immer noch kein gravierendes Problem bei dem konstruierten Fall. Wenn ich das falsche Datum feststelle, korrigiere ich das Datum auf dem PDC-Emulator und fahre im schlimmsten Fall alle Rechner neu hoch. Ich würde meinen, dann stimmen sie alle.

 

grizzly999

Link zu diesem Kommentar

Ja ich meine nur die Zeitsynchronisation.

 

Und unter Anmelden verstand ich sich pysikalisch mit user und passwort am Server anmelden.

 

Denn ein Techniker tauscht nur das Mainboard schaltet ihn ein und wartet bis der Server hochgefahren ist. Er meldet sich aber nicht an. (Jedenfalls unsere Service Techniker nicht, die haben nicht einmal ein Account).

 

Aber das hat mir jetzt als Antwort geholfen. So gut konnte es mir noch niemand sagen.

 

thorgood

 

PS: Und so konstruiert ist Fall garnicht, kommt bei den Netware-Server regelmässig vor, aber da ist die Hardware auch schon älter.

Im AD Umfeld sind die Server jetzt gerade mal ein Jahr alt.

Link zu diesem Kommentar

Hallo Thorgod,

In produktiven Systemen sollte sich der PDC-Emulator der ersten Domäne (an dem hängen alle PDCs aus evtl. vorhandenen weiteren Domänen) seine Zeit von einer externen Quelle (etwa einem Router) abholen. Die Beschreibung des Registrykeys findest du z.B. in dem Papier von Grizzly auf Seite 19. Du setzt als auf diesem PDC den NTPServer Key und den Period Key. Alle anderen Rechner ziehen dann automatisch nach. Die Mainboardzeit des PDCs interessiert dann niemanden.

cu

blub

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...