Daim

Servus, ohhjaa... SYSVOL-Probleme können ekelig sein. Aber genau dieser Artikel könnte und sollte dein Problem lösen. Das Zauberwort lautet oftmals bei SYSVOL-Problemen eben BURFLAGS. Der Artikel hört sich schlimmer an als er ist. Wenn du ihn mal durchgelesen hast und dich darauf beschränkst was durchzuführen ist, ist es garnicht so wild. P.S. 10 DCs in einer Domäne, auch wenn diese an acht Standorten stehen, halte ich im ersten Moment für "oversized".

Wie gesagt, dann erleichterst du es den Helfern ungemein. OK. Wie jetzt, zwei DCs mit dem gleichen Namen? Wie habt ihr denn das geschafft? Falls es so ist, war das sehr unklug. Bei gleichen Namen... kein Wunder. Das kannst du machen. Allerdings lässt sich der DC nicht "normal" mit einfachem Ausführen von DCPROMO herunterstufen, da er sich ja nicht mehr repliziert. Das bedeutet für dich, du musst im ersten Schritt den DC "mit Gewalt" und zwar mit Ausführen von "Start - Ausführen - "DCPROMO /FORCEREMOVAL" das ACtive Directory auf dem DC entfernen. Im zweiten Schritt musst du dann mit NTDSUTIL oder ADSIEdit den DC noch aus dem AD entfernen. Da sich der DC nicht ordnungsgemäß durch die Replikationsprobleme mit DCPROMO herunterstufen lässt, musst du diese Schritte händisch durchführen. Yusuf`s Directory - Blog - Das Active Directory gewaltsam vom DC entfernen Wie du den DC händisch aus dem AD entfernst, erfährt du aus diesem Artikel: How to remove data in Active Directory after an unsuccessful domain controller demotion Da noch ein weiterer DC existiert, handelt es sich also NICHT um den letzten DC der Domäne. Die Konten bleiben auf dem anderen DC erhalten. Danach benenne den heruntergestuften DC um. Kontrolliere aber vorher auf dem anderen DC noch das AD mit den Tools DCDIAG sowie NetDIAG aus den Windows Support Tools. Überprüfe auch das Eventlog. Nicht das auf dem anderen DC noch etwas im argen liegt. Ich würde hingehen und den Server neu installieren.

Servus, ich weiß, es ist noch früh am morgen, aber wenn du in klaren verständlichen Sätzen deine Anforderung formulieren würdest (Ist-/Ziel-Situation), würdest du dir selbst einen gefallen tun. Denn dann könnte man dir besser helfen. Ein SDC soll wohl ein "Sicherungs-DC" sein? Wenn ja, vergiss diese Abkürzung, die gibt es nicht. Seit Windows 2000 sind es alles DCs. Es gibt auch keinen BDC mehr. Und um welche Replikationsprobleme handelt es sich denn? Der Server ist im AD bedeutet, dass der Server ein DC ist oder ein Mitgliedsserver? Aha.. scheinbar ist der Server ein DC... aber das meine ich mit "klaren verständlichen Sätzen". Wenn der Server der letzte DC in der Domäne, in der er sich befindet ist, ist er eben der letzte DC dieser Domäne. Existieren noch weitere DCs in dieser Domäne, dann ist er NICHT der letzte DC. Es handelt sich um die Domäne, in der der Server DC ist, entweder in einer Sub- oder Root-Domäne. Bei dem Herunterstufen fordert dich der Assistent auf, ein Admin-Kennwort zu vergeben. Dabei handelt es sich um das LOKALE Administrator-Kennwort. Wenn das NICHT der letzte DC der Domäne ist, bleiben alle Benutzer-, Gruppen- sowie Computerkonten auf dem anderen DC dergleichen Domäne erhalten. Ist dieser Server der letzte DC dieser Domäne, dann musst du den Haken setzen das es der letzte DC ist und somit wird die Domänenpartition aufgelöst und somit verschwinden alle Konten.

Servus, wenn es sich jeweils um Windows Server 2003 Domänen handelt, wäre es das einfachste eine "bedingte Weiterleitung" in den Eigenschaften des DNS-Servers, im Reiter Weiterleitungen einzurichten.

Servus, nein, keine einfache. Möchte man die MMCs erweitern, in Form von weiteren Feldern, damit nicht angezeigte Attribute danach in der MMC angezeigt werden, müsste mit C++ die MMCs bearbeitet werden. Was möchtest du denn - gerade in dssite.msc - eingeblendet haben? So wie sich das bisher anhört, würde ich einen "anderen Weg" gehen.

Servus, du suchst ADMT. Mit ADMT kannst du die Benutzer-, Gruppen- sowie Computerkonten von einer Domäne in eine andere migrieren. Das schöne daran ist, dass die Migration wenn die Vorarbeit stimmt, ein leichtes ist. ALLE Profile bleiben erhalten, der Benutzer spürt nichts davon. Bei der Migration mit ADMT wird eine Namensauflösung und eine Vertrauenesstellung benötigt. Das ADMT richtet ein neues Benutzerkonto in der neuen Domäne ein und fügt die SID des alten Benutzerkontos, aus der alten Domäne an das neue Benutzerkonto der neuen Domäne als SID-History hinzu. Damit kann das neue Benutzerkonto die alte SID als "Ausweis" vorzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Servus, wenn es sich um eine Domänenumgebung handelt, kannst du doch in den Benutzereigenschaften vorgeben, an welchen Rechnern sich der Benutzer anmelden kann. Yusuf`s Directory - Blog - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann?

Ob du das kannst, weiß ich nicht. ;) In der Systemsteuerung unter SOFTWARE findest du den DNS-Server aber nicht unter "Anwendungsserver", sondern unter "Netzwerkdienste". Oder du installierst ihn über "Start - Programme - Verwaltung - Serververwaltung - Funktion hinzufügen oder entfernen". Du musst lediglich das DNS installieren, aber nicht konfigurieren, denn er ist doch bereits auf dem anderen DC konfiguriert. Siehe Punkt 3: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Servus, wenn es sich um eine Active Directory (AD) Umgebung handelt, wurde der DHCP-Server auch im AD autorisiert?

Servus, es gibt nicht NUR das Recht für zum aktivieren bzw. deaktivieren eines Benutzerkontos. Die Kontooptionen werden alle samt über das Attribut userAccountControl gesteuert, das sich aus einer Bitmaske zusammensetzt, wie der folgende Artikel es zeigt: User-Account-Control Attribute (Windows) How to use the UserAccountControl flags to manipulate user account properties Du kannst lediglich die gesamten Kontoopptionen delegieren und nicht ein einzelnes Recht in den Kontooptionen. Dazu musst du in der DACL (in den erweiterten Sicherheitseinstellungen) des Containers das Lese- sowie Schreibrecht den Benutzern für das userAccountControl gewähren. Also z.B. Rechtsklick auf den Standardcontainer USERS - Eigenschaften - Reiter Sicherheit (der Reiter Sicherheit erscheint nur, wenn unter Ansicht die Option "Erweiterte Funktionen" aktiviert ist) - dann fügst du dort den Benutzer, besser die Gruppe hinzu - klickst unter auf Erweitert - wählst den Benutzer/Gruppe aus und klickst Bearbeiten - klickst dort auf den Reiter Eigenschaften - im Feld "Übernehmen für" wählst du Benutzer-Objekte aus - und aktivierst dort "userAccountControl lesen und schreiben". Dann hat derjenige das Recht die Kontooptionen für den kompletten Container bzw. OU zu verändern. Das delegieren dieses Rechts, zum verändern der Kontooption lediglich einer einzigen Person ist nicht möglich. Oder du wählst im Objektdelegierungsassistenten einen "Benutzerdefinierten Task" und wählst als Objekttyp "Benutzer-Objekte". Im nächsten Fenster wählst du dann die Option "Lesen und Schreiben Kontobeschränkungen" aus. Am Ende kommt das gleiche raus, es ist nur der Weg begleitet vom Assistenten.

Servus, du hast schon einmal einen Mitgliedsserver installiert und zur Domäne hinzugefügt? Falls ja, was hast du in der Domäne "geändert"? Nichts. Ergo, auch bei dem Windows Server 2008 brauchst du beim installieren und Hinzufügen zur Domäne als Mitgliedsserver nichts zu ändern.

Servus, ein Freund von mir hat in kurzen Schritten die Vorgehensweise hier zusammengefasst: Wolfgang on the Road: 198: Sysvol Replikation per DFS-R Ich habe es bisher auch nur in meiner Testumgebung vollzogen mit 6 physikalischen DCs, die verteilt in drei Domänen sind. Ich hatte ebenfalls dabei keinerlei Probleme. Die Umstellung des SYSVOL-Verzeichnisses auf DFS-R ist ohnehin für die Unternehmen interessant, die ein großes SYSVOL haben und ständig Änderung an GPOs durchgeführt werden. Für den SoHo-Bereich bleibt der Nutzen eher gering.

Servus, ja, die Beschreibung kann sogar zur Lösung führen. Aber PSS selbst empfiehlt das nicht, sondern einen anderen Weg zu gehen den ich hier beschrieben habe: Yusuf`s Directory - Blog - Dateireplikationsfehler mit der ID 13568 @Outsider Bitte ab dem nächsten Mal immer die EventID mit angeben.

Servus, 1. Erstelle im AD ein Benutzerkonto für den DHCP-Server und setze den Haken, dass das Kennwort nie abläuft und das Kennwort vom Benutzer nicht geändert werden darf. Es reicht wenn das Benutzerkonto lediglich in der Gruppe Domänen-Benutzer Mitglied ist. 2. Im Reiter DNS setzt du den Haken bei der Option "Dynamische DNS-Updates mit den unten eingegebenen Einstellungen aktualisieren". Du wählst dann die Option "DNS-A- und -PTR-Einträge immer dynamisch aktualisieren" aus. Zusätzlich aktivierst du noch die Kontrollkästchen "A- und PTR-Einträge beim Löschen der Lease verwerfen" und "DNS-A und -PTR-Einträge für DHCP-Clients die keine Updates anfordern (....) dynamisch aktualisieren". 3. In der DHCP-MMC rufst du mit einem Rechtsklick auf das Server-Icon, die Eigenschaften auf. Dort klickst du auf den Reiter ERWEITERT und wählst die Option "Anmeldeinformationen..." aus. Anschließend trägst du dort das DHCP-Benutzerkonto ein.

Und nochmals; Wenn die Domäne steht, wirst du, dein Chef und der Papst sehen wie einfach doch das Leben sein kann. Und für dich gilt, man wächst mit seinen Aufgaben. Schau auf den Link den nschlueter gepostet hat, denn dort wirst du sicherlich einiges an Informationen die du benötigst bekommen. Genau so. Ich weiß, dass das zu NT-Zeiten von vielen Administratoren genutzt wurde. Aber zu Zeiten Windows Server 2003/2008 gibt es weit mehr Möglichkeiten als damals. Ergo, lasst die DOS-Partition weg. Der Windows Server 2003 bringt einiges mit. Zusätzlich noch das SYSTEM STATE sichern (für die Domänendaten wie z.B. Benutzerkonten etc.), ein für eure Ansprüche angepasstes Backup und gut ist.

Servus, du hast dich aber in deinem OP wirklich verquer ausgedrückt. Dann suchst du GPRESULT. RSOP tut es aber auch.

Ach? Und der jetzige Standalone Arbeitsgruppenserver darf ausfallen oder wie? Oder anders formuliert, wenn der AG-Server ausfallen würde, hätte man richtigen Stress. Verloren geht erstmal garnichts. Wie ich bereits geschrieben hatte, du hast am Anfang beim erstellen der Domäne einen "Mehraufwand". Aber wenn die Domäne dann mal steht, wird der Administrator und vorallem die produktiven Einheiten der Technik die Füße küssen. Idealerweise, gerade wegen der Ausfallsicherheit, sollte dann ein zweiter Domänencontroller (DC) installiert werden. Dieser lässt sich aber auch auf einer Client-Hardware (1 GHZ mit 512MB RAM) installieren, denn schließlich dient er nur zur Redundanz. Ja. Um eine Active Directory-Umgebung aufzusetzen, wird DNS benötigt. Idealerweise installiert man auf einem DC auch das DNS und nutzt das Windows DNS. Du könntest aber auch BIND nutzen, dann müsste aber manuell Anpassungen am BIND vorgenommen werden. Aber durch das Aufsetzen einer Domäne (samt Windows DNS) hat sich das mit dem BIND doch sicherlich erübrigt. Denn dann kann alles über den DC laufen. Falsche Formulierung. Nach DCPROMO hast du Arbeit. Danach Urlaub. ;)

Ausnahmen bestätigen zwar die Regel... aber dann würde ich mich mit den Tools FRSUTIL, SONAR, FRSDIAG oder UltraSound auf die Fehlersuche begeben. Ich weiß allerdings selbst aus Erfahrung, wie mühselig SYSVOL-Probleme sind.

Servus, es ist ja kaum zu glauben. Eine Umgebung mit 150 Clients in einer Arbeitsgruppe.. Gibt es wirklich so etwas noch? Dringende Empfehlung: Erstelle dir eine Domäne, gerade bei diese Benutzer-/Client Anzahl. Das erleichtert dir und den produktiven Einheiten unheimlich das Arbeitsleben. Wenn du den Server zum Domänencontroller deklarierst (du führst dazu DCPROMO auf dem Server aus), werden automatisch die lokalen Benutzer- sowie Gruppenkonten auf dem Server, in die Domäne übernommen. Du hast dann zwar etwas Arbeit am Anfang, die Clients zur Domäne hinzufügen und mit den Profilen usw. Aber wenn das dann alles eingerichtet ist, hast du für die Zukunft ein leichteres Administrationsleben.

Servus, du meinst, dass er mit DCPROMO /FORCEREMOVAL gewaltsam das AD auf dem DC entfernen kann. Anschließend muss aber der DC noch händisch mit NTDSUTIL oder ADSIEdit aus dem AD entfernt werden, ehe der Server erneut mit gleichem Namen als DC hinzugefügt werden kann. Du zerstörst damit doch nicht alles. Nicht gerade optimal. Ein Exchange-Server "sollte" nicht auf einem *DC* installiert werden. Microsoft empfiehlt den Exchange auf einem Memberserver zu installieren. Wenn aber mal der Exchange installiert wurde, sei es auf einem Memberserver oder DC, darf hinterher die Rolle des Servers nicht verändert werden. Das bedeutet in beiden Fällen (Memberserver oder DC), DCPROMO darf nicht ausgeführt werden. Das wird seitens Microsoft nicht supportet. Wenn der DC sich mit DCPROMO herunterstufen lässt, wird der Server automatisch zum Memberserver gestuft. Als Memberserver hat er weiterhin Zugriff auf die Konten in der Domäne. Aber wie bereits erwähnt, ist das Ausführen von DCPROMO auf einem installierten Exchange seitens Microsoft nicht supportet. Auha... STOPP! VORSICHT! Langsam. Kopiere nicht einfach händisch das SYSVOL hin und her. Denn sonst stimmen die Junction Points nicht mehr überein. Gehe nun Schritt für Schritt vor. Auch wenn BURFLAGS nicht funktionierte, lies dir trotzdem diesen Artikel durch und auch die verlinkten Microsoft Artikel. Denn immer wenn ich Probleme mit dem SYSVOL hatte, war der Schlüssel BURFLAGS die Lösung. Daher kontrolliere deine Vorgehensweise mit diesem und der verlinkten Artikeln: Yusuf`s Directory - Blog - Dateireplikationsfehler mit der ID 13568

Servus, eine Protokollierung, wann - wer auf welche Datei zugegriffen hat oder wann sich wer - wo angemeldet hat, ist ein ganz heißes Eisen. Wo tatsächlich Ausnahmen bestehen, kann dir letztenendes nur der Datenschutzbeauftragte und in letzter Instanz, ein Rechtsanwalt geben. Was ich aber mit Sicherheit sagen kann, dass die beiden angesprochenenen Punkte von mir in Deutschland, Zustimmungspflichtig sind. Es bringt auch nichts, dieses hier im Forum weiter und tiefgehender zu diskutieren oder gar zu philosophieren!

Servus, die EventID 675 deutet auf ein falsch eingegebenes Kennwort hin. Das ist in den meisten Fällen der Fall, wenn auf einer Maschine eine Applikation/Prozess/Task unter dem Benutzernamen läuft, mit einem veralteten Kennwort.

Abgesehen von dem gemeldeten Fehler, versuchst du hier einen Administrator auf dem Ziel-DC zu importieren. Aber standardmäßig existiert ohnehin bereits ein Benutzer Namens "Administrator" im Container USERS. Daher solltest du dieses Objekt entfernen. Ansonsten sieht das Export ok aus. Ich könnte mir nur vorstellen, dass sich an der Bedienung von LDIFDE im Windows Server 2008 etwas geändert hat. Ich habe mir das noch nicht angeschaut. Sehe aber zu, dass ich es mir die Tage anschaue. Na das wäre ja auch noch schöner, wenn man die Kennwörter exportieren könnte. Das geht natürlich nicht, sonst wäre es ein großes Sicherheitsloch. Synchronisation? Wer mit wem? Dein neuer DC, der in einer eigenen Gesamtstruktur steht, also mit dem anderen DC nichts zu tun hat, kann sich mit diesem auch nicht replizieren. Abgesehen davon, werden in den GC auch keine Kennwörter repliziert. Natürlich müssen die Daten der Export-Datei entsprechend der Ziel-Domäne angepasst werden.

Du kannst ja trotzdem vorher nur einen Check drüber laufen lassen. Einen Reparaturversuch (Fixup) musst du ja nicht laufen lassen. Aber mit einem Check der AD-DB weiß man schonmal, ob prinzipiell mit der DB alles soweit ok ist. Dann kläre ob eine aktuelle funktionierende Sicherung, mindestens vom System State existiert. Das Kennwort für DSRM kannst du vorher auch unter Windows 2000 rücksetzen. Dort funktioniert das zurücksetzen mit SETPWD. How to Change the Recovery Console Administrator Password on a Domain Controller Den PSS kannst du jederzeit anrufen. Ich würde mir erstmal vor Ort mit dem Kunden einen genauen Überblick verschaffen. Ja, dass würde - sofern die AD-Datenbank auf dem DC keinen Schaden hat - sicher funktionieren. Aber dann muss zwingend der Ursprungsträger vom Netz genommen werden, ehe noch mehr Schaden entsteht. Genau und momentan wäre ich mir nicht sicher, ob sogar das seizen funktionieren würde. Das wäre auch nicht so das Problem. Den kann man auch händisch aus dem AD entfernen.

Servus, warum Chaos? In vielen Umgebungen ist das Standard. ;) Du möchtest wohl mit OUs das ganze anders strukturieren. Das ist aber immer noch kein Chaos. Wie Norbert bereits erwähnte, ist das so nicht möglich unterhalb von USERS eine OU oder einen weiteren Container (CN) zu erstellen. Das bedeutet aber nicht, dass es überhaupt nicht möglich wäre. Aber man sollte sich nicht vom Standardverhalten entfernen. In der MMC ADUC ist es eben so nicht möglich. Wenn du aber die entsprechenden Rechte hast, kannst du auf Domänenebene weitere OUs erstellen. Erstelle die OU direkt auf dem DC, in der MMC "Active Directory-Benutzer und -Computer" und nicht etwa von einer Admin-Workstation mit vielleicht delegierten Berechtigungen.