schroeder750

Genau so ist das gedacht :) Hoffe, Jimmypop lässt was von sich hören und ist nicht schon ausgewandert ... und ich schreib mir hier den Wolf :D Grüsse schroeder750

Hm... bevor ich da ewig rummachen würde, würde ich eher hergehen und den Inhalt des Postfachs in eine *.pst exportieren, das Postfach löschen, eine neues Postfach auf den bestehenden Account anlegen, die Inhalte aus der *.pst wieder reinimportieren und sehen, ob es jetzt funktioniert. Ich denke mal, da hat es was am Postfach zerhagelt. Die Aktion dauert je nach Postfachgröße 20 Minuten, die Fehlersuche dauert sicher erheblich länger ... Wäre so meine erste Vorgehensweise, da es sich ja nur um diesen einen Benutzer handelt ... Nicht vergessen, ihn wieder in die entsprechenden Verteilerlisten aufzunehmen und die Berechtigungen auf seine Ordner zu setzen... Grüsse schroeder750

... stehe da gerade auf dem Schlauch. Beispiel: XP-Client. Habe mir ne MMC geöffnet, SnapIn Richtlinien für den lokalen Computer rangeholt. Durchgehangelt: Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten\Lokal Anmelden. Da werden mir genau die Benutzer angezeigt, die ich ja in der default Domin policy definiert habe, ich kann jedoch nichts hinzufügen, ist ausgegraut. Weder als lokaler Admin noch als Domänenadministrator. Ich teste das gerade hier in einer Testumgebung unter VMWare... Was mache ich falsch ? Und vor allem, selbst wenn ich hier was ändern könnte, kann ich ja nur Benutzer aus einer Domäne hinzufügen und keine lokalen vom Rechner, oder ? Grüsse schroeder750

Und schonmal was zum Weitermachen, evtl. habe ich morgen nicht die Zeit, ständig ins Forum zu schauen: Wenn der DC einen Tag gelaufen ist und die Ereignisanzeige keine abstrusen Fehler meldet kannst Du weitermachen: Start => Ausführen => "mmc" eingeben. In diese Konsole über Datei => "SnapIn hinzufügen oder entfernen" vorerst mal die folgenden SnapIns hinzufügen: - Active Directory Benutzer und Computer - Active Directory Domänen und Vertrauensstellungen - Active Directory Standorte und Dienste - Dienste (lokal) - DNS - Ereignisanzeige - WINS Konsole (MMC) speichern (am besten auf dem Desktop) und schließen. Anschließend über Start => Ausführen folgendes eingeben: Regsvr32.exe %SystemRoot%\System32\schmmgmt.dll Nun die Konsole wieder öffnen und noch das SnapIn "Active Directory Schema" hinzufügen. Konsole speichern. Testen, ob der NT4 PDC vom DC aus via Ping erreichbar ist. Aufbau der Vertrauensstellung: MMC starten, rechte Maustaste auf den Domänennamen unter "Active Directory Domänen und Vertrauensstellungen", Eigenschaften, "Vertrauensstellungen" Hier eine neue Vertrauensstellung aufbauen, zur NT4-Domäne. (Bidirektional, Domänenweite Authentifizierung) Auf der Gegenseite, der NT4-Domäne genau das gleiche machen, hier über den Benutzermanager => Richtlinien => Vertrauensstellungen. Hier das gleiche Passwort benutzen, wie es auf der AD-Seite vergeben wurde. Anschließend Installation der W2K3-Support-Tools von der W2K3-Server CD. (Unterverzeichnis \Support\Tools) auf dem W2K3 DC. SID-Filter ausschalten: W2K3 DC: DOS-Box öffnen, Eingabe: netdom trust firma.de /domain:nt4dom /quarantine:No /usero:Administrator /passwordo:PASSWORT. wobei hier firma.de der Name der AD-Domäne ist und nt4dom der NETBIOS-Name der alten Domäne. Bitte die kleinen "o" hinter password"o" und user"o" nicht vergessen. Ist kein Schreibfehler... Vergabe der Berechtigungen: Es muss die globale Gruppe der Domänen-Admins der NT4-Domäne in die lokale Gruppe der Administratoren der W2K3-Domäne eingefügt werden. Umgekehrt muss auch die globale Gruppe der Domänen-Admins der W2K3-Domäne in die lokale Gruppe der Administratoren der NT4-Domäne eingefügt werden. Ebenso bitte für die Benutzer/Domänen-Benutzer verfahren. Anschließend testen, ob der Trust sauber funktioniert. Mal einfach testen, ob ich auf Verzeichnisse in der alten Domäne Berechtigungen auf User der neuen Domäne vergeben kann. Und dann mal Meldung machen, ob alles funktioniert, O.K ? Grüsse schroeder750

Hy BlackPixel, danke für die fixe Antwort. :D Die alten Domainkonten (ich denke, Du meinst damit die Computerkonten in der alten Domäne, oder ?) sind definitiv nicht mehr existent. Die Rechner wurden sauber aus der alten Domäne genommen, dabei wird ja das Konto in der NT4-Umgebung gelöscht. Anschließend wurden sie aus der Arbeitsgruppe, in der sie sich ja jetzt befanden, sauber in die neue Domäne aufgenommen. Es existiert also für jeden Rechner exakt ein Computerkonto in der neuen Domäne. Die Anmeldung in der neuen Domäne funzt auch problemlos, nur halt die lokale Anmeldung am Client mit dem lokalen Konto wird verboten ... Grüsse schroeder750

Hallo zusammen, Diesmal keine Frage oder ein Hilfegesuch. Mal was neues, oder ? Ich bin durch einen anderen Thread, in dem es um eine Parallelmigration geht, vom Benutzer Jimmypop angesprochen worden zwecks Migration einer kleineren Umgebung von NT4 auf W2K3 AD. Bevor wir das jetzt alles telefonisch oder per Mail durchziehen, haben wir uns eben darauf geeinigt, daß wir hier einen neuen Thread aufmachen, in dem wir die Migration einmal komplett Schritt für Schritt durchgehen. Könnte dem ein oder anderen, der mal drüber stolpert, evtl. mal weiterhelfen. Klar, es gibt bereits einige Threads zu diesem Thema, wir wollen hier aber einfach mal eine komplette Migration durchgehen, um die Infos gesammelt zu haben. Ich hoffe auf eifrige Beteiligung, Wortmeldungen sind jederzeit gerne erwünscht :D O.K. Los geht es: IST-Aufnahme: 1 x NT4 PDC / 1 x NT4 BDC, ca 15 User, ein Exchange 5.5. Es soll, wie gesagt, eine Parallelmigration werden, da vorerst nicht in die produktive Domäne eingegriffen wird, wie bei der InPlace-Migration. Der neue W2K3 Server ist bereits aufgesetzt, jedoch absolut standardmäßig. Dieser Server wird der erste DC der neuen Domäne sein. fqdn für den Server wurde eingegeben (Rechte Maustaste auf den Arbeitsplatz, Eigenschaften, Computername, Ändern, Weitere => Hier den geplanten Namen der neuen Domäne z.B. firma.de eingeben) Der Server wurde in seinen Netzwerkeigenschaften als DNS-Server eingetragen, die Reverse- und die Forward-Lookupzone wurden erstellt. Anschließend "dcpromo" ausgeführt, NETBIOS-Name und fqdn der neuen Domäne eingegeben. Mal auf Rückmeldung von Jimmypop warten, ob soweit alles funktioniert hat.

Help !! Folgende Situation: Parallelmigration, NT4-Domäne auf W2K3 AD. Einige Computer bereits mit Computerkonto ins AD übernommen, der Kunde stellt fest, daß sich die Benutzer aus der NT4-Domäne nun nicht mehr an diesen Rechnern anmelden können, obwohl Trust usw. sauber steht. O.K. Kein Problem. Default Domain Policy geschnappt, unter "Windows-Einstellungen/Sicherheitseinstellungen/LokaleRichtlinien/Zuweisen von Benutzerrechten" die lokale Anmeldung für Benutzer der alten und der neuen Domäne zugelassen. Test: Funktioniert. Prima... Jetzt ruft mich der Kunde eben an und sagt mir, daß er ein paar PCs in der neuen Domäne hat, auf denen lokale Benutzerkonten existieren. Nur leider kann man sich mit diesen Benutzerkonten nicht mehr lokal anmelden... Es erscheint die Meldung, daß eine Richtlinie es verbietet... Auf den PCs hat die lokale Anmeldung noch funktioniert, als diese Mitglied der alten Domäne waren... Und nun ? Ich tappe momentan im Dunkeln, kann mir mal einer nen Schubs in die richtige Richtung geben ? Danke ! Grüsse schroeder750

Wenn Du das AD sichern willst, musst Du den "Systemstatus" oder auch "Systemstate" sichern. NTBackup bietet das an, diverse andere Backuplösungen auch. Wirf es einfach mal auf einem DC an, wirst sehen, daß Du den Punkt angeboten bekommst.... Die Sicherung des systemstate kann bei einem normalen DC mal locker 400 / 500 / 600 MB groß werden. Da werden alle Infos gesichert, die den DC zum DC machen... Grüsse schroeder750

Na, das ist doch mal ne beruhigende Info, daß Du eine Spielwiese hast, um das vorher sauber durchzutesten. Auch von mir viel Erfolg und wenn Fragen auftreten, meld Dich einfach, O.K ? Grüsse schroeder750

Na ja, eine Migration ist natürlich für einen Azubi ne heftige Aktion ... Vor allem eine InPlace-Migration, bei der Du am lebenden Patienten (=Eurer produktiven Umgebung) arbeitest... Nicht falsch verstehen, will Dich als Azubi absolut nicht abwerten, liegt mir fern, aber mach Dich bitte vorher in Ruhe schlau... Der neue DC hält dann u.a. die fsmo-Rolle des PDC-Emulators, spielt also einen NT5.2 PDC. Das machen die Clients problemlos mit. Den upgedateten DC solltest Du wirklich nicht im Netz lassen. Ist so ein Bauchgefühl, das steht dann eine Kiste mit einer durch den Wolf gedrehten registry und soll die Domäne hochhalten ? ... meiner Meinung nach unschön ... Wenn schon InpLace Migration, dann sieh zu,. daß so wenig leichen wie möglich überbleiben. Und achte drauf, daß vor dem Update auf W2K / W2K3 der richtige DNS-Suffix eingetragen ist, sonnst rennt Dir die Kiste beim Update vor die Wand und Du bekommst das AD nicht sauber hin... Der DNS-Suffix in den Eigenschaften der Netzwerkkarte sollte dem späteren fqdn der AD-Struktur entsprechen... Und noch ein Tip: Vergiss den Assistensten, der direkt nach dem Update hochploppt. Brich das Ding ab, bau per Hand ne saubere DNS-Struktur auf und führ den dcpromo per Hand aus...besser is das... Grüsse schroeder750

... und dann noch was zum weiteren Vorgehen: einen NT4 PDC direkt auf W2K3 updaten macht erfahrungsgemäß schon mal Probleme. Da gibt es auch ein paar Infos zu hier im Board. Solltest drüber nachdenken, den PDC zunächst erst zum W2K DC hochzustufen, dann später auf ihm das Schema für W2K3 AD zu erweitern und dann den endgültigen späteren DC auf W2K3 ins AD zu bringen... Die upgedatete Kiste willst Du ja hoffentlich nicht als endgültigen DC behalten... :D Grüsse schroeder750

Moin moin, kurze Frage: Exchange 2003 => Outlook in verschiedenen Versonen (meist 2000): Im Outlook wird unter dem Adressbuch (Extras => Adressbuch) nicht nur die globale Adressliste angezeigt, sondern auch andere Einträge wie "All adress lists", "Alle Benutzer", "Alle Gruppen" usw... Dies stört einen Kunden. Hier sollte nur das globale Adressbuch und evtl. selbst angelegte Outlook-Adressbücher angezeigt werden. Diese Einträge finden sich natürlich im Exchange System Manager wieder (Empfänger/Alle Adresslisten/...). Ich habe testweise in einer Spielumgebung mal im Exchange System Manager die Berechtigung (Über Reiter Sicherheit) für "Autentifizierte Benutzer" und für "Jeder" explizit verweigert, mit dem Resultat, daß ich jetzt selbst im Exchange System Manager als Administrator nicht mehr drankomme :mad: Ist in der Testumgebung nicht weiter schlimm, aber wie kann ich diese Einträge für die Outlooks der Benutzer sauber ausblenden ? Irgendwer eine Idee ? Danke Euch !!! Grüsse schroeder750

Hört sich brauchbar an. Wenn Du nur ne anderere HD in die gleiche HW einbaust, dürfte das funzen. ... und bau Dir mal nen zweiten DC auf... besser is das :D Grüsse schroeder750

... DC mit F8 beim Booten im Wiederherstellungsmodus starten, ntbackup oder die entsprechende Backupsoftware starten und den systemstate zurückbügeln... Wenn Du nur einen DC hast, musst Du eigentlich nichts mit autorisierendem Restore oder ähnliches beachten... Grüsse schroeder750

Hy, Du schreibst, daß Du den neuen DC gleich konfiguriert hast... auch den gleichen Namen des abgerauchten DCs ? Keine Probleme gehabt, den ins AD zu bringen ? Wenn der alte abgeschmiert ist, hattest Du ja keine Chance, den sauber mit "dcpromo" wieder aus dem AD zu nehmen, ergo sind natürlich noch Zombieeinträge für diesen Server im AD... normalerweise bekommst Du dann beim Ausführen des dcpromo auf dem neuinstallierten Server eine Fehlermeldung und bekommst ihn nicht als DC rein... In diesem Fall muss man vorher mit Tools wie "ntdsutil" oder "ldp.exe" die Einträge für den alten DC manuel rausschnippeln... Solltest Du den DC unter anderem Namen neu aufgesetzt haben, sollte Dir klar sein, daß Du zwar physikalisch zwei DCs hast, Dein AD aber der Meinung ist, es wären drei. Deine beiden DCs versuchen also kontinuierlich, mit einem dritten DC, der ja nun nicht existiert, zu kommunizieren und zu replizieren... daß würde ewige Wartezeiten und langsames Ansprechen erklären ... Grüsse schroeder750

Na das sind doch mal klare Aussagen, die selbst ein Nicht-Lizenzguru wie ich versteht :D Ich danke Dir vielmals, hast mir sehr weitergeholfen !!! Wünsche Dir ein schönes Wochenende !! Grüsse schroeder750

@Dr. Melzer: Danke Dir für die schnelle Info !! Ich muss aber ehrlich gestehen, daß ich jetzt entweder auf dem Schlauch stehe, oder vielleicht nicht das Zeug zum Jurastudenten hätte... Die Infos in Deiner Antwort kann ich ja nun auch wieder auslegen, wie ich es will: O.K. der Kunde "entwickelt" und "Testet" ja die Datenbanken auf msdn-Software. Also eigentlich alles im grünen Bereich... Tut der Kunde ja auch nicht. Seine Mitarbeiter greifen nicht im produktiven Umfeld auf die Datenbanken zu. Es wird nur das Endresultat später verkauft. ... und genau da habe ich jetzt ein echtes Verständnisproblem... Tut mir leid, wenn ich so genau nachhake und nerve, aber ich möchte dem Kunden ja nun schon eine definitive Aussage machen... Habe ja oben beschrieben, was der Kunde treibt. Wenn ich Dir jetzt einen Zettel hinlegen würde, auf dem steht: "Handelt der Kunde lizenztechnisch legal ?", würdest Du dan "JA" oder "NEIN" ankreuzen ? :p Ganz ehrlich, mir sind diese Formulierungen einfach zu schwammig. Ich brauche Sicherheit... Klar gibt es im Internet jede Menge Infoseiten zum Gebrauch von msdn-Lizenzen, klar kann ich die komplett durchkämmen und nachher 5 Stunden mit dem Kunden drüber diskutieren, aber habe ich dann ein klares Ja oder Nein ? Eine Aussage, die auch später im Falle eines Falles vor Gericht Bestand hat ? Hilf mir beim Verstehen, Bitte !! :D Grüsse schroeder750

Moin zusammen, mal ne theoretische Frage: Nehmen wir mal an, jemand hat eine kleine Firma, Server und Clients sind alle sauber durchlizenziert. Für W2K SVR, WinXP und Office auf den Clients wurden ganz normle Lizenzen (Open oder teilweise OEM usw...) erworben. Alles im grünen Bereich... Jetzt lebt diese Firma aber davon, Datenbanken zu entwickeln und diese an Kunden zu verkaufen. Kann diese Firma für die ENTWICKLUNG der Datenbanken ohne gegen Lizenzrecht zu verstoßen msdn-Versionen von Microsoft-Programmen benutzen ? Oder müssten hier theoretisch Offizielle Lizenzen erworben werden, da ja eigentlich nicht nur intern getestet und entwickelt wird, sondern dabei ja was produktives rauskommt, was später zum Gewinn der Firma beiträgt ? Ich vergleiche das jetzt mal mit einem Word... wenn ich intern bei uns in der Testumgebung ein bisschen mit einer neuen Word-Version rumteste, um für die neuen Anforderungen im Kundenumfeld später gewappnet zu sein, ist das ja genau der Sinn von msdn. Würde ich jetzt jedoch in der "Testumgebung" mit diesem msdn-Word ein Buch schreiben und dieses dann mit Gewinn verkaufen, nutze ich das msdn-Word doch eigentlich produktiv, oder ? Sorry, echt dämliche Frage, aber ich stecke in der Lizenzgeschichte echt nicht so tief drin... Danke schonmal für Eure Infos ! Grüsse Schroeder750

Moin moin, vielleicht hilft das hier ein wenig weiter, ich mache solche Dinge ganz gerne mit dem Programm ldp.exe aus den Support-Tools: Support Tools auf einem DC installieren. Starten des Programms „ldp.exe“ Auswahl „Connections“ ==> „Connect“ Hier den Servernamen eines DCs eintragen Auswahl „Connections“ ==> „Bind“ Authentifizierung durchführen … Auswahl „View“ ==> „Tree“ „BaseDN“ leer lassen… Anschließend auf folgende Einträge doppelklicken (durchhangeln bis unten): DC=domäne,DC=suffix CN=Configuration, DC=domäne,DC=suffix CN=Services,CN=Configuration, DC=domäne,DC=suffix CN=Services,CN=Configuration, DC=domäne,DC=suffix CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=domäne,DC=suffix CN=Exchange Organisationsname,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=domäne,DC=suffix CN=Administrative Groups,CN=Exchange Organisationsname,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=domäne,DC=suffix CN=Standort,CN=Administrative Groups,CN=Exchange Organisationsname,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=domäne,DC=suffix CN=Servers,CN=Standort,CN=Administrative Groups,CN=Exchange Organisationsname,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=domäne,DC=suffix Hier kann ein eventueller Exchange-Zombie gelöscht werden... Rechte Maustaste, Auswahl „Delete“ Alle drei Haken setzen bei „Extended“, „Synchronous“ und „Recursive (client)“ und das Löschen bestätigen. Unter "DC=domänenname,DC=suffix" => "OU=Domain Controllers,DC=domänenname,DC=suffix" tauchen alle Server auf, die in der OU "Domain Controllers" in der Managementkonsole angezeigt werden. Nur kann ich die Dinger hier mit Gewalt löschen... Interessant ist hier auch: DC=domänenname,DC=suffix => CN=Configuration,DC=domänenname,DC=suffix => CN=Sites,CN=Configuration,DC=domänenname,DC=suffix => CN=Standardname des ersten Standorts,CN=Sites,CN=Configuration,DC=domänenname,DC=suffix => CN=Servers,CN=Standardname des ersten Standorts,CN=Sites,CN=Configuration,DC=domänenname,DC=suffix Hier tauchen die Server auf, die ich über die Managementkonsole unter "Active Directory Standorte und Dienste" sehe, sie aber dort nicht löschen kann. Wenn das alles nicht so ganz genau passt, bitte selber ein wenig suchen, ich habe das gerade aus ein paar alten Threads von mir zusammengebaut... :D Bitte vorsichtig mit dem LDP am AD, O.K ? Notfalls vorher einen systemstate von allen verbleibenden DCs ziehen, um im Falle des Falles alles wieder herstellen zu können... Grüsse schroeder750

... Überleg Dir aber bitte genau, wie Du diese Server ins AD bringst. Wenn da der alte Server als Replikationsleiche drin ist und Du ihn nicht via dcpromo raus nimmst bzw. nicht manuell rauskratzt, werden alle weiteren DCs in alle Ewigkeit versuchen, mit dem Zombie zu kommunizieren... Hmmm... Was brauchst Du zum autarken anmelden ? Einen Global Katalog Server für Clients ab W2K, wenn die Domäne im native mode ist. Und das kann jeder DC sein. DNS kann ja auch jeder DC ohne Probleme übernehmen. Auf dem jeweiligen DNS der Zweigstelle kannst Du ja dann auf den Haupt-DNS in der Hauptdomäne verweisen. Wenn Du allerdings Clients wie Win 98 oder ähnliche Multimediaspielzeuge hast, dann benötigst Du einen PDC-Emulator. Und der steht dann leider nur in der Hauptdomäne, wenn Du in die Aussenstelle "nur" einen weiteren DC der einzigen Domäne stellst... Das wäre dann ein Grund für eine childdomain... Installation der weiteren DCs auf jeden Fall im Hauptstandort und dann die fertigen Rechner in die Zweigstelle rausbringen. Dann warst Du bisher in den falschen Foren :D :D Gerne geschehen... Grüsse schroeder750

@dmetzger ... und genau darüber werde ich die Tage auch mit dem Kunden reden. Habe gerade wieder ein Gespräch mit dem Disti gehabt, wir werden es dem Kunden auch finanziell schmackhaft machen können, die entsprechenden Lizenzen zu kaufen. Er bekommt eh einen neuen Server, jetzt schauen wir mal nach OEM-Lizenzen für diesen Server und dann werde ich die SBS-Geschichte zur Vergangenheit machen ... Da muss eh mal (auch auf Clientseite) sauber durchlizenziert werden, so wie das aussieht ... :D Danke Dir !!! Grüsse schroeder750

O.K. Leute, hier wie versprochen ein Update: - Habe noch einmal bei einem Kunden angerufen, bei dem ich die Migration auf diese Art und Weise durchgezogen hatte und mich rückversichert: Hier war es definitiv so, daß die User sich noch in der alten Domäne angemeldet haben und schon auf die Mailboxen auf dem neuen Exchange zugegriffen haben. Und das über Wochen hinweg. Es gab dort definitiv keine Probleme... hier waren die Berechtigungen auf die öffentlichen Ordner allerdings etwas einfacher gestrickt. - Habe eine Testumgebung unter VMWare aufgebaut und konnte dort wahnwitzigerweise die Zugriffsprobleme von NT4-Benutzern auf die öffentlichen Ordner nachvollziehen, wenn die Postfächer bereits auf den Exchange 2003 verschoben waren ... - Am Service Pack 1 für den Exchange liegt es definitiv nicht, das habe ich in der Testumgebung vorerst weggelassen. - Mit einem Outlook XP habe ich die gleichen Tests durchgeführt, leider mit exakt dem gleichen Ergebnis. Outlook 2000 scheint da also auch nicht der Schuldige zu sein. Trotzdem danke für den Ansatz !!! - Wenn die Benutzer, die Ihr Postfach bereits auf dem neuen Exchange liegen haben, sich an der neuen Domäne anmelden, funktioniert es problemlos. Eine der Prioritäten bei dieser Migration war, so schnell wie möglich vom Exchange 5.5 wegzukommen (Standard Exchange, priv.edb war schon 16 GB), daher wurde die Exchange-Migration zu einem recht frühen Zeitpunkt durchgezogen und die Postfächer verschoben. Wir haben nun den Zeitplan etwas umgestellt und werden schnell dafür sorgen, daß sich die Benutzer halt in der neuen Domäne anmelden. Dabei ist es erst einmal egal, in welcher Domäne das jeweilige Computerkonto ist ... Ist momentan ein Workaraound, der genauso zum Ziel führt, der Kunde ist also erst einmal bestens versorgt. Was mir nur als fader Beigeschmack überbleibt, ist die Tatsache, daß ich schon einige Migrationen genau so durchgezogen habe und es ausgerechnet HIER diese Zugriffsprobleme auf die öffentlichen Ordner gibt. Warum schreibe ich das alles ? Ganz einfach: FAZIT: wer Probleme umgehen will, die evtl. auftauchen KÖNNTEN, sollte VOR dem Verschieben der Postfächer auf den neuen Exchange bei einer Parallelmigration darauf achten, daß sich die Benutzer bereits in der neuen Domäne anmelden... :suspect: Grüsse schroeder750

Hy dmetzger, klare Worte :D Ich danke Dir !!! Hatte, ehrlich gesagt, auch nicht vor, mich auf solche Spielereien einzulassen. Jetzt habe ich noch ein wenig Infos mehr, den Kunden in einer sachlichen Weise zu überzeugen... Prima !! Grüsse schroeder750

Hy Leute, da ploppe ich mich jetzt gleich mal ganz frech dran... :D Habe einen Kunden, der momentan zwei SBS (!) W2K im Einsatz hat. Er bekommt einen neuen Server und will bei dieser Gelegenheit von W2K auf W2K3 umsteigen... Ich habe mit SBS selber noch nicht sonderlich viel zu tun gehabt, bisher immer nur mit "normalen" und Enterprise-Servern Domänen migriert und aufgebaut. War bisher noch nicht bei dem Kunden draussen und werde demnächst das erste Gespräch haben, daher hier mal ein wenig Nachhaken, damit ich Infos habe: - Wenn zwei SBS in der Domäne im Einsatz sind, dann kann doch beim Setup für den zweiten eigentlich nur das Setup für den DC abgebrochen worden sein, oder ? Mir gruselt es vor der Vorstellung, da noch einen dritten Server reinzubringen...womöglich NOCH einen SBS...buuuaaahhh... - Wäre doch wohl besser, bei drei Servern einfach mal reinen Tisch zu machen und drei normale Server aufzusetzen, oder ? Auch wenn die Anzahl der Clients deutlichst unter 75 liegt... - Der Exchange des SBS wurde bisher nicht benutzt, es soll aber jetzt ein Exchange aufgebaut werden. Kann da irgendwas lizenztechnisch upgegradet werden oder müssen wirklich drei neue Serverlizenzen samt 1 x Exchange gekauft werden ? Ich warte da auch noch auf Infos von der Lizenzierungsstelle meines Distris, wenn ich vorher Infos bekomme, werde ich die hier posten. Wäre nett, wenn der ein oder andere mal seinen Senf dazu gibt :wink2: Danke !! Grüsse schroeder750

Hy jimmypop, was Du vorhast (Domäne neu aufsetzen), ist die klassische Parallelmigration. Hier mal Ratzfatz im Ultrakurzabriss zusammengefasst, damit Du Dich anhand der Stichworte mal schlau machen kannst: - Neue W2K3 AD-Struktur parallel zur bestehenden Domäne aufsetzen und gleich in den native mode schalten - Trust zwischen den beiden Domains aufbauen, Verschachteln der gegenseitigen Berechtigungen - Gruppen- und Benutzermigration mittels ADMT, Passwörter und SID-History mitnehmen - Workstations in die neue Domäne aufnehmen, Benutzer in der neuen Domäne anmelden - Schemenerweiterung des neuen AD für den Exchange - Installation Active Directory Connector, Verbindungsvereinbarungen für öffentliche Ordner und Empfängerverbindungsverinbarung - Installation Exchange 2003 in der neuen Domäne in die gleiche Organisation wie den vorhandenen 5.5er - Einrichten der Replikation der öffentlichen Ordner - Verschieben der Postfächer, Verlegen des IMC vom Exchange 5.5 auf den Exchange 2003 (SMTP-Connector) - Verlagern der weiteren Ressourcen (Fileserver usw.) in die neue Domäne - Deinstallation des Exchange 5.5, Exchange-Org in den native mode bringen - Abnabeln der alten Domäne, evtl. Übernahme der alten Server durch Neuinstallation im AD, Aufbau eines zweiten DCs zwecks Redundanz. War jetzt der brutale Kurzabriss, nimm einfach mal die Bordsuche und mach Dich ein bisschen schlau, ist halb so wild... Grüsse schroeder750