schroeder750

Hmmm... hoffentlich kriege ich das jetzt noch richtig zusammen... ich habe bei einem Kunden einmal das AD von W2K auf W2K3 erweitert und habe dann ein paar Tage später einen Anruf bekommen, daß plötzlich die Terminaldienstelizenzen in 30 Tagen auslaufen würden...mach Dich da bitte richtig schlau... Hintergrund ist folgender, sagte mir damals einer unserer Vertriebler, der mit dem Lizenzkram mehr zu tun hatte: MS hat wohl Probleme bekommen, weil im Windows 2000 Professional die Lizenzen für den W2K Terminalserver schon mit drin waren. Das sollte wohl nicht mehr sein von wegen Wettbererbsvorteilen und so... Wenn man dann ein Linux einsetzte, musste man ja extra wieder Lizenzen erwerben, was ja ungerecht ggü. Linux wäre ... Daher wurde es so gehandhabt, daß beim Windows 2003 die TSCals einzeln erworben werden müssen. Jetzt ist es ja so (wenn ich mich recht erinnere), daß beim 2000er Terminalserver irgendein Server der Lizenzserver sein kann. Der 2003er Terminalserver verlangt aber einen DC als Lizenzserver. man schlage mich, wenn das so nicht stimmt, O.K ? :D Wenn ich also einen 2000er Terminalserver habe und die Lizenzierung auf irgend einem 2000er Server liegt, gibt es keine Probleme. Haarig wird das, glaube ich, wenn man einen 2003er Terminalserver einsetzt, weil der nach einem 2003er DC als Lizenzserver schreit und dann komplett neue Lizenzen fällig werden. Ebenso haarig wird es, wenn die Lizenzierungsdienste auf den 2003er DC verlegt werden, auch wenn weiterhin nur ein 2000er Terminalserver im Einsatz ist. Dann werden, glaube ich, auch neue Lizenzen fällig. Das Problem bei meinem Kunden war nämlich damals, daß wir auch die Lizenzierung für die Terminaldienste auf einen 2003er Server verlegt hatten... da waren auch weiterhin erstmal nur 2000er Terminalserver im Einsatz, trotzdem wurden neue Lizenzen fällig... Wer Ahnung von dieser Lizenzierung hat, bitte mal eben bestätigen oder dementieren, O.K ? - Ich bin da nicht mehr soooo sicher... Grüsse schroeder750

Moin 004, ich hoffe, ich habe da jetzt nicht alles komplett falsch verstanden, aber mir fallen dazu folgende Aussagen ein: a) soweit ich weiß, kann mit Outlook-Clients nur auf den ersten, ursprünglichen Öffentlichen Ordner zugegriffen werden. Du kannst zwar weitere öffentliche Ordner (auch in weiteren Speichergruppen) anlegen, diese können jedoch nicht mit dem normalen Outlook-Client betrachtet werden. Habe das beim Exchange 2003 noch nicht hinreichend getestet, beim 2000er war es so, meine ich. Der einzige Sinn für mich, weitere öffentliche Informationsspeicher anzulegen war bisher eigentlich nur der, daß ich dort Inhalte aus Sicherungen wieder hergestellt habe. (Habe mir dazu das Laufwerk M: via Registry wieder sichtbar gemacht und konnte so auf Dateiebene drauf zugreifen...) b) Bei den Eigenschaften eines Informationsspeichers für Postfächer ist irgendwo angegeben, welche öffentliche Ordnerstruktur den Postfächern dieses Informationsspeichers zugeordnet ist. Wenn ich also z.B. 2 Exchangeserver in der Organisation habe und nur Server A hält die öffentlichen Ordner, werde ich als Postfachbenutzer vom Server B die öffentlichen Ordner erst sehen, wenn ich beim Informationsspeicher des Servers B angebe, daß die zugehörige öffentliche Ordnerstruktur die des Servers A ist. Ich hoffe, ich täusche mich da nicht, bin aber der Meinung, es ist so... In Deinem Fall ist es aber nicht allzu sinnvoll, den zusätzlichen öffentlichen Ordner anzugeben, da dieser ja mit einem normalen Outlook nicht eingesehen werden kann. Schau mal in dieser Richtung weiter, ich denke, hier könnte Dein problem liegen... Grüsse schroeder750 Grrrmmmbll.. wer lesen kann ist eindeutig im Vorteil... vergiss das, was ich unter a) geschrieben habe, habe erst jetzt Dein Zitat von weiter oben richtig gelesen... ;)

Harr harr !! Hättest nicht die 30-Tage-Trial Version vom AD nehmen sollen... :D Prima, hat sich das also erledigt ... fragt sich nur, woher diese Replikationsfaulheit kommt ... :suspect: Grüsse schroeder750

Hmmm... steige ich momentan auch nicht so ganz dahinter... Aber mal ein Tip, um momentan beim produktiven Netz etwas den Druck rauszunehmen (diese unverschämten User wollen ja immer an Ihre Daten und lassen uns nicht mal in Ruhe testen :D ): Falls Du in absehbarer Zeit nicht zu einem Ergebnis kommst und den temporären DC aus dem Rennen nehmen kannst, kannst Du (als vorrübergehende Krücke !!) im DNS einen Alias setzen, der den namen des temporären DCs auf die IP des neuen DC auflöst... so schreien die Clients dann nach \\server-temp\Homelaufwerk und landen über die verdrehte DNS-Auflösung auf \\server-neu\Homelaufwerk ... Wie gesagt, ne Krücke, die das Problem nicht löst, Dir aber erstmal für weitere Fehlerdiagnosen die Useranfragen vom Hals halten kann... Grüsse schroeder750

Moin moin, kleine Anmerkung noch: wenn es geplant ist, später einen (oder mehrere) Exchange in der Umgebung einzusetzen, ist es sinnvoll, das Schema so früh wie möglich für den Exchange zu erweiteren. Wenn der Aussenstellen-DC erstmal draussen steht und Du in der Zentrale den Exchange installierst (da steht ja dann sehr wahrscheinlich der Schema-Master), geht ne Replikationswelle in die Aussenstellen los. Kann im laufenden Betrieb nervig sein... Also am Besten zuerst Schema erweiteren, dann den Aussenstellen-DC ins AD bringen und rausstellen. Dann kannst Du später in Ruhe den / die Exchange installieren... Grüsse schroeder750

Moin meit, was ist denn, wenn Du die daten der Profile (kannst ja erstmal bei einem testen) mit Gewalt vom temporären DC auf den endgültigen verschiebst ? Wird dann bei Anmeldung des Useres ein neues Profil angelegt ? Habe da momentan echt ein kleines Verständnisproblem... Im AD steht beim Profilpfad für den jeweiligen User der neue Server drin, die Daten LIEGEN auch auf dem neuen Server und es wird trotzdem auf dem temporären Server ein neues Profil erzeugt ? Sehe ich das richtig ? Grüsse schroeder750

Hallo zusammen, kurze Frage: Hat jemand schon einmal versucht, große Dateien mit ntbackup zu sichern und hat dabei Probleme gehabt ? Hintergrund ist folgender: Ein Kunde hat ein neues System implementiert, hier ist jedoch das backupkonzept nich nicht bis zum Ende durchgeplant, so daß temporär mittels ntbackup gesichert werden soll. Es geht hier nur darum, daß einfach, große Dateien (teilweise größer 50 GB) gesichert werden sollen, ntbackup jedoch hier abbricht. Den genauen Wortlaut der Fehlermeldung habe ich momentan nicht da, den reiche ich noch nach. Ich wollte im Vorfeld nur schonmal nachfragen, ob dieses Problem bekannt ist ? Wenn es keine Lösung gibt, kein Problem, ich benötige nur eine klare Aussage, wenn es ntbackup nun mal mit solch großen Dateien nicht aufnehmen kann... Der Kunde berichtete mir auch eben via Mail, daß das Kopieren der großen Daeien von einem auf ein anderes Laufwerk ebenso Probleme bereitet. Es wird einfach abgebrochen... Irgendwelche Infos ? Danke schonmal !! Grüsse schroeder750

Hy Jimmypop, den Worten von lefg kann ich mich nur anschließen... War die Woche leider etwas im Stress, so daß ich jetzt erst antworte. Ich dachte eben,mich tritt ein Pferd... in der heutigen Zeit kann ich ja nur hoffen, daß die Sache von Dir ausing, weil Du einen besseren Job gefunden hast... andernfalls drücke ich Dir ganz fest die Daumen, daß wir hier im Bord bald wieder Meldung von Dir bekommen, weil Du irgendwelche abstrusen EDV-Probleme für irgend eine andere Firma löst... :D Ich habe das Anfang des Jahres auch hinter mich gebracht, die alte Firma gibt es jetzt halt nicht mehr ... ging aber ohne große Bewerbungen nahtlos in das Arbeitsverhältnis mit der jetzigen Firma über ... Ohren steif halten, O.K ? Tscha, dann würde ich mal sagen, warten wir auf weitere Anfragen eines Boardmitglieds mit dem Namen "CheffevonJimmypop" oder so ... :D Grüsse schroeder750

Hy lefg, genau, und deshalb sehe ich ja hier Probleme im Verzug. Das Tool rendom bringt uns in diesem Fall wirklich nichts, da wir den Domänennamen ja beibehalten. Es gibt kein nettes Tool zum umbenennen eines DCs, welches einem die Arbeit abnimmt, sämtliche Registry-Einträge, WINS- DNS- und sonstige Dinge die noch irgendwie auf den alten Namen und die alte IP gemünzt sind, umzubiegen. Da muss wirklich manuell nachgearbeitet werden. Ich habe bisher wirklich für einige Kunden einige Konfigurationen zurechtgebogen und des öfteren mit nicht ganz MS-konformen Mitteln arbeiten müssen, aber einen DC (zumal es der einzige ist, der die Domäne oben hält) umzubenennen ... nööö, wollte ich mir bisher nicht wirklich antun... ;) Vielleicht gibt es ja einen MS-Artikel, in dem alle Schritte genau beschrieben sind, hier wäre dann aber roch darauf zu achten, das es der EINZIGE DC ist. Wie gesagt, Bauchgefühl von mir. Ich würde sonstwas für Kapriolen anstellen, um diese Situation zu umgehen... :D Grüsse schroeder750

Tach nochmal, ... muss ich leider uneingeschränkt zustimmen... aber es gibt da auch Ausnahmen... :D (Bin selber Senior IT-Consultant in einem Systemhaus in Stuttgart) ... harr harr... ... hier wird nix zerpflückt... es wird konstruktive Kritik hageln, sonst nix ... :D :D Ernst beiseite. Hast recht. Mache es am Besten so. Lass es Dir über Weihnachten durch den Kopf gehen (dann hast Du auch nicht genug Zeit, Dir Speck auf die Rippen zu fressen, wie es wohl bei mir wieder enden wird...) und dann bauen wir das alle zusammen zu einem Konzept mit Hand und Fuss... Solltest dann vielleicht später noch in die Runde werfen, wann Du die ein oder andere kritische Aktion machst, dann können die Leute hier im Bord, die Zeit haben zu diesen Zeitpunkten mal reinschauen und Dich ein wenig "live" unterstützen... Das kriegen wir ... Mach Dich nur bitte wegen SQL nochmal schlau. Wir müssen eigentlich nur warten, bis hier mal ein SQL-Freak vorbeischneit ... Grüsse schroeder750

Hey hey, locker bleiben, ich bin einer von denen, die gerade Zeit haben, warte mal ab, bis alle hier richtig loslegen ... :D Ich tümmle mich hier nicht umsonst. Auch mir wurde hier schon oft genug geholfen, wenn es brenzlig wurde ;) Grüsse schhroeder750

Hy zusammen, @lefg: Es würde ja in diesem Falle nicht die ganze Domäne umbenannt... der Domänenname bleibt ja die ganze Zeit erhalten. Es geht ja hier nur um den Namen des DCs. Wenn da ein weiterer DC wäre, der solange die fsmo-Rollen hält und man den zweiten DC via DCpromo rausnimmt, umbenennt und wieder zum DC macht, sehe ich da keine Probleme. Wir hätten aber hier, wie schon erwähnt, nur diesen einen DC. Und der IST die Domäne... Wenn ich den umbenenne, passt in diesem Moment irgendwie gar nix mehr zusammen. Da hätte ich persönlich dann echt die erwähnten Bauchschmerzen... Wäre für mich wirklich ein Grund, mit einem Ausweich-DC zu arbeiten ... @Apollon: den Adprep /forestprep und adprep /domainprep führst Du generell nur auf EINEM DC aus, der das Recht hat, das Schema zu ändern. Dieser erweitert dann das Schema und alle anderen DCs (in Deinem Falle sind da ja keine...) bekämen dann durch die höheren USNs des DCs, auf dem geändert wurde, die Sachen rüberrepliziert... Habe das schon mehrmals gemacht, keine Probleme. Wenn man das Schema bereits unter W2K durch einen Exchange 2K erweitert hatte, ist hier noch was zu beachten, aber das ist ja in Deinem Fall auch nicht so ... Zum DNS-Alias: den habe ich bereits mehrfach verwendet. Ich brauche das schonmal bei Kunden, wenn die Postfächer auf einen anderen Exchangeserver gemovt wurden und die Clients es noch nicht alle mitbekommen haben, bevor der alte Exchange exekutiert wird. Das funzt ganz wunderbar. Mach doch mal einen Test, setze im DNS einen Eintrag auf irgend einen imaginären Namen, dessen IP auf einen existenten Server verweist. Wenn Du dann von einem Client auf den imaginären, nicht vorhandenen Server zugreifst, landest Du wunderbar auf dem wirklichen Server, auf dessen IP Du den Alias gesetzt hast. Als weiteren Hintergedanken kannst Du ja auch mal im Kopf behalten, daß man auf eine Netzwerkkarte mehrere IPs festnageln kann. Sowas kann bei einer Umstellung mit Datenhin- und Herschubserei auch ganz nett helfen ... Wenn das mit der SQL Geschichte ohne Probleme funktionieren kann und Du es sauber durchführst, kommst Du mit sehr sehr hoher Sicherheit ganz geschmeidig ans Ziel. Wie gesagt, viele Wege führen nach Rom, ich habe nur mal fix einen Ansatz gegeben, wie ich es machen würde. Den sehe ich als absolut durchführbar an. Warte mal noch ein paar Antworten ab und bau Dir dann eine Vorgehensweise zurecht, ich denke, wir sind da in diesem Thread schon einer guten Lösung sehr nahe. Grüsse an alle !! Schroeder750

Moin moin, @zuschauer: ... heißt ja automatisch, daß ich einen anderen Namen und eine andere IP als der alte DC habe... später nehme ich dann den alten DC raus und es verbleibt eine Domäne, die nur aus dem neuen DC besteht. Siehst Du keine Probleme darin, den dann komplett umzubenennen und ihm ne andere IP zu verpassen ? Die IP geht ja noch, aber den Namen des einzigen DCs zu ändern ... sehe ich als nicht so ganz trivial an... Hast Du schon mal Erfahrungen damit gemacht ? Ich würde es (jetzt aus dem Bauch heraus) eher vermeiden wollen... Erfahrungsgemäß tauchen da noch jede Menge Einträge in der registry auf, die irgendwie noch am alten Namen kleben, die SOA-Einträge im DNS müssen geändert werden, der einzige WINS- und DNS-Server der noch existiert ist der nun umbenannte, auf dem müssen dann die ganzen Einträge geändert werden, wer weiß was da an Verweisen im AD noch auf den alten namen des DCs rumdümpeln ... finde ich recht unübersichtlich ... Wie gesagt, nur mein Bauchgefühl... @Apollon: Soll da auch auf Dauer nur ein DC existieren ? Schon mal Gedanken drüber gemacht, den alten DC zumindest mal als weiteren DC in der AD-Struktur zu behalten, für den Fall eines Ausfalles des ersten ? Ist doch jetzt ne gute Chance, dem alten DC noch ein Weilchen sein Gnadenbrot zu geben ... Grüsse schroeder750

Moin moin, O.K., möchte auch mal meinen Senf in die Runde schmeißen ... :D Die Daten (Userprofile), die SQL-Datenbank(en) und die DC-Rollen zu verschieben dürfte technisch ja nicht die Riesenherausforderung sein. Ich bin leider kein SQL-Freak, daher haue mir bitte wer auf die Finger, wenn ich das zu einfach sehe. Folgender Gedankengang: Problematisch ist, daß der endgültige, neue Server den gleichen Namen und die gleiche IP haben soll wie der alte. Solange der alte noch da ist, kann ich ihn nicht so nennen. Klar... Habe ich den neuen schon als DC mit anderem Namen ins AD integriert und fange dann an, ihn umzubenennen, ist dies garantiert auch nicht die Königslösung ... Ich würde daher vorschlagen, einen temporären DC für ein Wochenende einzussetzen, um die Daten "zwischenzuparken". Kann eine fixe, moderne Workstation aus dem Lager sein...bleibt ja nicht lange... Sagen wir mal folgendes: Alter Server=server1, temporärer Server=server2, neuer Server=server3, O.K. ? Dann mal grob folgende Vorgehensweise: - Server1: Adprep auf W2K3. Vorsicht, SP-Stand beachten. Muss mind. SP2 für W2K drauf sein... - Server2: als weiteren W2K3 DC reinbringen (anderer Name, andere IP, klar), Benutzerprofile darauf verschieben, SQL installieren, replizieren lassen. fsmo-Rollen und globalen Katalog rüber. Jetzt der Trick: Im DNS einen Alias setzen, der beim Auflösen des Namens des alten Servers die IP des neuen zurückgibt. Wenn ich jetzt den alten Server aus dem Rennen nehme, bekommen die Clients trotzdem noch Antwort, wenn sie nach dem Namen vom alten schreien... Wenn ich das an einem Wochenende durchziehe, sind da eh wenige Clients, die drauf zugreifen wollen... - Server1: Globalen Katalog entfernen, dcpromo, raus damit aus der Domäne. Name und IP sind jetzt frei... - Server3: (neuer Server): Unter dem Namen und der IP des alten aufsetzen, dcpromo, fsmo-Rollen und globalen Katalog rüber, SQL installieren, Daten vom temporären Server rüberholen, DNS-Alias entfernen. Ab diesem Zeitpunkt greifen die Clients auf den endgültigen DC zu. Ohne das ich einen Client angerührt habe. - Server2: (temporär): Globalen Katalog runter, dcpromo, raus damit aus der Umgebung... Für Anmeldungen und Benutzerprofile sehe ich hier keine Probleme, wie gesagt, SQL müsste noch jemand anderes was dazu sagen, ob es da mit dem DNS-Alias funktionieren kann...stecke ich nicht drin... Kann man aber vorher testen, oder ? Gut, soweit meine Ideen dazu, hilft viellicht ein wenig bei der Findung des endgültigen Weges... Grüsse schroeder750

Moin anickeni, Willkommen an Bord !!! Schau bitte mal hier rein: http://www.mcseboard.de/showthread.php?t=72480&page=2&pp=10 Da hatte ich im Thread 12 erklärt, wie man via "ldp.exe" Exchange-Leichen aus dem AD schneiden kann... Falls Du Probleme damit hast oder Fragen, einfach wieder melden, O.K ? Viel Erfolg !!! Und lass mal hören, ob es funktioniert hat... :D Grüsse schroeder750

Moin moin, ich geb da jetzt auch mal meinen Senf dazu, O.K ? Im Wesentlichen geht es doch hier um a) die Anmeldungen an der Domäne bzw. die Verfügbarkeit der Domäne und b) die Verfügbarkeit von ein paar 100 MB Daten, oder ? Habe noch kein DFS aufgesetzt, gehe aber mal nach anderen Threads hier im Bord davon aus, daß mittels DFS die Daten verfügbar vorgehalten werden können. Schauen wir uns mal die Domäne und die Anmeldungen an: Wenn ich eine AD-Domäne im native mode habe und die Clients auf XP aufsetze, benötige ich für die Anmeldung meines Wissens nach einen Global Katalog Server. Dies kann jeder DC sein. Fällt also der erste DC aus, können sich die Clients noch am zweiten anmelden, wenn obige Bedingungen erfüllt sind. Die 5 fsmo-Rollen, die ja meist (wenn sie nicht verlegt oder verteilt wurden) auf dem ersten DC liegen, werden eigentlich bei genauerem Hinsehen nicht ständig benötigt. Wenn ich im Falle des Ausfalles des ersten DCs keine Childdomänen oder Benutzer hinzufügen möchte oder ähnliche Dinge erledigen muss, werde ich eigentlich erst aus den eventlogs auslesen, daß meine fsmo-Rollen momentan nicht verfügbar sind. Da bricht ja nicht gleich die Domäne zusammen... Alles in allem für mich also kein Grund, einen DC zu clustern ... Das kommt mir alles ein wenig vor wie mit Kanonen auf Spatzen zu schiessen... Wenn ich den zweiten DC incl. globalem Katalog sauber aufgesetzt habe und die Daten über DFS repliziere, kann ich also ohne manuellen Eingriff erst einmal ein Weilchen weiterarbeiten. (Wie gesagt, DFS ist nicht so mein Hauptding, vielleicht gibt da jemand mal noch Info, der sich damit richtig auskennt) Wenn ich sehe, daß mein abgerauchter erster DC für längere Zeit das zeitliche segnet, kann ich dem verbleibenden DC innerhalb von 3 Minuten die fsmo-Rollen rüberschieben und kann dann wieder 100%-ig weiterarbeiten. Reicht diese Redundanz nicht aus ? Klar habe ich schon Cluster (Exchange, SAP) bei Kunden aufgebaut. Die haben auch ihren Sinn. Mir kräuselt das immer so ein wenig die Nackenhaare hoch, wenn ich "Hochverfügbarkeit" höre und im Hinterkopf immer nur "teuer teuer teuer ..." habe, wenn bei genauerem Nachfragen beim Kunden oft rauskommt, daß man es mit gesundem Menschenverstand und den Bordmitteln auch absolut zufriedenstellend hinbekommt. Ich würde erstmal genau abklopfen, was die Anforderungen sind und dann über teure Lösungen nachdenken, wenn es gar nicht anders geht. - Nur so als gedanklicher Ansatz, O.K ? :D Grüsse schroeder750

Hy Tom, Grundsätzlich kannst Du demoten und direkt wieder unterm gleichen Namen promoten... da sehe ich weniger das Problem... Dein Problem wird eher sein, daß Du bei nicht gestartetem AD nicht demoten kannst... Sorry, hätte jetzt gerne die passende Lösung parat, habe ich aber leider nicht. Selbst wenn Du den Server neu aufsetzt (worauf es leider evtl. hinauslaufen wird, wenn das AD auf dem DC nicht gestartet werden kann), musst Du daran denken, daß noch der Name des Servers als DC und somit als Replikationspartner für die anderen DCs im AD gespeichert ist. Das heißt a) Du wirst ihn mit dem gleichen Namen nicht mehr als DC promoten können und b) Du wirst Replikationsversuche der anderen DCs haben, die ins Leere laufen und somit alles verlangsamen können. Als Lösung gibt es da dann nur eins: mit einem Tool wie ldp.exe oder adsiedit den betreffenden DC aus dem AD rausschneiden... Habe sonst leider momentan auch keinen brauchbaren Ansatz für Dich, aber zumindest mal diese Warnung vor dem Stolperstein, wenn es weitergeht ... Grüsse schroeder750

Moin moin, einen DC zu clustern empfinde ich so aus dem Gefühl heraus als nicht allzu sinnvoll... Hier mal ein paar gedankliche Ansätze: - Zweiten DC (mit Kopie des globalen Katalogs) aufbauen und dafür sorgen, daß die Profile ein oder zweimal am Tag (anfangs einmal Komplettkopie, danach nur noch die Delta-Daten via xcopy-Script) rüberrepliziert werden. - Die Drucker auf dem zweiten DC genauso anlegen und freigeben wie auf dem ersten DC. - Vernünftige Doku erstellen, damit auch ein nicht so tief drinsteckender Kollege im Notfall die fsmo-Rollen via ntdsutil auf den zweiten DC verschieben kann. Wenn der erste DC nur eine bestimmte Zeit ausfällt, kommt man unter besten Bedingungen auch mal ne Weile ohne fsmo-Rollen aus. Ist ja nicht so, daß direkt die ganze Domäne weg ist ... - Fällt der erste DC aus, kann man im AD Snap-In der MMC alle User auf einmal markieren und den Server für den Profilpfad ändern, so daß die Profile beim Login vom zweiten DC gezogen werden. Die Drucker evtl. über Policies zuweisen, die sind dann im Bedarfsfall auch relativ schnell zentral auf den zweiten DC geändert... - Den letzten Punkt kann man evtl. komplett umgehen, indem man für die Zeit des Ausfalles des ersten DCs einfach einen Alias im DNS setzt, der beim Namen des ersten DCs auf die IP des zweiten DCs verweist... Die Clients rufen dann wegen den Profilen und den Druckern nach "server1", bekommen aber die IP des "server2" aufgelöst und sind glücklich ... O.K. nur so als erste Ansätze, technisch garantiert noch zu verfeinern ... :D Grüsse schroeder750

Moin Piffer, dazu muss die Datei "ristndrd.sif" oder die "riprep.sif" editiert werden. Es existiert eine über 100-seitige Dokumentation zum Inhalt dieser Dateien... Werde mal schauen, ob ich den Link noch finde ... Grüsse schroeder750

Moin moin, der Exchange kann ohne Zusatztools keine POP3-Mails ABHOLEN (vom Provider oder ähnliches), POP3 Server spielen kann er jedoch von Hause aus ... Grüsse schroeder750

Hy Leute, danke nochmal für die Unterstützung, das Thema hat sich erledigt. Ich hatte gestern Nacht den Exchange, wie erwähnt, nochmal drüberinstalliert, nachdem ja vorher der Dienst nicht da war. Ich habe aber ( es war nach 24:00 Uhr...) nicht mehr nachgesehen, ob der Dienst nun vorhanden war, sondern habe nur versucht, den virtuellen POP3-Server zu starten, was natürlich vor die Wand gelaufen ist. Habe eben noch einmal mit dem Kunden telefoniert, der Dienst war natürlich nach der nächtlichen Drüberinstallieraktion da, natürlich nur deaktiviert und somit nicht gestartet... Jetzt scheint soweit alles zu tun. Es frage mich jetzt bitte niemand, warum der Dienst bei der ersten Installation, die wirklich problemlos durchgelaufen war, nicht installiert wurde ... :D Thanx nochmal für die fixe Hilfe !!!! Bis demnächst !! schroeder750

Moin moin, Beim 2003er Exchange ist das analog zu den (sehr guten) Erklärungen von mwuff. Hier solltest Du allerdings den aktuellsten ADC vom Exchange 2003 nehmen. Übrigens, den Test, ob auf dem alten Exchange 5.5 evtl. mehrere Postfächer auf einen Benutzer oder Postfächer auf Gruppen genagelt sind kannst Du auch sehr gut mit dem Tool "Ntdsattrib" machen, das findest Du wiederrum auf der SP3 CD vom Ex2K... Grüsse schroeder750

... und mal noch ne weitere Zusatzinfo: habe gerade in der VMWare-Testumgebung mal die NNTP- und die SMTP-Komponente vom IIS deinstalliert und danach den Exchange neu gestartet. Resultat: Der "Microsoft Exchange POP3" ist weiterhin da und auch gestartet, jetzt lässt sich jedoch der Informationsspeicher nicht starten... Bringt mich auch nicht wirklich weiter ... Werde die beiden Komponenten wieder installieren, damit der Exchange wieder läuft ... Gruss schroeder750

Hy Tom, Wow, superfixe Antwort, danke Dir !!! ... und genau da liegt ja der Hase im Pfeffer... Habe bei meinem Exchange hier unter VMWare nachgesehen. Hier läuft ja alles sauber ... Wenn ich unter den Komponenten nachsehe, wie Du es beschrieben hast, sehe ich, daß diese EMail-Dienste und speziell der POP3-Dienst auf diesem Server NICHT installiert sind. Das ist nämlich der POP3, der standardmäßig beim W2K3 Server dabei ist... Wenn ich hier versuche, den nachzuinstallieren, bekomme ich die Meldung, daß es nicht geht, weil auf dem Server ja Exchange installiert ist ...Ich soll entweder den Exchange entfernen oder den POP3 vom Exchange benutzen... Habe gerade mal die registry nach der inetinfo.exe durchforstet, das Ding taucht ca. 15 mal auf... liegt auch anderen Diensten wie dem SMTP zu Grunde... Also diesen Dienst per Hand mit registryeinträgen reinzubiegen dürfte auch nicht so einfach sein... Evtl. solte ich mal testen, die NNTP- und die SMTP-Komponente des IIS zu deinstallieren und neu zu installieren ... Habe übrigens gestern beim Kundenserver den Exchange nochmal sauber neu drüberinstalliert und das SP1 wieder hinterhergeschubst... juckt ihn wenig... Der Exchange selber läuft sauber, nur eben ohne den POP3-Dienst des EXCHANGE ... Noch ne Idee ? Grüße schroeder750

Hy Leute, danke für die fixen Antworten !!!! Ihr liegt absolut richtig, habe das gerade mal in einer Testumgebung unter VMWare so nachvollzogen. Der Dienst ist standardmäßig deaktiviert, habe ihn aktiviert und gestartet, sofort konnte ich den virtuellen Standardserver für PO3 starten... Und jetzt komt natürlich gleich der Haken: Beim Kunden habe ich den Exchange 2003 ganz normal installieren können (geht ja eh erst, wenn die NNTP- und die SMTP-Komponente und der ASP. NET installiert ist, was sie auch waren) und habe keinerlei Probleme mit der Installation oder nachher mit dem Server gehabt. Es gibt auf diesem Server jedoch den Dienst nicht ... Wenn ich das Exchange-Setup erneut starte, habe ich ja keine Option den irgendwie nachzuinstallieren... Irgend jemand eine Idee, was hier schiefgelaufen sein könnte bzw. wie ich den Dienst "Microsoft Exchange POP3" nachinstalliert bekomme ? Der Pfad zur EXE-Datei ist: C:\Windows\System32\inetsrv\inetinfo.exe... Das sagt mir, daß der Dienst doch nicht direkt vom Exchange kommt, sondern vom Internet Information Server, oder ? Ich brauche da echt mal Eure Hilfe ... ;) Danke schonmal im Vorraus !!! Grüsse schroeder750