alias

Hallo daabm, Genau so hatte ich mir das gedacht. Danke dir dafür. Gruß Frank

Hallo zusammen, ich möchte mich diesbezüglich nochmal melden. Ich habe nun einen 3. DC hinzugefügt und den 2. DC (defekt, laufende Systemneustarts, da wohl durch den Festplattencrash Systemdateien in Mitleidenschaft gezogen wurden) entfernt. Nun habe ich aber noch eine Frage zur Heraufstufung des 3. DC als DC. Ich habe ja die Domain letztens auf dfs-r migiriert, was ja auch einwandfrei geklappt hat. Das Sysvol-Verzeichnis wurde ja daraufhin in SYSVOL_DFSR umbenannt. Als ich den 3. DC heraufgestuft habe hat er aber das normale SYSVOL-Verzeichnis angeboten. Ist ja eigentlich kein Thema. Ich gehe mal davon aus, dass er die dfs-r-Migrierung so übernommen hat, oder? Sollte ich nach dem Hinzufügen des neuen DC und dem Herabstufen des alten (defekten) DC noch irgendetwas anderes beachten? Lieben Gruß und ein schönes Wochenende, Frank

Muss es ja auch mal geben. Ist halt eine nicht so große Domain mit ca. 150 Clients. Hat aber so gesehen doch schon insgesamt seine 30 - 40 Minuten gedauert. Vielen Dank nochmals an alle. Mal schauen, ob sich der 2. DC wieder verabschiedet. Dann wäre das die nächste Baustelle.

So: "Alle DC wurden erfolgreich zum globalen Status (""Entfernt"") migriert. Die Migration hat auf allen DC einen konsistenten Status erreicht. Erfolgreich." Sollte also alles geklappt haben

Kann da im laufenden Betrieb etwas schiefgehen? Oder sollte man soetwas nach Feierabend machen?

So, nachdem ich die Replikation neu gestartet habe (non-authoritative) und den ntfrs-Dienst neu gestartet habe sind auch die Fehlermeldungen im Eventlog verschwunden. Die Freigaben SYSVOL und NETLOGON wurden aktuell einwandfrei repliziert. DCDIAG gibt alles Tests als Bestanden aus. Das sollte es wohl gewesen sein hoffe ich. Aber kann das wirklich durch den Crash (wer weiß, welche Bereiche im Betriebssytem dadurch in Mitleidenschaft gezogen wurden) passiert sein? Danke an alle nochmals für die Tipps und Hinweise.

Stimmt. Sorry. Etwas zu heftig im Moment hier. Asche auf mein Haupt. Muss wohl warten bis hier etwas Ruhe einkehrt Nun tauchen auch nach einem Neustart des 2. DC die Fehler 13552 "Der Dateireplikationsdienst kann diesen Computer dem folgenden Replikatsatz nicht hinzufügen: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" Mögliche Ursachen sind: -- ein ungültiger Stammpfad, -- ein fehlendes Verzeichnis, -- ein fehlender Datenträger oder -- ein Dateisystem auf dem Datenträger, das NTFS 5.0 nicht unterstützt. Die folgenden Informationen können bei der Problembehebung hilfreich sein: DNS-Name des Computers: "DC2.domain.local" Mitgliedname des Replikatsatzes: "DC2" Stammpfad des Replikatsatzes: "c:\windows\sysvol\domain" Replikatstagingverzeichnis: "c:\windows\sysvol\staging\domain" Pfad des Replikatarbeitsverzeichnisses: "c:\windows\ntfrs\jet" Windows-Fehlerstatuscode: "" Fehlerstatuscode des Replikationsdienstes: "FrsErrorMismatchedJournalId" Andere Ereignisprotokollmeldungen bieten weitere Problemlösungen. Beheben Sie den Fehler, dann wird der Dienst zu einem späteren Zeitpunkt versuchen, die Replikation automatisch zu starten." und 13555 "Der Dateireplikationsdienst befindet sich im Fehlerzustand. Dateien werden nicht von oder zu einem oder allen Replikatsätzen auf diesem Computer repliziert, bevor nicht die folgenden Wiederherstellungsmaßnahmen durchgeführt wurden:" auf. Wie bekomme ich das jetzt wieder ordnungsgemäß repliziert? Ich kann mir echt nur vorstellen, dass das mit dem problemmachenden DC2 zu tun hat (sporadische Neustarts, Systemdateien beschädigt etc.) Kann das sein? P.S. DCDIAG gibt auf dem DC2 folgendes aus: Der Test FrsEvent für DC2 ist fehlgeschlagen. Alle anderen Tests sind bestanden.

Treffer Norbert. Komischerweise steht bei dem 2. DC in den GPOs immer noch der alte WSUS drin. Sollte da nicht dann doch irgend etwas in den Logs erscheinen? Dass nicht ordnungsgemäß repliziert etc. wurde? Ich habe auf dem 2. DC die GPO jetzt händisch geändert und beobachte das ganze mal. Danke Dir für den Tipp.

Das ist der Fall. Auf beiden DCs wird über die GPMC der richtige WSUS-Server angezeigt. Im Replikationslog keine Auffälligkeiten.

Dachte, das hab ich weiter oben schon geschrieben: Eventlog Client: Die Gruppenrichtlinieneinstellungen für den Benutzer wurden erfolgreich verarbeitet. Es wurden neue 3-Gruppenrichtlinienobjekte erkannt und angewendet. (z.B. nach gpupdate) und Die Gruppenrichtlinieneinstellungen für den Benutzer wurden erfolgreich verarbeitet. Es wurden keine Änderungen seit der letzten erfolgreichen Gruppenrichtlinienverarbeitung erkannt. Im Eventlog DC keine Fehler, Warnungen etc. Nur Infos, dass ordnungsgemäß verarbeitet.

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.

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.

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

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).

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?