schroeder750

Hmmmm... ob der NT4-PDC zum Zeitpunkt des Aufbaus der W2K3-Domäne angeschaltet und erreichbar war oder nicht, ist dem neuen W2K3-DC eigentlich ziemlich egal. Was ich meinte ist, bei einer InPlace-Migration beispielsweise, bemerkt der erste DC, auf dem das AD konfiguriert wird, das in seiner Domäne noch NT4 BDCs vorhanden sind und schaltet dann erstmal in den mixed mode. Wenn er beim Aufbau der AD-Strukturen keine vorhandenen Controller für seine Domäne vorfindet ( Und das sagst Du ihm ja beim erstellen der neuen Strukturen, daß er der erste Controller für eine neue Gesamtstruktur ist), gibt es keinen Grund, noch in den mixed mode zu gehen... die rein physikalische Verbindung zu irgend einem NT4-PDC interessiert dabei nicht... Aber glaub mir, das hat mit dem Trust nix zu tun. Ich habe schon mehrere Domänen so migriert. Du kannst zwischen einer NT4-Domäne und einer W2K / W2K3-Domäne im native mode ohne Probleme trusts aufbauen ... Mir fiel gerade ein, daß ich eigentlich immer in der neuen Domäne das gleiche Administratorpassword vergeben habe, wie in der alten Domäne ... vielleicht hat es bei mir daher immer problemlos funktioniert... teste das doch mal... Ich habe gerade erst Unterlagen für eine Schulung, die ich gehalten habe, erstellt und habe diese neben mir liegen... Finde aber irgendwie keinen Hinweis ... Im W2k3-AD-Snap-In Domänen und Vertrauensstellungen => Eigenschaften der Domäne => Vertrauensstellungen => Neue Vertrauensstellung => Assistent erscheint => NETBIOS-Name der NT4-Domäne eingeben => Bidirektional => Domänenweite Authentifizierung => Kennwort eingeben (und merken) => Wechseln zur NT4-Domäne => Trust hinzufügen, (NetBIOS)Name der W2K3-Domäne eingeben, gleiches Passwort eingeben => Bestätigen lassen und es funktioniert... Bist Du so vorgegangen ? Kann ich leider momentan auch nicht wesentlich mehr zu sagen... Wenn Du das mit dem Trust hinbekommen hast, denk bitte dran, daß der SID-Filter noch ausgeschaltet werden muss, sonst bekommst Du keine SID-History rüber ... Am W2K3 DC in der Eingabeaufforderung: "netdom trust w2k3dom /domain:nt4dom /quarantine:No /usero:administrator /passwordo:password Für die entsprechenden Parameter (w2k3dom, nt4dom, password) natürlich Deine "echten" Parameter einsetzen... Sorry, wenn ich da jetzt zu Deinem Trust auch keine Idee mehr habe ... Trotzdem noch viel Erfolg !!! Grüsse schroeder750

Hy Jochen, das Schalten der Domäne in den native mode ( hier windows 2000 Pur ) ist eine Einbahnstrasse. Da ist nix mit zurück in den mixed mode. Wenn eine W2K3 Domäne standardmäßig aufgebaut wird, ohne irgendwelche NT4 BDCs drin, kommt die automatisch im Win2000 pur-modus hoch ... Das hat aber mit Deinem Trust nix zu tun... Kannst Du vom PDC der NT4-Domäne auf den W2K3-DC pingen und umgekehrt ? Schlimmstenfalls für die Zeit der Migration, bis die NT4-Domäne endgültig vom Kabel genommen wird, auf die beiden Netzwerkkarten der Server zusätzliche IPs aus den gleichen Ranges festnageln... Alternative wäre eine Eintrag des W2K3-DCs in der lmhosts des NT4 PDCs und eine Eintrag des NT4 PDCs im DNS der W2K3-Domäne ... Wenn die Dinger sich physikalisch anpingen können, müsste der Trust dann auch funktionieren... Viel Glück !! schroeder750

Zur zeitlichen Planung und den Outlook-Clients: Wenn ein Postfach auf einen anderen Exchangeserver verschoben wird, wird das im Outlook automatisch bei der nächsten Anmeldung eingetragen und bleibt auch drin. Es muss aber der alte Exchange solange stehen bleiben, bis sich auch das letzte Outlook einmal an ihm angemeldet hat, damit er die Umleitung auf den neuen Exchangeserver an den Client weitergeben konnte. Wenn man den alten Exchange auf einem BDC hat, ist es natürlich pfiffig, das Ganze an einem Wochenende durchzuziehen. Ich nenne jetzt mal den alten Exchange 5.5-Server EXOLD und den temporären EXTEMP. Wenn man jetzt Freitag abend anfängt, den EXTEMP aufzubauen, die Postfächer zu verschieben und den EXOLD aus dem Netzt nimmt, ist der Name und die IP vom EXOLD wieder frei. Wenn man jetzt übers Wochenende den Exchange 2003 mit gleichem Namen (EXOLD) und der gleichen IP aufbaut, und fix die Daten wieder auf ihn verschiebt, bemerkt keiner der Clients am Montag morgen irgendetwas davon. Der Server ist zwar dann ein Exchange 2003-Server, aber der Client findet unter dem gleichen Namen wieder seinen Exchange... Ist auch ganz praktisch für die Internet Mail Connectoren. Da muss dann an der Firewall oder am AV-Gateway nix geschraubt werden. Die IP vom alten Exchange hat der neue ja wieder ... Der AV-Gateway muss dann halt nur für die Übergangszeit die Mails puffern... Soooo, das war die ganze Geschichte im Ultra-Kurz-Abriss. Wenn Fragen auftauchen sollten, einfach nachfragen, O.K ? Ist ein Haufen Geschreibsel, aber vielleicht hilft Dir ja diese Komplettzusammenfassung um zu sehen, wo es bei Dir noch hakt ... Grüße schroeder750

Mahlzeit !! Ich schalte mich jetzt hier mal ein, da ich schon einge Exchange migriert habe. Ich gehe jetzt mal folgendermaßen vor: Um evtl. Tips oder Anregungen zu geben, rattere ich jetzt mal die Vorgehensweise runter, nach der ich immer vorgehe, mit der eigentlich keine Probleme auftauchen, O.K ? Also: Zuerst die Domänenmigration. Wenn der Domänenname erhalten bleiben soll, sollte man zunächst mal über eine InPlace-Migration nachdenken. Parallel ginge auch, wäre aber umständlicher. InPlace-Migration der Domäne aber bitte nur, wenn Du bei der alten Domäne ein gutes Gefühl hast, d.h., wenn da nicht mit policies oder ähnlichem einiges verbogen ist. Nach der Migration der Domäne ist dann der Exchange dran. Hierbei bitte folgendes beachten: Bevor der Exchange migriert wird, muss sich die Domäne im native mode befinden. Ineinander verschachtelte Verteilerlisten aus dem Exchange 5.5 werden nämlich in der neuen AD-Struktur zu ineinander verschachtelten Gruppen und das müssen dann universelle Gruppen sein. Und universelle Gruppen gibt es eben nur im native mode. Native mode ist natürlich nicht möglich, wenn man InPlace migriert hat und noch NT4 BDCs in der Domäne hat. Es müssen also erst alle BDCs aus der Domäne entfernt werden. Wenn der alte Exchange natürlich auf einem BDC läuft, entsteht hier ein Problem. Man kann den BDC nicht entfernen, weil der Exchange drauf läuft, man kann die Domäne nicht in den native mode schalten, weil noch ein BDC da ist und man kann den Exchange nicht migrieren, weil das AD noch nicht im native mode ist... Wenn ich das richtig gesehen habe, läuft Dein Exchange ja momentan auf dem PDC, der nach der InPlace-Migration ja nun mal leider BDC ist ... Lösung: zweiten Exchange 5.5 auf einem Memberserver aufziehen (gleiche Organisation, gleicher Standort), User und öffentliche Ordner auf den neuen Exchange verschieben ( wird dann bei den Outlooks automatisch eingetragen). Den alten Exchange 5.5 auf dem BDC dann vor den Augen des zweiten Exchange auf dem Memberserver deinstallieren, damit die Rollen wie Routing Calculation Master, Scedule Free+Busy und Offline Adressbook auf den verbleibenden Exchange verschoben werden. Danach kann dann der BDC aus der Domäne entfernt werden, alle weiteren BDCs natürlich auch. Und ab mit der Domäne in den native mode... Als nächtes darauf achten, daß der Account, mit dem man die Daten über den adc rüberschieben will, auf dem alten Exchange 5.5 die richtigen Berechtigungen hat. Das wären Administratorberechtigung auf der Organisation, dem Standort, und dem Konfigurationscontainer. (Das wäre die Fehlermeldung) Danach bitte kontrollieren, ob beim Exchange 5.5 eventuell mehrere Postfächer auf einen Account genagelt sind (NTDS NoMatch Utility). Ist dies der Fall, führt es zu unschönen Ergebnissen... Jetzt den active directory connector aufbauen und die Informationen zu den öffentlichen Ordnern und den Postfächern rüberholen ins AD. Der active directory connector macht zwar schon eine Schemenerweiterung, ich habe jedoch die Erfahrung gemacht, daß es besser ist, das Setup vom Exchange 2003 vorher mit den Parametern /domainprep und /forestprep auszuführen, bevor der Exchange 2003 dann installiert wird. Dann den Exchange 2003 installieren, über diesen dämlichen Wizzard vom adc nochmal alles gegenchecken lassen ( Verbindungsvereinbarungen, LDAP-Port usw.) sonst geht nämlich gar nichts... Danach kontrollieren, ob die öffentlichen Ordner sauber rüberrepliziert wurden. Anschließend können dan von der AD-Seite her die Postfächer verschoben werden. Dies geht nicht mit dem Exchange 5.5 Administrator... (MMC, Snap-In AD-Users + Computers, rechter Mausklick auf den benutzer, Exchange-Aufgaben, Postfach verschieben) Anschließend wieder den alten Exchangeserver vor den Augen des neuen deinstallieren, damit auch hier wieder die Hauptrollen auf den verbleibenden Server verschoben werden. Sonst ist nachher nix mehr mit Besprechungsanfragen mit Übersicht der Kalender der Kollegen oder mit Offline Adressbuch ... Sorry, Nachricht wird hier zu lang, mache in der nächsten Box weiter ...

Moin zusamm, habe mal nur ne kurze Frage, ob jemand damit schon Erfahrung gemacht hat: Ich muss einen Exchange 5.5 Server auf Windows 2000 als BS-Plattform clustern. SAN usw. ist alles sauber angeschlossen, der Cluster läuft auch einwandfrei. Der einzige Unterschied, der mir zum Exchange 2000 / 2003 Cluster aufgefallen ist: Wenn ich den Exchange 5.5-Server installieren will, bietet mir die erste Node, auf der ich installiere, nur das gemeinsame externe Laufwerk für die Installation an. Das da später die Exchange Datenbanken und Logs liegen sollen, ist ja klar, aber das eigentliche Programmverzeichnis wird ja beim Exchange 2000/2003 definitiv lokal auf die einzelnen Nodes gelegt... Diese Option bekomme ich beim Exchange 5.5-Setup nicht. Ist eigentlich kein Beinbruch, dann liegt das Programmverzeichnis halt auf der externen Platte (in diesem Fall auf der SAN). Aber gibt es da evtl. doch einen Weg, den Exchange 5.5 jeweils auf die lokalen Platten der Nodes zu installieren ? Grüsse schroeder750

Wie wäre es mit dem guten alten MS Dos 6.irgendwas ? Hatte das schon mal getestet. Funzt wunderbar. Im zweifelsfalle kann man da die Kiste sogar von einer Bootdiskette hochziehen. Im einfachsten Falle mit dem guten alten NT4-Server die Setupdisketten für die Clientinstallation (Netzwerkbootdisketten) erstellen und diese dann entsprechend frieieren ... Grüsse schroeder750

Hy zusammen, kriege hier gerade ein Hörnchen... vielleicht kann mir jemand weiterhelfen: Habe eine Testumgebung (Unter VMWare, aber egal) laufen, in der ich von einer NT4-Domäne mit Exchange 5.5-Server via Parallelmigration auf W2k3 AD und Exchange 2003 will... Alle Server sind Servicepackmäßig auf dem neuesten Stand. Der Windows NT4 PDC ist gleichzeitig der Exchange 5.5-Server (Exchange 5.5 SP4). Habe die neue Domäne (W2K3) parallel aufgebaut. Danach folgende Schritte: - Konfiguration beidseitiger Trust, funktionstüchtig - Deaktivierung des SID-Filters - Vergabe der Berechtigungen ( Administratoren der einen Domäne sind auch Admins der anderen Domäne und umgekehrt, das gleiche bei den Benutzern) - ADMT konfiguriert - Lokale Gruppe NT4DOM$$$ erstellt - Auditing eingeschaltet - Registrywert "TcpipClientSupport" am PDC auf "1" gesetzt - Administrative Freigaben überprüft - 128 Bit-Verschlüsselung mit dem neuesten IE installiert - Encryption Key erstellt - Password Migration Server auf dem NT4BDC installiert - Registryänderung am BDC vorgenommen (AllowPasswordExport=1") - Berechtigungen Benutzer "Jeder" gesetzt - Komplexitätsvorraussetzungen für Kennwörter im W2K3-AD deaktiviert - W2K3-Domäne in den "Windows 2000 pur"-Modus geschaltet (native mode) - Active Directory Connector auf dem W2K3 DC installiert (ohne Probleme) - Verbindungsvereinbarung für Postfächer, benutzerdefinierte Empfänger und Verteilerlisten (vorerst von Exchange zu Windows) konfiguriert - Verbindungsvereinbarung für öffentliche Ordner konfiguriert - Benutzer mittels ADMT problemlos rübermigriert ( Ineinander verschachtelte Verteiler wurden zu ineinanderverschachtelten globalen Gruppen, funktionierte alles wunderbar) - "Anonyme Anmeldung" in die Gruppe "Prä-Windows 2000-Kompatibler Zugriff" gebracht - Berechtigungen für den W2K3-Administrator, unter dem der Exchange 2003 installiert wird, auf den Exchange 5.5-Server gesetzt (Organisation, Standort, Konfiguration und Server) Und dann der Hammer: Bei der Installation des Exchange 2003-Servers kann ich nur eine neue Organisation erstellen... Wenn ich versuche, mit dem Exchange 2003-Server in die bestehende Exchange 5.5-Organisation beizutreten bekomme ich folgende Fehlermeldung: " Setup kann nicht fortgesetzt werden, da mindestens einer der folgenden Zustände festgestellt wurde: - Fehler: ADC-Tools wurden in Ihrer Organisation nicht ausgeführt." Der ADC WURDE installiert und konfiguriert... ich werd noch bekloppt ;-)) Ich MUSS aber in die bestehende Exchange 5.5-Organisation, da ich ja später die Postfächer samt aller Berechtigungen und pipapo auf den neuen Exchange 2003 moven will... Habe mal die Installation des Exchange 2003-Servers in eine neue Organisation mit gleichem Namen durchgeführt, das bringt mir jedoch genau nichts, weil ich dann keine Benutzerpostfächer vom alten Exchange 5.5 auf den neuen Ex2k3 moven kann... Habe auch schon versucht, den ADC auf dem Exchange 5.5 zu installieren, was natürlich Mumpitz ist, da er sich da direkt beim Setup mit einer Fehlermeldung verabschiedet. Das Ding ist halt für W2K AD geschrieben... Irgendjemand, der sich den goldenen Zonk verdienen will, indem er mir Hinweise geben kann ? ;-) Ich danke Euch schon mal im Vorraus !!

O.k. O.k. O.k. war vielleicht alles teilweise etwas ungenau beschrieben ;) Gehen wir mal der Reihe nach durch: 1) Das mit dem DOS-verfügbaren "USERCOMMENT" wusste ich nicht. Guter Tip, Danke dafür, fürs nächste mal gespeichert !! 2) Das /domain habe ich nicht benutzt, da ich dieses Script beim Kunden auf dem PDC laufen lasse. Da is ja klar, daß er die Domänenbenutzer anfassen muss. Die Info fehlte natürlich, sorry ... 3) Excel scriptet natürlich nicht, ich benutze es nur um meine Scripte schön einfach zu erstellen. Nochmal die Erläuterung in aller Ruhe, was ich treibe: Anforderung vom Kunden: VOR der Umstellung auf W2K / W2K3 müssen Benutzer in der NT4-SAM teilweise umbenannt, teilweise rausgelöscht werden, bei einigen soll einfach nur ein bestimmter Begriff vor der Beschreibung eingefügt werden. Es handelt sich hier um ca. 6000 Benutzer. Des weiteren sollen die zugehörigen Homelaufwerke, Noteslaufwerke natürlich auch umbenannt und unter dem neuen Usernamen freigegeben werden. Um herauszufinden welcher User in welchen Namen umbenannt werden soll und welcher User gelöscht, bzw nur mit einem Begriff markiert wird, haben wir x verschiedene Quellen hinzuziehen müssen. Teilweise auf wildestem Wege, da bei 80% der User jegliche Zuordnung von altem zu neuem Namen fehlte. Da war einiges an manueller Arbeit fällig, um überhaupt mal eine Zuordnung von alten zu neuen Namen usw. herzustellen. Teilweise mussten Listen aus der Personalabteilung manuell im Excel zu den bestehenden Benutzern zugeordnet werden Optimalfall ist natürlich eine Liste, in der links die alten Benutzernamen und rechts die neuen Benutzernamen stehen. Dazu habe ich als allererstes mal Exchange 5.5 genommen, um mir die derzeitige SAM zu exportieren. Da entsteht ja bekanntermaßen eine *.csv-Datei, womit wir auch schon beim Excel wären. Aus der *.csv-Datei alle Infos rausgelöscht, die ich nicht mehr benötige (wen interessiert in dem Zusammenhang der Mailhomeserver ? -> Raus damit ), dann bleibt eine Liste übrig, die zu den jeweiligen bestehenden Benutzern die Anzeigenamen und die Beschreibung beinhaltet. Schön in drei Spalten voneinander getrennt... Jetzt kann man aus den verschiedenen Quellen, die wir anzapfen mussten, die gewünschten späteren Namen rechts in eine Spalte daneben schreiben (oder reinimportieren oder oder oder ...) Die nun nicht benötigten Infos wie Beschreibung und Anzeigename rausschmeissen, dann habe ich in der Tabelle links in einer Spalte den alten und rechts in einer weiteren Spalte den neuen Namen. Nun noch vorne eine Spalte eingefügt, in der einfach in jeder Zeile "renuser" steht. Wenn man das ganze dann als Textdatei speichert, hat man folgenden Inhalt: renuser XXX hmueller renuser xyz pmeier renuser abc fhuber usw... Die Textdatei einfach in eine *.cmd umbenennen, Doppelklick und schon werden die ca. 6000 User automatisiert umbenannt... Man kann es natürlich auch so machen, daß man den Inhalt der Textdatei an ein Script übergibt, aber das ist in diesem Fall nicht notwendig. Die Scripte sind natürlich wunderbar rekursiv zu gestalten, indem man die Spalte mit dem alten und dem neuen namen einfach vertauscht... falls es igendwo Probleme gibt. Das diese Scripte alle in einer Testumgebung (Abgesaugter BDC, alleinstehend zum PDC hochgestuft) sauber durchgetestet werden, versteht sich von selber. Und genauso gehe ich vor, um Homelaufwerke umzubenennen, neue Shares zu vergeben und und und ... Ich benutze Excel halt, weil man da ruckzuck vor eine 6000 Zeilen lange Kolonne von Benutzernamen den passenden Befehl eingefügt hat. Alles Klaro ? Puh, meine Tastatur qualmt... Nichts desto trotz, tausend Dank nochmal an alle, die hier geholfen haben !!!! Ciao schroeder750

Hy Leute, habe das Problem gelöst... Zuallererst aber mal ein gaaaanz liebes dankeschön für Eure Bemühungen. Himbidas: Lass gut sein, steck keine Arbeit mehr rein. Echt supernett von Dir, daß Du schon anfangen wolltest zu scripten !!! Die Lösung ist echt banal: Man darf weder im NT4 noch im W2K den von MS vorgegebenen Begriff "USERCOMMENT" benutzen, sondern einfach nur "COMMENT". Ist zwar so nicht dokumentiert, aber wir haben selbst ein wenig rumprobiert. Nochmal ganz einfach zur Erläuterung: Der Befehl net user mueller /COMMENT:"Blabla" führt dazu, daß beim Benutzer der Kommentar "Blabla" eingefügt wird. Das ganze mit /USERCOMMENT: führt nur zu einer Meldung, die sagt, es wurde erfolgreich durchgeführt, passieren tut aber nix. Habe mir aus dem Exchange eine Liste der SAM erstellt, die im Excel den Usernamen und den Kommentar enthält (Rest rausgelöscht). Dann ein paar Spalten einzufügen, um das "net user" und das "comment" und die Worte, die vor den bestehenden Kommentar eingefügt werden sollen, ist ja kein Problem. Daraus neues Script erstellt und es funzt wunderbar ... O.K. dann mal bis demnächst !! Ciao schroeder750

Hy Leute, zuerst mal vielen lieben Dank für die schnellen Reaktionen. :D Zur Antwort von auer: das Auslesen der alten Beschreibung und das Zusammenbauen des Scriptes ist wirklich das kleinere Problem (da wird kurzerhand ein Exchange 5.5 draufgetüddelt, der exportiert mir das wunderbar, bin da faul). Habe mich schon tierisch über den Parameter /USERCOMMENT gefreut, den ich blöderweise übersehen hatte. Habe das eben gleich mal getestet. NT4 gibt diesen Parameter in der Ausgabe bei "net help user" auch aus. Wenn ich den Befehl absetze, bekomme ich in der DOS-Box auch schön brav gemeldet "Der Befehl wurde erfolgreich ausgeführt", passieren tut jedoch leider ganz genau NICHTS. Die Beschreibung wird nicht geändert :mad: Zur Antwort von himbidas: Hey, supernett von Dir, aber wenn ich ganz ehrlich bin, komme ich nicht gerade aus der Script- und Programmierecke... Kannst Du mir das bitte einfach ein bisschen erläutern ? Ich denke, wir können das sehr verkürzen: Geh bitte dabei davon aus, daß ich die Liste der Benutzernamen, Vollständigen Namen und Beschreibung vorliegen habe. Ich kann das ganze in eine Excel-Tabellelaufen lassen und Befehle einfügen, wie ich lustig bin... Was genau soll ich einfügen ? Du schreibst " ... mit dem zugehörigen net user /domain-Befehl..." genau um DEN geht es mir ... Machen wir ein Beispiel: Vorhanden (mittels Exchange 5.5 rausgesaugt): Mueller Mueller, Thomas Buchhaltungsuser Ich bearbeite mit Excel: net user Mueller /USERCOMMENT:"ausgeschiedener Buchhaltungsuser" So in der Richtung soll es gehen... aber es funktioniert eben nicht... Noch ne Idee ? Danke schonmal !!!! Gruß schroeder750

Hy folks, bin gerade dabei, einen größeren Kunden auf W2K / W2K3 zu migrieren. Jetzt müssen vorher im NT4 noch die Benutzer umbenannt werden. Kein Problem. Man schnappe sich "renuser.exe" und benenne die Benutzer automatisiert mittels Script um. SIDs bleiben gleich, alle Berechtigungen passen, nur der logonname ändert sich halt... soweit so gut. Jetzt gibt es da aber leider auch einige Benutzer ( so um die 500, ca. 10% der Gesamtanzahl ), bei denen der Benutzername und der vollständige Name gleich bleiben muss, hier soll nur hinten bei der Beschreibung ein Wort davorgesetzt werden, um später diese Benutzer anhand der Beschreibung selektieren zu können... Da lässt mich das gute "renuser" natürlich im Stich. Mit "net user /add" kann ich auch nicht arbeiten, um nur die Beschreibung zu überarbeiten, da bekomme ich die Meldung, daß der Benutzer ja bereits existiert ... Benutzer via Script löschen und mit der richtigen Beschreibung wieder neu anlegen wäre fix passiert, führt aber dazu, daß die SIDs nicht mehr passen...wäre fatal... Und 500 User per Hand... naja, kann und will ich dem Kunden nicht anbieten... Jemand ne Idee für mich ? Wie gesagt, spielt sich alles noch vor der eigentlichen Migration in der NT4 SAM ab ... Danke schonmal !! Gruß schroeder750