Daim

Der Benutzer aus c.test.local kann sich dabei aber nur an der Domäne c.test.local anmelden, von einem Client aus das Mitglied in der Domäne b.test.local ist. Also an einem Client in der Domäne b.test.local würde das Anmeldefenster dann so aussehen: Benutzername: Benutzer aus c.test.local Kennwort: Sein Kennwort Anmelden an: c.test.local Die Frage ist doch eher was du erreichen möchtest. Abgesehen davon, der Benutzer kann sich nur an der Domäne anmelden, in der sein Benutzerkonto existiert. Eine Gruppe einzurichten ändert nichts an dieser Tatsache. Ich würde eher das Domänenmodell in Frage stellen.

Salut, das funktioniert nicht. Denn dein Benutzerkonto im AD existiert in der Domäne c.test.local. Wenn du dich nun an der Domäne b.test.local anmelden möchtest, kennt dich der DC dieser Domäne doch garnicht. Du könntest dich von einem Client das Mitglied in der Domäne b.test.local ist, mit deinem Benutzerkonto an der Domäne c.test.local anmelden.

Moin, die LDIF.log Datei darf nicht bereits in Benutzerung sein. Das ADPREP muss darauf zugreifen können bzw. dürfen. Evtl. lade dir den Process Explorer von Sysinternals herunter und prüfe welcher Prozess die Datei im Zugriff hat. Der Virenscanner ist dabei einer der Verdächtigen. Und ja, du kannst das ADPREP /FORESTPREP mehrmals ausführen. Auch wenn du es erfolgreich abgeschlossen und erneut ausführen würdest, dann würde ADPREP dir lediglich melden das es bereits durchgeführt wurde. Das mehrmalige ausführen von ADPREP macht also nichts kaputt.

Salut, das ist zwar alles korrekt, nur trifft es auf den OP nicht zu. Denn er schrieb: Das bedeutet, der OP ist schon längst über deine genannte "Hürde" drüber. @rohstoff77 Nein, keineswegs. Warum sollte das auch so sein? Macht keinen Sinn. Ja, dass solche Aussagen nicht ganz zutreffen: ;)

Nicht erst seit Windows Server 2003, sondern seit das AD mit Windows 2000 eingeführt wurde. Die DCs innerhalb eines AD-Standortes replizieren im Ring miteinander. Diese Ringtopologie versucht zwecks Fehlertoleranz mindestens zwei Verbindungen zu anderen Domänencontrollern zu erstellen mit maximal 3 Hops zwischen den beliebigen DCs. Der KCC erstellt für jede dabei für jede Verzeichnispartition eine eigene Replikationstopologie (Schema-, Konfigurations-, Anwendungs- sowie Domänenverzeichnispartition). Der KCC überwacht permanent die Gegebenheiten wie z.B., wenn DCs einem AD-Standort hinzugefügt, entfernt oder verschoben werden, die Kosten sich ändern oder wenn ein Domänencontroller nicht erreichbar ist. In diesen Fällen "justiert" der KCC nach, so dass die AD-Replikation weiter reibungslos verläuft. Standortübergreifend, also zwischen den AD-Standorten, baut der KCC (genauer ISTG) einen spanning-tree auf. Eine Sternverbindung erstellt man in erster Linie dann, wenn kein Full-Mesh Netzwerk existiert. Also wenn Routingtechnisch nicht jeder AD-Standort mit jedem anderen AD-Standort kommunizieren könnte/dürfte, dann würde man eine Sterntopologie aufbauen. Bei einem Stern würde man dann auch die Eigenschaft "Brücken zwischen allen Standortverknüpfungen herstellen" (in dssite.msc Eigenschaften "IP" unter "Intersite Transports") deaktivieren, damit sich die AD-Replkation an deine explizit erstellten Standortverknüpfungen hält. Danke nochmals für die Blumen. :) Bei einem Buch hätte ich aber den kleinen Nachteil, dass ich in meinen Antworten hier im Forum nicht direkt auf einen Artikel verlinken könnte. ;) Aber irgendwann würde ich schon gerne mal eins schreiben (was ich noch alles mal "irgendwann" tun möchte... da langt das Leben nicht dazu). Mal sehen. ;)

OK, aber wenn der DC vor Ort physikalisch nicht "sicher" stehen sollte, solltest du den RODC in Erwägung ziehen und die Kennwörter der Benutzer- sowie Computerkonten zum RODC replizieren. Kann man machen, muss man aber nicht. Du kannst auch direkt DCPROMO ausführen und den Server zum DC stufen. Somit bleibt dir ein Schritt und damit ein Neustart erspart. ;) Du meinst ein AD-Standort samt Subnetz. Kann man machen. Du könntest auch dem AD-Standort der Zentrale das Subnetz des Aussenstandorts zuweisen. Man erstellt AD-Standorte um das Anmeldeverhalten des Clients zu beeinflußen (denn der Client versucht sich zuerst an einem DC an "seinem" AD-Standort anzumelden) und Einfluß auf die AD-Replikation zu nehmen. Dabei kann ein AD-Standort mehrere Domänen enthalten und eine einzige Domäne, kann mehreren Standorten angehören. Durch das erstellen von Standorten kannst Du die Replikation von Active Directory bzw. das SYSVOL Verzeichnis "besser" steuern. Standortintern (Intrasite) werden Änderungen nämlich wesentlich häufiger repliziert als zwischen AD-Standorten (Intersite) und vorallem werden die Daten über die Leitung komprimiert repliziert und nicht so wie standortintern - unkomprimiert. Dadurch hast Du nicht nur die Möglichkeit, die effektive Performance im Netzwerk zu optimieren, sondern auch die WAN-Struktur im Hinblick auf Geschwindigkeit und Kosten Rechnung zu tragen. Durch AD-Standorte kannst Du z.B. jeden DC zu einem AD-Standort verschieben und somit klar definieren, welcher DC zu welchem Standort gehört. Damit wissen die Clients schneller, welcher ihr Anmeldeserver ist. Ebenfalls hast Du die Möglichkeit, gezielter mit GPOs zu arbeiten bzw. standortabhängige GPOs anzuwenden, falls das gewünscht ist. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort Wenn du vorher das AD-Standortobjekt samt Subnetz erstellst, du dem Server die IP-Informationen des Aussenstandorts in den TCP/IP-Einstellungen konfigurierst, dann wird der Server direkt an "seinem" AD-Standort (als dem Aussenstandort) zugeordnet. Ein nachträgliches verschieben des DC-Objekts an seinen richtigen AD-Standort bleibt einem somit erspart. Genau. Dabei solltest du primär das Eventlog im Auge behalten und zu einem späteren Zeitpunkt das DCDIAG sowie REPADMIN ausführen. Wenn man z.B. kein Full-Mesh Netzwerk hätte, würde es eher Sinn machen. Aber in deiner Situation ein klares nein. Denn wenn du Hand an die AD-Replikationstopologie legst, nimmst du dem AD das Recht bei etwaigen Veränderungen der Netzwerktopologie, automatisch einzugreifen. Die AD-Replikation ist ein robuster Vorgang und das AD regelt die Replikation sehr gut alleine. Wenn möglich, solltest du die AD-Replikation dem AD selbst überlassen. ... to be continued.

Der Domänenname und die Benutzernamen des Benutzerkonten sind "Schall und Rauch". Das entscheidende hinter den Namens ist die SID. Auch wenn du die Benutzer mit dem gleichen Anmeldenamen neu erstellst, sind es neue bzw. andere Benutzer. Das gleiche in grün. Du müsstest die alle Clients zur neuen Domäne hinzufügen. Du würdest so oder so eine neue Domäne erstellen. Ob du nun den gleichen Domänennamen wie die gecrashte Domäne verwendest oder einen ganz anderen Domänennamen nimmst, in jedem Fall ist es eine neue Domäne.

Servus, du könntest dein Glück mit UMOVE versuchen. Diese Variante ist aber "nicht supportet" von Microsoft. UMove - Move or copy Active Directory for backup or recovery

Servus, du fügst also einen neuen zusätzlichen DC der bestehenden Domäne hinzu. Dieser soll dann in der Aussenstelle aufgestellt werden. Brav. Lieber VORHER einmal zu viel gefragt, als NACHHER den Salat zu haben. ;) Danke dafür, aber kann man jemals zum "Guru" werden? ;) In dem Artikel geht es um das Verschieben des DCs. Wie möchtest du denn die Installation des neuen DCs durchführen? An welchem AD-Standort installierst du den DC? Erzähl mal etwas mehr über die Umgebung. Existieren mehrere AD-Standort? Mit welcher Bandbreite sind die Standorte miteinander verbunden? Du kannst auch den DC direkt vor Ort mit den richtigen IP-Informationen in der Aussenstelle mit der IFM-Funktion installieren. LDAP://Yusufs.Directory.Blog/ - Domänencontroller-Installation von einer Sicherung

Keine Ursache, viel Erfolg und VORHER testen ist immer gut. ;)

Servus, nein, dann bist du durchgefallen.

Servus, dann kannst du das ADPREP /FORESTPREP und ADPREP /DOMAINPREP /GPPREP von der --> zweiten R2-CD <-- ausführen. Anschließend kannst du den R2 als zusätzlichen DC hinzufügen. Du musst nichts weiteres beachten.

Servus, das ADPREP unter 2008 R2 befindet sich aber im Verzeichnis "<DVD-Laufwerk>:\Support\Adprep". Warum denn "Neue Domäne"? Du möchtest doch die bestehende Domäne aktualisieren, also die bestehenden 2003er DCs durch 2008 R2 ersetzen. Du fügst einen zusätzlichen Domänencontroller einer bereits bestehenden Domäne hinzu. Was denn nun. Neue Domäne oder möchtest du der --> bestehenden <-- Domäne einen 2008 R2 DC hinzufügen? Die FSMO-Rollen und insbesondere die Rolle des PDC-Emulators sollte stets der DC inne haben, der das aktuellste OS installiert hat. Ein "Forceremoval" ist nicht notwendig. Nach einem Monat ist die Tombstone Lifetime noch nicht abgelaufen, daher kannst du diesen normal mit "DCPROMO" herunterstufen. Nichts was zumindest mit der Domäne zu tun hat. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Servus, die einen waren bereits beim Friseur und die anderen warten noch auf ihren Termin. ;) Es handelt sich dann um eine größere Gruppe. Dann ist das "by Design" so. Denn wenn die Gruppe mehr als 500 Mitglieder enthält, ändert sich bei einigen die Frisur. :) Hair color of the "person" icon for a user group becomes gray if the group contains more than 500 users

Servus, Mit dem Befehl "DSGET GROUP „CN=<Gruppenname>,CN=Users,DC=intra,DC=dikmenoglu,DC=de“ -members -expand" werden dir alle Mitglieder, samt den verschachtelten Mitgliedern der angegebenen Gruppe angezeigt. LDAP://Yusufs.Directory.Blog/ - Active Directory - Abfrage Nein, nicht bei DSGET.

Servus, nein, du hast nichts falsch gemacht. Man kann das ADMT entweder in der Quell- oder Zieldomäne ausführen. Aber in besonderen Situation bzw. im Fehlerfall sollte man das ADMT dann in der Zieldomäne ausführen und prüfen, ob der Fehler weiterhin entsteht. Das ADMT muss nicht auf einem DC installiert werden aber der PES schon. Dabei kann das ADMT entweder in der Quell- oder Zieldomäne installiert werden, wobei der PES zwingend in der Quell-Domäne auf einem DC installiert werden muss (logischerweise).

Servus, 1. Hast du denn auch die "Authentifizierten Benutzer" aus der Richtlinie entfernt? 2. Hast du dir den Link den Nils gepostet hat durchgelesen? Nein? Dann tue es. Korrekt, steht auch in dem Link.

Off-Topic: Hey Norbi und Nils, ihr müsst` doch Geld verdienen --> beim Kunden <-- und sollt` hier nicht als "Lingering Objects" euch aufhalten. ;)

Salut, ... und dazu müssen vorher die RSAT für Win7 installiert werden, damit das dsacls zur Verfügung steht. http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d

Da könnte etwas dran sein. ;) Das stimmt auch. Aber das liegt zum einen daran das du uns bisher nur schwer vermittelst was der Sinn des ganzen ist und zum anderen, du uns immer noch nicht erklärt hast warum du einem Benutzer das Recht geben möchtest eine AD-Replikation durchzuführen. Du bist dir hoffentlich auch sicher bei dem was du tust. Dann installiere dir die Windows Support Tools und rufe das ADSIEdit auf. Danach verbindest du dich mit allen Verzeichnispartitionen, inklusive der beiden DNS-Partitionen (DomainDNSZones und ForestDNSZones). In den Eigenschaften der jeweiligen Verzeichnispartition fügst du deinen Benutzer im Reiter Sicherheit hinzu und erteilst ihm in den Berechtigung die entsprechenden Rechte. Uns was das Lesen anbetrifft, lies dich durch diese beiden Whitepapaer durch: https://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3&displaylang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en Aber nochmals: Man sollte nur Hand anlegen, wenn man weiß was man tut.

Sorry, aber man merkt dir schon an, dass bei dir noch eine Wissenslücke diesbezüglich existiert. 1. Was soll denn der Benutzer genau ausführen können und welche Daten sollen repliziert werden? Denn wie ich bereits in meiner vorherigen Antwort geschrieben hatte, die AD-Replikation findet automatisch "by Design" von ganz alleine statt. 2. Warum soll überhaupt ein Benutzer Hand an die AD-Replikation legen? Denn wenn man nicht weiß was man tut, kann man sich die AD-Replikation auch schnell lahm legen und damit sich viel mehr Probleme ins Haus holen. Doch, die gibt es. Man kann einem Benutzer das Recht delegieren eine Replikation anzustoßen. Aber wozu das ganze Geweih? Die AD-Replikation ist ein robuster Vorgang und repliziert von ganz alleine und macht das sehr gut. Wenn es also ein Problem mit der AD-Replikation gibt, dann sollte man die lösen und nicht versuchen drumherum zu basteln. Leider immer noch...

Überprüfe trotzdem mit NTDSUTIL ob nicht doch noch eine "Leiche" im AD existiert. LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Poste doch mal den exakten Wortlaut der Fehlermeldung.

Salut, was steht denn in den Eigenschaften des DC-Objekts (dsa.msc) im Reiter "Betriebssystem"?

Also deine Beschreibung passt immer noch nicht. Wenn zwei Domänen innerhalb einer Gsamtstrukturen existieren, sorgt das AD von ganz alleine für die AD-Replikation. Du musst also nichts im Idealfall (was der Regel entspricht) händisch zusätzlich konfigurieren, damit die AD-Replikation durchgeführt werden kann. Das AD repliziert "per Design" automatisch ohne das zutun des Admins. Du musst das nochmals genauer erläutern. WAS wird nicht zwischen den Domänen repliziert und wie lautet exakt die Fehlermeldung (samt EventID)?

Servus, das war überhaupt keine gute Idee. Du hast ja selbst gemerkt was am Ende daraus werden kann. Und mit dieser Aktion hast du mehr oder weniger deine Domäne "begraben". Warum stufst du denn "mit Gewalt" den noch einzigen gesunden DC herunter? Ich nehme nicht an das noch weitere DCs existieren, oder? Hast du von irgendeinem DC noch ein aktuelles System State Backup? Falls nicht, setze die Domäne neu auf. Ansonsten kannst du dir noch diese " nicht supportete Variante" mit UMOVE anschauen. UMove - Move or copy Active Directory for backup or recovery Wenn du BEVOR du selbst tätig wurdest hier gefragt hättest, hätte man dir noch adäquat helfen können... Das ist auch nicht empfohlen.