Daim

Salut, eieieii... wie kann denn so etwas passieren? Ihr habt "Jugend forscht" betrieben? Was hat euch Exchange wann wo was vorgeschlagen? Klar, denn Schemaerweiterungen können nicht rückgängig gemacht werden, ausser man führt ein Forest-Recovery durch. Die Attribute lassen sich höchstens deaktivieren aber nicht mehr löschen. Deshalb sollte jede Schemaerweiterung auch gut überlegt sein. Du weißt aber schon, dass der Parameter /PrepareAD für die Installation des Exchange notwendig ist? Prepare Active Directory and Domains: Exchange 2010 Help Du hast ADPREP für das Hinzufügen eines neueren DCs ausgeführt. Das hat aber nichts mit Exchange zu tun. Du musst von der Exchange DVD das "setup /prepareAD" durchführen, um die Exchange-Schemaerweiterung durchzuführen. Ich hoffe desweiteren, dass du nicht auf die Idee kommst und Exchange auf einem DC installieren möchtest. Das ist nicht empfohlen, wird jedoch supportet. Zu viel "Jugend forscht". ;)

Servus, gibt es jetzt noch ein Problem?

Servus, du machst an einer Stelle einen Eingabe-Fehler. Du kannst natürlich auch nicht zum gecrashten DC "connecten". Du musst natürlich eine Verbindung zu einem bestehenden DC herstellen. Deshalb kontrolliere bitte deine Vorgehensweise anhand des folgenden Artikels und dort genau nach dem Abschnitt "Mit NTDSUTIL die Gesamtstrukturmetadaten bereinigen": LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Salve, ja, kannst du. Die Bezeichnung der Attribute ist überall gleich und lautet extensionAttribute1 bis 15.

Servus, ist die Namensauflösung auch sichergestellt? Falls nicht, würde sich eine bedingte Weiterleitung anbieten. Na dann tue dir keinen Zwang an und führe eine Inter-Forest Migration durch. ;) Wenn du die Benutzer in eine neue Gesamtstruktur migrierst, können sich die Benutzer in der Quell-Domäne weiterhin an ihrer Domäne anmelden. Na zu migrieren!? LDAP://Yusufs.Directory.Blog/ - Eine Domänenmigration durchführen

Servus, ok, schau aber sicherheitshalber nochmals in die beiden Links: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Was genau meinst du mit "könnte" schief gehen? Wenn im AD-Schema nicht gepfuscht wurde, sollte ADPREP problemlos das AD-Schema erweitern. Aber auch wenn ADPREP abbrechen sollte, funktioniert die bestehende Umgebung weiterhin. Danach kontrolliert man warum genau ADPREP den Vorgang nicht abschließen konnte und behebt den Fehler. Denn jede Aktion die das ADPREP durchführt stellt eine Transaktion dar und somit können keine halben Attribute bzw. Klassen erstellt werden. Entweder das neue Attribut wird erstellt oder nicht. Bricht die AD-Schemaerweiterung mittendrin ab, wird die Schemaerweiterung lediglich nicht zu Ende geführt, aber das AD wird dadurch keineswegs Inkonsistent. Für alle weiteren Probleme kommt es darauf an, welcher GAU genau eintritt. Bevor du anfängst, solltest du natürlich mindestens ein funktionierendes System State Backup von min. zwei DCs erstelllen. LDAP://Yusufs.Directory.Blog/ - Hinweise zu ADPREP Nein, dass ist nicht notwendig. Du kannst dann eben keine NT-BDCs mehr zur Domäne hinzufügen, aber das möchtest du hoffentlich ohnehin nicht mehr. ;) Das ist ebenfalls nicht notwendig und wird auch nicht empfohlen. Und nochmal, wenn das AD "Standard" ist, also keine unüberlegt "eigenen" Erweiterungen durchgeführt wurden, läuft das ADPREP sicher durch. Denkbar ist vieles in der IT, aber eine funktionierende System State Sicherung von min. zwei DCs sollte vorher erstellt werden. Das ist ja auch gut so. Lieber vorher sich (auch wenns viele sind) Gedanken machen, als hinterher zu weinen. ;) Viel Erfolg und du weißt ja wo du uns findest. :cool:

Ach woher, man muss nur wissen was das für Auswirkungen hat. Wenn du den Modus auf "Windows Server 2003" heraufstufst, kannst du zukünftig keine "Windows 2000" DCs (und älter) zur Domäne hinzufügen. Lies dir den folgenden Artikel durch, dann wird es klarer: LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Nicht dafür. ;) Ob der Server unter einem x32Bit oder x64Bit System läuft, ist für den Vorgang des Heraufstufens zum DC egal. Die Vorgehensweise ist immer gleich, denn das AD kennt weder x32Bit noch x64Bit. In diesem Fall passiert das nicht.

Servus, selbstverständlich tun sie das! Du möchtest einen der bestehenden 2003er DCs virtualisieren (also P2V)? Das funktioniert natürlich ebenfalls problemlos, allerdings ist das nur supportet, wenn der DC offline konvertiert wird! Aber das Konvertieren ist nicht notwendig und das würde ich dir auch nicht empfehlen, wenn es sich "nur" um einen DC handelt. Installiere eine neue VM und stufe diesen zum zusätzlichen DC.

Salve, ich kann Nils nur beipflichten! Wenn du keinen Mehrwert von EventID.net und das für nur 20EUR siehst, dann solltest du es wirklich sein lassen. :-/

Servus, garnicht. Das ist doch genau der Grund, warum man die Verwaltung von GPOs immer vom aktuellsten Betriebssystem durchführen soll. Einen Windows 7 Client kannst du auch in einer VM betreiben, die du nur hochfährst wenn du GPOs administrieren möchtest.

Salve, seit ihr euch auch wirklich sicher? Denn eine Migration z.B. mit ADMT erleichtert euch die Aufgabe immens! Ihr wollt also allen Ernstes eine Migration händisch mit Export-/Import durchführen? Habt ihr auch an die Benutzerprofile gedacht? Welche Größe hat denn die Umgebung? Idealerweise migriert ihr mit ADMT. Dazu ist eine Vertrauensstellung und die Namensauflösung (z.B. eine bedingte Weiterleitung ab Windows Server 2003) Voraussetzung.

Servus, ist die Forward Lookup Zone (FLZ) im DNS nicht AD-integriert gespeichert? Denn wenn das so ist, replizieren sich die DNS-Informationen über die AD-Replikation. Der Server erhält die DNS-Daten erst dann, wenn dieser zum DC gestuft wurde. Oder hast du auf den DCs die Zonenübertragung zugelassen? Falls ja, ist das unnötig. Wenn der 2003er DC auf einer vertrauenswürdigen Hardware läuft, würde ich den 2000er vorher herunterstufen. Anschließend auf dem 2003er DC das Speichern der DNS-Daten von der Domänenpartition umstellen auf die Anwendungsverzeichnispartition "DomainDNSZones". Denn in Windows 2000 befinden sich die Active Directory-integrierten DNS-Informationen in der Domänenpartition (wo sich z.B. auch die Benutzer und Gruppen etc. befinden) und können daher nur innerhalb der Domäne repliziert werden. Ab Windows Server 2003 hat man nun die Möglichkeit selbst zu bestimmen, wo bzw. in welchen Verzeichnispartitionen die DNS-Informationen gespeichert werden. Dort sind die folgenden Replikationsoptionen in den Eigenschaften der FLZ im Reiter Allgemein möglich: 1. Auf alle DNS-Server in der AD-Gesamtstruktur. Somit werden die DNS-Informationen in einer neuen Anwendungsverzeichnispartition "ForestDNSZones" gespeichert. Die DCs müssen mindestens unter Windows Server 2003 betrieben werden. 2. Auf alle DNS-Server in der Domäne. Somit werden die DNS-Informationen in einer neuen Anwendungsverzeichnispartition "DomainDNSZones" gespeichert. Auch hier müssen die DCs mindestens unter Windows Server 2003 betrieben werden. 3. So wie bei Windows 2000 in der Domänenpartition. Du solltest die zweite Option wählen. Erst wenn du das durchgeführt hast, würde ich den 2008 R2 zum DC stufen. Dauer der gesamten Aktion mit herunterstufen des 2000er DC und umstellen des DNS: Weniger als eine Stunde. Wenn der 2003er DC nicht vertrauenswürdig wäre, so das er also jeden Moment crashen könnte, solltest du den 2008 R2 als dritten DC zur Domäne hinzufügen und erst später, den 2000er DC herunterstufen und die DNS-Umstellung vornehmen.

Servus, das sehr wohl! Eine neue Maschine muss es nicht gleich sein, aber ein DC und SQL auf der gleichen Maschine laufen lassen ist genauso wenig empfohlen, wie Exchange auf einem DC. Als zusätzlichen DC reicht eine Client Hardware locker aus. Lediglich die Serverlizenz wird dann benötigt.

Es ist deshalb so einfach, weil du zum einen überhaupt eine System State Sicherung hattest und zum anderen, diese auch funktionierte und sich rücksichern ließ. Freut mich das es funktioniert hat und danke für deine Rückmeldung. :)

Genau, dass erleben wir doch immer wieder. Nein, dass nicht. Aber zumindest erleichtert es das Zurücksetzen des Kennworts. Joah, aber diese Variante kommt dem doch schon nahe. ;) Das stammt ja auch nicht aus Redmond. ;) Leben und leben lassen lautet die Devise aus Redmond. Ich könnte mir aber schon vorstellen, dass es in der Zukunft für den DSRM eine GUI geben wird. Tja, wer weiß schon warum und wiese die US Boys diese Denkweise haben. :cool:

Das meine ich aber auch. :cool: Das ist kein "Gewese", sondern wie du weißt "US Redmond-Style". Klar, wem nicht. Aber wer hört schon auf uns Sunnyboys. :wink2: Doch, tue das. Wer aufhört zu denken, der hört auf diese IT-Welt zu verbessern. ;) Für dich als erfahrenen ist dieses Feature sicherlich nicht gewaltig. Aber denke an denjenigen, der nicht so fit ist mit der Materie und sich Tag für Tag durch alle Facetten von IT-Problemen durchschlagen muss. Für den ist es einfacher das Kennwort eines Benutezrkontos zu ändern, als die schwarze Box aufzurufen.

Nö warum? Per GPP verteilst du doch nicht das Kennwort, sondern lediglich den NTDSUTIL Befehl, mit dem der Kennwort-Sync von dem angegebenen Benutzerkonto durchgeführt wird. Das Kennwort selbst vergibt man ja wenn man das, ich nenne es mal DSRM-Benutzerkonto erstellt. Per GPP triggert man lediglich den Sync an. Um die Verwaltung des DSRM-Kennworts zu vereinfachen. Es geht um nichts anderes bei diesem Feature. ;) Der eine mag die Kommandozeile, der andere die GUI. ;) Im Übrigen ist das Feature, dass man nun das Kennwort eines Benutzerkontos in das Konto vom DSRM syncen kann und somit die Verwaltung des DSRM-Kennworts wie bereits erwähnt vereinfacht. Wie du dieses Feature nutzt, ob nun in der Kommandozeile oder per GPP bleibt jedem selbst überlassen. Aber Fakt ist für mich, es ist ein sinnvolles Feature. Genau und wie du weißt, mahlen die Mühlen in Redmond langsamer als vielleicht in DE (ok ok, auch in AT und CH :p). ;)

Huhuu, genau. Idealerweise ja, aber über die GPP kann man das für alle DCs konfigurieren. Du kannst also entweder für jeden DC ein eigenes Kennwort kreieren was die Sicherheit immens erhöht oder du konfigurierst eins für alle deine DCs mit den GPPs und achtest darauf, dass Kennwort des DSRM-Benutzers regelmäßig zu ändern. Das kannst du ja über die GPP, vermindert jedoch die Sicherheit! Du möchtest also für alle DCs in der Domäne das gleiche Kennwort für das hochsensible DSRM Konto verwenden. Bei den Domänen-Benutzern achtest du darauf, das die Kennwörter der Kennwortrichtlinie entspricht und die Benutzer ihr Kennwort niemandem verraten, aber gerade für das DSRM-Konto wählst du ein Kennwort das auf allen DCs gleich lauten soll... Vom Sicherheitsaspekt her: Vergebe jedem DC sein eigenes DSRM-Kennwort. Ja, die Sicherheit. Du argumentierst nun vielleicht, dann ändere ich das Kennwort sehr oft über die GPPs. Trotzdem haben dann aber alle DCs immer das gleiche DSRM-Kennwort. Ich behaupte dann: Konfiguriere für jeden DC ein eigenes Kennwort UND ändere es ebenfalls oft auf jedem DC. Das kann man ja auch über die GPP lösen. Für jeden DC erstellt man dann eine eigene GPP mit einem eigenen Kennwort. Ob das je nach Größe der Umgebung und Anzahl der DCs praxistauglich ist, steht auf einem anderen Blatt. Sicherer ist es aber allemal. ;)

Servus, warum mache ich mir eigentlich die Arbeit, wenn keiner die Links die man postet (siehe Link in meiner ersten Antwort!) sich anschaut. :rolleyes:

Servus, unter Windows Server 2008 kann man nach der Installation eines Hotfix, das Kennwort für den Modus „Verzeichnisdienstwiederherstellung“ und einem Domänen-Benutzerkonto synchronisieren. Das Konto für den DSRM erhält dann das Kennwort vom angegebenen Domänen-Benutzerkonto. Ab Windows Server 2008 R2 ist der Hotfix bereits integriert. Siehe: LDAP://Yusufs.Directory.Blog/ - Das Kennwort vom DSRM ab Windows Server 2008 synchronisieren

Aber ich hoffe doch sehr, dass du den Filter an deine Umgebung angepasst hast. ;) OK, also existiert kein Fehler auf meiner Seite.

Bonjour, z.B. das System State Backup rücksichern. Das solltest du tun. Das bringt doch nichts, wenn die AD-Datenbank einen Schaden hat. Du benötigst zuerst eine stabile und ordnungsgemäß funktionierende AD-Datenbank. Das ist nicht notwendig. Aber natürlich sollte man wissen was man tut. ;) Genau so ist es. Du führst einen non-authority Restore des System States durch und nach einem Neustart, werden die Änderungen die seit der Sicherung getätigt wurden auf den DC repliziert. Wenn du dir aber bei den durchzuführenden Aufgaben nicht im klaren bist was du da tust, solltest du dir dringend Hilfe von einem Dienstleister holen. Ja, der kostet Geld, aber dafür weiß er garantiert was zu tun ist.

Salve, "kaputt" ist nicht gerade ein professioneller Ausdruck. Definiere das. Ist der Server *wirklich* irreparabel defekt? Das kannst du besser beurteilen als wir. Du musst schließlich wissen welche Dienste auf dem DC laufen und ob evtl. Daten auf dem DC gespeichert sind, die permanent im Zugriff sein müssen. Herunterstufen kannst du den DC unter Start - Ausführen - DCPROMO. Ja, dass funktioniert.

Korrekt. Das steht aber auch in dem Link aus meiner vorherigen Antwort. Genau. Exakto Mundo.