none
Exchange Server 2010 SP3: Kein Zugriff auf die Postfächer nach Migrationscrash RRS feed

  • Frage

  • Hallo und einen schönen Abend zusammen!

    Ohne große Umschweife komme ich auch schon zu meinem Problem:

    In unserem Unternehme wurde bis vor kurzem der Exchange Srv 2010 SP3 eingesetzt. Aufgrund eines Hardwarewechsel sollte auh der Exchange auf den neueste Stand gebracht werden. Die Migration der Postfächer auf Exchange 2013 lief auch zunächst ohne Probleme bis nach und nach alles den Geist aufgab. Kurzum: Wir haben eine saubere Exchange Server 2010 Installation auf einen anderen physischen Server vorgenommen.

    Nach langen Probieren und mit der "Holzhammermethode" konnte ich ein Backup der damaligen 2010-Datenbank unter dem neuen Server 2010 auf der o.e. anderen Hardware einbinden und die Postfächer werden mir endlich angezeigt. Dabei musste ich folgende Anleitung nutzen, da es sonst nie zum Erfolg kam: http://www.frankysweb.de/exchange-2010-datenbank-wiederherstellen-die-holzhammer-methode/

    Nun stellt ich aber folgendes Problem: Weder das Verschieben der Postfächer auf eine neue Datenbank noch das Aufrufen selbiger per Outlook/OWA/ActiveSync ist möglich. Emails werden sauber über unsere Firewall an den Exchange ausgeliefert, aber der User kann sich nicht mit seiner Mailbox verbinden.

    Per OWA kommt folgender Fehler:

    Problem bei der Verwendung des Postfachs.
    
    
    Request
    Url: https://MAILSERVER.de:443/owa/
    User: Krupski, Lars
    EX Address: /o=DOMÄNE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Krupski, Larsb82
    SMTP Address: Krupski@DOMÄNE.de
    OWA version: 14.3.224.2
    
    Exception
    Exception type: Microsoft.Exchange.Data.Storage.StoragePermanentException
    Exception message: Unable to read this mailbox's folder data in order to determine if the default folders are present.

    Outlook verweigert den Dienst mit folgender Meldung (neues Profil, etc. wurden bereits erfolglos versucht und der Server ist erreichbar und nicht Offline):

    Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Microsoft Exchange ist nicht verfügbar. Es bestehen Netzwerkprobleme, oder der Servercomputer mit Exchange wurde für Wartungsarbeiten heruntergefahren.


    Und schlussendlich bekomme ich folgende Fehlermeldung beim Verschieben der Postfächer in eine neue Datenbank:

    Zusammenfassung: 1 Element(e). Erfolgreich: 0, Fehler: 1.
    Verstrichene Zeit: 00:00:01
    
    
    Krupski, Lars
    Fehler
    
    Fehler:
    MapiExceptionNotFound: Unable to get properties on object. (hr=0x8004010f, ec=-2147221233)
    Diagnostic context:
        Lid: 55847   EMSMDBPOOL.EcPoolSessionDoRpc called [length=72]
        Lid: 43559   EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=278][latency=0]
        Lid: 23226   --- ROP Parse Start ---
        Lid: 27962   ROP: ropOpenFolder [2]
        Lid: 17082   ROP Error: 0x8004010F
        Lid: 21857  
        Lid: 21921   StoreEc: 0x8004010F
        Lid: 27962   ROP: ropExtendedError [250]
        Lid: 1494    ---- Remote Context Beg ----
        Lid: 26426   ROP: ropOpenFolder [2]
        Lid: 21097  
        Lid: 39027   dwParam: 0xEC1C48
        Lid: 8756    StoreEc: 0xFFFFF9BF
        Lid: 58685  
        Lid: 63603   dwParam: 0xEC1C48
        Lid: 50493   StoreEc: 0x8004010F
        Lid: 49161  
        Lid: 6719    StoreEc: 0x8004010F
        Lid: 7007    StoreEc: 0x8004010F
        Lid: 48671  
        Lid: 1750    ---- Remote Context End ----
        Lid: 27962   ROP: ropGetPropsSpecific [7]
        Lid: 17082   ROP Error: 0x4B9     
        Lid: 26465  
        Lid: 21921   StoreEc: 0x4B9     
        Lid: 27962   ROP: ropExtendedError [250]
        Lid: 1494    ---- Remote Context Beg ----
        Lid: 26426   ROP: ropGetPropsSpecific [7]
        Lid: 36739  
        Lid: 1750    ---- Remote Context End ----
        Lid: 26849  
        Lid: 21817   ROP Failure: 0x4B9     
        Lid: 20385  
        Lid: 28577   StoreEc: 0x8004010F
        Lid: 32001  
        Lid: 29953   StoreEc: 0x8004010F
    
    Ausführungsversuch eines Exchange-Verwaltungsshellbefehls:
    'DOMÄNE.de/UO1/UO2/UO3/Krupski, Lars' | New-MoveRequest -TargetDatabase 'Mailbox Database 0249339200'
    
    Verstrichene Zeit: 00:00:01
    

    So langsam bin ich mit meinem Latein am Ende. Die Datenbank befindet sich im "Clean Shutdown" und passiert erfolgreich sämtliche Tests (z.B. Integrationstest). Die Mailboxen wurden alle per "Set-Mailbox NAME -ApplyMandatoryProperties" auf die nun installierte Exchange-Version gestellt und per "New-MailboxRepairRequest" getestet und repariert. Alles ohne Erfolg...

    Kennt ihr im Forum jemand eine Lösung wie die User wieder ihre Mailboxen öffnen können?

    Beste Grüße
    Lars Krupski

    Mittwoch, 25. Februar 2015 18:18

Antworten

  • So...nachdem ich zwei Tage mit dem Exchange-Support gesprochen habe (nette Jungs!) sind wir zu folgendem Ergebnis gekommen:

    Die Datenbanken waren durch das Hin- und wieder zurück Migrieren derart kaputt, dass die Postfächer nicht mehr zu retten waren. Einzige Lösung war das Deaktivieren der Postfächer, die anschließende Erstellung neuer Benutzerpostfächer und das Einlesen der PST-Dateien (Gott sei Dank hatten wir den Cache-Modus an!).

    Somit ist das Problem vom Tisch und ich eine Weisheit reicher ;)

    Gruß

    Lars

    • Als Antwort markiert Lars Krupski Freitag, 27. Februar 2015 12:00
    Freitag, 27. Februar 2015 11:59

Alle Antworten

  • Hmm 2 Ideen, kannst du per MFCMAPI schauen ob du "Default" Ordner vorhanden sind? Oder versuch mal per "Set-MailboxRegionalConfiguration" die DefaultFolderNames auf eine Sprache neu zu setzen.

    Ansonsten ist der Weg den du gegangen bist schon ziemlich "brutal", von daher scheint ein Ticket bei MS auch nicht zu schaden.

    Mittwoch, 25. Februar 2015 18:51
  • Hmm 2 Ideen, kannst du per MFCMAPI schauen ob du "Default" Ordner vorhanden sind? Oder versuch mal per "Set-MailboxRegionalConfiguration" die DefaultFolderNames auf eine Sprache neu zu setzen.

    Ansonsten ist der Weg den du gegangen bist schon ziemlich "brutal", von daher scheint ein Ticket bei MS auch nicht zu schaden.

    Hallo Jörg,

    das "Set-MailboxRegionalConfiguration" hat leider nichts gebracht. 

    Bzgl. der Default Ordner in der MFCMAPI: Kannst du mir das genauer erklären? Habe damit bisher noch nicht gearbeitet.

    Ja ich weiß...leider wollte es einfach anders nicht funktionieren. Ich kann aber auch nicht ganz nachvollziehen warum ich einfach nicht auf die Postfächer zugreifen kann. Alles funktioniert mittlerweile ordnungsgemäß nur dieser, und entschuldige meine Wortwahl, verdammte Zugriff nicht.

    Kann ich vielleicht auch nochmal etwas zurückrudern? Hast du vielleicht dazu eine Idee?

    Vielen Dank!

    Mittwoch, 25. Februar 2015 19:48
  • Moin,

    @Jörg: Das Vorgehen ist zwar ein wenig "ungewöhnlich" beschreiben, aber eigentlich es nichts anders, als die offizielle erlaubte und dokumentierte Datenbank Portabilität.

    Hier findet man die Anleitung und sie passt bis in weiten Teilen gut zu Franks Seite:

    https://technet.microsoft.com/de-de/library/dd876926%28v=exchg.150%29.aspx

    Das ist etwas, dass ich in jedem zweiten Kurs zeige, und das grundsätzlich funktioniert.

    @Lars: MFCMAPI ist eine externes "Low-Level Outlook". Ich würde wie Jörg auch mal damit einen Blick ins Postfach werfen. Hier schreibt Frank recht gut, wie das geht:

    http://www.msxfaq.de/tools/mfcmapi.htm

    Du müsstest damit im Postfach einen "IPM_SUBTREE" finden mit den passenden Ordnern, wie "Posteingang" usw.

    Der oben beschriebene Fehler "0x8004010f" sagt erst mal grundsätzlich, dass ein erforderliches Objekt nicht gefunden wurde. Mit anderen Worte: Das kann alles oder nichts sein.

    Ich vermute, Du hast irgendeinen Fehler beim "harten Wiederherstellen" gemacht. Welchen, kann ich nicht sagen, Du beschreibst ja nicht Deinen Vorgang.

    Wenn Du noch einen Datensicherung hast, würde ich den Vorgang zuerst wiederholen. Wichtig ist unbedingt, dass die Exchange Version 100% übereinstimmen. Es ist nicht möglich, ein DB mit Stand SP2 in einen neuen Exchange 2010 mit Stand SP 3 zu recovern. Hier muss im Zweifelsfall bis auf das RU der neue Exchange identisch sein.

    Eventuell führst Du vorher auch noch mal eine "Clean-Mailboxdatabase DATENBANK" aus. Danach wartest Du ein wenig und schaust, ob die Postfächer nun verschwinden und als getrennte Postfächer auftauchen. Verspreche ich mir aber nichts von.

    Na ja, und ganz am Ende bleibt noch die Möglichkeit, die Datenbank mit einem externen Tool zu öffnen und die Daten zu exportieren. PowerControlls von Ontrack ist das beste am Markt. Einen Versuch ist aber auch der kostenlose Veeam Exchange Explorer wert.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 25. Februar 2015 21:14
  • Moin,

    @Jörg: Das Vorgehen ist zwar ein wenig "ungewöhnlich" beschreiben, aber eigentlich es nichts anders, als die offizielle erlaubte und dokumentierte Datenbank Portabilität.

    Hier findet man die Anleitung und sie passt bis in weiten Teilen gut zu Franks Seite:

    https://technet.microsoft.com/de-de/library/dd876926%28v=exchg.150%29.aspx

    Das ist etwas, dass ich in jedem zweiten Kurs zeige, und das grundsätzlich funktioniert.

    @Lars: MFCMAPI ist eine externes "Low-Level Outlook". Ich würde wie Jörg auch mal damit einen Blick ins Postfach werfen. Hier schreibt Frank recht gut, wie das geht:

    http://www.msxfaq.de/tools/mfcmapi.htm

    Du müsstest damit im Postfach einen "IPM_SUBTREE" finden mit den passenden Ordnern, wie "Posteingang" usw.

    Der oben beschriebene Fehler "0x8004010f" sagt erst mal grundsätzlich, dass ein erforderliches Objekt nicht gefunden wurde. Mit anderen Worte: Das kann alles oder nichts sein.

    Ich vermute, Du hast irgendeinen Fehler beim "harten Wiederherstellen" gemacht. Welchen, kann ich nicht sagen, Du beschreibst ja nicht Deinen Vorgang.

    Wenn Du noch einen Datensicherung hast, würde ich den Vorgang zuerst wiederholen. Wichtig ist unbedingt, dass die Exchange Version 100% übereinstimmen. Es ist nicht möglich, ein DB mit Stand SP2 in einen neuen Exchange 2010 mit Stand SP 3 zu recovern. Hier muss im Zweifelsfall bis auf das RU der neue Exchange identisch sein.

    Eventuell führst Du vorher auch noch mal eine "Clean-Mailboxdatabase DATENBANK" aus. Danach wartest Du ein wenig und schaust, ob die Postfächer nun verschwinden und als getrennte Postfächer auftauchen. Verspreche ich mir aber nichts von.

    Na ja, und ganz am Ende bleibt noch die Möglichkeit, die Datenbank mit einem externen Tool zu öffnen und die Daten zu exportieren. PowerControlls von Ontrack ist das beste am Markt. Einen Versuch ist aber auch der kostenlose Veeam Exchange Explorer wert.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Hallo Robert,

    vielen Dank für deine ausführliche Antwort!

    Nun hat sich kurioserweise etwas getan. Ich habe genau einen von 80+ Usern, die eine Verbindung mit ihrem Client zum Exchange aufbauen und Emails senden und empfangen können!

    Können wir aus dieser Erkenntnis etwas ziehen? Kann ich die Postfächer kontrollieren und die Unterschiede herausfinden und bei den anderen ausmerzen?

    Gruß

    Lars

    // EDIT //

    Nach der Überprüfung aller Attribute durch "Get-Mailbox EMAIL@DOMÄNE.de | format-list *" von dem funktionierenden und einem beliebigen Postfach haben sich folgende UNterschiede ergeben:

    Attribute: ExchangeGUID ->
    sind unterschiedlich. Ist das so richtig? Sollte diese nicht gleich sein, da es der selbe Exchange-Server ist (wir haben nur einen im Unternehmen)

    Attribute: Office ->
    beim funktionierenden Postfach steht "114" bei den anderen "207"

    Attribute: UserCertificate ->
    beim funktionierenden Postfach steht "{}" bei den anderen eine Zeichenfolge

    Könnt ihr euch dazu etwas reimen?


    • Bearbeitet Lars Krupski Donnerstag, 26. Februar 2015 09:28
    Donnerstag, 26. Februar 2015 08:44
  • So...nachdem ich zwei Tage mit dem Exchange-Support gesprochen habe (nette Jungs!) sind wir zu folgendem Ergebnis gekommen:

    Die Datenbanken waren durch das Hin- und wieder zurück Migrieren derart kaputt, dass die Postfächer nicht mehr zu retten waren. Einzige Lösung war das Deaktivieren der Postfächer, die anschließende Erstellung neuer Benutzerpostfächer und das Einlesen der PST-Dateien (Gott sei Dank hatten wir den Cache-Modus an!).

    Somit ist das Problem vom Tisch und ich eine Weisheit reicher ;)

    Gruß

    Lars

    • Als Antwort markiert Lars Krupski Freitag, 27. Februar 2015 12:00
    Freitag, 27. Februar 2015 11:59