schroeder750

Hallo Leute, kleines Problem, bei dem mir bestimmt irgendwer helfen kann (hoffe ich doch mal ...) :D NT4-Domäne, InPlace-Migration wurde angefangen, also NT4 BDC ins Netz gebracht, hochgestuft zum PDC, Update auf Windows 2000 Server, manuelles Erstellen der DNS- und AD-Strukturen. Funzte alles ganz wunderbar. Dann Schemenerweiterung auf W2K3 AD auf dem 2000er DC. Ohne Probleme. Danach Neuaufbau eines Windows 2003 DCs ins aufgebohrte AD. Auch keine Probleme. FSMO-Rollen und GC auf den neuen W2K3 DC rübergeschubst, einwandfrei... Zum Schluss wurde sauber mit DCPromo der W2K DC wieder aus dem AD genommen. Auch sauber gelaufen. Nun existieren in der Domäne (wie vorher als es noch eine NT4-Domäne war), 2000er Memberserver. In den Eventlogs dieser Memberserver taucht jetzt seit dem Update aufs AD alle 15 Minuten folgende Meldung auf: Quelle: LicenseService Ereigniskennung: 213 Beschreibung: Die Replikation der Lizenzinformationen ist fehlgeschlagen, da keine Verbindung mit dem Lizenzprotokollierdienst auf dem Server "\\NAME DES W2K3DCs" hergestellt werden konnte. Kein Problem, schroeder is ja kein Dummchen und hat sich hier schlau gemacht... Der Lizenzprotokollierdienst ist auf dem W2K3 DC auf automatisch eingestellt und läuft auch. In der Managementkonsole unter "Active Directory-Standorte und -Dienste" => "Sites" => "Standardname-des-ersten-Standorts" => "Licensing Site Settings" => "Lizenzierungscomputer" ist der W2K3 DC auch eingetragen. Hmmmm, hätte das Problem jetzt da vermutet... isses aber nicht... die Meldung auf den 2000er Servern taucht nach wie vor auf ... Alternativ kann natürlich der Lizenzprotokollierdienst abgeschaltet werden, ist aber nu nich die ultimative Lösung, oder ? Erstens: tauchen dann keine Probleme auf ? Zweitens: wenn ich den Dienst, wie unter NT4 einfach abschalte, werden die 2000er Server ja wohl trotzdem weiter meckern, weil sie jetzt den Lizenzprotokollierheimerserver erst recht nicht erreichen. Kommt irgendwem dieses Problem bekannt vor ? Sagt mir, wie einfach die Lösung ist, damit ich mich selber drüber ärgern kann ;) Grüsse schroeder750

Hy Stephan, hmmm, ich gehe mal davon aus, daß Du auf einem der Exchange 5.5 einen Internet Mail Connector hattest, richtig ? Dann gehe ich mal weiterhin davon aus, daß Du irgend eine Firewall hast, die darauf gedrillt ist, die Mails mit einem Exchangeserver mit der IP-Adresse xxx.xxx.xxx.xxx (eben dem Exchange 5.5 mit dem Internet Mail Connector) auszutauschen, richtig ? Wenn Du nun natürlich beim Bridgeheadserver (eben dem Exchange 5.5 mit dem IMC) die Dienste beendest, hat die Firewall nicht mehr viel zum kommunizieren, oder ? Geh doch mal her und dokumentiere die Konfiguration des IMC vom Exchange 5.5. Danach schmeißt Du den IMC raus, konfigurierst auf einem der neuen 2000er einen SMTP-Connector mit den Informationen. Jetzt musst Du nur noch dafür sorgen, daß Deine Firewall mit dem Exchange 2000 SMTP-Connector kommuniziert. Das heißt also entweder die Einträge in der Firewall auf die IP des Exchange 2000 zurechtbiegen oder die IP-Adressen der beiden Exchangeserver tauschen, so daß der Exchange 2000 mit dem SMTP-Connector die IP-Adresse des Exchange 5.5 mit dem IMC bekommt ... Mal so als ersten Ansatz, O.K ? Grüsse schroeder750

O.K., dann mal viel Erfolg. Wenn Du noch ein paar abstruse Gedanken und wirre Bemerkungen brauchst, stehe ich jederzeit gerne zur Verfügung :D Grüsse schroeder750

Hy Sven, schau mal hier rein, ist noch ganz frisch... :D http://www.mcseboard.de/showthread.php?t=64902 Im Thread 4 habe ich die Vorgehensweise mit ldp.exe geschildert... Dürfte so in die Richtung gehen... Grüsse schroeder750

... jetzt hab ich aber auch langsam keine Ideen mehr ... Wie wäre es denn, mal einen weiteren Exchange 2003 testweise in die gleiche Org zu installieren, nur um festzustellen, ob dort das gleiche Problem auftritt ? Auf diese Art und Weise bekommst Du heraus, ob es ein spezifisches Problem Deines jetzigen Exchange 2003 ist oder etwas generelles... Hört sich jetzt nach viel Aufwand an, ist aber doch relativ fix passiert. Und wenn Du nach einem klaren Ergebnis den neuen Exchange 2003 sauber vor den Augen der anderen deinstallierst, ist der ja auch sauber wieder draussen... Ich pflege in solchen Fällen immer nach dem K.O.-System vorzugehen, um erstmal festzustellen, an welcher der beteiligten Komponenten es denn nun liegt. Sonst fummelt man an 5 Baustellen gleichzeitig und steht sich selbst im Weg... Im Falle der Integration eines weiteren Exchange 2003 kannst Du dann auch testen, ob von diesem neuen Exchange2003server aus die Kommunikation a) zu den öffentlichen Ordnern auf dem bestehenden Exchange 2003 funzt und b) die Kommunikation mit den ö.O. des Exchange 5.5. Das lässt dann wieder Rückschlüsse zu... Funzt es zwischen den beiden neuen Exchange 2003, liegt das Problem definitiv in der Kommunikation zwischen neu und alt. Dann kannst Du da dediziert weitersuchen... Nur so als Idee... Grüsse schroeder750

Hy sigmundfreud, mein Gedanke ging eher in die Richtung, eine bereits mit SP6a gepatchte CD für das Setup zu nehmen. Soweit ich mich erinnere, konnte man sich mit Hilfe des Service Packs und einer auf die Platte kopierten NT-Installationsversion diese patchen und den ganzen Senf wieder auf CD bruzzeln... dann war es möglich, direkt mit SP6a zu installieren. Beim W2k ging das, beim NT4 bin ich mir echt nicht mehr sicher... Wäre nur mal so als Alternative, die Dir evtl. weiterhelfen kann, wenn man denn sicher wäre, daß es mit dem SP funzen würde... ;) Trotzdem noch viel Erfolg !! Ciao schroeder750

Hy Christoph, äääh, steh ich da jetzt auf dem Schlauch ? CA repliziert zwischen Exchange 2003 und AD ? Normalerweise gibst Du dort doch den Exchange 5.5 und das AD an ... zwischen einem Exchange 2003 und dem AD brauchst Du doch keinen ADC... Ich würde mal eine Verbindungsvereinbarung zwischen dem Exchange 5.5 und einem AD-Server erstellen, die in beide Richtungen geht (wenn ich mich recht erinnere, geht das doch eh nur in beide Richtungen) und die immer aktiv ist... Tatsache ist doch, daß neue öffentliche Ordner, die am Exchange 2003 erstellt werden, von allen Seiten her verwendbar sind. Zu haken scheint es ja nur bei öffentlichen Ordnern, die auf dem Exchange 5.5 liegen und auf die von Benutzern zugegriffen wird, die ihre Postfächer auf dem neuen Exchange 2003 haben. Ich würde an Eurer Stelle wirklich mal die CA plätten und neu erstellen. Dabei darauf achten, daß die Ports usw. sauber angegeben werden, daß der Haken gesetzt ist bei "Gesicherte Active Directory Objekte in das Exchange-Verzeichnis replizieren" und natürlich auf bei "Dies ist eine primäre Verbindungsvereinbarzung..." Werde irgendwie das Gefühl nicht los, daß es daran liegen könnte. Versuchts am Besten mal, ist ja schnell passiert... Grüsse schroeder750

O.K. dann kann das mit SIDs oder irgendwas in der Ecke schon mal nicht zusammenhängen ... Sag mal, eine Verbindungsvereinbarung für öffentliche Ordner über den ADC habt ihr am Laufen, oder ? Steht die zeitplanmäßig auf "immer" ? Habt Ihr die mal gekillt und sauber neu angelegt ? Hatte auch schon ein paarmal das Problem, daß die nicht ganz sauber taten... ****e ist halt nur, daß die Ordner ja repliziert werden, also kann die Verbindungsvereinbarung schon mal nicht so ganz untätig sein... Was sagt denn dieser Assistent der ADC-Tools wenn Du den ausführst ? Gibt es irgendwelche Meldungen in den eventlogs ? Der neu angelegte Ordner auf dem Exchange 2003 wird auch rüberrepliziert auf den Exchange 5.5 ? Und ist der da für die User des Exchange 5.5 erreichbar ? Grüsse schroeder750

... da stimmt doch an der generellen Kommunikation zwischen den beiden Exchangeservern was nicht ... Ist der Exchange 2003 in einer anderen Domäne ? Evtl. Parallelmigration zwischen NT4 und W2K3 AD ? Exchange 5.5 in der alten NT4-Domäne und Exchange 2003 in der neuen AD ? Rutsch doch bitte in der Richtung mal mit ein paar Infos rüber, evtl. was wann wie wo aufgebaut wurde... Ich habe irgendwie das Gefühl, als könnte das Exchangemäßig passen, aber die User haben irgendwie nicht so ganz die Berechtigungen... War das ne Migration mit SID-History ? Gib mal ein paar Infos in der Richtung durch, O.K ? Grüsse schroeder750

Hmmm... bieg doch den Verweis der Postfach-Benutzer auf dem Exchange 2003-Server mal auf den öffentlichen Ordner des Exchange 5.5 um und teste nochmal. Wenn es funktioniert, weißt Du, daß wahrscheinlich bei den öffentlichen Ordnern auf dem Exchange 2003 was nicht stimmt ... Der umgekehrte Weg (allen Exchange 5.5-Usern den öffentlichen Ordner des Exchange 2003 unterzujubeln) wäre zwar auch hilfreich, aber unglücklicher, weil dann evtl. eine Menge User meckern werden ... :D Grüsse schroeder750

Hy Christoph, ich tappe auch so ein bisschen im dunkeln, trotzdem mal fix zwei Fragen als Ansätze: - Hast Du die öffentlichen Ordner auch auf den neuen Exchange2003 replizieren lassen ? - Wenn Du auf dem Exchange 2003 im System Manager mal die Eigenschaften des Postfachspeichers anschaust, was ist dort unter "Allgemein" bei "Öffentlicher Standardinformationsspeicher" eingetragen ? Hier wird ja angegeben, auf welche öffentlichen Ordner die Benutzer zugreifen, die sich genau an diesem privaten Informationsspeicher anmelden ... ... nur mal so als erster Ansatz ;-) Grüsse schroeder750

Hy Stephan, bei den Memberservern kommt es natürlich drauf an, was sie genau für Funktionen haben. Beispiel Exchange (auch wenn das jetzt ein schlechtes Besispiel ist, weil der ja eh einzeln migriert wird): Nimm einen Exchange aus der alten Domäne raus und pack ihn einfach in eine neue Domäne ... das mag der ü-ber-haupt nicht ... :D Bei weiteren Servern also bitte vorher in Ruhe eine Tasse Kaffee schnappen und mal genau drüber nachdenken, was Dir bei einem Entfernen aus der einen (also Verbringen in eine Workgroup) und Integration in die andere Domäne über die Klinge springen könnte. Hier mal ein paar Stichworte zum Abklopfen: - NTFS-Berechtigungen - Freigaben - Datenbanken, die evtl. von Dienstkonten abhängig sind und ähnliche Geschichten... Ganz wichtig ist natürlich, daß die beiden Domänen sauber vertrustet sind und Du die Gruppen und Benutzerrkonten incl. SID-History rüberholst. Sonst nutzen Dir die besten Übernahmen von Berechtigungen und ähnlichem nicht, wenn die Ressource-Server schon in der neuen Domäne stehen und Deine Benutzer, die noch aus der alten Domäne drauf zugreifen, auf die Finger gehauen bekommen... :D Mach Dich mal in Ruhe schlau, bastel Dir vielleicht ein kleines Konzept zurecht und stell es hier mal ansatzweise vor, ist immer besser wenn ein paar mehr Augen drüberwandern... Grüsse schroeder750

Hy Stephan, hmmm..., is natürlich irgendwie jetzt nicht ganz so einfach, mal eben so im Vorbeigehen zu erklären, wie die Migration auf ne neue Umgebung läuft ... :D Mach doch am Besten mal eins: ich habe des Öfteren zu diesem Thema einige Zeilen hier im Forum geschrieben (habe jetzt noch blutige Fingerkuppen ), da ich die letzten Jahre einige Domänen migriert habe. Schau Dir doch bitte mal einfach die Beiträge an, kannst ja nach schroeder750 suchen, meine Einträge sind hauptsächlich zu diesem Thema. Dann brauche ich nix doppelt zu schreiben, O.K. ? Es sind wirklich ne Menge guter Infos dazu in diesem Forum zu finden. Und dann poste mal ein paar genauere Informationen zur Umgebung. Ich habe es jetzt so verstanden, daß Du mit der InPlace-migrierten Domäne nicht zufrieden bist, also am Liebsten parallel eine neue, saubere Domäne hochziehen willst und die ganzen Ressourcen Stück für Stück aus der alten Umgebung in die neue schieben möchtest, richtig ? Die Standorte haben jeweils einen DC schreibst Du, ist das jeweils eine childdomain oder einfach nur ein DC der forest root domain, der draussen steht ? Ist / sind die Domäne(n) im native mode ? Wenn wir uns Stück für Stück an Deine Vorstellungen annähern, können wir Dir garantiert durch die ganze Geschichte durchhelfen... Wenn das so ist, wie ich es jetzt auffasse, müsstest Du zuerst eine neue Domäne mit sauberer DNS-Struktur hochziehen, diese Domäne mit der alten vertrusten und dann mit Tools wie ADMT die Gruppen und Benutzer rüberholen, aber dies incl. SID-History. Anschließend dann die weiteren Server und die Clients. Exchange-Migration ist dann eine Geschichte für sich, da würde ich den alten 5.5er zusammen mit der alten Domäne sterben lassen und in der neuen Domänbe gleich sauber einen auf 2000/2003 aufziehen und mittels ADC die Ressourcen rüberholen. Empfehlung von mir wäre, hier gleich über Windows 2003 AD nachzudenken. Du fasst dann eh jeden Server (und auch die Clients) einmal an... Das sind jetzt mal ganz ganz grob ein paar Schlagwörter, damit wir einen Einstieg finden, O.K ? :D Grüsse schroeder750

moin moin, mal ne ganz dumme Frage: könnte es sein, daß das ganze erst nach einem gewissen Service Pack Stand geht ? Nackter NT-Server 2 CPUs (also Unterstützung für Multiprozessor drin), 4 CPUs aber erst nach Service Pack 4 oder so ? War nur so ne Idee... :cool: Grüsse schroeder750

Hy Christoph, Ich hab da was gefunden: :p http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/windows/2000/server/reskit/en-us/distrib/dsfl_utl_TDNO.asp Zitat: Table C.6 Authoritative Restore Commands Restore database Marks the entire Ntds.dit (both the domain and configuration naming contexts held by the domain controller) as authoritative. The schema cannot be authoritatively restored. Ich denke, daß ist die Aussage, die sich bei mir im Hirn festgebrannt hatte... Daher befürchte ich, daß es die einzige Möglichkeit sein dürfte, ALLE DCs runterzufahren und den jeweiligen Systemstate zurückzubügeln, um den alten Stand des AD vor der Schemenänderung wieder herzustellen. In diesem Moment muss das natürlich auch nicht autorisierend geschehen, es ist ja nachher keiner da, der ne höhere USN hat ... Notfalls nach dem Starten mit F8 die ntds.dit manuell löschen, dann KANN da nix mehr von der Schemaänderung überleben. Oder ? Finde es gut, das Forum mal als ne Art Chatroom zu benutzen, das erweitert den Horizont und lässt über Dinge, die man bisher als selbstverständlich angesehen hat, mal genauer nachdenken... Hat irgendwer damit schonmal Erfahrung gemacht ? Ein vergurktes Schema auf diese Art wieder herzustellen ? Grüsse schroeder750 P.S: Sorry an Katjes, daß wir Deinen Thread gerade so misbrauchen (schäm...), aber das bietet sich an ... :D

Du meinst, den Schemamaster restaurieren, um eine Änderung des Schemas rückgängig zu machen ? Das Problem dürfte dabei ja sein, daß das Schema in seiner (dann veränderten und evtl. verballerten) Version sofort (o.k. innerhalb von 15 Minuten im Normalfall) auf alle DCs repliziert wird. Wenn ich jetzt nur den Schemamaster wieder herstelle, werden die anderen DCs ihm dann erzählen, er soll den alten Eintrag, den er da hat, überschreiben, wenn er wieder ins Netz kommt. Ist ja ähnlich bei einer Schemenerweiterung, wie ich sie z.B. beim Exchange mache. Ich nehme die Änderung auf einem DC vor und innerhalb der nächsten paar Minuten wird das ganze dann auf die anderen gebügelt. Ist ja in diesem Falle auch so gewollt. Für den eigentlichen Schreibvorgang ist dann der Schemamaster verantwortlich. Schemamaster heißt ja nicht, daß das Schema, was er gerade hat, Gesetz ist, sondern daß er für die Änderungen am Schema verantwortlich ist, er ist derjenige, der ins Schema schreibt. So habe ich das jedenfalls bisher verstanden. Falls das so nicht simmt und es jemand liest, der andere Infos hat, bitte her damit ! :p Ist ja nun nicht unwichtig... Grüsse schroeder750

Hy Christoph, bin gerade etwas im Stress, ich werde noch versuchen, den Link zu finden, ich hatte mir das vor ewigen Zeiten mal in meine Schulungsunterlagen übernommen. Diese Aussage wurde mir aber auch schon mehrmals bestätigt, als ich mich anfangs selber schulen ließ. Scheint also Hand und Fuss zu haben. (ich frage da auch immer lieber etwas genauer nach, schon absolut legitim Deine Fragen :D ) Auf die Schnelle habe ich folgenden Link gefunden: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/160ffb83-bbbd-4a56-aec0-7c495866c45f.mspx Da steht dann auch drin: Schemaerweiterungen können nicht rückgängig gemacht werden. Was ja meiner Meinung nach durch die Blume schon heißt, daß ich da auch autorisierend nix dran drehen kann. Wenn ich aber bei allen DCs komplett ohne AD mit F8 starte, ist das AD natürlich wehrlos und kann komplett überbügelt werden, also incl. Schemapartition. Wie gesagt, wenn ich den richtigen Link noch finde, poste ich das, O.K ? Ist immer interessant, sowas im kompletten Zusammenhang zu haben. Grüsse schroeder750

... hat sich wieder überschnitten :D

Hy Katjes, nix sorry und null Ahnung... Peinlich wird es dann, wenn man Dinge tut, von denen man keinen Plan hat. Du fragst ja wenigstens vorher nach und genau dafür ist das Board da :D Systemstate ziehen: Ntbackup starten und beim jeweiligen DC den "Systemstatus" anhaken. Der erstellt Dir dann eine ca. 400 - 500 MB große *.bkf-Datei, von der Du dann notfalls autorisierend wieder herstellen kannst. Autorisierendes Restore des AD heißt mit ntdsutil (da war´s wieder, Gruss an Christoph, der Mann hat doch Recht, das Ding ist wichtig... ;) ) dafür sorgen, daß diese Wiederherstellung auf diesem DC intern eine höhere USN bekommt als die anderen DCs und somit die einzig gültige ist. Mal ganz salopp formuliert. VORSICHT: Die Schemapartition lässt sich NICHT autorisierend wieder herstellen. Wenn ich also mehr als einen DC habe, sollte man bei solchen Aktionen (bei denen Du ja evtl. mit dem ldp.exe an der Schemapartition rumbiegst) von JEDEM DC einen systemstate ziehen. Wenn Bockmist passiert, alle DCs gleichzeitig runterfahren, das Restore vom AD zurückziehen und alle DCs wieder starten. Dann hat keiner eine neuere Info (=höhere USN) als die anderen und das AD existiert wieder in der Version, die bestand, als das Backup gezogen wurde... In diesem Fall brauchst Du auch nicht groß mit dem ntdsutil autorisierend rumzuwerkeln... Bei Unklarheiten einfach nachfragen, dafür ist das Board da. Solltest Dich vor solchen Aktionen aber besser nochmal genau über die Vorgänge schlau machen. Besser ist das ... Grüsse schroeder750

Hy Christoph, siehste, wieder was gelernt... Metadata Cleanup vom NTDSutil war mir bisher noch nicht bekannt... Werde ich mir in der nächsten Testumgebung mal ansehen :D Grüsse schroeder750

Hy there, Ntdsutil sehe ich jetzt nicht unbedingt als DAS hilfreiche Tool für dieses Problem an. Ausser, es liegt noch eine fsmo-Rolle auf dem abgerauchten DC, dann sollte man sie natürlich mit ntdsutil auf den verbleibenden DC verlegen (das wär dann die "seize" Option). Am Besten mal auf dem verbleibenden DC die Support Tools installieren. Danach Eingabeaufforderung und folgenden Befehl absetzen: "netdom query fsmo" Jetzt wird angezeigt, welcher DC denn so welche fsmo-Rolle hält. Die sollten natürlich nicht auf einer Leiche liegen... Danach ab in die Konsole auf dem verbleibenden DC und unter "Active Directory Standorte und Dienste" mal bei "Standardname des ersten Standorts" => "Servers" nachsehen, ob die Leiche da noch auftaucht. Hier kann man den leider nicht unbedingt einfach löschen. Falls er da noch auftaucht, mit der rechten Maustaste mal auf die "NTDS-Settings" dieser Leiche klicken und nachsehen, ob der angeblich noch einen globalen Katalog hat. Um solche Zombies aus der AD-Struktur zu bekommen, benutze ich immer ganz gerne "ldp.exe" aus den Support-Tools: Starten des Programms „ldp.exe“ aus einer Kommandozeile heraus. Auswahl „Connections“ ==> „Connect“ Hier den Servernamen des verbleibenden DCs eintragen Auswahl „Connections“ ==> „Bind“ Authentifizierung durchführen … Auswahl „View“ ==> „Tree“ „BaseDN“ leer lassen… Nun kann man sich auf der linken Seite ganz gut durchhangeln nach Einträgen des Namens des verblichenen Servers. 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 nämlich genau die Server auf, die ich eben über die Managementkonsole sehen konnte, sie aber dort nicht löschen konnte...(unter "Active Directory Standorte und Dienste") Auf diese Weise mal durchhangeln, ist natürlich mühsam, aber so bekommt man die Leichen raus... Bitte vorsichtig mit dem ldp.exe, 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

Moin, mir dämmert da was ganz ganz tief im Hinterkopf... da war mal was, wenn ich aus einer Workgroup auf eine Domäne zugreifen wollte... es kam, egal welche Anmeldeinfos man angegeben hatte, immer daß der Zugriff auf die Ressource IPC$ usw. nicht funktioniert. Abhilfe war damals das Gastkonto auf dem Server, auf den zugegriffen werden sollte bzw. das Gastkonto der Domäne zu aktivieren... dies nur so als Zusatzinfo, falls beim Zugriff diese IPC$-Meldung kommt... Bitte über die Sicherheitslücken nachdenken, die man sich mit Aktivierung des Gastkontos aufmacht !! Ist wirklich sauberer, die Rechner in die Domäne zu bringen. Habe das allerdings mit dieser MediaCenter-Spielwiese noch nicht gemacht... was soll so ein Spielzeug auch in der Domäne ? :D (nicht hauen ...) Grüsse schroeder750

Hy MMaier, dann solltest Du in Euer Helpdesk-System die genaue URL dieses Threads eingeben und die Zuständigkeit auf den Exchange / AD-Administrator ändern. Du hast Deine Schuldigkeit getan und hast prima Arbeit abgeliefert. Euer Admin sollte sich dann diesen Thread mal ansehen und vielleicht erst einmal nachsehen (ldp.exe) ob der alte Exchangeserver dort noch rumdümpelt. Die Angaben sind ja schon so genau, wie es geht. Wenn er dann genauere Infos hat, kann er diese ja hier posten und wir schauen weiter. Ist doch mal ein Ansatz, oder ? :D Grüsse schroeder750

Einen habbich übrigens noch: Wenn die Jungs den alten Exchange nach der Migration einfach abgeschaltet haben, können auch solche Dinge auftreten... 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 Schau hier bitte mal nach, ob da der alte Exchange(5.5)server noch eingetragen ist. Ist dies der Fall, wurde der schlicht nicht sauber vor den Augen des neuen deinstalliert und stellt immer noch Dienste bereit, obwohl er schon nicht mehr existiert. Wenn er da noch als Zombie rumdümpelt, sollte er gelöscht werden. Bitte vorsichtig mit dem ldp.exe am AD, O.K ? Grüsse schroeder750

Ha !!! Verstärkung !!! :p Hy GuentherH, danke Dir !! :D Fällt Dir zu dieser Geschichte was ein ? Wie kann man sauber erfassen, was hier genau schief läuft ? Hatte eben die Idee, daß ja bei den Postfachspeichern im Exchange jeweils eine Standard-Adressliste angegeben ist, aber da handelt es sich um die StandardOFFLINE-Adressliste und um die dürfte es hier nicht gehen... grmppfff sowas wurmt mich ... Grüsse schroeder750