Daim

Eine Domänenaktualisierung ist nicht so stressig wie eine Migration. Ganz besonders wenn man ungeübt im Thema "Migration" ist. Auch das Risiko das etwas schief gehen könnte ist bei einer Domänenaktualisierung geringer, als bei einer Migration. Zumal mindestens Exchange existiert. Des Weiteren nimmt eine Migration mehr Zeit in Anspruch.

Servus, ... und ist auch heute, unter Windows 7 / Windows Server 2008 R2 noch so.

1. Niemand ist "allwissend" und das hat auch keiner von uns behauptet! Nur erkennt man an deinen Ausführungen, das er bei dir/euch einige Defizite in diesem Bereich gibt (um es milde auszudrücken). 2. Hattest du bereits zeitnah nach den ersten beiden Antworten die Lösung. Was möchtest du mehr? Das wurde dir hier ebenfalls genannt. Deshalb: LDAP://Yusufs.Directory.Blog/ - Warum es ein dedizierter DC sein sollte! Wenn du es noch möchtest, erläutere das uns doch einmal näher. Welche Schemaaktualisierung hat genau welches Replikationsproblem gelöst. Denn "so" liest sich das wieder einmal... komisch. :wink2: OK, anhand der Eventlogeinträge und einer Suchmaschine sollte das für euch zu schaffen sein.

Ihr könntet schon, ihr wollt' es nur nicht! Das ist ein himmelweiter Unterschied. Scheinbar kennt ihr euch doch nicht "so gut" mit dem AD aus. Nimm es mir bitte nicht übel und es ist auch nicht böse gemeint, aber das Thema AD ist mehr als nur "Benutzer erstellen" oder einen Server zum DC stufen. 1. Hast du die Hilfe hier bereits erhalten. Du musst sie nur verstehen. 2. Der Fall wäre eben nicht eingetreten, wenn ihr euch mit dem AD auskennen würdet. Ihr wärt schneller fertig, wenn ihr euch Hilfe holen würdet. Aber das wollt ihr ja nicht. Aber zum Glück kennt ihr euch ja mit dem AD aus. Nichts für ungut.

Na und? Nur weil ihr mehrere Standorte habt ist das noch immer kein Grund "viele" DCs zu haben! Ihr solltet doch besser über einen Dienstleister nachdenken, der die Umgebung einmal inspiziert (das ist ernst gemeint!). "Da repliziert gar nix mehr" ist keine professionelle Aussage. Du meinst wohl eher, die DCs replizieren sich mit dem "geimageten" DC nicht mehr. Das ist auch "normal" so. Cool. Seit ihr auch einer derjenigen, die keine produktive dafür aber eine Testumgebung besitzen? Was beinhaltet denn alles das System State? Vielleicht auch die Registry? In der sich unter anderem Hardware- und Treiberinformationen befinden? Deshalb greif' zum Hörer und hole einen Dienstleister! Wenn du die Artikel die man dir postet einmal gründlich durchlesen und vor allem verstehen würdest, wäre dir schnell klar, dass es sich bei dir um ein USN Rollback handelt. OK, aber verabschiedet euch wenigstens vorher noch von dem DC.

Bonjour, was soll man dazu sagen, außer: Selbst daran Schuld! Warum darf denn euer Helpdesk an den DC ran? Und vor allem, warum auf dem DC? Steht kein anderer Server zur Verfügung? Idealerweise hätte man die Software z.B. in einer VM *vorher* getestet. Sosoo... "Glück" nennst du das?! Ach... also doch kein "glück" gehabt? Na "sowas" aber auch. Evtl. war das Image, insbesondere in einer Umgebung mit mehr als einem DC, doch keine gute Idee? Verständlich! Das Image ist das Problem. Such mal im Internet nach: USN Rollback. Oder besser, hol dir einen Dienstleister. Ich dachte, ich wäre der deutschen Sprache etwas mächtig, aber das scheint wohl doch nicht der Fall zu sein. Richte deinem Chef schöne Grüße aus uns sage ihm... ne, lieber nicht. ;) Wenn es sich "lediglich" um einen DC handelt, entferne zuerst lokal die AD-Informationen. Danach bereingst du die AD Metadaten und stufst ihn wieder zum zusätzlichen DC. Vorher solltest du den Server neu installieren. LDAP://Yusufs.Directory.Blog/ - Das Active Directory gewaltsam vom DC entfernen Wie wäre es mit einem kostenpflichtigen Dienstleister?! Du bist hier in einem Forum. Wenn du sofortige Hilfe haben möchtest, bist du in einem Forum falsch. Du musst dich an einen Dienstleister wenden!

Servus, was soll das denn bedeuten? Was heißt "ausgesteckt"? Existiert denn ein funktionierender DC? Oder was ist der Stand? Evtl. suchst du ja UMove. Allerdings ist das nicht supportet. UMove - Move or copy Active Directory for backup or recovery

Servus, faq-o-matic.net Borg: AD-Standorte dokumentieren

Ja..jaa... "so" hast du das aber "nie und nimmer" gemeint. :cool:

Ich markiere dir die entsprechende Stelle in rot: Da du nun weißt, auf welche Objekte eine Kennwortrichtlinie angewendet werden muss, kannst du dir auch erklären, warum man die Kennwortvorgaben NICHT in der "Default Domain Controllers" Policy konfigurieren darf. Oder?

Moin Norbi, nö das lese ich nicht so, aber mir fällt gerade das hier auf: "DDC Policy". Ich hoffe (was ich jedoch glaube) das damit nicht die "Default Domain Controllers" Policy gemeint ist. Wenn doch, dann bringt das in dieser Richtlinie überhaupt nichts. Denn die Kennwortvorgaben werden von Computerkonten ausgewertet. Demnach muss die definierte Kennwortrichtlinie auf die Clients verlinkt werden. Idealerweise konfiguriert man die Kennwortrichtlinie in der "Default Domain Policy".

Servus, wie lautet denn die genaue Fehlermeldung und welche Optionen hast du wie konfiguriert? Du weißt hoffentlich wie man eine Suchmaschine bedient. Diesmal nehme ich dir die Arbeit noch ab... Gruppentypen

Servus, das Konfigurieren einer Kennwortrichtlinie macht nichts anderes, als Werte in die entsprechenden Attribute, die sich in der Domänenpartition befinden einzutragen. Die Konfiguration der Kennwortvorgaben kann sowohl in der Default Domain Policy (DDP), als auch in einer eigenen Richtlinie konfiguriert werden. Es ist aber auch möglich, die Konfiguration in den Attributen direkt auf dem PDC-Emulator vorzunehmen. Wenn man die Konfiguration direkt in den Attributen vornimmt, werden diese in die GPO übertragen, aber nur(!) in die DDP. Daher ist es empfehlenswert, die Kennwortrichtlinie gleich in der DDP zu konfigurieren. So lange niemand auf die Idee kommt, die Änderungen in den Attributen vorzunehmen anstatt in der GPO, kann man die Kennwortvorgaben auch in einer anderen Kennwortrichtlinie vornehmen. Empfohlen ist jedoch ganz klar, die DDP zu nehmen.

Servus, so? Welche denn genau? Dann kannst du die doch auch aus dem AD entfernen? Na das kommt doch darauf an, wie groß die Umgebung ist und wie viel Aufwand du investieren möchtest bzw. kannst. Am einfachsten und schnellsten ist es, wenn du eine Domänenaktualisierung durchführst. Eine Migration ist aufwändig und anstrengender. Eine Domänenaktualisierung ist sicherlich einfacher für dich, als eine Migration. Aber das musst DU entscheiden.

Was möchtest du jetzt noch zu den bereits getätigten Aussagen wissen?

Wenn sich das OS installieren lässt samt Treiber, sicher. Aber ein *DC sollte stets auf vertrauenswürdiger Harware installliert werden. Von welcher Konfiguration sprichst du denn? Die IP-Informationen müssen natürlich passen.

Salve, im Jahre 2010 gibt es tatsächlich noch NT-Domänen? Schon mal an "Aktualisieren" gedacht oder warum wurde bisher die Domäne noch nicht aktualisiert? Wie dem auch sei: Einen NT-PDC betreibt man heute auf aktueller Hardware idealerweise virtuell. Somit bekommst du auch keine Treiberprobleme. Dann sollte neben dem NT-PDC noch ein NT-BDC existieren. Idealerweise auf einem anderen Host. Aber nochmal: Bevor ich das mache, aktualisiere ich die Domäne auf "Windows Server 2003" mit AD. Natürlich nur wenn keine trifftigen Gründe für die NT-Domäne existieren. 2. Was spricht gegen einen Versuch? ;)

Windows Server 2008 Active Directory - Die technische Referenz: Informationen und Tools, direkt von der Quelle: Amazon.de: Stan Riemer, Mike Mulcare, Conan Kezema, Byron Wright: Bücher Active Directory : Designing, Deploying, and Running Active Directory Amazon.com: Inside Active Directory: A System Administrator's Guide (2nd Edition) (0785342228489): Sakari Kouti, Mika Seitsonen: Books Active Directory Cookbook Dann noch vieles im Web: Windows Server 2003 Active Directory-Betriebshandbuch: Inhaltsverzeichnis Betriebshandbuch für Active Directory: Übersicht über die Problembehandlung bei Active Directory ...

Das kommt auf die Umgebung an. Die Kurzfassung: Der Infrastrukturmaster ist dafür verantwortlich, die Integrität der Objektreferenzen zwischen domänenübergreifenden Objekten innerhalb einer Gesamtstruktur aktuell zu halten (beispielsweise bei domänenübergreifenden Gruppenmitgliedschaften). Existiert aber lediglich ein Single-Domain Forest, also nur eine Domäne, dann existieren schlichtweg keine domänenübergreifenden Objekte die es zu vergleichen gibt. In solch einer Umgebung kann der GC auf dem Infrastrukturmaster aktiviert werden, da es für beide keine Arbeit gibt. Wenn es sich um einen Multi-Domain Forest handelt, also mehrere Domänen innerhalb einer Gesamtstruktur existieren, darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs (GC=Global Catalog) innehat. Denn wenn auf dem Infrastrukturmaster zusätzlich der globale Katalog aktiviert wird, kann er nie einen Unterschied erkennen, da er durch den GC bereits jedes Objekt (nicht mit allen Attributen) innerhalb der Gesamtstruktur kennt. Es sei denn, man deklariert jeden DC dieser Domäne zum GC. Siehe den folgenden Link und zusätzlich das gesamte Internet. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Config, ich verstehe dich nicht. Spätestens nach den ersten beiden Antworten direkt nach deinem OP, hattest du die Lösung. Du könntest schon längst fertig sein... Und nun, ran an die Arbeit.

Servus, die FSMO-Rollen (mindestens die Rolle des PDC-Emulators), sollte stets der DC inne haben, der unter dem aktuellsten Serverbetriebssystem betrieben wird. LDAP://Yusufs.Directory.Blog/ - Der PDC-Emulator Alle FSMO-Rollen sollten sich, wenn es die Umgebung nicht anders fordert, auf *einem* DC befinden, nämlich auf dem 2008 R2. Bitte trenn dich von der Begrifflichkeit "PDC und BDC". Seit der Einführung des Active Directory mit Windows 2000 gibt es nur noch DCs. In einer AD-Umgebung hat, im Gegensatz zu einer NT-Umgebung wo lediglich der PDC das Schreibrecht in die Security Account Manager (kurz SAM) Datanbank hatte, jeder DC das Schreibrecht. Da diese Konstellationen auch zu Problemen führen kann (wenn z.B. zwei DCs gleichzeitig das AD-Schema ändern) dürfen eben manche Änderungen nur von bestimmten DCs durchgeführt werden. Diese DCs sind die Träger der fünf FSMO-Rollen. Ob nun per Skript oder manuell: Wenn der Rolleninhaber crasht, kann man die Rollen von einem anderen DC übernehmen lassen. Die FSMO-Rollen haben nicht direkt etwas mit der Benutzerauthentisierung zu tun. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Servus, ja, du musst die Client-Side Extensions für Windows XP auf den Clients installieren. Das kann man auch mit Hilfe des WSUS erledigen. Information about new Group Policy preferences in Windows Server 2008

Wenn es *zwingend* eine Migration sein muss, wäre mein Vorschlag eine Migration mit ADMT 3.0 durchzuführen, sofern es kostenlos sein soll. Ansonsten Quest. ;) http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=6f86937b-533a-466d-a8e8-aff85ad3d212 LDAP://Yusufs.Directory.Blog/ - Die verschiedenen ADMT Versionen

Also "unkomplizierter" als die bereits erwähnte Vorgehensweise ist nicht möglich. Abgesehen davon geht es auch garnicht anders. Die Alternative wäre eine Migration mit ADMT von der NT-Domäne in eine AD-Domäne. DAS ist schon eher "kompliziert". Aber kompliziert ist etwas meistens dann, wenn man sich mit der Materie nicht gut auskennt. ;)

Servus, einfach alles. ;) Mit dem hochstufen des neuen 2003 Servers erstellst du eine neue Domäne, die nichts mit der NT-Domäne zu tun hat. Wenn du eine bestehende NT-Domäne zu einer AD-Domäne aktualisieren möchtest, musst du zwingend den NT-PDC per Inplace Update auf 2003 aktualisieren. Nach der Betriebssysteminstallation und dem ersten Neustart, startet dann automatisch der DCPROMO Assistent mit dem du zum einen die AD-Domäne installierst und zum anderen, gleichzeitig das DNS installieren und konfigurieren lassen kannst. Idealerweise löst man das wie bereits von Günther erwähnt, mit Hilfe einer VM. Das ist auch "einfach" (sofern man das in der IT behaupten kann). Man muss nur die Vorgehensweise kennen, die du ja JETZT kennst. ;)