schroeder750

Sooo, nochmal ganz in Ruhe ein Test: 1) Erstelle bitte mal auf dem NT4-PDC ein Verzeichnis Namens "TEST" 2) Gib das Verzeichnis frei mit dem Namen "TEST" 3) Bei den Freigabeberechtigungen fügst Du bitte die Domänen-Benutzer der W2K3-Domäne hinzu. Standardmäßig dürfte hier "Jeder" mit "Vollzugriff" drin sein. Das lässt Du auch. Von den NTFS-Berechtigungen her dürfte ja die lokale Gruppe der Administratoren Vollzugriff haben. Und diese Gruppe beinhaltet ja die globale Gruppe der Domänen-Admins der W2K3-Domäne. ( Ich hoffe, da hat beim Verschachteln alles hingehauen, bitte nochmal prüfen.) 4) Wechsle auf den W2K3 DC und gib unter Start => Ausführen die IP-Adresse des NT4-PDCs und den Freigabenamen, also \\xxx.xxx.xxx.xxx\TEST ein. 5) Gib unter Start => Ausführen den Namen des NT4-PDCs und den Freigabenamen, also \\"NT4PDC"\TEST ein. 6) Versuch bitte mal, etwas in die Freigabe reinzukopieren. Anschließend machst Du die gleiche Geschichte noch einmal, allerdings jetzt umgekehrt, d.h. auf dem W2K3DC etwas freigeben, berechtigen und den Zugriff aus der NT4-Domäne testen. Nimms mir bitte nicht übel, wenn ich das hier so genau beschreibe, als würdest Du es nicht auf die Rille kriegen, liegt mir wirklich fern, ich möchte nur GANZ genau testen, wo es anfängt zu klemmen. Sei so gut und gib dann mal Bescheid, bei welcher Nummer es Probleme gab und welcher Fehler aufgetreten ist. Wir haben Zeit, da können wir das Problem genau einkreisen, O.K ? Und geh evtl. nochmal die oben beschriebenen Punkte alle durch. Evtl. hast Du was übersehen oder es ist irgendetwas schiefgelaufen. Grüsse schroeder750

Hy Jimmypop, ich denke, der Assistent wird Dir im Moment nicht sonderlich weiterhelfen, da der erst dann ansetzt, wenn die "Autobahn" drunter richtig steht (will sagen, wenn über den Trust der Weg frei ist). Wie schon gesagt, habe ich diesen Assistenten auch noch nicht eingesetzt, vielleicht meldet sich Christoph35 ja noch, um Dir evtl. hier genauere Infos zu geben. Ich habe mal ins ADMT reingeschaut, dort gibt es auch einen Assistenten zum Migrieren von Vertrauensstellungen, der ist hier jedoch fehl am Platze, wenn ich das richtig sehe. Der ist meiner Meinung nach dafür, eine bestehende Vertrauensstellung Deiner NT4-Domäne mit einer anderen Domäne auf die neue AD-Struktur zu übertragen. Sowas mache ich immer manuell... Ich werde mir die Geschichte nochmal anschauen, vielleicht finde ich einen Ansatz... ich hatte auch hier und da mal Probleme mit dem Trust, im Zweifelsfalle habe ich den dann zwei/dreimal neu aufgebaut, bis es dann passte... ist ne etwas kritische Stelle... Ich schau mal, O.K ? Bis später schroeder750

Hy Christoph, Hmmmm, damit ich das schnaggeln kann, lass uns bitte nochmal drüber reden: Habe eben nochmal nachgesehen, wenn ich an besagter Stelle in der Default Domain Policy wen hinzufügen will, bekomme ich auf dem DC (über "Pfade") zunächst einmal vier Möglichkeiten, aus denen ich Benutzer auswählen kann: a) eigene Domäne (die neue W2K3 AD-Domäne) b) die alte NT4-Domäne c) "Gesamtes Verzeichnis" d) den lokalen Rechnernamen Möglichkeit d) vergessen wir jetzt direkt mal wieder, da ja die lokalen Benutzer des DC den Domänenbenutzern entsprechen und ich ja lokale Benutzer der WORKSTATIONS hinzufügen möchte. Zur Möglichkeit a) oder b): Hier sehe ich nur die Domänengruppen wie Administratoren und Benutzer ... Backupoperatoren und Hauptbenutzer tauchen hier nicht auf. Hier kann ich ja nun definitiv nicht angeben, daß der lokale Benutzer "Hans" von irgend einer Workstation sich lokal anmelden darf... Zur Möglichkeit c) "Gesamtes Verzeichnis": Hier bekomme ich natürlich schon mehr angeboten, aber z.B. die Hauptbenutzer tauchen hier auch nicht auf. Ich habe jetzt echt Schwierigkeiten, mir zu erklären, wie ich hier dafür sorgen soll, daß sich der lokale Benutzer "xyz" von irgendeinem PC der Domäne an diesem PC anmelden sollen darf. Normalerweise ist das ja standardmäßig auch gar nicht verboten, daß sich lokale Benutzer anmelden, daher habe ich mir da auch nie Gedanken drüber gemacht. Ich muss echt sagen, daß ich nach wie vor ziemlich ****e aus der Wäsche schaue... Wenn der Spuk mit der Parallelmigration vorbei ist und sich alle Rechner in der neuen Domäne befinden, kann ich in der Default Domain Policy ja wieder alles auf "nicht definiert" setzen, dann dürfte das auch wieder funktionieren, aber in der Zwischenzeit ... :mad: Noch jemand ne Idee oder ne brauchbare Erklärung / einen Workaround ? Danke Euch schon mal !! Ist prima, immer wieder Antworten zu bekommen und zu diskutieren, man kann da echt auch aus kleinen Dingen ne Menge Wissen ziehen, wenn man das bis ins kleinste durchgeht... Grüsse schroeder750

Hy Jeff, ich kann mich lefg nur anschließen. Diese Vorgehensweise MUSS schiefgehen, da ein systemstate alle Infos des DCs beinhaltet, also auch die SID. Wenn Du das mit name und IP-Adresse geändert bekommst und es Dir nur darum geht, die SID zu ändern, dann versuch mal das Tool "NewSID" von Sysinternals: http://www.sysinternals.com/Utilities/NewSid.html Wenn es Dir nur darum geht, die Rollen des DC, also hauptsächlich die fsmo-Rollen für den Katastrophenfall des Komplettausfalles des ersten DCs schnell wieder herstellen zu können, dann solltest Du folgende Vorgehensweise ins Auge fassen: - Installiere einen zweiten DC ins bestehende AD - Sorge dafür, daß er eine Kopie des globalen Katalogs bekommt - Installiere die W2K3 Support-Tools auf allen DCs - Im Falle eines Ausfalles des ersten DCs kannst Du nun mit "ntdsutil" und dem "seize" Befehl jederzeit die 5 fsmo-Rollen auf den verbleibenden DC verschieben. Das funktioniert natürlich auch, wenn der eigentliche fsmo-Rollen-Inhaber nicht mehr erreichbar ist. (Daher auch der "seize"-Befehl und nicht der "transfer") Der verbleibende DC hat alle Informationen zu den fsmo-Rollen in seiner lokalen Kopie des AD, bekommt jedoch im Normalzustzand nur nicht die "Erlaubnis", diese Rollen zu übernehmen, da dies ein anderer tut. Sollten auf dem DC noch weitere Applikationen laufen, musst Du Dir natürlich zusätzlich noch Gedanken machen, wie Du diese im Ernstfall auf dem verbleibenden DC zur Verfügung stellst. DNS und WINS können ja alle DCs ohne Probleme parallel fahren. So Dinge wie DHCP kannst Du ja auf dem zweiten DC mit der gleichen Range einrichten und dann die Dienste deaktivieren. Im Ernstfall sind die dann schnell gestartet... Wenn Du keinen zweiten DC parallel laufen lassen willst, hilft Dir der systemstate natürlich gut weiter, wenn Du einen neuen DC aufbaust und den systemstate drüberbügelst, dann aber bitte definitiv NICHT zusammen im netz mit dem ersten DC... das knallt natürlich ... Grüsse schroeder750

Moin Kollegen, vielen Dank schonmal für die Infos !!!!!!! Das mit dem gpupdate auf den Clients kann natürlich für mich schon ne gute Lösung sein... Obwohl da ein bitter Beigeschmack bleibt... Wenn ich als Domänenadmin an der Default Policy was ändere muss ich danach Turnschuhnetzwerk spielen und an alle Kisten rennen oder einen Eintrag ins Logonscript aller User machen oder ähnliches, damit die policy zieht ? Ihr werdet mir doch sicherlich zustimmen, daß das irgendwie suboptimal ist, oder ? :D @Christoph35: Wenn ich in der default domain policy einen Benutzer für irgendeine Einschränkung auswählen will, bekomme ich doch nur die Domänenbenutzer, maximal noch die Benutzer der getrusteten Domäin angezeigt. Wie soll ich an dieser Stelle lokale Benutzer von irgendwelchen Workstations, die wahrscheinlich in diesem Moment eh heruntergefahren sind angeben... das meinte ich mit "nur Domänenbenutzer". Schraube ich an den lokalen Policys auf den Clients rum, klar, da kann ich dann lokale Benutzer angeben. Ich werde das mit dem gpupdate auf jeden Fall auf den Clients durchtesten und bin Euch schon mal superdankbar für die Tips !!! :D Aber mal ganz ehrlich: einen faden Beigeschmack hinterlässt es doch, daß die Policys nicht automatisch beim nächsten Start von den Clients gezogen werden, oder ? Grüsse schroeder750

Hy walker, sorry, jetzt muss ich echt nochmal nachfragen: Du hast Dich auf einem DC der Forest Root Domain (ich denke, die meinst Du mit "der richtigen") angemeldet, dort den dcpromo ausgeführt, das AD entfernt und den Haken gesetzt bei "Letzter Domaincontroller dieser Domäne" ?? :shock: Mach mich jetzt nicht fertig ... die Domäne läuft noch ? Ich hoffe echt, ich habe da ein dickes Verständnisproblem. :eek: Das mit dem ldp.exe ist nicht so windig, wie es sich anhört. Habe das schon mehrmals eingesetzt, wenn ich einen DC oder einen Exchangeserver aus dem AD rausschnippeln musste. Ich denke ganz ehrlich, wenn Du es auf normale Art nicht hinbekommst, wirst Du auf Dauer um eine solche Aktion nicht herumkommen. :wink2: Und jetzt sag mir bitte, daß ich was falsch verstanden habe und Du nicht in der Forest Root Domain auf einem DC das AD entfernt hast und den Haken gesetzt hast... bitte bitte ... :p Grüsse schroeder750

... und ganz davon ab, wenn ich eine Childdomain entfernen will, muss ich mich doch auf dem letzten DC der childdomain anmelden, dort das dcpromo ausführen, das AD entfernen und den Haken setzen bei "Dies ist der letzte Domänencontroller dieser Domain". Führe ich den dcpromo auf einem DC der Forest Root Domain aus, kann ich doch damit nicht eine Childdomain löschen, oder sehe ich das verkehrt ? Grüsse schroeder750

... ich würde als allerersten Ansatz mal einen systemstate aller DCs der Domäne ziehen. Rein zur Sicherheit. Danach würde ich mir ein Tool wie "ldp.exe" krallen und mich damit auf einem DC mal mit dem AD verbinden. Wenn Du hier in aller Seelenruhe die Einträge durchgehst, wirst Du die entsprechenden Stellen, an denen die Childdomain verzeichnet ist, finden und kannst diese löschen. Sollte etwas schief gehen, hast Du die Sicherung des AD und kannst jederzeit den Ursprungszustand wieder herstellen... Mach Dich in diese Richtung mal schlau. Ich kann Dir jetzt nicht die genauen Stellen nennen, an denen die Childomain auftaucht, könnte aber notfalls mal in einer VMWare-Testumgebung nachsehen... Grüsse schroeder750

Moin zusammen, muss doch diesen Thread nochmal nach oben bringen, da es ein paar neue Infos gibt. Ich habe den Admin des Kunden telefonisch (war selber inzwischen noch nicht vor Ort) beim Client direkt eintragen lassen, daß sich selbst "Anonymous" lokal anmelden darf. Resultat ist leider immer noch das gleiche. Lokale Anmeldung nicht möglich ... Mehr aufmachen, als den "Anonymous"-Account zuzulassen, kann ma doch wohl nicht, oder ? Und jetzt noch was anderes: habe in einer Testumgebung einmal versucht, einiges nachzustellen: W2K3 DC mit SP1 / Client ist eine W2K Workstation mit SP4. Schaue ich auf der Workstation lokal in der gpedit.msc-Konsole unter \Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten nach, sehe ich dort, daß folgende Benutzer bei "Lokal Anmelden" erlaubt sind: - Administratoren - Sicherungs-Operatoren - Hauptbenutzer - Benutzer - NAME DES RECHNERS\Gast In der Default Domain Policy auf dem DC sind jedoch folgende Benutzer bei "Lokal anmelden zulassen" eingetragen: - Administratoren - Benutzer (Habe ich so eingestellt). Müsste dies nicht die Einstellungen der lokalen Richtlinien der Clients überschreiben ???? Ich bin nun auf die Default Domain Policy auf dem DC gegangen und habe dort unter \Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten\Lokal anmelden verweigern einen bestimmten Benutzer verboten. Anschließend "gpupdate /force" auf dem DC abgesetzt. Melde ich nun exakt diesen Benutzer, den ich in der Default Domain Policy verboten habe an der Workstation an, passiert ganz genau NICHTS... der kann sich locker anmelden... funktioniert alles. Bei mir funktioniert in der Testumgebung das, was beim Kunden eigentlich funktionieren sollte und NICHT geht und ich bekomme hier nicht einmal mit Gewalt das hin, was beim Kunden harte Realität ist und NICHT funktioniert... verkehrte Welt ... :mad: Habe ich da irgendwie ein fettes Verständnissproblem ? War bisher der Meinung, was ich in der Default Domain Policy an besagter Stelle (oder eigentlich auch generell) angebe, überschreibt die lokalen Richtlinien der Workstations, die sich in der Domäne anmelden, oder ? Wenn ich also in der Default Domain Policy jemandem verbiete, sich lokal anzumelden, bezieht sich das doch auf alle Rechner der Domäne, oder sehe ich da was falsch ? In der Default Domain Policy kann ich ja nun auch nur Benutzer der Domäne angeben, um Dinge zu verbieten oder zu erlauben... wie kann ich dort generell verbieten, daß sich LOKALE Benutzer von den Workstations anmelden ? Hauerha, ich brauch da echt mal einen kleinen Klaps auf den Hintern von Euch, bisher war die Welt da für mich sooo einfach, jetzt sehe ich aber, daß das nichts so ist, wie ich dachte ... Hilft mir bitte mal jemand ? Danke !!! Grüsse schroeder750

Moin Arnd, danke Dir für die fixe Info. Super !! Auf den SBS können wir dort definitiv nicht gehen, hat andere Hintergründe. Müssen wir mal als gegeben hinnehmen. Zum Exchange: Soweit ich bisher informiert bin, kann der Exchange zwar als POP-Server dienen, was damit gemeint ist, ist, daß die Clients via POP3 ihre Mails bei ihm abholen. Damit der Exchange selber POP-Postfächer leerräumt, wird doch ein Zusatztool wie Pullmail oder ähnliches benötigt, oder ? OWA ist standardmäßig dabei, klar, nur VPN für den sicheren Zugriff wird ja vom Exchange selber nicht bereitgestellt. Da muss ich mir ja was zusätztliches überlegen, oder ? Korrigiert mich, wenn ich mich irgendwo irre... Und zwei Exchange 2003 Enterprise, nur um einen mit beendeten Exchange-Diensten in die DMZ zu stellen, um ein bisschen OWA zu spielen, kommt auf kenen Fall in die Tüte... Den Haken für den Frontendserver kann ich ja nur bei der Enterprise-Edition setzen... Für den Intranator sehe ich eher weniger Probleme, wir haben das Ding bei uns auch im Einsatz, ein Kollege ist da recht fit drin. Auf jeden Fall mal danke für die Info... Bin mal auf weitere Wortmeldungen gespannt... Grüsse schroeder750

Moin zusammen, helft bitte mal einem auf die Sprünge, der in dieser Materie nicht so drinsteckt... Habe einen Kunden, der momentan ein W2K AD Netz hat. Auf einem der Server läuft ein MS Proxy 2.0. Des Weiteren existiert dort eine Firewall auf Linux-Basis. Ich möchte diesen Kunden komplett auf W2K3 AD bringen und bei dieser Gelegenheit einen Exchange 2003 implementieren. Der Kunde kam in einer ersten Besprechung des Öfteren auf den MS Proxy zu sprechen und zog auch schon in Beracht, diesen durch einen ISA-Server abzulösen. In einer weiteren Mail fragte er nach, ob nicht der beim W2K3-Server standardäßig mitgelieferte IAS-Server eine Lösung wäre ... Ich habe mich jetzt mal halbwegs schlau gemacht und sehe das folgendermaßen: - Der IAS ist doch eigentlich genau für den umgekehrten Weg der Fall, d.h. die (Radius)User können sich darüber von draussen einwählen, Proxy spielt der IAS ja nur, wenn er dann auf einen anderen internen Server weiterleitet, oder ? - Der MS Proxy 2.0 wurde doch hauptsächlich eingesetzt, um HTML-Seiten, auf die die internen User im Internet zugegriffen haben, zwischenzucachen, oder ? Ist sowas bei den heutigen Standleitungen (vorhanden ist hier eine 1,5 MBit-Leitung für ca. 15-20 Mitarbeiter) überhaupt noch zeitgemäß ? - Der ISA-Server kostet natürlich mal ein paar Euronen, die ein kleineres Unternehmen ja nun nicht mit Freuden ausgeben will. Ich suche daher auch nach Alternativen und stelle mir etwas in dieser Art vor: Für diesen Kunden mit einer überschaubaren Anzahl von Clients dürfte eine "BlackBox"-Lösung eigentlich reichen, die a) Proxy spielt b) die Mails via POP3 vom Provider abholt und diese dem Exchange übergibt c) Einen Zugriff von aussen auf den Exchange via VPN realisiert (OWA) Ich habe da z.B. eine Lösung wie den "Intranator" von Intra2net im Auge. (http://www.intranator.de). Sorry, wahrscheinlich alles dumme Fragen, stecke da aber echt nicht so tief drin und bräuchte mal ein paar Wortmeldungen, um ein Gefühl zu bekommen. Ich danke schonmal im Vorfeld für die jetzt sicher reichlich eintrudelnden Meinungen :D Grüsse schroeder750

... und bitte vorsichtig damit, einen weiteren DC ins AD zu bringen und diesen dann nur von Zeit zu Zeit zu starten, wenn er synchronisieren soll. Der verbleibende DC versucht dann krampfhaft, ständig mit seinem Partner zu replizieren, was der Performance und der Übersichtlichkeit der eventlogs nicht gerade positiv gegenübersteht ... ;) Und das mit dem ASR...da hat Data natürlich absolut Recht. Ist mir noch gar nicht aufgegangen und habe ich auch noch nicht getestet... siehste, wieder was neues für die nächste Testumgebung. Danke für den Hinweis !!! :D Grüsse schroeder750

Klar kann man auch ohne zweiten DC mit einem guten Desaster-Recovery-Scenario gut leben... Ich habe es allerdings noch nicht versucht, den systemstate auf eine Hardware zurückzubügeln, die komplett anders ist... Im worst case musst Du ja immer mal davon ausgehen, daß der jetzige DC hardwaremäßig abraucht und nicht mehr zu gebrauchen ist. Dann hilft ein Ghostimage erstmal nicht sonderlich weiter. Vielleicht mal einfach den Test machen, einen systemstate zu ziehen und ihn auf komplett andere HW zurückzuspielen, nachdem dort ein nackter Server installiert wurde. Dafür dürfte der PC aus der hinteren Ecke des Lagers ausreichen, wenn er irgendwas wie einen P II und um die 128 MB RAM drin hat... dient ja nur dazu, sich Gedanken für den Horrorfall zu machen... Grüsse schroeder750

Supergut, dann kannst Du ja jetzt in Ruhe einen Kaffee schlürfen und Dir Gedanken machen, auf welcher Hardware Du Deinen zweiten DC aufbaust :D :D :D Ernst beiseite, ist doch mal ein Grund, nach so einem Fast-Katastrophenfall, Cheffe einen weiteren Server aus den Rippen zu leiern, wenn Ihr danach alle etwas ruhiger schlafen könnt, oder ? Muss ja kein Geschoss sein, soll halt nur ein weiterer DC sein, der zumindest mal das AD hält und im Notfall die fsmo-Rollen übernehmen kann... Ciao schroeder750

... was blub schreibt, kann ich nur bestätigen. Habe das auch mal getestet, damals war ein Exchange(2003)server mit auf dem DC drauf. Nach erstellen eines nackten Servers und Rückspielen des Systemstate hatte ich wirklich alle Infos wieder drauf, die fürs AD benötigt wurden. Der DC lief wieder, der Exchange natürlich nicht. Warum ich das schreibe: Ich hab echt keine große Ahnung vom SQL-Server, beim Exchange taucht dann aber die Situation auf, daß man ihn nicht sofort wieder neu installieren kann, weil das zurückgespielte AD die Info hat, es gäbe bereits einen Exchange mit diesem Namen. Den Eintrag muss man dann erst per Hand rauslöschen. Inwiefern sich der SQL-Server im AD verewigt und daher nicht einfach neu installiert werden kann, weiß ich echt nicht, dies also nur als kleine Warnung auf ne eventuelle Stolperfalle, wenn Du via restore nicht alles komplett zurückbekommst und nachinstallieren musst... :D Grüsse schroeder750

Hy Charly, ... Du hast Dich nicht unverständlich ausgedrückt, Du hast nur einfach schon eine Menge gemacht, so daß einem langsam keine weiteren Tips mehr einfallen ... :D Die vorhandene Sicherung ist zu einem Zeitpunkt gezogen worden, bevor der Fehler auftrat ? Dann versuch doch einfach mal im Wiederherstellungsmodus, wenn das AD nicht gestartet ist, die Datei "ntds.dit" manuell zu löschen (Liegt im Verzeichnis \NTDS). Dann ist das verdrehte AD ja wohl definitiv mausetot. Anschließend die Sicherung wieder herstellen ... Nur so als erster Ansatz... Wäre natürlich besser, sich vor solchen Aktionen ein Image des Servers zu ziehen ... Grüsse schroeder750

@Christoph35: Absolut legitimer Einwand ;) Ich muss nur ehrlich sagen, daß ich mir irgendwann abgewöhnt habe, diese Assistenten (so gut sie auch teilweise sein mögen) zu benutzen. Ich arbeite heute teilweise noch Domänen von Kunden auf, die damals unter W2K mit dem Assistenten fürs AD aufgesetzt wurden und nur die Hälfte der lookupzones haben. Wie gesagt, wenn der Assistent das alles sauber durchzieht, ist es natürlich eine absolute Alternative. Hast Du schon einmal eine Migration mit dem Assistenten durchgezogen und kannst was dazu sagen, ob der sauber arbeitet ? Würde mich echt interessieren. Habs echt noch nicht gemacht ... bin immer für alles offen... Vielleicht zieht der ein oder andere, der diesen Thread später mal liest, eine Migration mit dem Assistenten durch und falls Probleme auftreten sollten, kann er ja über meine "handmade"-Infos die Fehlersuche angehen ... so haben wir eine komplette Doku mit verschiedenen Varianten. Umso besser, oder ? :p @jimmypop: Versuch bitte mal, auf beiden Seiten den jeweiligen anderen PDC/DC als weiteren DNS-Server einzutragen... Wenn Du (egal von welcher Seite) einen ping -a auf die IP des jeweiligen anderen Server machst, bekommst Du sauber den Namen aufgelöst ? Ein weiterer Punkt, um Fehlerquellen aufzudecken sind die in den Support-Tools enthaltenen "dcdiag" und "netdiag". Einfach mal auf dem DC ausführen und sehen, was an Ergebnissen gebracht wird. Im Zweifelsfalle bei den NT4-DCs und dem W2K3-DC eine lmhosts anlegen und die jeweiligen anderen Server sauber eintragen. Die Auflösungen der IPs und Namen und der Zugriff auf die jeweils andere Domäne muss schon sauber funktionieren, sonst funzt das später alles nicht ... Ansonsten lass doch evtl. mal den Migrationsassistenten drüber laufen, wie Christoph35 das schon erwähnt hatte, vielleicht bringt der noch ne Info... Werden bei Dir die Server "per seat" oder "per server" lizenziert, wenn Sie aufgesetzt werden ? Läuft auf beiden Seiten der WINS sauber ? Sind in den jeweiligen WINS-Servern auch die Einträge für die Server der anderen Seite drin ? Notfalls mal statisch per Hand nachtragen... Halt uns mal auf dem Laufenden, O.K ? Grüsse schroeder750

Ein paar Worte noch zum Password Migration Server: Da sagtest, daß Du in Deiner Domäne eine sehr handliche Anzahl an Usern hast... Wenn Du den Aufriss mit dem PW-Migrationserver nicht machen willst, MUSST Du das auch nicht. In diesem Fall kannst Du ja die Benutzer auch ohne Passwörter migrieren (wichtig ist die SID-History) und kannst den Benutzern Standardpasswörter verpassen, die bei der ersten Anmeldung geändet werden müssen. In kleineren Umgebungen geht sowas eher mal... In großen Firmen ist das natürlich nicht so lustig, wenn der Azubi morgens die Mails vom Chef lesen kann, weil alle das gleiche Passwort haben... Das war übrigens bei mir und meinen Kunden oft ein K.O.-Kriterium für die Parallelmigration zu Zeiten des ADMT 1.1 (W2K). Hier konnte man nur Passwort=Benutzername oder Passwort=ein vom system generiertes kryptisches Password wählen. Da bekommt man bei 3000 Benutzern dann noch Logistikprobleme dazu, wenn man die neuen Passwörter verteilen muss... Sprich das evtl. mal Firmenintern durch, ob hier einfach ein Standardpasswort genommen werden kann, welches die User dann bei der ersten Anmeldung in der neuen Domäne ändern. Wir wollen hier aber mal alles sauber zusammenfassen, dashalb mach ich mir die Mühe jetzt mal einfach, das incl. Passwortmigration zu erklären... Grüsse schroeder750

... und damit Dir auch ja nicht langweilig wird, hier schon mal was zum Weitermachen: NT4: Usermanager: Benutzer ==> Neue lokale Gruppe Die neue lokale Gruppe muss den Namen der Quelldomäne, gefolgt von drei $ haben, die Gruppe darf KEINE Mitglieder enthalten. Beispiel: Die alte Domäne heist "NT4DOM", dann muss die Gruppe "NT4DOM$$$" heißen. ========================================================== NT4: Überwachung (Auditing) einschalten: Benutzermanager starten => "Richtlinien" => Überwachen" => "Diese Ereignisse überwachen" anklicken und bei "Benutzer- und Gruppenverwaltung" jeweils einen Haken bei Erfolg und Fehler machen. Für die W2K3-Domäne sparen wir uns das, da kommt später eine Abfrage, die man nur bestätigen muss... ========================================================== Registryänderungen am NT4-PDC der Quelldomäne: Regedit starten: Unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA den Wert "TcpipClientSupport" als "REG_DWORD:0x1" hinzufügen. Neustart des Servers. ========================================================== Die Administrativen Standardfreigaben (C$) müssen übrigens auf beiden Seiten auf den PDCs / BDCs / DCs bestehen. Wenn die mal entfernt wurden, bitte rückgängig machen. ========================================================== Es wird ein NT4BDC in der alten Domäne benötigt, der für den Password-Export-Server genommen wird. Falls es später Probleme mit dem Passwortexport gibt, sollte man drüber nachdenken, sich einen frischen BDC aufzusetzen. Hier reicht ja Notfalls eine alte Workstationgurke völlig aus. 128-Bit-Verschlüsselung muss auf diesem BDC installiert sein, ich schmeiße immer den IE6.01 SP1 drauf, der bringt diese Vorraussetzungen mit. ========================================================== Installation des Active Directory Migration Tools (ADMT): W2K3 Server CD in den W2K3 DCD einlegen. Aus dem Verzeichnis \I386\ADMT der Windows 2003-Server-CD die Datei "admigration.msi" starten. Die Installation einfach mit "Weiter" durchklicken... ========================================================== Encryption Key: Eine leere Diskette ins Laufwerk des W2K3 DCs einlegen, auf dem ADMT installiert wurde. Folgenden Befehl in einer DOS-Eingabeaufforderung absetzen: "admt.exe key %SourceDomainNetBIOSName% Zielpfad\Zieldatei Beispiel: admt.exe key nt4dom A:\ Auf der Diskette befindet sich jetzt eine Datei mit der Endung *.pes... Die Datei wird im weiteren Verlauf für die Installation des Password Export Servers (oder auch Passwort Migration Server) auf dem NT4 BDC benötigt. ========================================================== Installation Password Migration Server auf einem (NT4) BDC: Einlegen der Diskette mit dem Encryption Key in das Laufwerk des BDCs. Ausführen der Datei Pwdmig.exe aus dem Unterverzeichnis "PWDMIG" des ADMT 2.0-Installationsverzeichnisses (liegt auch auf der W2k3-Server CD). Installation mit den Standardoptionen durchziehen, dabei die Datei auf der Diskette angeben, wenn danach gefragt wird. Fragt er nicht danach, hat er automatisch erkannt, daß die Diskette drinliegt und nimmt den Key. Nach der Installation den BDC neu starten, nach dem Neustart regedit aufrufen und folgendes prüfen: Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa muss unter dem Eintrag "AllowPasswordExport" der Wert "1" gesetzt sein. Sinnigerweise wird dieser Schlüssel zwar bei der Installation erzeugt, der Wert aber auf "0" gesetzt. DANKE MS !! Nach der Änderung auf "1" den BDC erneut starten. Auch danach bitte nochmal prüfen, ob jetzt endlich alles passt... So, weiter später dann... jetzt kill Du erstmal den SID-Filter und dann sehen wir weiter, O.K. ? Viel Erfolg !! schroeder750

... das wäre dann folgender Befehl, den Du absetzen müsstest: ========================================================= netdom trust test.at /domain:test1 /quarantine:No /usero:administrator /passwordo:1234 ========================================================= Das zu verwendende Passwort ist das des Administrators der neuen W2K3-Domäne, NICHT das vom Trust ... Das ist wieder so ein Beispiel, warum ich die Adminpasswörter in beiden Domänen gleich wähle... da muss man weniger denken... es gibt halt nur ein Passwort :D Wenn es damit nicht hinhaut, dann schreib bitte mal genau auf, was an Fehler gemeldet wird, O.K ? Übrigens, an der Stelle, an der Du im W2K3 AD den Trust aufgebaut hast, kannst Du den Trust auch prüfen lassen. Es müsste die Meldung kommen, daß der Trust bestätigt wurde und aktiv ist... auch mal ganz nett, hier vorher nachzusehen, ob der Trust überhaupt sauber steht... Bis später ! schroeder750

Danke Dir für die Antwort Tom, werde ich testen. Ich berichte dann, was draus geworden ist, O.K ? Grüsse schroeder750

... ich gehe übrigens mal davon aus, daß Du die Werte "firma.de", "nt4dom" und "PASSWORT" jeweils durch Deine Werte ersetzt hast, oder ? By the way, ich habe mir übrigens angewöhnt, in der neuen Domäne dem Administrator das gleiche Passwort zu verpassen, wie in der alten. Dann muss man im Laufe der Migration nicht ständig überlegen, auf welcher Seite man jetzt gerade wieder etwas einrichtet und welches Passwort ich wieder eingeben muss... reine Faulheit :D schroeder750

Sooo, da bin ich auch wieder... Der Befehl dient einzig und alleine nur dazu, den SID-Filter, der beim Implementieren der Vertrauensstellung automatisch erstellt wird, wieder abzuschalten. MUSS nicht zu diesem Zeitpunkt geschehen, spätestens jedoch, wenn wir mittels ADMT die Benutzer incl. SID-History rüberholen wollen, stört der SID-Filter. Mich würde aber auch interessieren, was es da für einen Fehler gibt. Es müsste eigentlich, wenn alles glatt läuft, in der DOS-Box die Meldung auftauchen "Setting the trust to not filter SIDs". Mehr passiert nicht... Was für ein Fehler kommt denn genau ? Erkennt er den Befehl netdom erst gar nicht ? Dann solltest Du vielleicht in der DOS-Box vorher in das Verzeichnis wechseln, in das die Support-Tools installiert wurden. Da liegt die Datei "netdom.exe" nämlich nach der Installation. Oder kopier diese Datei halt ins \System32-Verzeichnis. Geht auch... Wo klemmts genau ? Ansonsten hat alles sauber hingehauen ? Die Gruppen konntest Du verschachteln ? Grüsse schroeder750

Moin Tom250376, werde das mal beim Kunden ansehen, dann gebe ich Bescheid, O.K. ? Danke Dir auf jeden Fall schon mal ! Ich werde auf jeden Fall auch mal einen nagelneu aufgesetzten Rechner vom Kunden in die neue Domäne bringen lassen, der vorher noch NICHT Mitglied der alten Domäne war. So kann ich dann erkennen, ob es was lokales an den alten Clients ist oder eine Einstellung in der policy der neuen Domäne... Bis später !! Schroeder750

Genau das ist der Sinn der Sache :D Es kann nur einen PDC geben, also wird dieser automatisch herabgestuft, wenn ein anderer zum Cheffe gemacht wird. Man kann keinen PDC mit Bordmitteln herabstufen, man kann nur einen BDC heraufstufen und somit den König entthronen ;) Wenn bei diesem Vorgang der PDC nicht vorhanden ist und Du ihn nachher wieder ins Netz bringst, wirst Du ein paar unschöne Szenen erleben. Die vertragen sich dann nicht wirklich ... diese Meldung wird Dir aber auch beim Hochstufen des BDCs in Abwesenheit des PDCs ganz klar gebracht... NIE wieder den ursprünglichen PDC reinbringen... Ja wie jetzt ? Den BDC mal einfach umbenannt ? Und was hast Du mit dem bestehenden Konto des PDC gemacht ? Wow wow, langsam... ist ja zum Glück alles nur die Testumgebung... Auf welchem Server läuft der Exchange ? Läuft der auf einem BDC ? Dann hast Du bei einer InPlace-Migration eh ein temporäres Problem und musst ihn vorläufig auf einen Memberserver umziehen. a) Keine Exchange-Migration (jedenfalls keine saubere) ohne die Domäne vorher im native mode zu haben. b) Kein native mode ohne vorher alle NT4 BDCs aus der Domäne entfernt zu haben. c) Kein Entfernen des letzten BDCs ohne vorher den Exchange darauf entfernt zu haben, womit wir wieder bei a) wären ... Hast Du die Testumgebung genauso aufgebaut wie die echte Umgebung ? Was genau heißt "der Exchange funktioniert nicht mehr" ? Konnten Dienste nicht gestartet werden ? Werd bitte mal etwas genauer, dann können wir einen Ansatz finden, was da schiefgegangen ist... :suspect: Grüsse schroeder750