schroeder750

Auch wenn ich hier später als Nervensäge verpöhnt werde, muss ich doch noch mal etwas nachfragen :D Exchange 5.5 Server ohne Domäne ? Hab ich da was verpasst ? Is mir irgendwie nie gelungen... Auf welche Benutzerkonten hast Du denn dann die Postfächer des Exchange 5.5 festgenagelt ... Rätsel ...Irgendwie bin ich jetzt gerade leicht irritiert ... Ansonsten kann ich momentan Guenther nur zustimmen und evtl. noch eine kleine Ergänzung: Der Server sollte als DNS-suffix noch den Domänennamen dranhaben... Grüsse schroeder750

Hy FragHunter, ääähhh... zement mal... Du schreibst "Nun geht es wieder"... heißt das, daß auch der Dienst "MS Exchange Verzeichnis" wieder startet ? Falls dies der Fall sein sollte, hast Du definitiv eine dir.edb... ansonsten startet dieser Dienst unmöglich ... Schau in disem Fall bitte mal auf den anderen Platten / Partitionen nach, ob da nicht irgendwo noch ein Verzeichnis \Exchsrvr\dsadata rumfliegt... Die dir.edb liegt im dsadata, nicht im mdbdata, wie die pub und die priv ... Grüsse schroeder750

Hy Angus, sei doch so gut und erläutere mir nochmal genauer, in welcher Beziehung der alte Exchange 5.5 zu dieser AD-Domäne steht. Du schreibst, Du hast einen AD-Benutzer angelegt mit Exchange-Postfach. Ist das jetzt ein Postfach auf dem alten Exchange 5.5, also hast Du im Exchange 5.5 explizit ein Postfach erstellt und hier als primären Windows-Account das AD-Konto angegeben oder hast Du über die Exchange-Aufgaben in der Managementkonsole ein Postfach auf diesem neuen Exchange 2003 erstellen lassen ? Ist schon wichtig, ich muss die Beziehung zwischen Deinen Exchangeservern, den Benutzern und dem AD gepeilt haben, um Dir richtige Auskünfte geben zu können. Ist der alte Exchange(5.5)server ein Memberserver der AD-Struktur oder ist das ein Server einer andern Domäne ? Am besten mal einfach in kurzen Stichworten schreiben, was VOR der Implementierung der AD-Struktur da war und was dann genau gemacht wurde...ich möchte Dir gerne helfen, nur ist mir das momentan noch zu schwammig ... :D Grüsse schroeder750

Hy hy, ich glaube, wir können uns die Hand reichen... schau mal bitte in diesen Thread rein: http://www.mcseboard.de/showthread.php?t=72035 Ich arbeite gerade an einem sehr sehr ähnlichen Problem... Aber bei Dir hätte ich evtl. einen Ansatz: Du schreibst, daß Du auf dem neuen Server ein neues Benutzerkonto erstellt hast... ich blicke da momentan nicht so ganz durch... Habt Ihr eine Parallelmigration der Domänen gemacht ? Normalerweise geht man dann doch her und schaufelt mittels ADMT die Benutzer samt SID-History (und um die geht es mir gerade) rüber. Anschließend "verheiratet" man den alten und den neuen Exchange in einer Organisation, kann die öffentlichen Ordner replizieren lassen (warum hier pfmigrate?) und kann dann in Ruhe die Postfächer von alt nach neu moven... Ich denke, wenn Ihr händisch einen neuen Benutzer angelegt habt, hat der doch mit dem alten Benutzer (der zwar gleich heißt, aber ein neuer User ist) nicht viel zu tun. Da können die Berechtigungen doch nicht passen, oder steh ich da jetzt komplett auf dem Schlauch ? Erzähl mal bitte ein bisschen was darüber, wie Ihr den neuen Exchange aufgebaut habt und vor allem, ob es mit einer Domänenmigration zusammen gelaufen ist... Evtl. sollten wir beide in den nächsten Tagen immer in beide Threads reinschauen, wir haben irgendwie die gleiche Problematik ... :D Grüsse schroeder750

Hy Leute, ich werde morgen wieder beim Kunden sein und die hier bisher besprochenen Tips probieren. Die Outlook-Versionen sind gemischt (größere Umgebung), aber der Tip mit dem Problem beim Outllok 2000 ist sehr gut ... ich glaube, mich zu erinnern, daß auf sämtlichen Kisten, mit denen wir gestestet haben, Outlook 2000 war... is natürlich toll, wenn ich an den Servern sonstwas teste und es liegt an den Clients... :mad: Werde mal drauf achten, ein Outlook XP oder eine andere Version zu nehmen und es auch damit zu testen. Was aber leider immer noch nicht erklärt, warum die User auf dem neuen Exchange nicht sauber die Berechtigungen auf die alten Ordner haben... Bei den bisher durchgezogenen Migrationen hat es mit den Berechtigungen nie Probleme gegeben, daher habe ich dies kleine Outlook 2000-Problem wohl nie bemerkt ... Ich habe morgen eine Spätschicht angesetzt und werde den alten Exchange 5.5 mal ganz aus dem Rennen nehmen, damit ich definitiv weiß, daß nur auf den 2003er zugegriffen wird. Werde alles berichten, O.K ? Danke schonmal für die Zwischenmeldungen. Und weiterhin: Wer irgend etwas zu sagen hat, auch wenn es nur entfernt damit zu tun hat, ich bin über jede Info dankbar !!! :D Grüsse schroeder750

Wo genau sitzt Ihr als Administratoren eigentlich ? Gibt es einen eigenen Standort für Euch oder sitzt Ihr räumlich in einer der beiden Domänen ? Wäre ja sinnvoll, wenn Ihr später oben in der Root Domain hockt und die andere AG als childdomain drunter hängt, mit eigenem DC, DNS und vor allem GC... Grüsse schroeder750

Hy arpma, Du brauchst die neue Root Domain nicht unbedingt, es würde sich aber anbieten... Wird ja eine klassische Parallelmigration werden, nehme ich mal an... Mal ganz grob, die Möglichkeiten: Neue Forest Root Domain aufbauen, DNS hier natürlich implementiert. Domäne A schnappen, das klassische InPlace-Update durchziehen und dabei die Domäne als Childdomäne unter die Forest Root Domain hängen. In der Childdomäne kannst Du natürlich einen weiteren DNS-Server aufbauen, der als Forwarder den DNS der FRD eingetragen hat. Das gleiche dann mit Domäne B. Empfehlen würde ich aber eine klassische Parallelmigration: Forest Root Domain aufbauen, Childdomain drunterhängen, Trust zur alten NT 4-Domäne aufbauen und die User und Gruppen über ADMT in die Childdomain rüberholen. Denkbar wäre auch eine einzige Forrest Root Domain, in die Du via Parallelmigration beide alten NT4-Domänen holst und diese da als OU-Strukturen abbildest. Dann hättest Du als Endresultat eine einzige große Domäne... Möglich ist da einiges, kommt auf Eure Umgebung an und das, was Ihr administrativ machen wollt. Grüsse schroeder750

Hy Uschcom, Zu den OSTs kann ich Dir jetzt nicht viel sagen, aber das Hauptproblem dürfte doch sein, daß trotz Löschen von Elementen aus der priv1.edb diese Datenbank immer noch an der 16 GB-Grenze kratzt, oder ? Meiner Meinung nach bringt da eine Offline Defragmentierung Abhilfe ... In einer Dos-Box ins Exchange-Verzeichnis wechseln, hier ins Unterverzeichnis \BIN und von da aus den Befehl "eseutil /d mit dem Pfad zur priv1.edb" absetzen, nachdem die Bereitsstellung des Informationsspeichers aufgehoben wurde. Also etwa so: " eseutil /d c:\Programme\exchsrvr\mdbdata\priv1.edb " Dauert dann ein Weilchen, aber die Offlinedefrag lässt ne Menge Luft aus der Datenbank ... Wenn es geht, evtl. vorher noch ne Sicherungskopie der DB anlegen ... trau schau wem ... :cool: Hoffe, ich konnte Dir helfen Grüsse schroeder750

Hy subby, von wegen einmischen, ich bitte darum !! :D Ist immer prima, wenn jemand dazukommt, der noch andere Ideen hat... Der Hinweis mit dem Image ist absolut legitim, problematisch wird es aber leider in jedem Fall, wenn irgendetwas Richtung dcpromo durchgeführt wurde. Dann kannst Du das Image zurückspielen, wie Du willst... Der verbleibende DC hat dann in seiner Kopie des AD gespeichert, daß der aus dem AD entfernte DC nicht mehr da ist. Fährst Du den vom Image gesicherten wieder hoch, hat der niedrigere USNs als der verbleibende, der ja alles live mitbekommen hat und wird gezwungen, die AD-Version des verbleibenden zu übernehmen. Er wird also Quasi gezwungen, sich selbst wieder aus dem AD rauszureplizieren... Wobei das schon kaum noch passieren wird, weil er ja vom anderen DC keine Replikate mehr bekommen wird... er ist ja für den verbleibenden nicht mehr da ... (Das wird ja fast philosophisch hier ...) Sinnvoll ist es aber in jedem Fall, wenn zusätztlich zum Image des Rechners, an dem man rumschrauben will, ein Systemstate ALLER DCs gezogen wird, um im Zweifelsfalle das gesamte AD auf den Stand vor dem dcpromo zurückbringen zu können. Hier muss man dann alle DCs gleichzeitig im Wiederherstellungsmodus starten und das AD auf allen gleichzeitig zurückbügeln... Von da her prima Einwand !! Sei bitte so gut und bleib bei uns, ich denke, IxxZett wird evtl. noch Spass bekommen und ein wenig Unterstützung brauchen... ;) Grüsse schroeder750

Autsch... Auf beiden Servern Exchange ist natürlich nicht sonderlich lustig... Beide Exchange in der gleichen Organisation und der gleichen Site / Routinggruppe nehme ich mal an, oder ? Standard oder Enterprise ? Ist es möglich, alle Benutzer auf den verbleibenden Exchange zu moven ? Genug Platz ? Ist ja nur vorrübergehend, bis der zweite (der mit dem jetzigen Fehler) wieder neu aufgebaut ist ... Die User auf dem Exchange mit dem Schuss können sauber arbeiten ? Oder gibt es hier Meldungen von den Usern, das etwas nicht funktioniert ? Natürlich ist der drohende Aufwand, Exchange- UND DC-mäßig alles verschieben zu müssen ein Ansporn, es doch erst einmal mit einer wie auch immer gearteten Reparatur zu versuchen. Ich sag Dir nur ganz ehrlich, wie ich arbeiten würde: ich hätte einfach ein mieses Gefühl, auf Dauer mit so einem reparierten Exchange/DC weiterzuarbeiten... mag Leute geben, die das anders sehen, mein Bauchgefühl würde mir trotzdem sagen: Neuinstallation... Schreib mal bitte ein bisschen was genaueres über die Umgebung, damit wir uns evtl. Gedanken machen können, wie der Rechner am Besten neu aufgesetzt werden kann. Bei guter Planung ist das eine Arbeit von Freitag bis Samstag abend ... Ich will Dich jetzt aber zu nix überreden, nur auf den worst case vorbereiten, O.K ? Grüsse schroeder750

Das sollte seit Exchange 2000 eigentlich besser sein. Beim Exchange 5.5 musste man von Zeit zu Zeit die "Luft rauslassen", d.h. die Datenbanken defragmentieren. Hierzu wurden die Dienste beendet und der Befehl "eseutil /d" aus dem Unterverzeichnis "Bin" des Exchangeservers ausgeführt. Beim Exchange ab 2000 sollte das mit der normalerweise implementierten Onlinedeframentierung von selber laufen, tut es aber in der Praxis (jedenfalls das was ich bisher gesehen habe) nicht immer sauber. Im Zweifelsfalle also von Zeit zu Zeit mal offline mit der Hand defragmentieren ... Grüsse schroeder750

Hy @ all, falls mal jemand über ein ähnliches Problem stolpert, hier ein Zwischenstand: Habe eben GuentherH mit einer PN gemartert und werde auf Grund seiner Hilfe mal folgendes versuchen: Exchange System-Manager: Rechter Mausklick auf den betroffenen neuen Server, Eigenschaften, "Verweise auf öffentliche Ordner". Hier umstellen auf "Benutzerdefinierte Liste verwenden" und keinen weiteren Server angeben. Das müsste eigentlich dazu führen, daß nur dieser Server für die öffentlichen Ordner hergenommen wird. Mal sehen, ob das funzt, wenn ich es in den nächsten Tagen in der Kundenumgebung teste, werde Bescheid geben... Bin trotzdem über jede weitere Äusserung dankbar. Müssen keine perfekten Lösungen sein, wirre Gedanken reichen mir auch schon... ich muss da irgendwie weiterkommen... Grüsse schroeder750

Zitat: "Auf dem alten Server läuft im Moment noch der Kalender mit Exchange 5.5." Eben, genau darum geht es mir ja :D Ist dieser Server Mitglied der Domäne, also ein Memberserver mit NT4 der in dieser Domäne seine Benutzerkonten hat ? Oder stellt dieser alte Server seine eigene Domäne dar, ist also zusätzlich noch PDC einer Domäne, die mit der neuen AD-Struktur eigentlich nichts zu tun hat ? :D :D :D Lass Dir nicht alles aus der Nase ziehen :D :D :D Wenn man das nämlich von vorne herein richtig anstellt, kann man die öffentlichen Ordner ganz locker vom alten auf den neuen Exchange replizieren lassen. Aber ich denke, egal wie die Umgebung auch ist, Du kommst jetzt erstmal klar, oder ? ;) Viel Erfolg !!! Grüsse schroeder750

Ähhh... wie jetzt ? :p Das Exchange-Profil erstellst Du an der Workstation im Outlook, wie ich es unten erklärt habe. Ich denke eher, Du meinst, wie Du für einen Benutzer ein Postfach erstellst, damit er sich überhaupt am Exchange via Outlook anmelden kann, oder ? NT4 / Exchange 5.5: Exchange 5.5 Administrator starten => im linken Fenster unter dem Standort auf "Empfänger" klicken => Datei => Neues Postfach. Hier dann die benötigten Daten eingeben und ein primäres Windows NT-Konto für dieses Postfach angeben (bestehendes Benutzerkonto in der Domäne). Danach mit genau diesem Benutzer an einer Workstation anmelden und oben beschriebenes Exchange-Profil erstellen. Achte drauf, daß dieser User den kompletten Zugriff auf den öffentlichen Ordner hat, den Du exportieren willst. AD / Exchange 2K oder 2K3: Auf dem Exchangeserver eine Managementkonsole öffnen mit dem Plugin "Active Directory Benutzer und Computer". Hier auf einen Benutzer mit der rechten Maustaste klicken, "Exchange-Aufgaben" auswählen und ein neues Postfach erstellen. Danach an die Workstation springen und das gleiche durchführen (Exchange-Profil fürs Outlook) wie oben beschrieben. Sei doch so gut und erklär mir evtl. nochmal genauer, wie Deine Umgebung jetzt aussieht (NT4 Domäne oder AD-Struktur ? / Exchange 5.5 und Exchange 2003 ? / Beide Exchange in einer Organisation ? oder Exchange 5.5 und Exchange 2003 auf zwei einzelnen Rechnern incl. Domänencontrollern, aber voneinander abgekapselt ? ) Dann kann ich Dir besser helfen... Ich steig da bisher nich ganz durch ... :D Grüsse Schroeder750

Auf einem Client mit der rechten Maustaste auf das Outlook-Symbol auf dem Desktop klicken, Eigenschaften auswählen. Danach ein Profil für einen Exchange Server konfigurieren, hier den Namen des Exchangeservers und den des Users angeben. Der User muss natürlich ein Postfach haben, klar... Alternativ: Start => Einstellungen => Systemsteuerung => Mail Hier kannst u auch ein Exchange-Profil erstellen... Bei Fragen hierzu einfach nachfragen... Dann Outlook starten, den öffentlichen Ordner markieren, aus dem Du exportieren wilst und aus dem Menu "Datei" => "Importieren/Exportieren" auswählen. => Exportieren in eine Datei => Persönlicher Ordner (*.pst) nochmal nachsehen, ob der richtige Ordner genommen wurde, evtl. Unterordner mit einbeziehen, Pfad für die PST-Datei angeben und los geht das... Danach mit dem gleichen Client an den neuen Exchangeserver connecten (Das Exchange-Profil auf den neuen Server ändern) und den gleichen Vorgang, nur diesmal importieren... Wenn was unklar ist, frag nach, O.K ? Grüsse schroeder750

Hm ? Ich schnaggel hier gar nix mehr... Exchange 5.5 ? Erster Beitrag ? Egal !! Die öffentlichen Ordner beim Exchange liegen in einer Datenbank namens pub.edb bzw. pub1.edb. Exportieren am besten, indem man sich mit einem Outlook an den Exchange connected und die jeweiligen Daten aus dem öffentlichen Ordner in eine *.pst-Datei exportiert (am besten lokal auf dem Client liegen lassen). Import danach in den neuen Exchange, indem man das gleiche am neuen Exchange nur umgekehrt macht. Also mit einem Outlook connecten, den jeweiligen öffentlichen Ordner öffnen und aus der lokal auf der Workstation liegenden Pst die Daten reinimportiert. Grüsse schroeder750

Moin moin, werde auch mal ein wenig Senf dazugeben, weil ich dieses Problem des öfteren bei Kunden hatte. Wenn der Exchange "nackt" installiert wurde, jedoch mit gleichem Rechnernamen, in der gleichen Domäne und mit gleicher Exchange-Org und Exchange-Standort, ist meine Vorgehensweise immer folgende: Wenn dem Exchange ein NT4 Server zu Grunde liegt, sollte zuerst die dir.edb getauscht werden. NIE alle DBs gleichzeitig austauschen, das führt zu Inkonsistenzen. - Dir.edb (original, also leer) wegsichern, die alte dir.edb unterjubeln. - MS Exchange-Verzeichnis-Dienst wird nicht starten, da die dir.edb nicht passt. - Beim Versuch des Startens werden neue log-Dateien erzeugt, die die nächsten Vorgänge behindern. Also muss die dir.edb sauber eingepatcht werden. Dies geht mit "isinteg -patch" jedoch nur, wenn der Dienst "MS Exchange Verzeichnis" gestartet ist. Und da beisst sich die Katze in den Schwanz ... Aaaaalso: - Versuchen, den Dienst MS Exchange Verzeichnis zu starten. - Während der Dienst "anstartet" den "isinteg -patch" in einer Dos-Box ausführen (ruhig mehrmals versuchen, der Dienst versucht ein Weilchen zu starten, da ist Zeit für 2 - 3 Patchvorgänge...) - Gleichzeitig immer wieder die entsehenden log-Dateien weglöschen. - Diesen Vorgang immer und immer wieder ausführen, bis die Meldung erscheint "Your Information store has successfully been updated". Ist ein wenig Alchemie und Geduld ist auch gefragt, aber ich habe wirklich auf diese Art und Weise schon mindestens 10 Exchange-Server wieder zum Laufen bekommen. Danach die Priv.edb austauschen, Verzeichnisdienst ist ja nun gestartet, wieder den "isinteg -patch" ausführen. Danach dürfte sich dann auch der Information store starten lassen. Gleicher Vorgang wieder bei der pub.edb. Information store natürlich vorher wieder beenden. Die originalen priv und pub vorher bitte wegkopieren, falls mal was schiefgeht... Wenn dem Exchange 5.5 ein W2K-Server zu Grunde liegt, reicht es im Normalfall aus, die dir.edb einfach zu tauschen, der Verzeichnisdienst lässt sich dann eigentlich starten. Hier aber dann als nächstes die pub.edb einpatchen und dann erst die priv... die pub ist meistens schwieriger... Sind so Erfahrungswerte... Bei Problemen einfach wieder nachfragen, O.K ? Grüsse schroeder750

Moin liebe Kollegen, habe da ein recht diffiziles Problem in einer Kundenumgebung und wäre wirklich froh über jeden Tip, der mich irgendwie in die richtige Richtung schubsen könnte. Ich leg mal einfach los: Domäne A: alte NT4-Domäne incl. Exchange 5.5 Domäne B: neue W2K3 AD-Struktur incl. Exchange 2003 Beide Domänen wurden über einen Trust verbunden, die klassische Parallelmigration halt, wie ich sie schon x mal bei Kunden ohne Probleme durchgeführt habe. Das heißt für den Exchange: Active Directory Connector konfiguriert, Verbindungsvereinbarungen etc. neuen Exchange in die gleiche Organisation gebracht wie den alten, öffentliche Ordner repliziert, Userpostfächer lassen sich absolut problemlos auf den neuen Exchange verschieben, die öffentlichen Ordner incl. Berechtigungen werden sauber repliziert... Nun habe ich festgestellt, daß Benutzer, deren Postfächer auf den neuen Exchangeserver verschoben werden, bei der Anmeldung am Exchange auf die öffentlichen Ordner des alten Exchangeservers zugreifen. Auf dem neuen Exchange ist beim Privaten Informationsspeicher eingestellt, daß der zugehörige öffentliche Informationsspeicher der des neuen Exchangeservers ist, was aber irgendwie ignoriert wird... Wäre weiter nicht schlimm, problematisch ist es aber, da die Benutzer des neuen Exchangeservers keinen sauberen Zugriff auf den öffentlichen Informationsspeicher des alten Exchange haben. Da werden Ordner z.B. nur angezeigt, wenn für alle Benutzer ein Haken bei "sichtbar" gemacht wird. Obwohl der User explizit als Besitzer angegeben ist, kann er den Ordner dann nur sehen und nicht sauber drauf zugreifen. Mache ich den Haken "sichtbar" für "jeder" weg, sehen die Leute die Ordner nicht, obwohl sie Besitzer sind... Ich brauche jetzt Unterstützung für folgende Fragen: - Warum funktioniert der Zugriff von den neuen Exchange-Usern auf die alten öffentlichen Ordner nicht sauber ? oder - Warum nehmen die Benutzer des neuen Exchangeservers nicht dessen öffentliche Ordner, obwohl es am Exchange 2003 so angegeben ist ? Die Benutzer wurden ohne Probleme incl. SID-History und Passwörtern migriert. Einziger Unterschied, den ich zu bisherigen Umgebungen, wo es funktioniert hat, feststellen konnte: SP1 für W2K3 ist auf den DCs installiert, SP1 für den Exchange 2003 ist installiert... Kann das daran liegen ? Irgendwelche Erfahrungen ? Leute, ich brauche hier echt Hilfe, habe seit Tagen hin und her getestet, ich komm nicht drauf ... Wenn noch Infos benötigt werden, einfach fragen, O.K ? Danke Euch schonmal im Voraus !!!!!!!! Grüsse schroeder750

Hy, Freigabe ist das, was klassisch im Netzwerk unter Netzwerkumgebung angezeigt wird. Sicherheitseinstellungen beziehen sich auf die NTFS-Berechtigungen auf der Platte. Beispiel: Du gibst einen Ordner frei für alle Benutzer. Dann kann potentiell jeder drauf zugreifen. Gibst Du aber über die Sicherheitseinstellungen an, daß nur die Gruppe "Vertrieb" drauf Zugriff hat, werden alle Anderen den Ordner in der Netzwerkumgebung zwar sehen können, bekommen aber beim Draufklicken auf die Finger gehauen... Ich richte es bei meinen Kunden eigentlich immer so ein, daß die Freigaben für Alle Vollzugriff haben, die NTFS-Berechtigungen dann aber zuschnüren. Hat den Vorteil, daß man Beispielsweise bei einer Fileservermigration auf neue Hardware die Daten mittels xcopy incl. der NTFS-Berechtigungen kopieren kann und dann ein einfaches Script drüberlaufen lässt, welches die Freigaben erneut setzt. Wenn Du Dir mal einen Fileserver denkst, der ein neues Betriebssystem bekommt, die Daten auf der D-Platte aber liegen bleiben, dann sind durch die Neuinstallation des Betriebssystems die Freigaben weg, die NTFS-Berechtigungen aber noch da... Ääähhmmm...Halbwegs verständlich ? :D Grüsse schroeder750 EDIT: O.K. O.K. ich war wieder zu lahm beim Schreiben, war schon lange gelaufen ... sollte mal öfter meinen Browser aktualisieren... ;)

Zieh aber vorher einen systemstate von allen DCs ... besser is das ... :D

... sorry, hatte gerade Besprechung, daher erst jetzt die Antwort... Die 4 GB müssten eigentlich reichen. Danke an The_brayn für die Links, ich hätte jetzt alles wieder alles manuell geschrieben ... keuch ... Falls Du die Artikel nicht durchkramen willst, hier die Ultra-Kurzform: Managementkonsole auf dem W2K DC: Unterm Active Directory Schema-Plugin nachsehen, ob der Haken gesetzt ist, daß auf diesem DC das Schema geändert werden kann. In den W2K DC die W2K3 CD einlegen und aus dem Unterverzeichnis I386 den Befehl "adprep /forestprep" absetzen. (W2K SP2 oder höher muss installiert sein). Danach den Befehl "adprep /domainprep" absetzen. Ergebnisse prüfen. Das war´s eigentlich im Groben ... Viel Erfolg !! schroeder750

Moin moin, wenn das Schema unter W2K von einem Exchange 2K erweitert wurde, entstehen Probleme beim Update des Schemas auf W2K3-AD. Ganz einfach, weil das Schemaupdate des W2K3-Servers Attribute vorfindet, mit denen es nichts anfangen kann. Man muss in diesem Fall das bereits durch den Exchange 2K "aufgebohrte" Schema vorbereiten. Der KB-Artikel dazu ist folgender: http://support.microsoft.com/default.aspx?scid=kb;en-us;314649 Grüsse schroeder750

Ich kann Wolke2K4 nur zustimmen... Ein Update des PDCs auf W2K funktioniert eher, der upgedatete PDC sollte auf Dauer eh nicht weiterleben, es sollte dann ein endgültiger, sauber aufgesetzter W2K3 DC ins AD gebracht werden, der endgültig alle Rollen übernimmt. Da ist der Zwischenschritt über das W2K eh nur temporär... Denk aber dran, wenn Du den PDC auf W2K upgedatet hast, daß Du anschließend in diesen DC die W2K3 Server CD einlegst und das Schema auf W2K3-AD erweiterst, sonst bekommst Du den 2003er-DC nicht rein... Der "temporäre" W2K-DC sollte ausreichend Platz auf der Platte haben, da sich das AD beim Update auf 2003 ganz schön aufbläht. So um die 4 GB sollten da reichen... Ansonsten wie Wolke 2K4 schon sagte, Boardsuche bemühen. Steht schon ne Menge drin... Wenn Probleme auftauchen gib Bescheid, O.K ? Grüsse schroeder750

Hy Dansen, Herzlich willkommen an Board :D Frage: Ist der Server DC ? Was tümmelt sich sonst noch so auf dem Server ? Greifen die User ganz normal darauf zu, um Programme (Office etc.) über die Terminalsession zu starten ? Schon mal drüber nachgedacht, den Server evtl. einfach parallel neu aufzusetzen ? Im Allerdümmsten Falle: Image des originalen Servers ziehen, Image auf die neue Hardware zurückspielen, starten und sehen, was passiert. Bekommst Du einen Bluescreen, W2K-Server-CD rein und schauen, ob Du über den Reparaturmodus oder über drüberinstallieren was hinbekommst... Um genaueres sagen zu können, sollten wir mehr Infos haben. Wenn es nur darum geht, ein Office, evtl. ein paar Daten und vielleicht noch einen Acrobat Reader und ein Winzip zur Verfügung zu stellen, bist Du mit ner Neuinstallation schneller dran, oder ? Grüsse schroeder750

Wow, das is ja wirklich recht merkwürdig ... ich würde jetzt mal aus dem hohlen Bauch raus tippen, daß der Infrastructure master irgendwie nicht ganz sauber tickt. Der sollte eigentlich dafür zuständig sein, solche Namensänderungen zu replizieren... soweit ich mich erinnere, war da aber in der Formulierung zum Infrastructure master die Rede von domänenübergreifend ... hmmm... Anderer Ansatz: Für jede Änderung im AD benötigen die DCs eine neue USN und die werden vom RID-Pool-Master vergeben... wenn die DCs nun keine USNs mehr vom RID-Pool-Master bekommen, könnte das auch zu ähnlichen Effekten führen... Was wieder dagegen spricht, ist, daß ja die Administration Eurer Umgebung ansonsten sauber zu laufen scheint. In den eventlogs der DCs sind keinerlei Probleme zu finden ? Ich würde in diesem Falle mal hergehen und via "ntdsutil" die fsmo-Rollen auf einen anderen DC legen und das ganze nochmal testen. Vielleicht hat ja einfach der DC, der gerade die Rollen hält einen Schuss... dieser Test ist sehr schnell gemacht und kann ganz geschmeidig im laufenden Betrieb vollzogen werden... einen Test ist es allemale wert ... kostet Dich 10 Minuten und Du kannst die fsmo-Rollen als Fehlerquelle ausgrenzen. Oder hast direkt den Schuldigen am Schlawickel... ;) Grüsse schroeder750