Problem mit der WSUS-GPO

[alias 11]

Hallo zusammen,

bei uns werden schon seit ewigen Zeiten die WSUS-Einstellungen per GPO an die Clients verteilt. Soweit so gut. Klappte alles einwandfrei. Bis letzte Woche...

 

Was ist passiert? Bei einem unserer Server, der auch die WSUS-Rolle innehatte, sind kurz nacheinander 2 Festplatten ausgefallen.

Muss dazu sagen, dass es sich um einen ESX-Server inkl. 2 VM´s (Backup-DC sowie Server inkl. WSUS-Rolle) handelt.

 

Daraufhin haben wir den WSUS-Server auf einem anderen Server installiert und dementsprechend die GPO geändert.

Komischerweise ziehen sich die Clients sporadisch immer wieder den alten WSUS-Server. Dieses ist ja leicht zu erkennen an dem Registry-Eintrag (der auch schon händisch geändert wurde).

Und am nächsten Tag steht wieder der alte Eintrag (mit dem alten/falschen WSUS-Server) in der Registry.

 

Könnt ihr mir einen Tipp bzw. Hinweis geben, wonach ich hier schauen muss bzw. was ich da machen kann?

Ich hoffe, ich habe das einigermaßen verständlich rübergebracht.

 

Vielen Dank im Voraus und Gruß

 

Frank

 

[NorbertFe 2.089]

Wenn da auch ein dc kaputt war, was habt ihr mit dem denn gemacht? Und „Backup-dc“ gibts nicht mehr.

bearbeitet 10. April 2019 von NorbertFe

[alias 11]

Hallo Norbert,

 

auf diesem (Backup)-ESX liefen nur der sogenannte BDC (den ich wohl entfernen werde) sowie ein Backupserver (VEEAM), welcher auch die WSUS-Rolle beinhaltete.

Der DC sowie die anderen Server laufen als VM auf einem aktuellen ESX.

 

Das Thema BDC hätte ich auch noch angesprochen, entnehme aber deiner Antwort, dass dieses wirklich nicht mehr zeitgemäß ist.

Ich sage nur übernommene und gewachsene Strukturen...

 

Gruß

 

Frank

[NorbertFe 2.089]

vor 22 Minuten schrieb alias:

sogenannte BDC

es gibt auch keine sogenannten BDCs mehr. Oder setzt ihr noch NT4.0 ein? Wenn die Clients falsche Policies bekommen, dann sollte man evtl. was per Eventlog auf Clients und DC rausbekommen. Gibts da irgendwelche relevanten Einträge?

[alias 11]

NT setzen wir natürlich nicht mehr ein. Deswegen nehme ich dieses jetzt zum Anlaß, den "BDC" rauszukicken.

Mittels GPLogView habe ich festgestellt, dass einige Clients eben diesen BDC als DC anzeigen. Fehler werden keine angezeigt.

Nach dem Festplattencrash läuft dieser allerdings "unrund", will ich mal sagen. Das resultiert u.a. in sporadischen Neustarts.

Bevor ich diesen bzw. das Betriebssystem "repariere" werde ich den komplett rausschmeißen.

 

Könnte das Problem mit den (WSUS)-GPOs damit zusammenhängen?

[PadawanDeluXe 75]

Moin,

wenn du auf einem beliebigen Client ein gpupdate /force durchführst. Was siehst du dann im Eventlog? Wenn du einen Sync durchführst auf den DCs: laufen diese fehlerfrei? Welches Kompatibilitätslevel hat eure AD Domain?

 

Viele Grüße

Carsten

[NorbertFe 2.089]

vor 8 Minuten schrieb alias:

NT setzen wir natürlich nicht mehr ein. Deswegen nehme ich dieses jetzt zum Anlaß, den "BDC" rauszukicken.

Mittels GPLogView habe ich festgestellt, dass einige Clients eben diesen BDC als DC anzeigen. Fehler werden keine angezeigt.

Nach dem Festplattencrash läuft dieser allerdings "unrund", will ich mal sagen. Das resultiert u.a. in sporadischen Neustarts.

Bevor ich diesen bzw. das Betriebssystem "repariere" werde ich den komplett rausschmeißen.

 

Könnte das Problem mit den (WSUS)-GPOs damit zusammenhängen?

Ich glaub ich rede chinesisch. Vergiß doch mal BDC. Das Ding ist ein DC und wenn du jetzt noch mehr als einen hast ist das ok, wenn du jetzt nur noch einen besitzt, solltest du wieder einen zweiten einrichten. Und nein, das ist dann kein BDC!

[alias 11]

Nö Norbert. Mein Fehler. Komischerweise haben meine Vorbeter genau diesen "DC" in der Domäne "BDC" getauft. Deswegen hängt diese Begrifflichkeit bei mir so drin. Sorry dafür.

Problem ist aber laut meinem vorigen Post das gleiche.

Die Clients beziehen bzw. bezogen laut GPLogView über diesen 2. DC (der da BDC heißt) ihre GPO. Daher mein Bedenken, dass es etwas mit dem (defekten) 2. DC zu tun hat.

 

@PadawanDeluXe

Die Gesamtstruktur der Domain besteht aus derzeit 2 Windows 2012 R2-DC´s.

Nach dem gpupdate sieht es im Eventlog einwandfrei aus. Die GPOs wurden angewendet (und diesesmal vom 1. DC gezogen).

 

Ich gehe mal davon aus, dass ich den 2. DC (der da BDC heißt) entfernen und neu installieren muss (evtl. auch einen anderen Server dafür hernehme).

[v-rtc 91]

Brauchst Dich nicht entschuldigen, gibt Dinge die man von hier aus nicht sieht oder wissen kann.

 

In den GPOs steht der neue WSUS drin? Oder wie verteilst Du das?

[alias 11]

Hallo v-rtc,

 

ja, ich habe die GPO nach Einrichtung des neuen WSUS geändert. Der neue WSUS steht da einwandfrei drin.

[NorbertFe 2.089]

Und übernehmen überhaupt Clients diese Einstellung? Was sagt das Eventlog auf dem DC (wieviele hast du?)

[alias 11]

DC´s existieren derzeit 2. Einmal der Betriebsmaster und der 2. DC (auf dem Backup-ESX, der nach dem Crash ja Probleme aufzeigt).

Auf den laufenden Clients wurde nach der WSUS-Neuinstallation und Anpassen der GPO ein gpupdate /force ausgeführt.

Die neuen Werte wurden daraufhin einwandfrei in der Registry hinterlegt.

Komischerweise sind einige Clients betroffen, die z.B. nach einem Neustart (z.B. nächster Arbeitstag) wieder den alten WSUS in der Registry stehen haben.

Als Behelf die Reg händisch geändert, etwas gewartet, und schon melden die sich wieder am WSUS.

 

Es sieht so aus, als wenn die Clients irgendwoher noch die Daten des alten WSUS ziehen würden. In der GPO steht jedenfalls der neue WSUS drin.

[Dukel 457]

Was ist gecrashed? Der ESX? Der DC?

Was ist nach dem Crash passiert/ gemacht worden?

Replizieren die DC's korrekt?

[alias 11]

Hallo Dunkel,

geht etwas unpräzise aus meinen Beiträgen hervor.

Auf dem 2. ESX sind 2 Festplatten gecrasht.

Auf dem 2. ESX befanden sich bis dahin 2 VM: der 2. DC (der nicht Master ist) sowie ein Backup-Server für die Datensicherung (VEEAM).

 

Nach dem Austausch der 2 Platten konnte das Betriebssystem des Backup-Servers nicht mehr gestartet werden, da durch den Ausfall Systemdateien beschädigt wurden. Eine Reparaturinstallation schlug ebenfalls fehl. Somit haben wir die 2. VM (Backup-Server) neu installiert und läuft.

Bei der 1. VM (2. DC) ist uns aufgefallen, dass diese zwar ordnungsgemäß gebootet ist, aber sporadisch neustartet. Auch hier sind wohl Systemdateien beschädigt worden.

 

Die Replikation funktioniert problemlos/ist erfolgreich (mittels repadmin /showrepl)

 

Auf dem 1. ESX befinden sich der DC (Betriebsmaster) sowie File-/Anwendungs- und Datenbankserver.

[NorbertFe 2.089]

OK dann schau endlich ins Eventlog.