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?

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

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

Hi Coolskin, Probleme dahingehend, das er mir, wenn ich die AD-Konsole aufrufe sagt, das das Snap-In nicht erstellt werden konnte :-( Gruß Frank

Hi Velius, Velius........ Du bist mein Held !!! Danke Dir für den Tip. Die Reparatur lief zwar mit ner kurzen Fehlermeldung durch, aber jetzt funktioniert die Konsole und der WSUS 3.0. Vielen lieben Dank nochmal, Frank

Teil 2 der Fehlermeldung:

Hallo und guten Morgen, ich habe nun auch unseren WSUS von 2.0 auf 3.0 geupdatet. Die Installation verlief ohne Probleme. Der Report Viewer sowie MMC 3.0 waren vorher installiert. Wenn ich nun die Konsole aufrufe und den WSUS-Server von dort aufrufen will komme ich nicht auf den Server bzw. bekomme keine Verbindung. Ich bekomme unter der Ereignisanzeige einen Fehler, der mit ASP zu tun hat. Ich hänge diese mal an. Kann mir da jemand einen Tip geben? Danke Euch im voraus, Frank Sorry, das ich dem Herrn Kohn die Mittagspause verdorben habe. Da ich nebenbei viel mit AB-Maßnahmen zu tun habe und viele Leute sich freuen würden, in einer mitarbeiten zu dürfen, finde ich das als Vergleich, ja, wie soll ich sagen, etwas ***. Sorry nochmals, Frank

Hallo und guten Morgen, ich habe jetzt das Update von WSUS2.0 auf WSUS3.0 durchgeführt. Installation verlief problemlos und Neustart des Servers wurde durchgeführt. Wenn ich nun die WSUS-Verwaltungskonsole starten will komme ich ja in das Plugin wo ich den Server, mit dem ich verbinden will, eingeben soll. Nur.... die Verbindung kann leider nicht hergestellt werden. Wora könnte das liegen? Habe bei mir schon für den WSUS vo jeher den Port 8530 angegeben. Bin auch als User in den 2 betreffenden Benutzergruppen eingerichtet. Habts ihr irgendwelche Tips für mich, wo ich da schauen kann? Danke euch im voraus, Frank Edit 1: Habe im Ereignisprotokoll den Fehler 1310 Quelle: ASP.NET 2.0.50727.0

Hi Coolskin, zu installieren und starten geht es ja. Nur kann er innerhalb der Console das Snap-In nicht erstellen. Hast du da ne Lösung für? Frank

Danke Dir, Gulp

Hallo und guten Tag auch, da ja Vista demnächst für Provatanwender rauskommt wollte ich mir gerne nochmal die Vorab-/Preview-Version installieren. Nun habe ich hier 2 Versionen liegen und weiß leider nicht mehr, welche aktueller ist. Könnt Ihr mir weiterhelfen? Und zwar habe ich 1. Windows Vista Release Candidate 1 CPR und 2. Windows Vista Beta 2 CPR. Welche von den beiden ist aktueller? Danke im voraus. Gruß Frank