schroeder750

Moin mirki, dünne Ausbeute bisher was ? :mad: Mal sehen, ob ich Dir irgendwie helfen kann... Ich schnaggel ehrlich gesagt, noch nich so ganz, was Du genau gemacht hast. Du hast im Exchange System-Manager unter Empfänger\Empfängerrichtlinien die default policy unter "E-Mail-Adressen (Richtlinie)" so bearbeitet, daß Du eine zusätzliche SMTP-Adresse für alle Benutzer angelegt hast und diese zum Standard (Hauptadresse) gemacht ? Sehe ich das richtig ? Oder hast Du hier die Standardadresse geändert und keine weitere hinzugefügt ? Oder hast Du gar eine neue policy angelegt mit den neuen Hauptadressen ? Gib mir erstmal ne Chance, das nachzuvollziehen, damit ich hier mal sehen kann, ob ich was nachstellen kann, O.K ? Ich habe hier unter VMWare einen Exchange (allerdings 2003) laufen, auf dem ich über den registrykey auch das Laufwerk M sichtbar gemacht habe. Habe gerade schonmal etwas rumgetestet: Standardeinstellungen der policy => Struktur auf Laufwerk M heißt genauso wie die Haupt-Mailadressen. Zusätzliche policy hinzugefügt: => Am Laufwerk M ändert sich nix. Bei der Standard-policy eine weitere Mailadresse hinzugefügt und zur Hauptadresse gemacht: => Struktur auf Laufwerk M wird umbenannt in neue Hauptadresse. Kann ich nachvollziehen. Nur hat das bei mir alles keine Auswirkungen aufs OWA ... ?! Das funktioniert nach wie vor... Du sagst, mit dem Adminaccount funktioniert OWA noch... was ist denn, wenn Du als Administrator angemeldet bist und Dir das OWA von einem anderen Benutzer anzeigen lässt ? (http://servername/exchange/username) Kommst Du dann auf die Postfächer ? Haben wir hier evtl. nur ein Berechtigungsproblem ? Gib mal genauere Infos durch, O.K ? Grüsse schroeder750

Moin zusammen, zuerst nochmal vielen Dank an die Mitstreiter, ich habe die Testumgebung jetzt soweit abgeschlossen und kann als Fazit folgende Ergebnisse angeben (Falls es hier mal noch so einen Wahnsinnigen wie mich gibt, der eine solche Cross-Over-Installation machen muss :D ): - Trotz der oben beschriebenen Konfigurationen in der default domain policy der 2003er AD-Struktur war nichts zu holen, OS/2 konnte nicht auf die Strukturen der Windows-Server zugreifen. Habe so ziemlich alles geöffnet, sogar den Gastaccount aktiviert, keine Chance. - Weitere Recherchen im Internet haben ergeben, daß viele Migrationen (oftmals Banken u.ä) durchgezogen wurden, aber alle immer genau anders herum, d.h. OS/2 SERVER und Windows XP CLIENTS... Für den umgekehrten Weg konnte mir keiner ne genaue Info geben. - Wir sind daher einen Schritt nach hinten gegangen und haben einen Windows 2000 DC (SP4) eingerichtet. Hier gibt es noch NetBEUI als Protokoll, was, so wie es aussieht, von OS/2 irgendwie benötigt wird. - Mit der W2K AD-Struktur funktionieren Dateizugriffe und Druckerfreigaben vom OS/2 Client auf die Windows Server problemlos. - Das AD habe ich auf W2K3 erweiteret, Zugriff funktioniert problemlos. - Domäne in den 2000er native mode geschaltet, Zugriff funktionierte problemlos. - Update des W2K DCs auf W2K3: Sofort Feierabend. Das NetBEUI-Protokoll wird rausgeschmissen und das war´s dann... genau hier ist dann Schluss mit Lustig... Also wieder zurück auf einen 2000er DC... :mad: Durch die Erweiterung des Schemas auf 2003 kann ich nun weitere W2K3 DCs reinbringen, muss dabei nur darauf achten, daß der pdc-emulator und der globale Katalog sich weiterhin auf dem W2K DC befinden, damit sich beim Anmelden keiner der OS/2-Clients auf einen W2K3 DC verirrt... Für die Zeit, in der also noch OS/2 Clients existieren, bleibt einfach ein 2000er DC als "Missing Link" zwischen den OS/2 Clients und der AD-Struktur erhalten. O.K. hoffe, ich habe Euch nicht zu sehr gelangweilt, aber es gehört doch wohl zum guten Ton, ne Rückinfo dazulassen, oder ? :D Danke nochmal !! Grüsse schroeder750

Moin mikelx, prima, dann kannst Du ja jetzt (wenn Du es so durchziehst) ganz in Ruhe in der Testumgebung Dein Unwesen treiben und Rückschlüsse draus ziehen für die produktive Umgebung. Ist besser so, glaubs mir... Lampenfieber brauchst Du keins zu haben, wenn Du Dir basierend auf den Ergebnissen aus der Testumgebung ein sauberes Projektdesign (!) erstellst und immer darauf achtest, was im worst case passieren kann, sprich: Dir den Rückweg offen hälst, bist Du auf der sicheren Seite. Wenn Du irgendwie unsicher bist, was die Vorgehensweise betrifft und ob die alte Domäne absolut sauber ist, zieh trotzdem mal noch die Möglichkeit einer Parallelmigration in Betracht. Da schraubst Du anfangs nicht gleich in der produktiven Umgebung rum. Wenn irgendwas unklar ist, frag vorher nach. Locker bleiben, O.K ? :D Nimms nicht zu sehr auf die leichte Schulter, immerhin fasst Du ja den Hauptteil der Rechner an, wenn Du es aber sauber planst und mit einem guten Gefühl rangehst, ist das echt nicht die Welt ... Ich bin nicht selbstständig, ich arbeite als Senior IT-Consultant bei einem Systemhaus in der Nähe von Stuttgart, bin hier verantwortlich für den Bereich Systemtechnik. Mich würde auch bei einigen anderen Leuten hier im Bord interessieren, was die so genau treiben, viele sind einem irgendwie sehr vertraut, obwohl man sie gar nicht persönlich kennt. Man trifft sich halt immer wieder in den Threads. Aber ich denke, das ist eher was für den Off-Topic-Bereich... ;) Grüsse und viel Erfolg !! schroeder750 Edit: Ach ja, und wenn es daran geht, die Exchange-Datenbanken einzupatchen, meld Dich einfach wieder, wenn man das richtig macht, echt kein Hexenwerk. Gibt da halt ein paar Dinge zu beachten. :)

Pah !! jetzt wo ich von lefg erfahren habe, daß meine Pflegerin nich von der Kasse übernommen wird mach ich hier gaaa nix mehr .... :mad: O.K. Ernst beiseite :p ... dann hast Du wieder eine "vollständige" Domäne bestehend aus einem PDC (der heißt zwar jetzt nicht genau so wie der originale, aber who cares, die Domäne ist da ...) und sämtlichen Benutzerkonten und Gruppen. Als nächstes baust Du dann einen weiteren virtuellen Rechner auf, das gibt dann den Exchange. Um den mit gleichem Namen reinzukriegen, muss natürlich vorher das aus der echten Umgebung übernommene alte Konto des Exchange gelöscht werden. Ab diesem Zeitpunkt besteht die abgekapselte Test-Domäne dann aus einem virtuellen PDC und einem virtuellen Memberserver (oder ist Dein Exchange auch BDC?), auf den der Exchange geschubst wird. Und diesen Memberserver bitte vom Namen, von der IP, von der Exchange-Organisation, vom Service Pack-Stand usw. her exakt so aufbauen, wie es beim "echten" Exchange der Fall ist. Dann bekommt man auch die Datenbanken eingepatcht...(nachdem man sie vom PDC rübergeschubst hat, wo sie ja kurz geparkt wurden, da der ja als BDC noch Verbindung zur echten Domäne hatte, bevor die Testumgebung abgekapselt wurde) Später kannst Du dann auch noch einen virtuellen Client und sonstwas dranhängen, alles was man so zum Testen braucht... Hat das die Frage beantwortet ? - Ich hoffe :D Grüsse schroeder750

Moin mikelx, als ich gestern abend so über unseren Thread hier nachsinniert habe (hab ja nix anderes zu tun...) kam mir da noch ein Gedanke, den ich Dir als Tip geben möchte. Oftmals ist es ja so, daß man in der Theorie alles plant und dann in der Praxis sieht, daß die echten, gewachsenen Systeme die Theorie irgendwie nicht ganz mitmachen wollen... :D Wenn Du eh schon mit einem virtuellen BDC starten willst denk mal zur perfekten Vorübung und Testumgebung über folgendes nach: - Den BDC virtualisieren, wie besprochen. - Wenn der virtualisierte BDC noch in der Echtumgebung hängt, die Exchange-Dienste auf dem Exchange 5.5 beenden und gleich die Exchange-Datenbanken (priv.edb, pub.edb und dir.edb) auf den virtuellen BDC rüberkopieren. - Den virtuellen BDC physikalisch komplett von der produktiven Umgebung trennen. Jetzt hast Du eine wunderbare Spielwiese, in der Du die dicksten Punkte der Migration am "Echtsystem" mal ohne Reue durchziehen kannst... - Hochstufen des BDCs zum PDC. Hier wird es kurz Gemecker geben, daß der PDC nicht erreichbar ist, die Hochstufung wird aber sauber durchgezogen. - Löschen des Computerkontos des PDC und des Exchangeservers in der Testumgebung. - Aufbau einer neuen virtuellen Maschine, exakt dem "echten" Exchange entsprechend. also mit gleichem Namen, gleicher IP, gleicher Servicepackstand usw... - Installation Exchange 5.5 mit gleichen Organisationsangaben / Standortangaben wie in der echten Umgebung. Gleicher Servicepackstand. - Rüberkopieren der aus der produktiven Umgebung abgesaugten Datenbanken des Exchange vom BDC (jetzt ja PDC) auf den neuen virtuellen Exchange. - Einpatchen der original Exchange-Datenbanken im virtuellen Exchange. Hört sich schlimm an, aber da kann ich Dir Tips geben, wie Du innerhalb weniger Minuten alle Datenbanken eingepatcht bekommst, so daß Du wirklich den produktiven Exchange "geklont" hast. - Jetzt hast Du die perfekte Spielwiese, die ziemlich genau Deiner produktiven Umgebzung entspricht. Für den kompletten Aufbau brauchst Du vielleicht einen halben bis einen Tag. Und jetzt kannst Du wirklich professionell in der Testumgebung die Migration sauber durchführen, alles mitprotokollieren, Dir anhand der Erkenntnisse ein sauberes Projektdesign schreiben und Dich darüber freuen, daß Du dann später in der wirklich produktiven Umgebung nur noch Dinge durchführst, die alle schon perfekt getestet wurden. Nimm Dir die Zeit, Du ersparst Dir damit ne Menge Ärger, glaubs mir ... :D Grüsse schroeder750

@lefg ... ist Jana jetzt eher so eine Schwester Rabiata mit Einlauf jeden Tag oder mehr so die wasserstoffblonde, die dem Blutdruck eines Greises wie uns gefährlich werden kann ? Falls letzteres der Fall ist, will ich auch ne Jana ... :D (Wird das von der Kasse bezahlt?) @mikelx Harr, noch haste den ganzen Mist, den ich Dir erzählt habe ja nicht durchgeführt ... :D ich hab schon andere in den Wahnsinn getrieben... :cool: jetzt aber ciao bis morgen !! schroeder750

Ja neee is klaa... harr harr... da werden noch einige Fragen kommen, verlass Dich drauf :) Wir hatten eben von den fsmo-Rollen geredet. Eine davon ist die des PDC-Emulators. Die NT4-Server und Rechner sind in diesem Moment der Meinung, sie würden mit einem NT 5.2 PDC kommunizieren. Die werden perfekt verärmelt ... kann man auch prima im Servermanager unter NT4 sehen... da steht als Version für den W2K3DC NT 5.2... Von da her läuft alles aus NT4-Sicht wie gehabt... natürlich auch für den Exchange. Wenn Du die Domäne upgedatet hast, existieren grundsätzlich mal nur nackte Benutzerkonten. Die bleiben weiterhin über die dir.edb des alten Exchange mit den Postfächern verheiratet. Irgendwann installierst und konfigurierst Du dann den Active Directory Connector. Der stellt grundsätzlich mal die "Autobahn" zur Verfügung, über die die gute alte dir.edb des Exchange 5.5 ihren Inhalt mit dem AD replizieren kann. Dann kommt die Schemenerweiterung für den Exchange 2003. Ab sofort haben die AD-Benutzer auch Exchange-Attribute, die prima mit den Inhalten der dir.edb abgeglichen werden. Damit ist dann der Weg frei für das Verschieben der Postfächer auf den neuen Exchange. Den Benutzermanager vom alten NT4 solltest Du übrigens ab der Migration auf AD nicht mehr benutzen. Das kann nur unschöne Nebeneffekte geben. Versuche nie eine neue Umgebung mit den alten Tools zu verwalten. Ebenso verhält es sich mit dem Exchange-Administrator. Der bietet Dir auch an, die Postfächer auf den neuen Exchange zu verschieben, den er ja durchaus sieht, als Exchange Version 6.5. Sobald Du aber hiermit ein Postfach verschieben willst, wird der alte Exchange-Administrator merken, daß er irgendwie doch nix damit anfangen kann. Dann bekommst Du eine Fehlermeldung. Is aber nich weiter schlimm. Geht halt nur nicht... So, ich muss jetzt gleich noch los zu einem Kunden, kann mich dann morgen wieder um Deine nächsten "letzten" Fragen kümmern ... :D Hö hö. Nur keine Hemmungen, dafür hängen wir ja alle hier ab, irgendwann hilfst Du auch mal wieder Jemandem... Grüsse aus Stuttgart nach München Ciao bis morgen schroeder750

HEY !!! Jetzt danke ich DIR mal !!! Bin eben durch das Geschreibsel für Dich zum Board Veteran geworden... :wink2: Wo sind meine Krücken und meine Asthmatropfen ...

... Bahnhof ?? Das must DU MIR jetzt mal erklären... schnall ich jetzt nicht, was Du damit meinst... Grüsse schroeder750

In der Managementkonsole, Snap-In "Active Directory Standorte und Dienste" unter "Sites" => "Standardname des ersten Standortes" => "Servers" gibt es unter den jeweiligen Servern einen Eintrag "Ntds-settings". Hier kann in den Eigenschaten ein Haken bei "globaler Katalog" gesetzt oder entfernt werden. Den Haken beim neuen DC setzen und beim alten rausnehmen... dann sauber replizieren lassen (evtl. antriggern mit dem replmon). ... wäre mir neu, dann hätten mir aber schon einige Migrationen sowas von vor die Wand laufen müssen ... :D :D Nööööö, habbich sooo nich gesagt. Nööö !!! Lüüüüüge !!! :p :p :p Ich habe gesagt: "Postfächer über die Managementkonsole eines W2K3 DCs mit Exchange System-Manager auf den neuen Exchange verschieben." Hmmmm..... wenn ich das jetzt so lese ... hmmm... is ja irgendwie schon misserständlich ausgedrückt .... :shock: O.K. O.K ich lasse mit mir handeln und drücke das mal anders aus ;) Du benötigst eine Managementkonsole eines DCs, auf dem auch der Exchange-System-Manager installiert ist. Oder Du öffnest einfach eine Managementkonsole auf dem neuen Exchangeserver mit dem Snap-In "AD Users and Computers". Rechtsklick auf den jeweiligen User => Exchange-Aufgaben => Postfach verschieben. Hier kannst Du auch x User auf einmal schnappen und deren Postfächer verschieben, seit Exchange 2003 kannst Du das auch schedulen... z.B. Nachts laufen lassen, während Du zu Hause vor dem Fernseher liegst... und Talkshows siehst :D Eine Menge der Exchange-Verwaltung ist jetzt vom ehemaligen Exchange-Administrator NICHT in den System-Manager, sondern in die Konsole gewandert. Der neue Exchange ist ja im Vergleich zum alten nur noch ein Datengrab, die Intelligenz liegt ja jetzt mehr im AD... Alles klar ? Grüsse schroeder750

O.K. das läuft natürlich echt auf ne Grundsatzfrage hinaus... kann ich nachvollziehen. Hauptsache erstmal ein Job nach der Insolvenz und dann geht einem so langsam ein Licht auf, wo das hingeht... auch DAS kann ich nachvollziehen. Lass Dich in dieser Firma nicht "verziehen". Die Arbeitsweise Deiner alten Firma klingt da wesentlich sympathischer... Dann halt am Besten jetzt einfach mal die Füsse still und lass Cheffe machen. Wenn er das so haben möchte, O.K.... Kannst ja dann aushelfen, wenn der Nullpunkt erreicht ist... Bei so einer kleinen Umgebung kann man ja recht geschmeidig die Nutzdaten wegsichern, den ganzen Krempel neu aufbauen und dann die Nutzdaten wieder einspielen... Und wenn eh keine 350 User hintendranstehen, die arbeiten wollen, ist das ja auch recht entspannt... Mich wundert es nur, daß Ihr bei der kleinen Umgebung nicht einfach einen SBS da stehen habt und den regelmäßig sauber sichert. Würde doch allemale tun... Tscha, Ohren steif halten, wenn noch was ist, meld Dich einfach, O.K ? :) Grüsse schroeder750

Das SOLLTEST Du sogar tun. Die upgedatete Kiste lasse ich bei einer InPlace-Migration auf keinen Fall in der Domäne. Aber: VORSICHT !! Der upgedatete DC hält in diesem Moment alle fsmo-Rollen und den globalen Katalog. Wenn der weitere W2K3 DC drin ist, sollten mit "ntdsutil" alle fsmo-Rollen auf den neuen rübergeschoben werden. Anschließend auf den neuen DC eine Kopie des globalen Katalogs legen und die Kopie des GC vom upgedateten entfernen. Und GANZ WICHTIG: Den upgedateten DC sauber mit "dcpromo" wieder herabstufen. Der verschwindet dann automatisch wieder in seiner Eigenschaft als DC aus dem AD. NICHT einfach abschalten. Dann werden die verbleibenden DCs in alle Ewigkeit versuchen, mit einem Zombie zu replizieren... Knackiges Thema, in das Du Dich auch in Ruhe einlesen solltest. Generell: - Active Directory Connector installieren und konfigurieren - Neuen Exchange 2K3 in die gleiche Organisation installieren wie den 5.5er - Öffentliche Ordner replizieren - Postfächer über die Managementkonsole eines W2K3 DCs mit Exchange System-Manager auf den neuen Exchange verschieben. - Replikation der öffentlichen Ordner vom 5.5er entfernen - 5.5er sauber vor den Augen des Ex2K3 deinstallieren. Das war jetzt nur in ganz groben Zügen. Wenn Du das richtig machst, wird kein User beeinträchtigt und Du kannst im Laufe des Tages sanft migrieren... Für genauere Infos einfach nachfragen oder mal die Bordsuche benutzen, hatte ich mich schon des Öfteren drüber ausgelassen :D Grüsse und viel Erfolg !!!!! Wenn was unklar ist, nachfragen !! Schroeder750

Das sind Dinge, die Du später in Ruhe klären kannst. :) Setz Dich hin, nimm einen Kaffe und mach Dir in Ruhe Gedanken, wie Du später das richten kannst, was Cheffe gerade versaubeutelt ... Wenn Du DAS dann wieder hingebogen bekommst, ist das doch die optimale Ausgangsposition für ein Gespräch, wie es denn ab jetzt mit der Administration weitergehen soll, oder ? - Man wächst mit seinen Aufgaben. - Glaubs mir ... Wenn Du da durch bist und Cheffe immer noch nicht einsichtig ist, kannste Dir in Ruhe Gedanken über oben beschriebene Alternativen machen, O.K ? :D Frag nach, ob es ältere Sicherungen vom AD gibt. Gezogen zu einem Zeitpunkt, als es die Schemenerweiterung und den W2K3 DC noch nicht gab. Ich habs im Urin, daß Ihr die brauchen werdet... Wenn Du die hast, dann fährst Du den W2K3 DC runter und spielst im Wiederherstellungsmodus die alte Sicherung auf den W2K DC zurück. Dann habt ihr zumindest mal wieder ne laufende Umgebung... und der W2K3 DC ist auch Geschichte... Mach das aber nicht, ohne vorher zumindest eine Sicherung der systemstates beider bestehender DCs zu machen... Und wenn Ihr so weit kommt, ist erstmal Kaffepause und Besprechung mit SAUBERER Planung angesagt, bevor irgendwer die Kisten wieder anfasst... Es kann doch momentan kein User so richtig arbeiten, oder ? Wieviele User habt Ihr ? Grüsse schroeder750

kein Problem, dafür gibt es ja das Bord. Sofort aufhören mit Rotwerden !!! :D Mach Dich bitte nur richtig schlau, bevor Du mit der Geschichte anfängst. Gerade bei der InPlace-Migration schraubst Du live an der produktiven Domäne rum. Bitte auf der Zunge zergehen lassen... :suspect: Also: Die NT4-Domäne hat einen NETBIOS-Namen, beispielsweise "FIRMA". Bei einer AD-Struktur gibt es auch den NETBIOS-Namen, zusätzlich dazu aber noch den fqdn, den Full Qualified Domain Name oder auch Full Qualified DNS Name. Man hört beides... Der würde dann z.b. "firma.de" lauten. Wenn Du den dcpromo auf einem nackten Server ausführst und eine neue Domäne erstellst, wirst Du zuerst nach dem fqdn und dann nach dem Netbios-Namen gefragt. Wenn Du allerdings ein InPlace-Upgrade durchführst, ist der NETBIOS-Name der Domäne ja schon da... es wird also nur noch nach dem fqdn gefragt... Damit alles sauber passt, erstellt man vorher die DNS-Zonen (Forward- und Reverse), wobei die Forward-Lookupzone als Name den fqdn der geplanten Domäne haben sollte, also z.B. "firma.de" Des weiteren vergibt man dem W2K3-Server vor dem dcpromo als primäres DNS-Suffix (Arbeitsplatz, rechte Maustaste, Eigenschaften, Computername, weitere...) den fqdn der geplanten Domäne. Der heißt dann danach komplett z.B. "DC1.firma.de". Beim NT4 BDC muss das VOR dem Update in den Eigenschaften der Netzwerkverbindung angegeben werden: Eigenschaften vom TCP/IP => DNS. Hier als "Host-Name" den Namen des Rechners angeben und als "Domäne" den geplanten fqdn der neuen Domäne, also wieder "firma.de". Dieser Eintrag ist der, den Du nach dem Update auf den W2K3-Server bei den Eigenschaften vom Arbeitsplatz wie oben beschrieben wiederfindest. Wenn der nicht passt, läuft der dcpromo nicht. Während des Updatevorganges kann der aber auf dem "fast fertigen" und noch im Updateprozess befindlichen W2K3-Server nicht geändert werden... Also VORHER im NT4 richtig einstellen... und zwar auf den geplanten fqdn der neuen AD-Struktur. Irgendwie klar geworden ? :D Nit janz einfach ohne Bilderchen ... :D :D Grüsse schroeder750

DAS ist aber die klassische InPlace-Migration... klar geht das so. Du übernimmst allerdings alle Einstellungen und somit auch Leichen (verbogene Policies, sonstige Fehlkonfigurationen) in die neue Domäne. Wenn das kein Problem darstellt, daß Du dabei keinen Reinigungsprozess hast, keine Einwände... Nicht können, MÜSSEN... :D Für eine AD-Struktur benötigst Du einen sauber laufenden DNS. Achte darauf, daß der DNS-Suffix in den Netzwerkeinstellungen des BDCs, den Du updaten willst, exakt so lautet, wie der fqdn der neuen Domäne lauten soll. Wenn Du das Update auf 2003 einmal angefangen hast, kannst Du das nicht mehr ändern. Wenn Du den BDC (der ja dann schon zum PDC hochgestuft sein muss) upgedatet hast, ploppt nach dem neustart ein Assistent hoch, der krampfhaft das AD erstellen will. Brich den ab, richte in Ruhe manuell das DNS ein und gib per Hand den dcpromo ein... Wenn alle NT4 BDCs raus sind, die Domäne in den W2K3 native mode geschaltet ist und Du das tool "rendom" nimmst: JA. habe das allerdings noch nie gemacht. Wenn ich einen anderen Domänennamen brauche, führe ich normalerweise eine saubere Parallelmigration durch ... hope, this helps... Grüsse schroeder750

... übrigens, die Domäne wird doch wohl schon ein Weilchen bestehen, oder ? Da muss es doch irgend eine ältere Sicherung des AD geben vom W2KDC... Manchmal ist es besser, auf den Stand von vor x Monaten zurückzugehen und die paar neu angelegten User wieder manuell neu anzulegen. Ihr müsst aus der Nummer rauskommen ... Grüsse schroeder750

... ich kann das nachvollziehen, ist aber jetzt echt wurst, mach Dich locker, Ihr habt ein größeres Problem. Die Boxhandschuhe könnt Ihr nach der Problemlösung anziehen... :D Danach WIRD Dein Chef zu Gesprächen bereit sein, glaubs mir ... ist jetzt an Dir, zu zeigen, daß Du auch bereit bist, seine Fehler mit auszubügeln. Mach ein bisschen die Bremse rein und jetzt ja keine Hektikreaktionen... ... ist mir zu ungenau. WAS genau haben wir auf der Sicherung? Welcher Stand des AD war da ? Ich nehme an, AD war bereits auf das 2003er Schema erweitert ? War da der W2K3 DC schon drin ? Hast Du bei der Sicherung auch einzeln den Systemstate gezogen ? Oder ist das eine Komplettsicherung mit einer Backuplösung, die auch open files mitsichert ? Ist das eine Art Ghost-Image ? Grüsse schroeder750

Vergiss das erstmal... machen wir uns Gedanken drüber, wenn es wieder eine saubere Domäne gibt, in die es lohnt, einen weiteren DC reinzuhängen, O.K ? Grüsse schroeder750

... ach Du meine Fresse... ups ´schuldigung... Hey, schau, daß Du gesichert bekommst, was geht, und hört mit dem Rumbasteln auf. Zuerst mal Glückwunsch an Deinen Chef. Sicherung nicht erfolgreich und trotzdem grundlegende Einschnitte in der produktiven Umgebung durchführen... geil !!! Sorry, solche Firmen sind mir die liebsten Kunden, da kann man dann Stunden ohne Ende plockern und wird so richtig reich dabei :cool: Gibt es auch keine ältere Sicherung des AD ? Schaut, daß Ihr a) einen systemstate von beiden DCs zieht b) Komplett-Images der beiden Server vom jetzigen Zustand zieht (dann habt Ihr freie Bahn, um willenlos testen und konfigurieren zu können) c) den W2K3 Server aus der Domäne rausbekommt !! Und dann hofft, daß sich das mit der Ganke und Schubert-Software wieder einpendeln wird. Gibt es da vom Hersteller eine klare Aussage, ob die SW nicht auf einem 2003er SERVER läuft oder hat die ein Problem mit dem 2003er AD ? Frag da bitte genauer nach, damit Du im worst case dagegen steuern kannst. Ganz ehrlich ? Ich sehe Euch schon da sitzen und die Domäne neu aufbauen... :eek: Habt Ihr dieses Wochenende schon was vor ? - Jetzt wahrscheinlich: JA... Wenn es an den neuen policy-Einstellungen liegt, die der W2K3 DC reingebracht hat, dann sind die definitiv da und können nur noch per Hand wieder nachgeregelt werden, wenn es keine alte Sicherung gibt... Wow wow wow, drücke Euch die Daumen !!! Grüsse schroeder750

Moin, ich würde die alte Richtlinie so lassen, wie sie ist und zusätzlich eine neue erstellen. Danach dann darauf achten, daß die neuen mailadressen als Hauptadressen eingetragen werden, weil die User dann mit der neuen versenden... Grüsse schroeder750

Moin moin, ... ich glaub, daß es jetzt losgeht, brauchst Dich hier nicht zu verteidigen... ;) ... wenn Du das alles auf die leichte Schulter nehmen würdest, hättest Du am Anfang dieses Threads nich so rumgeflucht :D :D :D . manchmal sind die äusseren Umstände einfach besch... Du bist doch gerade dabei, Dich reinzubeissen, oder ? ... immer schön cremig bleiben, deswegen tümmeln wir uns doch hier, oder ? ich würde jetzt mal folgende Vorgehensweise vorschlagen: Du versuchst, den neuen DC wieder mit dem dcpromo sauber aus dem AD zu nehmen, wie schon besprochen. Sollte dies NICHT sauber funktionieren, müssen wir ihn halt abschalten und manuell mit Tools wie "ldp.exe" oder ähnlichem aus dem AD beim verbleibenden W2K DC schnippeln... einfach Meldung machen, was daraus geworden ist. Wir müssen den Ursprungszustand wieder herstellen und von da aus sauber den W2K3 DC wieder reinbringen... Hast Du für den Notfall VOR der Aktualisierung des AD-Schemas einen systemstate des vorherigen Stands gezogen ? Danach baust Du den W2K3-Server sauber neu auf und wir bringen das Dingen zusammen sauber ins AD, O.K ? Hast Du Dich schon mal schlau gemacht über Dinge wie fsmo-Rollen, Globaler Katalog usw. ? Ntdsutil zum Verschieben der fsmos schon mal angesehen ? Diese Dinge solltest Du beherrschen, sonst wird das nix mit neuem DC und Rollen rüberschubsen. Falls nicht, frag einfach, O.K ? Grüsse schroeder750

Ach ja, falls Du Interesse hast, haben wir da noch folgenden Thread offen: http://www.mcseboard.de/showthread.php?t=73004 Vielleicht schaust Du da mal rein. Der ist ein wenig ins Stocken geraten, den könnten wir aber gerne reaktivieren und weiterführen ... ;) Grüsse schroeder750

Moin Mikelx, Eine Parallelmigration ist ein recht komplexer Vorgang, es ist daher nicht ganz so einfach, ohne genauere Informationen eine allgemeingültige Antwort rauszuschütteln :D Hier mal ein paar Ansätze: Du hast ja zwischen den beiden Domänen eine Vertrauensstellung aufgebaut. Sobald diese Vertrauensstellung steht, die User / Gruppen sauber migriert wurden (incl. SID-History) und die Gruppen der Domänen gegenseitig sauber verschachtelt sind, können sich die Clients ja sowieso in beiden Domänen anmelden. Da muss beim Start nur die andere Domäne angeklickt werden. Irgendwann wirst Du Dir dann die Arbeit machen müssen, die Clients in die neue Domäne zu bringen, weil Du die alte ja dann irgendwann mal abschalten willst. Hierzu würde ich persönlich nicht diesen Computermigrationsassistent des ADMT empfehlen, versuch es da evtl. mal mit dem "netdom" (gibt es auch Threads hier im Board zu). Z.B den hier: http://www.mcseboard.de/showthread.php?t=75857 Wenn Du einen Exchange im Einsatz hast und auch diesen migrierst, ist es meiner Erfahrung nach empfehlenswert, zuerst die Benutzer in der neuen Domäne arbeiten zu lassen, bevor auf dem neuen Exchange gearbeitet wird. Hier kann es sonst mit den NT4-Usern auf dem neuen Exchange 2K oder 2K3 zu Berechtigungsproblemen kommen. Ein Beispiel wäre das hier: http://www.mcseboard.de/showthread.php?t=72035 Wenn Du irgend eine Instanz dazwischen hast, die sauber routet, kein Problem. Musst halt immer drauf achten, daß ein Client beispielsweise mit der IP 192.168.10.x auch auf einen Server der neuen Domäne mit beispielsweise 172.16.35.x zugreifen kann. Ich würde für die Zeit der Migration evtl. auch darauf achten, daß der alte und der neue WINS und DNS-Server abgeglichen werden... Grüsse schroeder750

Is die Dauer der Leases evtl. auf eine sehr sehr kleinen Wert eingestellt ? Grüsse schroeder750

Moin ginka, die Frage ist doch eher, warum die beiden die gleiche IP-Adresse haben, oder ? :D Aus dem DNS kannst Du einen der beiden natürlich problemlos rauslöschen, nur sobald der wieder im netz ist, wird er sich (DDNS vorausgesetzt) dort wieder eintragen. Haben die Dinger mit Absicht beide die gleiche IP ? Weil immer nur einer der beiden hochgefahren wird ? Oder verstehe ich hier irgendwas völlig verkehrt ? :D Grüsse schroeder750