Daim

Na dann ists ja gut. Wenn du den Windows 2000 DC mit DCPROMO herunterstufst, ist dieser danach noch Mitgliedsserver der Domäne. Fügst du anschließend diesen Mitgliedsserver zu einer Arbeitsgruppe und entfernst somit den Server aus der Domäne, bleibt anschließend weiterhin das deaktivierte Serverobjekt im AD erhalten. Dieses musst du dann noch von Hand, aus der MMC "Benutzer und Computer" entfernen. Nein, du kannst dem neuen Server dann den Namen des alten DCs verpassen. Das funktioniert ohne Probleme, denn das Tombstone-Objekt erhält nach dem löschen quasi einen anderen Namen. Daim sagt brav "büddeeeee". :cool:

Salut, 1. warum migriert ihr in eine neue Domäne und behaltet eure bestehende nicht bei? 2. Was bedeutet "zu schieben"? 3. Ihr solltet die Benutzer- sowie Computerkonten mit ADMT in die neue Domäne migrieren. Sonst wäre eine Migration auch schlecht möglich. ;) Das musst du aber noch weiter erläutern. Warum muss das so sein? OK. Hmm... verstehe ich nicht. Wenn die Clients in die neue Domäne migriert werden, sollten sie von "ihrem" DHCP-Server aus ihrer eigenen Domäne die IP-Informationen erhalten. Dabei sollten den Clients natürlich die DNS-Server ihrer eigenen Domäne mitgeteilt werden. Dann tragen sich die Clients auch in der FLZ und RLZ automatisch ein, entweder selbst oder durch den DHCP-Server.

Servus, wenn der andere Windows 2000 DC nicht gerade aus dem letzten Loch pfeifft und auch nicht kurz vor dem Hardwarecrash ist, dann kannst du das so machen. Bevor du jedoch den neuen Server als zusätzlichen DC zur Domäne hinzufügen kannst, musst du im ersten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Da es sich bei dir aber um das erste 64Bit-System handelt, beachte bitte in dem folgenden Artikel den 64Bit-Abschnitt: Yusufs Directory Blog - Schemaupdate beim Windows Server 2003 R2 In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusufs Directory Blog - Einen zusätzlichen DC in die Domäne hinzufügen OK. Passt. Yusufs Directory Blog - Die FSMO-Rollen verschieben Das kann man so machen. Glauben tut der Pfarrer. ;) Wenn die Windows 2000 DCs vorher mit DCPROMO aus der Domäne entfernt werden und du anschließend das Serverobjekt aus dem AD entfernst, stellt das kein Problem dar. DCs, egal welche Serverversion sie ausführen, replizieren sich automatisch alle AD-Informationen. Du musst dazu nichts extra einstellen.

OK, dann führe den Artikel aus meiner ersten Antwort durch, um den Windows Server 2008 als zusätzlichen DC zur Domäne hinzuzufügen. Was du noch alles zu beachten hast, entnimmst du aus diesem (und den weiterführenden) Artikel/n: Yusufs Directory Blog - Den einzigen Domänencontroller austauschen

Warum machst du einen Doppelpost?

Servus, du möchtest also die bestehende Windows 2000 Domäne auf Windows Server 2008 aktualisieren? Du kannst die Domänenaktualisierung durch das Hinzufügen eines zusätzlichen "Windows Server 2008 DCs" durchführen. Ein Inplace-Update von Windows 2000 auf Windows Server 2008 ist nicht möglich! Das funktioniert erst ab Windows Server 2003 SP1. Siehe: Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Salut, mir fällt in letzter Zeit hier im Bord mehr und mehr auf, dass der Fragensteller die ihm geposteten Links "nicht" oder "nicht ganz und aufmerksam" durchliest. Das macht mich schon ein wenig sauer. Repadmin /kcc macht genau das, was olc bereits geschrieben hat. Nicht mehr und nicht weniger. Ja, der Artikel ist etwas länger, doch trotzdem musst du ihn durcharbeiten und nicht nur überfliegen oder nur das Anwenden, was dir bekannt vor kommt. :(

Servus, du kannst (musst) die Standard-Protokollierung der AD-Zugriffe aktivieren. Dazu solltest du in in der Default Domain Controllers Richtlinie die folgende Richtlinie aktivieren: Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\<Verzeichnisdienstzugriff überwachen>. Kontrollieren kannst du die Einträge im Verzeichnisdienstprotokoll des DCs. Reicht die das Log-Level nicht aus, kannst du die Protokollierung über die Registry "verfeinern". Damit solltest du aber auch "vorsichtig" umgehen, denn ansonsten wirst du nur so mit Einträgen erschlagen. Yusufs Directory Blog - Die Protokollierung des Active Directory`s konfigurieren

Ok, dann überarbeite ich ihn und reiche ihn dir zur Genehmigung ein. ;) Danke für die konstruktive Kritik. :)

Servus, guckst du hier: Event ID: 1411 is logged on a domain controller that is running Microsoft Windows Server 2003 or Microsoft Windows 2000

Hi Norbi, hmm... ich bin mir nicht sicher ob ich den "Wink mit dem Zaunpfahl" richtig verstehe, aber ich gehe doch in der zweiten Hälfte meines Artikels auf die Delegierung ein. :confused: Ich persönlich würde auch die Delegierung vorziehen. Scrolle mal den Artikel runter und schau noch mal. Wenn dort was fehlen sollte, ergänze ich es gerne. :)

Aha.. na dann ists ja klar. :cool: Merke: Wenn in einem DC mehr als eine Netzwerkkarte aktiv ist, sind Probleme vorprogrammiert. Suche mal im Internet nach "multihomed DC". Dann weißt du was ich meine. ;)

Dann musst du uns schon weitere Informationen geben. 1. Befindet sich die Forward Lookup Zone (FLZ) im AD? 2. Wenn die FLZ AD-integriert gespeichert ist, hat denn mittlerweile die AD-Replikation stattgefunden (sind z.B. alle Benutzer auch auf dem neuen DC )? 3. Steht in den TCP/IP-Einstellungen des R2-DCs ein anderer DC als primärer DNS-Server? 4. Was spricht das Eventlog? ....

Da bin ich anderer Meinung. Das Attribut "MS-DS-Machine-Account-Quota" worin der Wert 10 (standardmäßig) gespeichert ist, definiert den Wert dieser Richtlinie. Egal welcher Benutzer oder welche Gruppe in diese Richtlinie eingetragen wird, für den gilt der eingetragene Wert im Attribut. Weil diese Richtlinie bereits konfiguriert ist. Dort stehen schon die "Authentifizierten Benutzer".

Servus, wenn, dann müsstest du es in der Default Domain Controllers Richtlinie definieren. Mit dem Zuweisen dieses Rechts, können die angegebenen Benutzer lediglich 10 Clients zur Domäne hinzufügen. Du könntest den Wert im Attribut "MS-DS-Machine-Account-Quota" hochsetzen. Siehe: Yusufs Directory Blog - Clients in die Domäne hinzufügen

Salve, nein reicht nicht. Wenn du Gruppenzugehörigkeiten änderst, werden diese nur bei einer Neuanmeldung ausgewertet und nicht "online".

Nein, dass würde ohne Probleme funktionieren und könnte im laufenden Betrieb durchgeführt werden. Theoretisch, ja. Du müsstest das ADPREP /FORESTPREP von der zweiten R2-CD ausführen. Aber ich hatte in meiner ersten Antwort bereits darauf hingewiesen, dass das in "deiner Konstellation" aber nicht funktioniert. Daher schau dir in dem verlinkten Artikel den 64Bit-Abschnitt an.

Salve, ja, dass ist möglich. Sollte jedoch der 64Bit Server der erste Windows Server 2003 --> R2 <-- DC in der Domäne sein, kannst du das ADPREP /FORESTPREP diesmal nicht von der zweiten R2-CD ausführen. Näheres erfährst du aus dem folgenden Artikel: Yusufs Directory Blog - Schemaupdate beim Windows Server 2003 R2

Servus, das mit der "Multimaster Replikation" ist bereits out-of-the-Box so. In dem Moment wo du einen zweiten DC zur Domäne hinzufügst, findet automatisch eine Multimaster-Replikation statt. Seit der Einführung des Active Directory mit Windows 2000 kann auf jedem DC geschrieben werden. Nur zu NT-Zeiten konnte man lediglich auf dem PDC schreiben. Der BDC hatte ausschließlich lesezugriff. Aber auch zu AD-Zeiten kann es bei bestimmten Schreibaktionen zu schwerwiegenden Problemen führen, wenn z.B. mehrere DCs gleichzeitig das Schema aktualisieren würden. Denn für spezielle Aufgaben, darf nur ein einziger DC entweder in der Domäne oder Gesamtstruktur, diese ausführen. Aus diesem Grund spricht Microsoft auch von „Flexible Single Master Operations“, kurz FSMO. Siehe auch: Yusufs Directory Blog - Die FSMO-Rollen verschieben P.S. Bitte eigne dir Grundlagen an.

Salut, ich weiß wie schwer es dir gefallen ist. ;) Auha... ich sah direkt das der Eintrag userAccountControl nicht stimmt und hatte mich nur darauf "fokusiert". Den Rest davor hatte ich erstklassig ausser acht gelassen. :o

Servus, versuche es mal mit diesem Filter, in einer gespeicherten (benutzerdefinierten) Abfrage: (objectCategory=person)(objectClass=user)(lastlogon>=60)(userAccountControl:1.2.840.113556.1.4.803:=2) Yusufs Directory Blog - Gespeicherte Abfragen

Servus, siehe: Yusufs Directory Blog - Domänen- und Gesamtstrukturfunktionsmodus

Servus, aktualisieren den DC zuerst, der weniger von den Benutzern beansprucht wird. Laufen auf dem einen DC "mehr" Dienste und liegen auf diesem auch noch Daten, dann aktualisiere den anderen DC zuerst. Erstelle vorher aber eine Sicherung, insbesondere vom System State.

Salve, ja, dass ist so. Das Kennwort eines AD-Benutzers wird im Attribut unicodePwd gespeichert. Um das Kennwort zu setzen, wird eine 128Bit Secure Sockets Layer (SSL) Verbindung zum DC benötigt.

Servus, warum "nur noch"? Es ist ohnehin empfehlenswert auf jedem DC den GC zu aktivieren, was du auch tun solltest. Zwingend ist natürlich, dass der SBS der FSMO-Rolleninhaber sein muss und der GC muss auf diesem aktiviert werden. Auf den zusätzlichen DCs, kann und darf der GC selbstverständlich aktiviert werden.