Daim

Servus, dann wäre es sicherlich von der Zeit her zielführender für dich, in eine neue Domäne zu migrieren als nun tagelanges Troublshooting auf eigene Faust oder mit Hilfe dieses Forums zu betreiben. Besser ist es, du holst dir für die Fehlersuche einen erfahrenen Dienstleister zur Seite. Für die Migration kannst du einen der bestehenden DCs herunterstufen und mit diesem eine neue Domäne erstellen. Anschließend migrierst du die Benutzer- und Computerobjekte mit ADMT in die neue Domäne. Nach der Domänenmigration migrierst du dann noch die Postfächer in die neue Domäne.

Servus, das hat nichts mit dem Windows Server 2008 bzw. 2008 R2 zu tun. Ab Exchange 2007 musst du die Exchange Management Console (EMC) oder die Exchange Management Shell (EMS) verwenden. Die Reiter sind aus der MMC "Benutzer und Computer" verschwunden.

So muss das sein. Dann kann ja der Windows Server 2008 (warum nicht gleich 2008 R2?) als DC zur Domäne hinzugefügt werden. Dabei kannst du dich daran halten: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Salve, ich kenne nur einen: Brian Komar! Windows Server 2008 - PKI- und Zertifikat-Sicherheit von Brian Komar erschienen bei Microsoft-Press

Servus, wenn nichts weiter in der neuen Domäne erstellt wurde, lösche die Konten und migriere mit ADMT. Warum sich unnötig Arbeit machen? Das Attribut SIDHistory ist nur für Migrationsszenarien gedacht und lässt sich nicht so ohne weiteres (außer mit Hilfsmittel wie z.B. ADMT) sinnvoll bearbeiten. Nach einer Migration sollte ohnehin die SIDHistory bereinigt werden, da es in der Zukunft evtl. zu Problemen bzgl. zu vieler Gruppenzugehörigkeiten führen kann.

Bonjour, The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default Client computers may not work correctly when you add a Windows Server 2008-based domain controller to an existing pre-Windows Server 2008 domain

Servus, dann lösche den NT-BDC mit ADSIEdit. Aber Vorsicht, wenn du damit nicht vertraut bist, hole dir jemanden der Erfahrung damit hat zur Seite. Sonst kannst du dir mehr kaputt machen. ADSIEdit findest du in den Windows Support Tools. Error Message: DSA Object Cannot Be Deleted

Salve, jetzt hast du nicht eine einzige Frage die dir Norbert gestellt hat beantwortet. Des Weiteren, du weist schon das GPOs nur auf Benutzer- und Computerobjekte wirken und nicht auf Gruppen (auch wenn es der Name "Gruppenrichtlinien" darauf deuten lässt)! Sicherheitsgruppen können nur als Filter dienen. Du verwendest aber schon die GPMC?

Salve, könntest du das bitte noch weiter erläutern was du genau meinst.

Genau so habe ich das auch verstanden. Ich halte aber mit den bisher genannten Informationen eine Migration für sinnvoll und somit würden sich die Fragen des OPs erübrigen. Als Grund hatte der OP genannt: Das ist bei weitem kein Grund dafür, nicht die eine Domäne in die andere zu migrieren! Wenn sich schon zwei Domänen im gleichen Subnetz, physikalisch also an gleicher Stelle befinden, warum nicht gleich migrieren?

Klar, dass funktioniert. Das ist ja das besondere an weiteren Domänenstrukturen. Jeder Tree bekommt so seinen eigenen Namensraum.

So ist es. Man könnte einen eigenen Namensraum höchstens noch mit einer neuen Domänenstruktur (Tree) aufsetzen. Eine Gesamtstruktur besteht nämlich aus einer oder mehreren Domänenstrukturen. Der eine Tree heißt "company.company.com". Nun könnte man einen zweiten Tree mit dem Namen "wir.eu.company.com" in der bestehenden Gesamtstruktur "company.company.com" installieren.

Servus, klar gibt es jede Menge Dritt-Anbietertools. Eins wäre z.B. der Enterprise Security Reporter von ScriptLogic. Enterprise Security Reporter - Features and Benefits - ScriptLogic

Nein, musst du nicht. Aber warum Zeit lassen? Yepp, ist natürlich möglich. Welche Probleme beim hinzufügen des ersten Windows Server 2008/2008 R2 DCs entstehen können, erfährst du in der Linksammlung ganz unten in dem folgenden Artikel: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Wenn die Root-Domäne "domäne.domäne.com" lauten sollte und eure DE-Domäne als Subdomäne in die US-Gesamtstruktur migriert werden soll, kann eure neue Subdomäne nie "wir.eu.domäne.com" heißen. Aber das wird sich schon klären. :)

Dann geh doch schnell aufs WC. :D ... oder du stufst die eine VM herunter, wendest SYSPREP an und stufst die VM erneut zum DC und erstellst eine Domäne.

Dafür sind wir hier. ;) Das freut mich sehr zu hören. :cool:

Was steht in dem Link aus meiner vorherigen Antwort? Na komm... jetzt solltest du aber selber die Antwort auf deine Frage finden. ;)

Servus, lass mich raten: Da du von VMs sprichst, hast du zufällig eine VM geclonet? Falls ja, lies das hier (ab "Prinzipiell gilt"): LDAP://Yusufs.Directory.Blog/ - Vertrauensstellung zwischen zwei Gesamtstrukturen

Aloha, die Daten und das "u.s.w." ist noch keine Grund dafür, warum nicht die eine Domäne in die andere migriert werden soll. Jawollja. Klar würde das funktionieren. Der Client muss nur "sein" Gateway kennen. Da gibt es mehrere Möglichkeiten. Du könntest z.B. die beiden Domänen am Switch trennen. Also jede Domäne hätte seine eigenen Switche. Es kommt wie immer auf die Umgebung an. P.S. Was bezweckst du mit der größeren Schriftart? Das ist eher kontraproduktiv.

Servus, das kommt zwar auf die Größe der Umgebung an, aber bei einem Neuaufbau müssen zwei Domänen in die neue Domäne migriert werden, andernfalls nur die eine Domäne in die andere. Absolut! Das Umbenennen einer Domäne ist zwar seit dem Gesamtstrukturfunktionsmodus "Windows Server 2003" möglich, aber wie du es beireits erwähnt hast, alles andere als trivial. Aber auch hierbei kommt es auf die Umgebung an: Existiert Exchange? Existiert eine CA usw. das sind alles Faktoren die das Umbenennen einer Domäne beeinflussen. Warum sind denn die US-Kollegen der Meinung, dass ihr eure Domäne umbenennen solltet? Na klar. Du migrierst die DE-Domäne in die US-Domäne als eine Subdomäne. ADMT wäre hier das Stichwort. LDAP://Yusufs.Directory.Blog/ - Eine Domänenmigration durchführen Nein, natürlich nicht. Das würde eher nur zu Problemen führen. Denn für eine Migration wird eine Namensauflösung und vor allem eine Vertrauenstellung zwischen der Quell- und Ziel-Domäne benötigt. Bevor eine Vertrauensstellung vom Local Security Authority (LSA) Prozess erstellt wird, prüft dieser die Eindeutigkeit folgender Auflistung: - Den NetBIOS Namen der Domäne - Den Fully Qualified Domain Name (FQDN) der Domäne - Die Security Identifier (SID) der Domäne Diese drei Punkte müssen eindeutig sein, da ansonsten keine Vertrauensstellung zu Stande kommt. Es kommt aber wie so oft darauf an, was geplant ist. Soll die DE-Domäne als Subdomäne in die US-Umgebung integriert werden, ist der Domänenname schon vorgegeben. Lautet die Root-Domäne "intra.domäne.us", kann die Subdomäne nur "sub.intra.domäne.us" lauten. Soll hingegen die DE-Domäne als eine neue Domänenstruktur (Tree) in die US-Gesamtstruktur integriert werden, kann die DE-Domäne ihren eigenen Namen bekommen.

Server, du könntest zwar einen DC ab Windows Server 2003 umbenennen, jedoch ist das keine empfohlene Vorgehensweise und auch nicht trivial. Da zwei Windows 2000 DCs existieren, stufe zuerst den einen 2000 DC mit DCPROMO zum Mitgliedsserver herunter und nehme diesen Server dann aus der Domäne in eine Arbeitsgruppe. Anschließend entferne das deaktivierte Computerobjekt dieses Servers im AD. Wenn dann DNS und WINS bereinigt wurde, kannst du den ersten Windows Server 2008 R2 zur bestehenden Domäne, mit dem gleichen Computernamen und gleicher IP-Adresse wie es der entfernte 2000er DC hatte, als zusätzlicher DC zur Domäne hinzufügen. Das gleiche führst du mit dem zweiten DC durch. Diese Vorgehensweise hat den Vorteil, das man keinen DC umbenennen muss. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Dann existieren keine gesperrten Benutzerkonten. Man darf gesperrte Benutzerkonten (zu oft falsch eingegebene Kennwörter) nicht mit deaktivierten Benutzerkonten verwechseln. Du hast also das Attribut "lockoutTime" überprüft. Dann ist das Konto nicht gesperrt. Das kannst du ja auch in den Eigenschaften des Benutzerkontos verifizieren, ob dort der Haken bei "Konto ist gesperrt" gesetzt ist oder nicht. Zur Klarstellung: 1. Bei einem Benutzerkonto das noch nie gesperrt wurde, der Benutzer sich also immer erfolgreich an der Domäne authentisieren konnte, enthält das Attribut "lockoutTime" als Wert "<Not Set>". Wie oft der Benutzer ein falsches Kennwort eingeben darf bis sein Konto gesperrt wird, ist von der Kennwortrichtlinie vorgegeben. 2. Hat ein Benutzer sein Kennwort (mehr als es in der Kennwortrichtlinie definiert ist) zu oft falsch eingegeben, wird sein Benutzerkonto gesperrt. Dabei wird in "lockoutTime" ein Large Integer Wert eingetragen, dass den Zeitpunkt der Kontosperrung darstellt. 3. Wird ein Benutzerkonto vom Admin entsperrt, erhält das Attribut "lockoutTime" in den Eigenschaften des Benutzerkontos den Wert "0". Daran kann man erkennen, welche Benutzerkonten vom Admin schon einmal entsperrt wurden. 4. Wenn ein Benutzerkonto nach einer definierten Wartezeit durch eine Gruppenrichtlinie automatisch wieder entsperrt wurde, wird in "lockoutTime" der Zeitpunkt der Kontosperrung als ein Large Integer Wert eingetragen. Das Attribut "lockoutTime" enthält dann zwar einen Wert, aber der Haken "Konto ist gesperrt" ist logischerweise nicht "mehr" gesetzt. Der Wert in lockoutTime wird also nicht genullt und bleibt bestehen. Ist also eine Richtlinie definiert, in der ein Benutzer nach einer bestimmten Zeit automatisch wieder entsperrt wird, greift meine oben genannte erste Abfrage nicht. Dann muss errechnet werden ob die aktuelle Zeit größer ist als der Wert im Attribut "lockoutTime", plus die Zeit die ein Konto gesperrt bleiben soll (je nachdem wie es in der Kennwortrichtlinie definiert ist).

Salut, der Container in dem standardmäßig die Computerobjekte im AD erstellt werden ist keine "OU", sondern ein Container. Genau genommen handelt es sich zwar auch bei einer OU um einen Container, doch eine OU wird z.B. bei einer Abfrage anders "angesprochen". Aber der Client wird schon erfolgreich zur Domäne hinzugefügt? Also die Meldung "Willkommen in der Domäne xyz" erscheint? Kontrolliere das auch in der "Systemsteuerung" unter "System" im Reiter "Computername", ob dort der Computername und die Domäne entsprechend angezeigt wird. Existieren mehrere DCs und hast du das auf allen DCs verifiziert? Evtl. leigt ein AD-Replikationsproblem vor? Wie sehen die Eventlogs der DCs aus?

Servus, deine Abfrage stimmt nicht. Wenn dich lediglich die gesperrten Benutzer interessieren egal in welchem Container sich die Benutzer befinden, musst du gezielt das Attribut "lockoutTime" abfragen. Die Abfrage könnte so aussehen: Csvde -f "C:\Temp\GesperrteBenutzer.txt" -r "(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))" -l sAMAccountName,sAMAccountType,userPrincipalName Du könntest zwar eine Abfrage durchführen und dir dabei für jeden Benutzer das Attribut lockoutTime anzeigen lassen, doch das wird je nach Anzahl der Benutzer unübersichtlich. Die Abfrage könnte so aussehen: Csvde -f "C:\Temp\AlleBenutzer.txt" -r "(&(objectClass=user)(objectCategory=person))" -l samaccountname,sAMAccountType,userPrincipalName,lockoutTime Wenn dann bei lockoutTime solch ein Large Integer Wert eingetragen ist "129083854554461236", ist das Benutzerkonto gesperrt. Daher solltest du, wenn es dir lediglich um die gesperrten Benutzer geht, die erste Abfrage von mir verwenden.