lasseboo

Hallo zusammen, Sorry, dass ich erst jetzt antworte - wer im IT-Bereich tätig ist :D, kennt ja das Dilemma: kaum ist das eine Problem gelöst, lauert das Nächste an der Ecke :) Erstmal soweit die Schritte, wie es dann letztlich ablief: 1) Domain von Authoritative auf InternalRelay gesetzt: Set-AcceptedDomain unser-exchange.de -DomainType InternalRelay bzw (laut Microsoft) New-AcceptedDomain -Name "unser-exchange.de" -DomainName unser-exchange.de -DomainType InternalRelay 2) externen Sendeconnector erstellt bzw. zugewiesen: New-SendConnector -Name "Internal Relay" -Internet -AddressSpace unser-exchange.de -DNSRoutingEnabled $false -SmartHosts mx.extern.de-SmartHostAuthMechanism ExternalAuthoritative -MaxMessageSize 20MB bzw (laut Microsoft) New-SendConnector -Name "Internal Relay" -Custom -AddressSpaces unser-exchange.de -SmartHosts mx.extern.de -SourceTransportServers ex2007.mycompany.local 3) Da die Domain am Hauptstandort bereits angelegt war, ist die Adressbuch-Abfrage standardmässig aktiviert. Deswegen diese Abfrage für die entsprechende Domain abschalten: Get-AcceptedDomain | select name,domaintype,addressbookenabled Set-AcceptedDomain unser-exchange.de -AddressBookEnabled $false 4) Schliesslich noch Recipient filtering abschalten: = Exchange Verwaltungskonsole = Anti-Spam 5) Dann diese Schritte in der Exchange-Shell ausgeführt: Get-EmailAddressPolicy | Update-EmailAddressPolicy Get-AddressList | Update-AddressList Get-GlobalAddressList | Update-GlobalAddressList get-mailbox | set-mailbox -applymandantoryproperties 6) Jetzt funktionierte der Versand von einem NEU angelegten Outlook-Konto aus (bzw. einem PC mit neuem Profil, der nicht durch eine "alte" Autovervollständigung per NK2 bzw. vorgeschlagener Kontakte "belastet" war: a) Mail an user.hier wurde am alten Standort zugestellt b) Mail an user.dort ging problemlos an den User am neuen Standort (mit neuem Exchange) raus 7) An den "alten" PCs bzw. deren Konten muss man nun entweder a) die "falschen" Adressen aus den Vorschlägen manuell entfernen - das hat nur manchmal geholfen, bei ca. 20 PCs, es lebe die Berechenbarkeit von IT-Systemen ;) b) die alte Autovervollständigung komplett zu löschen hätte vermutlich auch geholfen c) wenn ein neuer User user.dort vom neuen Exchange am abgetrennten Standort übrigens eine Mail an die "alten" User am lokalen Standort hier schickt und beantwortet wird, geht diese auch zum abgetrennten Exchange. Letztlich muss man wohl entweder diesen berüchtigten X.500-Proxy anlegen (den ich aber bisher noch nicht begriffen habe - macht man das für die verschobenen User oder global für einen Bereich?), oder die alten Outlook-Konten manuell abklappern. So hat es bei uns geklappt, alle Aussagen ohne Gewähr, alles war sehr mühselig - aber wer eine bessere (funktionierende und nachvollziehbare!) Lösung hat, soll sie hier posten, ich lerne gerne dazu! Danke nochmal für die Tipps! Schöne Grüße Lasseboo

Hallo, Forum, an einem Exchange 2007 auf SBS 2008 hatten wir bisher die Domain unser-exchange.de lokal im LAN betrieben. Smarthost / MXer im Internet (Postfix) nimmt die Mails aus dem WAN für unser-exchange.de an, von dort ruft der Exchange / SBS mit dem integrierten POP-Connector ab. So weit, so gut. Nun ist aber ein Standort mit einem Teil der Benutzer aus dem AD DS (respektive der SBS-Console) abgetrennt worden. # user.hier@unser-exchange.de bleibt also bei uns. user.dort@unser-exchange.de wird auf dem neuen MTA am anderen Standort betrieben. Dummerweise unter derselben Domain, was ja dank Shared Namespace kein Problem sein sollte. Also habe ich: a) zuerst die vorhandene Domain unser-exchange.de auf dem lokalen Exchange von Authoritative auf InternalRelay gesetzt: Set-AcceptedDomain unser-exchange.de -DomainType InternalRelay B) den Sendeconnector für die Domain gesetzt: New-SendConnector -Name "Internal Relay" -Internet -AddressSpace unser-exchange.de -SmartHosts mx.extern.de c) den AddressBook-Lookup deaktiviert: Set-AcceptedDomain unser-exchange.de -AddressBookEnabled $false d) Schliesslich noch über die Exchange Verwaltungskonsole = Anti-Spam das Recipient filtering abgeschaltet. e) user.dort@unser-exchange.de auf unserem Exchange gelöscht. Schicke ich jetzt über unseren Exchange eine Mail von user.hier@unser-exchange.de an user.dort@unser-exchange.de, sollten diese an den SendConnector zugestellt werden, weil ich user.dort@unser-exchange.de ja bei uns gelöscht habe. Klappt nur leider nicht ... d.h. es klappt, aber nur für Adressen, die es vorher nicht im lokalen SBS / Exchange gab. a) Schreibe ich also an eine alte (gelöschte) Emailadresse, bekomme ich einen NDR vom lokalen Exchange. B) Schreibe ich an eine Phantasie-Adresse (gibts.nicht@unser-exchange.de), bekomme ich einen NDR vom MX/Smarthost (Postfix) - also funktioniert der Sende-Connector. c) Erstelle ich auf dem Postfix-MXer/Smarthost eine neue Emailadresse neuer.user@unser-exchange.de, wird diese Mail zugestellt. Ich habe alle Adressen gecheckt, in der Exchange-Verwaltungskonsole und im ADDS nachgesehen - aber es gibt user.dort@unser-exchange.de nirgends mehr auf unserem Exchange. trotzdem erhalte ich beim Versuch, eine Mail an user.dort@unser-exchange.de zusenden, einen NDR von unserem lokalen Exchange. Ich habe den SendConnector gelöscht und neu angelegt mit etwas anderer Syntax: New-SendConnector -Name "Internal Relay" -Custom -AddressSpaces unser-exchange.de -SmartHosts mx.extern.de -SourceTransportServers exchange-local - aber meines Erachtens ist das nicht das Problem, das Relayen an (neu) unbekannte Adressen funktioniert ja. Ich habe gestern abend den Exchange neugestartet in der Hoffnung, dass es das behebt, aber das war es auch nicht :( Habe ich etwas übersehen? Einen Verständnisfehler gemacht? Vielleicht hat ja jemand eine gute Idee ... :) Vielen Dank im Voraus! MfG lasseboo

Ist ja schon etwas älter - aber falls mal jemand nachliest: regdt32 - HKEY_LOCAL_MACHINE / SOFTWARE / Schlüssel POPCon und POPConPro samt Unterschlüsseln exportieren, auf der neuen Maschine den POPCon-Dienst stoppen und die Schlüssel importieren.

Danke für den Tipp! Damit gibt es aber noch Probleme, wenn ich es - wie von dir beschrieben - ausführe: "WARNUNG: Fehler beim Aktualisieren von Empfänger 'unsere-domaene.de/Microsoft Exchange System Objects/SystemMailbox{E10E8EB6-1ED5-4441-AF8B-362FFFA41BDB}'. Die folgende Ausnahme ist aufgetreten: Fehler bei Active Directory-Vorgang mit server.unsere-domaene.de. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus. Active Directory-Antwort: 00002098: SecErr: DSID-03150A48, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 . WARNUNG: Der Empfänger "unsere-domaene.de/Empfänger/Gast" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Empfänger/Leitung (Groß)" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Users/Team X" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Users/Beratung" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Schedule+ Zeitplaninformationen - Ersteadministrative Gruppe" ist ungültig und konnte nicht aktualisiert werden." Da es sich ja um die ohnehin etwas verrottete Domäne handelt und wir nach den Ferien eine neue, saubere Domäne aufziehen wollen, versuchen wir mal, uns über den Sommer zu retten ... :-\ Es sieht auch so aus, als würden sich die Clients nach und nach aktualisieren - und viele der SMTP-Aliase a la <username klammer-auf-irgendwas-klammer-zu>, die dann zu <username?irgendwas?@unsere-domaene.de> geführt haben, haben wir manuell korigiert.

OK! [PS] C:\>get-addresslist | update-addresslist WARNUNG: Der Empfänger "unsere-domaene.de/Empfänger/Gast" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Users/Beratung" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Offlineadressbuch - \/o=unsere Domaene\/cn=addrlists\/cn=oab" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Offlineadressbuch - Erste administrative Gruppe" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Schedule+ Zeitplaninformationen - Erste administrative Gruppe" ist ungültig und konnte nicht aktualisiert werden. [PS] C:\>get-globaladdresslist | update-globaladdresslist WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Offlineadressbuch - \/o=unsere Domaene\/cn=addrlists\/cn=oab" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Offlineadressbuch - Erste administrative Gruppe" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Microsoft Exchange System Objects/Schedule+ Zeitplaninformationen - Erste administrative Gruppe" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Empfänger/Beratung" ist ungültig und konnte nicht aktualisiert werden. WARNUNG: Der Empfänger "unsere-domaene.de/Empfänger/Gast" ist ungültig und konnte nicht aktualisiert werden. [PS] C:\>get-offlineaddressbook | update-addressbook Die Benennung "update-addressbook" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausf ührbaren Programms erkannt. ... also: [PS] C:\>Get-OfflineAddressBook | Update-GlobalAddressList Der Vorgang konnte nicht ausgeführt werden, weil das Objekt '\Standard-Offlineadressbuch' nicht auf 'fb-sv-01.unsere-domaene.de' gefunden wurde. + CategoryInfo : NotSpecified: (0:Int32) [update-GlobalAddressList], ManagementObjectNotFoundException + FullyQualifiedErrorId : 762B7CA,Microsoft.Exchange.Management.SystemConfigurationTasks.UpdateGlobalAddressList [PS] C:\>Get-OfflineAddressBook | Update-AddressList Der Vorgang konnte nicht ausgeführt werden, weil das Objekt '\Standard-Offlineadressbuch' nicht auf 'fb-sv-01.unsere-domaene.de' gefunden wurde. + CategoryInfo : NotSpecified: (0:Int32) [update-AddressList], ManagementObjectNotFoundException + FullyQualifiedErrorId : 762B7CA,Microsoft.Exchange.Management.SystemConfigurationTasks.UpdateAddressList

OK ;-) Welchen Fehler hattest Du denn erwartet?

moin, das ergibt: WARNUNG: Das Objekt unsere-domaene.de/Empfänger/Gast wurde beschädigt und befindet sich in einem inkonsistenten Zustand. Überprüfungsfehler: WARNUNG: 'Database' ist für 'UserMailbox' verbindlich. WARNUNG: 'Database' ist für 'UserMailbox' verbindlich.

username@unsere-domaene.de - wird auch so in den Eigenschaften des Adressbuchs angezeigt. Daneben gibt es als zweite Adresse noch username@alternativer-domaenennamen.de - was früher die Hauptadresse war. Ein bisschen habe ich ja den Verdacht, dass es auch daran hängt ...

Sooooo, nach vielen, vielen schlaflosen Nächten steht der neue Exchangeserver so halbwegs. Die Sache mit den Unterordnern war ganz einfach: das Exchange Management Shell taugt nicht für 5 Cent, wenn es um das Verschieben der Postfächer geht, aber mit OnTrack PowerControls konnten wir die meisten Postfächer problemlos direkt in den Exchange überführen - einschliesslich aller Unterordner. Neben 1000 anderen Probleme und Problemchen stört im Moment aber noch folgendes Problem: - wir haben die Postfächer auf dem 2010er neu angelegt und können beispielsweise an username@domaene.de mailen - kein Problem! Rein- und rausmailen geht auch. Aaaaber wenn man sich aus dem Globalen Adressbuch den User raussucht, geht die Mail mit Fehlermeldung zurück: "IMCEAEX: O=UNSERE+20DOMAENE+20STADT_OU=FQDN_CN=RECIPIENTS_CN=useradresse@unsere-domaene.de #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found##" useradresse@unsere-domaene ist der lokale Empfänger auf dem Exchange. Schaue ich mir die Eigenschaften im Adressbuch an, steht da als CN useradresse und als Emailadresse useradresse@unsere-domaene.de Wenn ich aus Outlook heraus unter Umgehung des GAL eine Mail an useradresse@unsere-domaene.de schreibe, wird die auch zugestellt. Nehme ich die Adresse aus der alten Autovervollständigung oder aus der GAL, schlägt es fehl. Wir haben den Usern gesagt, dass sie das Adressbuch imMoment vergessen müssen, aber es sollte dafür doch eine Lösung geben ... ?! Danke im Voraus für Tipps! MfG lasseboo

New-MailboxImportRequest -Mailbox willi -FilePath \\net\share\willi.pst -BadItemLimit 1000 -AcceptLargeDataLoss Wir haben es mit anderem BadItemLimit versucht, aber so richtig hat es bisher nicht geklappt. Ohne BadItemLimit ging auch nicht. Meines Wissens schlägt der Befehl von vornherein fehl, wenn du das nicht gemacht hast. wir haben ja aber importieren könen, es fehlt eben nur das Gros der Inhalte. Per OWA kommen wir auf das Postfach. Nebenbei bemerkt: der Import kollidiert mit den englischen Namen, es gibt jetzt fröhlich die Kontakte neben den Contacts und die Inbox neben dem Posteingang ... :-\ Aber das kriegen wir noch hin (hoffentlich) ...

Keiner eine Idee zu Unterordnern bei "new-MailboxImportRequest"? ****erweise betrifft diese Einschränkung alles, was Gliederungen hat: Kontakte, Kalender ...

ja, so ist (war) es - bei ca. 45 von 300 Accounts: . nachdem wir die Berechtigungen im AD für "Jeder" auf Vollzugriff gesetzt hatten, konnten wir die Postfächer im Exchange 2010 deaktivieren; anschliessend konnten die User sich aber in der Domäne nicht mehr anmelden! Erst nach Einsetzen des UPN ging´s wieder ...

So, einen hab ich noch: der neue Exchange läuft jetzt und wir importieren die PSTs per New-MailboxImportRequest. Kurioserweise überträgt das Tool NICHT die Inhalte der Unterordner im Posteingang :-( OnTrack hat aber alle Unterordner drin, was auch an der Grösse einiger PSTs zu erkennen ist (User hat bspw. eine 4 GB grosse PST, aber nur wenige Mails im Posteingang und viele, viele in vielen, vielen Unterordnern). Wir könnten natürlich jetzt beigehen und aus Ontrack heraus sämtliche Unterordner einzeln importieren, was aber bei 300 Postfächern nicht so richtig Spass macht :-( Bei Microsoft habe ich dazu nichts gefunden - hat jemand eine Idee dazu?! Irgendwas in der Syntax von New-MailboxImportRequest ... Danke im Voraus! by the way: die ESMs brauchten wir nicht; es genügt, im 2010er-Exchange zu warten, bis die Accounts aus dem AD in der Empfängerliste aufgetaucht sind, dann muss man nur noch auf "Deaktivieren" gehen. Bei einer ganzen Reihe von Usern hatten wir dann dabei eine AD-Berechtigungsfehlermeldung. Zufällig sind wir darauf gestossen, dass diese Konten sich seit Jahr und Tag in der Domäne anmelden können, aber dass das Feld "Anmeldename" leer ist!!! Gediegen!!

Frei nach der italienischen Kaffeewerbung: "isch ´abe doch gar keinen Exchange mehr ... " :-) Wir müssten das schon auf dem PDC durchziehen. Schaun wir mal!

ja! Aber ich habe so ein bisschen die Befürchtung, dass wir, wenn wir eine neue Domäne aufziehen und per Vertrauensstellung anbinden, dieselben Fehlermeldungen erhalten :-\ Frag mich nicht, warum! :cool: Ich such nochmal ein bisschen nach meinem Import-Mailbox-Fehler ...

OK ... :rolleyes: Einen noch: für geben ja ungern auf und sehen inzwischen die User alle im Exchange 2010-Management unter "Empfänger", aber beim Import kommt noch immer folgendes: "Datenbank für Postfach 'Administrator' konnte nicht ermittelt werden. MailboxLacksDatabasePermanentException" Und zu "MailboxLacksDatabasePermanentException" finden sich bei Google ganze 5 Einträge ... :confused: Ich hab das Gefühl, dass wir nicht mehr weit weg sind, wenigstens die alten Postfächer zum Laufen zu bekommen, dann könnten wir die neue Domäne in Ruhe aufziehen ...

das klingt logisch ... :mad: Und auch, wenn das was von Glaskugel-Aussagewert hat: würdest Du, ins Blaue geraten, dem Bereinigen der Attribute oder dem Aufbauen einer neuen Domäne schnellere Verwirklichung zusprechen ... ?! ;)

Vielen Dank! Einen letzten Versuch starten wir gerade noch, verzweifeln dabei aber daran, dass wir beim Erstellen eines Postfachs auf dem Exchange 2010 nur wenige Benutzer aus dem AD sehen. Legen wir bspw. das Postfach "Meier" trotzdem an, gibt es logischerweise eine Warnmeldung, weil Meier eben doch schon im AD vorhanden ist. Der direkte Import der PSTs aus OnTrack per Exchange ManagementKonsole schlägt fehl. Unserem Adminaccount haben wir per Konsole die Berechtigungen zum Import/Export zugewiesen. Es gibt aber die Meldung: Datenbank für Postfach 'Meier' konnte nicht ermittelt werden. + CategoryInfo : InvalidArgument: (empfang-hdd:MailboxOrMailUserIdParameter) [New-MailboxImportRequest] MailboxLacksDatabasePermanentException + FullyQualifiedErrorId : 7BC839AE,Microsoft.Exchange.Management.RecipientTasks.NewMailboxImportRequest Wir haben die PSTs lokal und auf einem Share abgelegt, beides geht nicht. Die Berechtigung für das "Exchange Trusted Subsystem" würden wir gerne hinzufügen, aber das gibt es gar nicht im AD ... Falls da jemand noch eine zündende Idee hat ...

Danke nochmal für eure Tipps! Inzwischen bin ich halbwegs sicher, dass der Fehler primär gar nicht im Exchange lag / liegt, sondern am AD. das ist bereits über mehr als ein Jahrzehnt von diversen Administratoren und über alle möglichen Servergenerationen hinweg immer weitergeschleppt worden, und trotz DSRM und AD-recovery bekommen wir die Probleme mit AD ud Exchange (hauptsächlich mit dem IS-Fehler) nicht weg - mal davon abgesehen, dass die Installation von Exchange 2003 und auch 2010 (sind wir als letzte alternative jetzt drauf ausgewichen) noch nicht ein einziges mal sauber durchgelaufen ist, obwohl wir versucht haben, uns penibel an die bekannten anleitungen (Yusuf ;-), Microsoft) zu halten. Zwischendurch ist dann erneut der FSMO abgeraucht, und mir fiel dann auf, dass es mit dem Informationsspeicherfehler in Exchange und einem zeitgleichen Ausfall des FSMO schon seit einiger Zeit so ging. Nach einer Woche Mehr oder weniger Durcharbeitens mit jeweils kaum mehr als 4 stunden schlaf wissen wir im moment keinen anderen Ausweg mehr, als eine zweite Domäne aufzuziehen, dort ein sauberes 2008er ADS aufzusetzen und einen zweiten Memberserver mit Exchange drin zu installieren. Wenn man sich dann mit dem Server verbinden kann, importieren wir die Postfächer (OnTrack PowerControls ist wirklich ein geniales Produkt und deren Kundenorientierung ist absolut lobenswert!) und sehen zu, ob wir den Usern aus der alten Domäne per Trust Zugriff auf den Exchange gewähren können. Im Herbst migrieren wir dann alle Server sukzessive auf die neue Domain. An Screenshots mit Problemen, die so alle bei der Installation in diesem Netzwerk aufgetreten sind, haben wir jedenfalls inzwischen Dutzende! :cry: "gääähn!"

das sind sicher so manche unter uns ... genau so haben wir es gemacht! ... und diesen Schritt konnten wir schon nicht mehr gehen, da der Exchange ums Verrecken nicht den Informationsspeicher laden wollte. Übrigens trat dieser Fehler in letzter Zeit immer wieder auf, ohne erkennbare Fehler (Logs). Der 2010er steht auch schon bereit, aber der Crash war schneller als wir; mal davon abgesehen, dass wir dem ganzen nicht besonders unruhig entgegengesehen haben - bis Montag nacht dachten wir ja auch noch, dass wir die Postfächer ohne grössere Probleme migrieren könnten. grüsse

Souverän geantwortet :) - hätte ich auch so gemacht! Wobei Öl heutzutage doch so teuer ist :D Du hast sicherlich 1000mal mehr Wissen um Exchange als ich, aber bei den Themen, mit denen ich mich seit Jahren täglich beschäftige, würde ich auch niemals behaupten, nicht noch dazuzulernen. Und was diese ganzen Microsoft-, Linux- oder Apple-Titel manchmal aussagen ... naja ... Wir gehen nochmal den ganzen Weg des Recovers durch, schaun wir mal! Notfalls gibt es OnTrack :( By the Way "Microsofts Doku": :D

Ich weiss. Deswegen haben wir ja auch versucht, die neue Exchangemaschine an die vergurkte alte Exchangeinstallation anzupassen. Die VMWare-Nummer war nicht von uns, sondern von der Vorgängerfirma. Da verwechselst du zwei Dinge! Das Recovery eines DC ist nicht empfohlen - und zwar schlicht aus dem Grund, dass die ADDS-Datenbank inkonsistent wäre und wegen der Kerberosgeschichte (Timestamps!). Und von dcpromo auf einem Exchange rät Microsoft ebenfalls ab. Seit ein paar Jahren lässt Microsoft Virtualisierung des Exchange ausdrücklich zu, allerdings nur auf ihrem eigenen Hyper-V-Zeugs. Eine Datenbank aus einem gesicherten Exchange zu ziehen ist meines Wissens nicht verboten - aber ich kenne auch nicht das gesamte ***-Kompendium. Zwei Tage und Nächte intensiver Fehlersuche würde ich jetzt nicht als blinden Aktionismus bezeichnen; aber es war natürlich noch nicht genug Fehlersuche, da hast Du sicher Recht ... Jetzt muss ICH mal fragen, ob du dich jemals auf den Microsoft-Supportseiten herumgetrieben hast und das von mir angeführte Dokument kennst ... Tipp: such mal einfach nach "exchange adsiedit" bei *** und wundere dich ... Du must dann anschliessend das Ding neu aufbauen und einreihen. Haben wir aber so gemacht! Zeigst du mir die Zitatstelle, an der Microsoft DAS sagt ... ?! :p Auch das findest Du (Microsofts Supportsuche ist dein Freund) - allerdings verbunden mit einer deutlichen Warnung davor, es in einer Produktivumgebug zu tun. Produktiv ist unser Exchange aber schon seit einiger Zeit NICHT mehr ... :-\ Es hat seinen Grund, dass Microsoft das Tool angibt und veröffentlicht. Es gibt Szenarien, wo das funktioniert - hat´s bei uns eben nicht. Aber wir wollen uns hier nicht streiten, sondern den Server wieder zum Laufen bekommen. Vielleicht hilft uns tatsächlich nur noch dies hier: Notfalls machen wir das sogar. Woebi wir für die 2000,- € von OnTrack schon noch einige Zeit arbeiten könnten ...

danke für die schnelle Antwort! Aktueller Stand: - wir haben die Datenbanken aus der Sicherung (die beiden edbs und die stm). - wir haben keinen funktionierenden Mailserver - wir haben aber unsere funktionierende AD DS-Struktur - Exchange ist 2003 - und die Clients haben logischerweise alle keine Mails mehr im Outlook, ausser bei denen, die en Cachemodus an hatten. By the way: wie hättest du´s denn gemacht, so dass es besser funktioniert hätte bzw. welche waren denn unsere gravierendsten Fehler aus deiner Sicht ... ? Wir haben ziemlich strikt versucht, nach Microsofts Anleitungen vorzugehen - und sind erst dann den inoffiziellen Tipps mit "Datenbank neuem Server unterschieben" und dergleichen gefolgt; alles erfolglos. Das hier kennst Du? http://www.microsoft.com/de-de/download/details.aspx?id=85 Wir kennen´s inzwischen - und es hat leider nichts funktioniert.

Hallo zusammen. wir hatten einen Totalausfall unseres Exchangeservers - VMWare-Maschine, die nicht mehr startete. Als wir die Maschine aus dem ShadowProtect wiederhergestellt hatten, liess sich der Informationsspeicher nicht mehr starten. eseutil sagt, dass die Datenbanken sauber wären. exmerge scheitert mit einer Fehlermeldung wegen der Datenbank. Nach vielem Hin und Her haben wir uns entschieden, den Server zu löschen und einen neuen Exchange aufzusetzen. Der Server liess sich aber nicht sauber aus der Domäne nehmen und Exchange liess sich nicht deinstallieren - vermutlich hing das eine am anderen. Da das Gerät auch ein DC ist, aber nicht der FSMO, haben wir ihn dann einfach abgeschaltet - so, als wäre er eben hardwaremässig ausgefallen. Im AD DS die Exchangeeinträge gelöscht, dann wollten wir das Computerkonto zurücksetzen, was nicht ging, weil sich der Exchange ja weigerte, die Domäne zu verlassen. Also haben wir das Computerkonto stumpf gelöscht. Den neuen Server haben wir mit gleicher IP und gleichem Namen versehen und in die Domäne aufgenommen. Exchange haben wir zuerst im DisasterRecovery-Modus versucht zu installieren - kein Erfolg, kein Zugriff auf die (rüberkopierten) Datenbanken aus der Sicherung möglich. Alles wieder auf 0, Computerkonto zurückgesetzt, Exchange erneut installiert, in die Domäne - diesmal als komplette Neuinstallation mit DomainPrep und ForestPrep. Diesmal wollte er die Datenbanken nicht, weil der alte LDAP-Name in den gesicherten Datenbanken bei /o=Organisation,/ou=Erste administrative Gruppe an Stelle der OU den Kurznamen der Firma stehen hatte - wir haben versucht, den Namen mit adsiedit und dann mit LegacyDN zu ändern - das schlug immer fehl :-(( Also den dritten Exchange aufgesetzt und nach Microsofts Anleitung versucht, die Datenbanken wiederherzustellen (Exchange-Tools, dann mit dem Systemmanager die Verzeichnisstruktur angepasst, dann erst den Rest installiert und die Datenbanken rübergeschoben) - ebenfalls Fehlanzeige, Informationsspeicher weigert sich zu starten, weil die Datenbank nicht gelsen werden kann, oder weil die alte Datenbank einen anderen Pfad verwendet, oder weil der übliche interne Verarbeitungsfehler auftritt ... An Fehlermeldungen haben wir inzwischen so viele gesehen, dass bei Microsoft nicht mehr viel ungelesen bleiben kann. Eines unserer Probleme dürfte daherrühren, dass der alte Exchange bereits ein 5.5er war, der seinerzeit in den 2003er überführt wurde - ich kann es mir jedenfalls nicht anders erklären, dass die Verzeichnisstruktur so unkonventionell aussieht ... aber davon abgesehen sollte eine der alten Datenbanken aus den Backups (haben wir tägliche von den letzten Wochen) doch mal in einen neuen Exchange zu integrieren sein!? Was könnten wir jetzt noch anfangen? Jemand eine zündende Idee, oder stehen wir vielleicht auf dem Schlauch und sehen den Wald vor lauter Bäumen nicht? Vielen Dank im Voraus! Grüsse lasseboo

moin, hirgelzwift, danke für deine reply. der 2003er soll in etwa einem halben jaahr den nt als (p)dc ersetzen, aber vorerst lediglich der domäne beitreten. muss ich WINS auf dem 2003er besonders konfigurieren? danke & gruss lasseboo