Windows 7 Pro verliert immer wieder Vertrauensstellung zur Domäne

[Esta 114]

Hi Leute,

 

also ich habe lange recherchiert, vielleicht habt ihr noch ein paar Tipps. Folgendes Problem: Ich habe hier in der Domäne ein paar Windows 7 Pilot-PCs zum Test der Migration. Seit Freitag bekommen einige die Fehlermeldung, dass "die Vertrauensstellung zur Domäne verloren" haben. Und das immer, wenn sie morgens den PC neu starten. Da hilft ja nur ein Rejoinen des PCs und das, soweit ich weiß, vor Ort. Am Freitag betraf es 2 PCs aus der gleichen OU, am Montag schon ein paar mehr aus unterschiedlichen OUs. Am Freitag dachte ich, es läge daran, weil ich in den Gruppenrichtlinien die Firewall Einstellungen der einen OU etwas geändert habe. Aber das war ja nun bei den anderen PCs der Fall. Die Fehlermeldungen auf den PCs und DCs sind Netlogon Event ID 3210, 5719, 5722 und 5781.

 

Heute hatte ich den Fall, dass die Windows Patche eingespielt wurden und nach dem Reboot wieder keine Vertrauensstellung vorhanden war.

 

Die PCs sind in einer Sub-Domäne, die 4 DCs hat. Dass sie sich nicht anmelden dürfen, passiert nur, wenn sie sich an einen bestimmten DC anmelden wollen. Heute habe ich heraus gefunden, dass dieser DC eine völlig falsche Zeit hat. Kann eine der Ursachen sein, warum die PCs sich nicht anmelden dürfen. Weiter habe ich festgestellt, das jeder DC sich mit einem anderen Zeitserver syncen. Nur ich betreue die Server nicht.

 

Gibt es noch irgendwelche Einstellungen, die ich clientseitig machen oder überprüfen kann? Es kann ja nicht die Lösung sein, den Usern zu sagen, sie sollen erst mal ihre PCs nicht abschalten oder rebooten. Oder die PCs jeden Tag zu rejoinen oder zu hoffen, dass sie sich nicht an dem einen DC anmelden.

[lefg 276]

Hallo Esta,

 

bekommen die Clients die richtige DNS-Adresse? Von DNS erhalten sie die Liste der DCs.

[zahni 550]

Hier solltest Du unbedingt stoppen und Deine Domäne(n) untersuchen. Datum und Uhrzeit müssen überall synchron sein.

Die Quelle der Uhrzeit ist immer der PDC-Emulator der Domäne. Andere DC's dürfen unter keinen Umständen mit einer anderen Quelle synchronisieren.

Der PDC-Emulator kann auf einen externen NTP-Server zugreifen (und sollte das vermutlich auch).

Dein Konstrukt mit den Sub-Domänen macht die Sache nicht einfacher. Eigentlich sollte man das vermeiden.

 

Vermutlich bringt der veraltete DC Deine Domäne durcheinander. Lasse da einen Spezialisten ran, sonst geht noch mehr kaputt.

Am Besten machst Du eine n Support-Call bei MS auf. Leider scheint MS Deutschland hier aber zunehmend den Support nach Rumänien zu verlagern.

Das Deutsch der Kollegen dort ist schrecklich...

[daabm 1.346]

Zeit out of sync ist tödlich. Wenn das mehr als 5 Minuten sind, verweigert der DC die Ausstellung des TGT... Und dann ist der PC zwar "eigentlich" noch in der Domäne, aber da weder der PC noch der User ein TGT bekommen, können sie auch nirgends zugreifen. Konfiguriere Deine Zeitdienste richtig, und Du bist dieses Problem los...

[Esta 114]

@Edgar,

wüsste jetzt nicht, wie ich es prüfen kann.

 

@Zahni,

ich bin nicht für die Server und den Aufbau der Domäne zuständig. Das sind "migrierte Altlasten" und ich werde mich nicht in die Arbeit diesen Herren einmischen. Er bekommt immer recht...

 

@daabm,

ach es waren doch nur 30 Sek. unterschied. ;) Unser Netzwerkspezialist war heute morgen drauf und so schnell konnte ich nicht schreien, wie er manuell die Zeit verstellte. :(

[zahni 550]

Dann musst Du aber weiter mit ernsthaften Problem leben. Auf einem DC verstellt man die Zeit nicht "per Hand"

 

BTW: Wir haben uns irgendwann mal eine Funkuhr mit LAN-Anschluss gekauft. Von dieser Uhr holen sich der PDC-Emulator und die ESXI-Hosts die Zeit ab.

Der Rest läuft komplett vollautomatisch über das AD. Nie Probleme gehabt und auch nie die Zeit manuell verstellt.

 

Selbst als bei einen Schaltjahr die Funkuhr mal beschloss in einem falschen Jahr zu existieren (Fimware-Fehler), gab es keine Probleme, da W32TIME diese falsche Zeit verwarf (dafür gibt es einen Paramater).

 

Ich weiß echt nicht, warum so viele "Freizeit-Admins" sich so intensiv mit diesem Thema beschäftigen. Das geht mit den Standard-Einstellungen ganz von alleine richtig.

bearbeitet 16. Oktober 2014 von zahni

[Sunny61 806]

@Zahni,

ich bin nicht für die Server und den Aufbau der Domäne zuständig. Das sind "migrierte Altlasten" und ich werde mich nicht in die Arbeit diesen Herren einmischen. Er bekommt immer recht...

 

Tja, dann würde ich ihn jetzt auch den Fehler ausbügeln lassen. ;)

 

Spaß beiseite, man kann natürlich auch mit Hilfe von GPOs etwas 'regeln', aber im allgemeinen muss man sich nicht um die Zeit kümmern, das kann Windows von alleine und ohne Einmischung am besten. Für die GPO gibt es einen Artikel von Norbert: http://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

 

 

 

@daabm,

ach es waren doch nur 30 Sek. unterschied. ;) Unser Netzwerkspezialist war heute morgen drauf und so schnell konnte ich nicht schreien, wie er manuell die Zeit verstellte. :(

 

Oje, das hört sich nicht gut an. Kannst Du in den GPOs/Scripten prüfen ob es dazu evtl. auf den Clients irgendetwas gibt?

[lefg 276]

@Zahni og Sunny,

 

Esta ist nicht der Serveradministrator, nicht Adminiistrator der Domäne, sie hat ihrer Schilderung nach auf diesen keinen Einfluss. Dieser hat sich ausdrücklich verbeten, dass andere in seinen Bereich eindringen. Der Schilderung nach erscheint der Admin sehr eigenwillig und unkoorperativ.

bearbeitet 16. Oktober 2014 von lefg

[zahni 550]

Nun, dabei können  wir aber auch nicht wirklich helfen.

[Sunny61 806]

Esta ist nicht der Serveradministrator, nicht Adminiistrator der Domäne, sie hat ihrer Schilderung nach auf diesen keinen Einfluss. Dieser hat sich ausdrücklich verbeten, dass andere in seinen Bereich eindringen. Der Schilderung nach erscheint der Admin sehr eigenwillig und unkoorperativ.

 

Das hab ich schon so verstanden, ich wollte nur auf die Möglichkeiten hinweisen, insbesonders die auf den Clients vorhandenen GPO-Einstellungen könnten vielleicht Licht ins Dunkel bringen.

[lefg 276]

Es gab in der Vergangenheit mehrfach Diskussionen zum Wunsch, am Client selbst den Anmeldeserver vorzuwählen, vorherzubestimmen, die von mir gefundenen Diskussionen führten aber zu keinem befriedigenden Ergebnis.

 

Die Diskussionen verwiesen wohl immer auf Standorte und Dienste oder auf Kosten, etwas was an einem DC einzustellen ist.

 

Ob es am Client unter Computerkonfiguration, System, Netzwerkanmeldung etwas Brauchbares gibt?

bearbeitet 16. Oktober 2014 von lefg

[Esta 114]

Danke für eure Rückmeldung.

 

@Zahni,

ich warte nur darauf, dass es endlich einmal crasht und auffliegt, wie viel Ahnung der Herr hat.

 

Unser Unix-Admin hat einen funktionierenden Zeitserver.

 

@Sunny,

den Artikel hatte ich auch schon gelesen. Die PCs beziehen ihre Zeit, je nachdem an welchen DC sie sich anmelden konnten. GPOs für die Server werde ich nicht anpassen. Bei den OUs, wo ich "meine" Windows 7 Clients drin habe, werde ich es explizit eintragen. Nur ist zu überlegen, welchen Zeitserver da sinnig ist. In der OU, wo ich die Firewall Regeln verändert habe, habe ich den UDP Port 123 frei gegeben.

 

@Edgar,

ein Kollege schlug vor, den betreffenden DC ganz auszuschalten. Doch davon konnte ich abraten, da wir nicht wissen, welche Auswirkung es hat und auch nicht Dokumentiert ist, ob eventuell dort noch andere Serverdienste oder Programme laufen.

 

Von mir aus könnten sich die PCs auch an allen DC anmelden, nur muss dann die Infrastruktur stimmen.

[lefg 276]

Esta, kann es sein, nicht alle DC sind aktuell, einer ist nicht aktuell, die Computerkonten der neu hinzugefügten Rechner wurden nicht repliziert?

[Esta 114]

@Edgar,

die betroffenen PCs waren schon mind. 2 Monate in der Domäne, bevor dieses Problem das erste mal auftrat.

[lefg 276]

Wie sieht es aber mit den Computerkonten im AD auf den DCs aus? Sind die Konten auf allen DCs unbeschädigt vorhanden?

 

Kannst Du auf den DC in die Ereignisanzeigen schauen? Kannst Du auf den DCs ausführen dcdiag?

bearbeitet 16. Oktober 2014 von lefg