Daim

Da kannst du dich darauf verlassen. Ich weiß, darüber hatten wir uns schon vor ein paar Jahren unterhalten. Die US-Boys haben halt in manchen Dingen eine andere andere Ansicht als Europäer und vorallem eine ganz andere Ansicht als Südländer. ;) Man siehe sich nur die Windows 7 Parties an die veranstaltet wurden. In den USA wo Tubberparties groß geschrieben werden kam das bestimmt cool rüber. Aber hier in Europa... :rolleyes:

Das war auch dein Glück. ;) Aber Halloooo.... :)

Da brät mir doch glatt einer einen Stroch... Weil mir das keine Ruhe gelassen hat, habe ich es nun umgekehrt getestet: Also englischen Windows Server 2008 DC installiert und von einer deutschen "Windows Server 2008 R2" DVD das ADPREP32 ausgeführt und ich erhalte das gleiche Ergebnis wie der OP. Also: 1. Auf einem deutschen 2008er Schemamaster lässt sich das ADPREP32 von einer englischen "Windows Server 2008 R2" DVD erfolgreich ausführen. 2. Auf einem englischen 2008er Schemamaster lässt sich das ADPREP32 von einer deutschen "Windows Server 2008 R2" DVD nicht ausführen. Da hat Redmond "saubere" Arbeit geleistet. ;)

Wenn keiner die Links liest, warum mache ich mir dann die Mühe... :( Genau, denn ab Windows Server 2008 R2 gibt es keine x32Bit Versionen mehr und ein Cross-Upgrade von x32 auf x64 ist nicht supportet und funktioniert technisch auch nicht. Wenn du in den Domänenfunktionsmodus "Windows Server 2008 R2" wechseln möchtest, dann ja. Dann kannst du auch noch den Gesamtstrukturfunktionsmodus auf "Windows Server 2008 R2" stufen, sofern alle Domänen innerhalb der Gesamtstruktur unter Windows Server 2008 R2 DCs betrieben werden. Aber das ist alles in dem Link aus meiner vorheringen Antwort beschrieben.

Hmm... ok, ich habe das eben in meiner Testumgebung in umgekehrter Version versucht und es funktioniert! Also auf einem deutschen Windows Server 2008 Schemamaster das ADPREP von einer englischen Windows Server 2008 R2 DVD ausgeführt. Das lief ordnungsgemäß durch.

Erläutere bitte nochmals "Schritt für Schritt" wie du vorgehst. Wenn du ADPREP /FORESTPREP von der "Windows Server 2008 R2" DVD ausführst, muss dein Schemamaster auch unter einem x64 Bit System laufen. Läuft der Widnows Server 2008 Schemamaster unter x32 Bit, musst du ADPREP32 /FORESTPREP ausführen. Aber das steht alles in dem Link in meiner vorherigen Antwort. Hast du in den Ordneroptionen auch alle ausgeblendeten Ordner einblenden lassen?

Servus, das traf auf Windows Server 2008 zu. Mit Windows Server 2008 R2 hat Redmond das nun gefixt was soviel bedeutet, man kann nun mit einer englischen DVD auf einem deutschen Schemamaster das ADPREP ausführen. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen P.S. Wenn man das ADPREP nicht auf dem Schemamaster ausführt, würde man eine klare Meldung die darauf hinweist erhalten.

Servus, lies diesen Artikel: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Bevor du den DC herunterstufst, schalte ihn für ein paar Tage aus. Dann fällt schnell auf ob noch etwas fehlt und du kannst den DC wieder hochfahren und das fehlende noch übernehmen. Wenn dann nach ein paar Tagen sich keiner gemeldet hat und alles so funktioniert wie es soll, schalte den DC wieder an und stufe ihn mit DCPROMO zum Mitgliedsserver herunter.

Servus, der zweite DC läuft wohl unter "Windows Server 2008 R2" und nicht "Windows Server 2008" oder du hast das verwechselt. Dann müssen alle DCs in dieser Domäne unter "Windows Server 2008 R2" betrieben werden. Vorher ist das hochstufen den Domänenfunktionsmodus nicht möglich. Zuerst müssen die DCs den höheren Domänenfunktionsmodus unterstützen. Das bedeutet, müssen muss der 2003er DC aktualisiert werden Was es zu beachten gilt und wie das hochstufen funktioniert, erfähst du von hier: LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus Zur Diagnose: Eventlog und DCDIAG sind die gängigsten Kandidaten um die Domäne bzw. DCs zu überprüfen.

Servus, du hast doch deine Domäne auf Windows Server 2008 R2 aktualisiert. Dann führe doch mal den AD- und DNS-BPA aus, um deine Umgebung zu überprüfen ob auch alles ordnungsgemäß funktioniert. LDAP://Yusufs.Directory.Blog/ - Der Active Directory Best Practice Analyzer

Servus, schau mal hier: LDAP://Yusufs.Directory.Blog/ - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann?

Das ist überhaupt nicht schlimm. Siehe: LDAP://Yusufs.Directory.Blog/ - DCDIAG: NCSecDesc Fehler Nein, musst du nicht und abgesehen davon handelt es sich ja dabei um kein echtes Problem. Das kannst du getrost ignorieren.

Merke dir für die Zukunft: Man stuft ohnehin nicht in der nächsten Sekunde den "alten" DC herunter. Diesen lässt man noch einige Tage mitlaufen und bevor man diesen endgültig herunterstuft, schaltet man ihn für ein paar Tage erstmal aus um zu überprüfen ob auch alles noch so funktioniert wie es soll. Das kommt evtl. daher. da sich der alte und neue DC noch nicht abschließend repliziert haben. Steht denn nun in den TCP/IP-Settings des neuen DC, der neue DC selbst drin? Die DNS-Einträge muss und tätigt der DC selbst. Denn wenn er das nicht tut, liegt ohnehin ein Problem vor. Hast du mal mittlerweile den neuen DC neugestartet? Falls nicht, dann jetzt. Zumindest starte den Anmeldedienst neu. Ich weiß das lässt sich jetzt so einfach schreiben, aber gerade in schwierigen Situationen wie diese sollte man zuerst einen kühlen Kopf bewahren. Erst dann, sofern man sich das zutraut, sich an die Analyse wagen. Dann trage in den TCP/IP-Settings des neuen DCs diesen zweiten DC als primären DNS-Server ein. Denn auf dem zweiten DC sollte ja alles in Ordnung sein. Das kannst du zwar machen, aber noch gibt es brechtigte Hoffnung den anderen (neuen) DC zum fliegen zu bringen. Abgesehen davon, die Rollen spielen bei einem DC wechsel keine so große Rolle. Was hast du denn jetzt mit NTDSUTIL durchgeführt und warum? Du solltest nicht voreillig "irgendetwas" tun. Tief Luft holen und eine Tasse Kaffee oder Tee trinken. Dann überprüfe das Eventlog des neuen DCs. Aber oberste Priorität hat das DNS!

Servus, zuallererst um dich selbst zu schützen, anonymisiere direkt die Ausgabe von DCDIAG. Firmenrelevante Daten gehören nicht hier her! Merke dir das für die Zukunft, auch in deiner Verzweifelung. Grüße von einem Meenzer.

Du musst Vorgehen, so wie es ab diesem Abschnitt "Stattdessen wäre folgendes durchzuführen:" in dem Link beschrieben steht. Die Anzahl der GPOs solltest du ohnehin kennen. Aber es zählt ja nicht nur die Anzahl der GPOs um ein "gesundes" SYSVOL zu erkennen. In dem genannten Abschnitt ist alles beschrieben. Wenn du den genannten Abschnitt aufmerksam liest, findest du auch die Hinweise bzgl. des NTFRS-Dienstes. Nur diesen musst du beenden bzw. starten und nicht den DC neustarten, was du natürlich auch tun kannst. Dito.

Das werde ich gerade noch überleben. :) Nee... von alleine behebt sich dieser Fehler nicht. Man brauch auch keinen "Respekt" vor dieser Aufgabe zu haben. Man sollte sich aber wie vor jeder Aufgabe schon seine Gedanken machen und mit gesundem Menschenverstand die Arbeiten erledigen. ;) Die FSMO-Rollen haben mit diesem Problem überhaupt nichts zu tun. Wie es in meinem Link beschrieben ist, suche dir den DC aus, auf dem das SYSVOL ordnungsgemäß existiert. Das steht aber alles in dem Link. Du hast den Link auch wirklich gelesen und auch verstanden? Ich frage deshalb, da die Antwort dieser Frage ebenfalls in dem Link steht.

Ahoi, also das müssen wir noch einmal üben. Aber dort steht doch auch der Lösungsweg (Stichwort "Burflags"). Kein Wunder, wenn doch die Replikation des SYSVOL-Verzeichnisses nicht funktioniert. Stichwort: Burflags. LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568

Aloha, schau mal bei Schöll vorbei. Die gibt es unter anderem auch in FFM und in DA. Willkommen bei der Schöll AG

Servus, dann migriere die Benutzer-, Gruppen- sowie Computerkonten mit ADMT in eine neue Domäne. Erstelle mit dem neuen Server die neue Domäne mit dem gewünschten Domänennamen und migriere dann nach und nach die Konten mit der SIDHistory in die neue Domäne. Somit können die Benutzer aus der alten und die Benutzer aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen. LDAP://Yusufs.Directory.Blog/ - Eine Domänenmigration durchführen

Dann solltest du trotzdem ein Benutzerkonto erstellen und in den Benutzereigenschaften definieren, dass er sich nur an einem bestimmten Client anmelden darf. Das er sich an einen anderen Rechner setzt wo gerade jemand anderes angemeldet ist, ist nicht ok.

Salve, wie die Kollegen es bereits korrekt genannt haben, suchst du die Objektdelegierung. Diese kann man entweder über die GUI oder in der Kommandozeile durchführen. Der Vorteil an der Kommandozeile ist, das einfache Handling und die Dokumentation. Der Befehl den du benötigst lautet: Dsacls "OU=OU-Name,DC=intra,DC=Domäne,DC=TLD" /I:S /G <Domäne>\<Gruppe>:CA;Reset Password;User. LDAP://Yusufs.Directory.Blog/ - Objektdelegierungen einrichten

Das Internet bietet unzählige Ressourcen und im Zusammenhang mit einer VM-Umgebung kann man das ganze auch nachstellen. Die Grundlagen sollten für dieses Vorhaben schon "sitzen"... Das zählt nicht als Entschuldigung. Mich persönlich enttäuschst du ganz und garnicht. Aber von einem "echten" zertifizierten Admin erwarte ich das keine grundlegenden Fehler gemacht werden. Nichts für ungut.

Salve, wozu ADPREP? Du "seizet" nicht, sondern verschiebst die Rollen (transfer). Nein, warum "mit Gewalt"? Ein DCPROMO genügt, sofern die AD-Umgebung ordnungsgemäß funktioniert. Der Rest stimmt. P.S. Von einem MCITP EA erwarte ich mehr!

Servus, was das AD anbetrifft, garnichts. Es gibt kein deutsches oder türkisches AD. Es gibt nur ein AD und das basiert auf der englischen Sprache, egal von welcher DVD man den DC installiert hat. Lediglich die Namen, also die Oberfläche unterscheidet sich. Im inneren steckt aber imer das gleiche. Was sollen denn die Benutzer alles von extern erreichen können? Direct Access wäre eine Möglichkeit. Wobei diese Technik eben "unsichtbar" einen VPN-Tunnel aufbaut, aber zumindest ist hierbei keine "extra" interaktion des Benutzers notwendig. Der Benutzer muss also nicht zuerst die VPN-Verbindung herstellen. Das musst du klar und deutlich nochmals erläutern.

Salut, bei der Größe und wenn "Changemanagent" im Unternehmen ein Thema ist, dann ist deine Vorgehensweise sogar "ein MUSS"! Du bist also sprichwörtlich nach der "Bilderbuchempfehlung" vorgegangen, was sehr löblich ist. :) So kann dann kaum mehr etwas schief gehen.