Exchange 2013 Migration und FolgeFehler

[pitcare 0]

Hallo zusammen,

 

nach der Migration von Exchange 2010 auf 2013 gibt es jetzt noch einige kleinere Fehler zu beheben.

 

Meine Konfig:

Windows Server 2012 R2 

Exchange Server 2013 Build 847.32

Clients Outlook 2013

 

Ereignislogs:

Der Leistungsindikator '\\EXCHANGE2013\LogicalDisk(C:)\Free Megabytes' hatte während des 15-minütigen Intervalls mit Start bei '05.12.2014 08:11:00' einen Wert von '7.320,00'. Weitere Informationen: None. Triggername:DatabaseDriveSpaceTrigger. Instanz:c:
Der Leistungsindikator '\\EXCHANGE2013\LogicalDisk(HarddiskVolume1)\Free Megabytes' hatte während des 15-minütigen Intervalls mit Start bei '05.12.2014 08:11:00' einen Wert von '59,00'. Weitere Informationen: None. Triggername:DatabaseDriveSpaceTrigger. Instanz:harddiskvolume1

Die Meldung schien ein Bug zu sein bis zum CU 3. Taucht bei aber immer noch als Fehler im Eventlog auf und das leider ständig.

 

 

Fehler des Informationsspeichertreibers beim Übermitteln von Ereignis "3456649", Postfach "8ae80c57-00b2-49b5-b9da-2acf26ade72c", MDB "66d9d0a3-6fdf-4499-80bd-67d85bddd2ab". Wegen der Ausnahme "Microsoft.Exchange.MailboxTransport.StoreDriverCommon.InvalidSenderException

   bei Microsoft.Exchange.MailboxTransport.Shared.SubmissionItem.SubmissionItemUtils.CopySenderTo(SubmissionItemBase submissionItem, TransportMailItem message)

   bei Microsoft.Exchange.MailboxTransport.Submission.StoreDriverSubmission.MailItemSubmitter.GenerateNdrMailItem()

   bei Microsoft.Exchange.MailboxTransport.Submission.StoreDriverSubmission.MailItemSubmitter.<>c__DisplayClass1.<SubmitNdrForFailedSubmission>b__0()

 

   bei Microsoft.Exchange.MailboxTransport.StoreDriverCommon.StorageExceptionHandler.RunUnderTableBasedExceptionHandler(IMessageConverter converter, StoreDriverDelegate workerFunction)" konnte kein Unzustellbarkeitsbericht generiert werden.

 

 

 

Speicher:

Der Exchange hat 12 GB Arbeitsspeicher und 4 CPU. Anfangs habe ich ihn mit 8 GB laufen lassen, eine Erhöhung des Arbeitsspeichers hat an der unten stehenden Meldung nichts geändert. Er nimmt sich alles was er kriegt :-)

Information Store - DB01 (6976) Ein erheblicher Teil des Datenbankcaches wurde in die Auslagerungsdatei des Systems geschrieben. Dies kann zu einer erheblichen Leistungsverringerung führen. 
Ausführliche Informationen zu den möglichen Ursachen finden Sie über den Hilfelink. 
Vorheriger Zustand vorhandener Cache: 85% (22725 von 26733 Puffern) (vor 1140 Sekunden). 
Aktueller Zustand vorhandener Cache: 79% (21374 von 26733 Puffern). 
Aktuelle Cachegröße gegenüber Ziel: 99 % (764.496 / 767.938 MB) 
Physischer Arbeitsspeicher/RAM-Größe:     12287.488 MB

Postfachregeln:

Ich habe nach der Migration bei den betreffenden Usern die Regeln komplett gelöscht und wieder neu angelegt. Das manuelle Ausführen der Regeln funktioniert einwandfrei. Clientseitig schliesse ich den Fehler aus, da auch im OWA der Fehler auftritt, wenn ich dort die Regeln neu anlege. Mir scheint also so, als wäre die Ursache direkt beim Exchange zu suchen.

 

Vielleicht gibts ja jemanden der noch ähnliche Probleme hat. Würde mich über einen Austausch freuen. CU6 werde ich noch nachziehen, das wird aber an den bestehenden Problemen so weit ich das erlesen konnte nichts helfen.

 

 Grüße

Stefan

 

[RobertWi 81]

Moin,

 

ein Update wird sicher nicht schaden. IMHO wurde im CU6 (oder evt. auch erst im demnächst erscheinenden CU7) auch was an den Indikatoren geschraubt.

 

Über wie viele Benutzer reden wir denn?

 

Und was ist denn nun wirklich das Problem? Viele Eventlog Einträge sind bei Exchange üblich und nichts besonderes - solange man keine negativen Folgen merkt.

[pitcare 0]

Hi Robert,

 

Es gibt ca. 100 Postfächer auf dem Server. Die Meldung mit dem Speicher führt wahrscheinlich dazu, das die Sicherung vom Backup nicht ganz ohne Fehler verläuft, B2D funktioniert noch einwandfrei, nachfolgende Sicherung auf Tape soll lt. Symantec Knowlegebase mit fehlenden Ressourcen zusammenhängen. Für 32 bit Systeme gab es hier noch eine Lösung, da hier die gleiche Fehlermeldung den selben Fehler produzierte wie ich ihn jetzt habe. (http://support.microsoft.com/KB/304101) 

Ansonsten ist es natürlich ärgerlich wenn Postfachregeln nicht mehr funktionieren, das kann ich nicht weg ignorieren. 

[RobertWi 81]

Moin,

 

12 GB RAM dürften für 100 Postfächer zu wenig sein. Da würde ich mindestens 24 GB vorsehen.

 

Ansonsten wäre es schön, wenn Du wirklich die Fragen und Probleme mal nennen würdest.

 

Eingangs schreibst Du, dass Du Posteingangsregeln gelöscht hast. Und erst hier, dass es damit irgendein Problem gibt, aber welches verschweigst Du uns immer noch.

 

Dann kommen plötzlich Backup-Probleme ins Spiel, die Du auf zu wenig RAM schiebst, aber einen KB-Artikel postest, der etwas mit der Festplatte zu tun hat.

 

Die meisten von uns sind keine Hellseher und wenn Du Deine Probleme nicht beschreibst, sondern nur, wie Du irgendwas änderst, dann werden wir Dir nur schwer helfen können.

[NeMiX 76]

Dein B2D wird ja vom Exchange auf einen Backupstore geschoben, der anschließende B2T Job ist ein Copy Job und hat dann nichts mehr mit dem Exchange am Hut.

Da solltest du eher schauen was der Backupserver für Errors produziert.

[pitcare 0]

In der Regel fällt es mir schwer Fehlermeldungen in Servern zu ignorieren, und nur darauf zu reagieren wenn irgendwo nichts mehr geht. Deswegen hatte ich u.a. auch die beiden Exchange Meldungen oben mit in den Post aufgenommen, um zu sehen, ob jemand hier im Forum gleichlautende Meldungen hat. Meistens ist man damit eben nicht alleine.  Von einem gut geschrieben Blog hatte ich die Empfehlung 12 GB, 4 CPU für unsere Größenordnung übernommen. Ich werde den Speicher erhöhen, ein Versuch ist es wert.

 

Problem 1:

Die angelegten Postfachregeln funktionieren nicht automatisch nach der Migration, sondern nur wenn man das Regelwerk händisch ausführt. Da habe ich mich vielleicht nicht ganz klar ausgedrückt. Das ist nicht bei allen Postfächern, sondern nur einige wahllos. 

 

 

ich habe nach der Migration bei den betreffenden Usern die Regeln komplett gelöscht und wieder neu angelegt. Das manuelle Ausführen der Regeln funktioniert einwandfrei. Clientseitig schliesse ich den Fehler aus, da auch im OWA der Fehler auftritt, wenn ich dort die Regeln neu anlege. Mir scheint also so, als wäre die Ursache direkt beim Exchange zu suchen

 

Problem 2:

Das der BackupJob c2t nichts mehr mit dem Exchange zu tun hat glaube ich allerdings nicht mehr, hierfür gibts bei ähnlichen Fällen einige Knowlege Bases bei Symantec die etwas anderes aussagen. Das Problem ist hier, das GRT beim Tape Copy Job nicht richtig funktioniert, (einer der beliebten VFF Writer Fehler)  beim  B2D funktioniert das noch. Die unten stehende Fehlermeldung nur zur Info. 

 

 

 

Auftragsabschlussstatus Auftrag beendet am Donnerstag, 4. Dezember 2014 um 20:18:38
Abschlussstatus: Fehlgeschlagen
Endgültiger Fehler: 0xe00002f7 - Ein Extrahieren der Postfachnachrichten aus dem Exchange-Backup ist nicht möglich. Im Auftragsprotokoll finden Sie zusätzliche Informationen.

Endgültige Fehlerkategorie: Ressourcenfehler

Zusätzliche Informationen zu diesem Fehler finden Sie unter der Verknüpfung V-79-57344-759
 
Fehler

Klicken Sie auf eine der unten aufgeführten Fehlermeldungen, um den Fehler im Auftragsprotokoll zu finden

 

Kopie- \\EXCHANGE2013\Microsoft Information Store\DB01
V-79-57344-759 - Kann den Vorgang aus folgenden Gründen nicht abschließen: VFF-Fehler beim Öffnen. Dies kann durch zu wenig Arbeitsspeicher oder Datenträgerressourcen verursacht werden.
 

[RobertWi 81]

Moin,

 

zu Fehlermeldungen im Eventlog: Es ist einfach so, dass Exchange sehr viel protokolliert und nicht alles davon unmittelbare Auswirkung hat oder eine unmittelbare Reaktion erfordert. Es gehört mit zu Erfahrung eines Exchange-Admins zu erkennen, wann ist ein Fehler von außen induziert (z.B. weil ein DC neugestartet wurde), wann ist ein Fehler einmalig und man wartet ab, ob er sich wiederholt und ab wann muss man sofort reagieren. 

 

Zum Problem 1: Versuch das mal näher zu analysieren. Betrifft es nur migrierte Konten? Betrifft es auch neue Konten? Funktionieren neue Regeln nach dem Aufräumen wieder? Wie wird aufgeräumt? Outlook.exe /cleanrules oder MFCMAPI können notwendig sein. Gibt es beim Ausführen der Regeln eine Fehlermeldung im Eventlog dies sich dem Vorgang zuördnen lässt?

 

Zum Problem 2; Symantec.... seufz. Muss ich mich leider auch mit rumschlagen. Erste Regel: Prüfen, ob Du die aktuellste Version benutzt - bis auf die vierte Stelle. Wenn nicht, aktualisieren. Und niemals auf Versprechungen verlassen, dass da mit der Version schon funktionieren müsste. Ich habe bei denen grundlegende Funktionaleänderungen erlebt, obwohl sich die Versionsnummer nur an der vierten Stelle änderte.

 

Und wichtig auch hier: Prüfen, welche Abhängigkeit GRT eventuell zum CU hat. Es wäre leider auch aus Exchange nicht das erste Mal, dass nach einem CU das Backup nicht mehr sauber funktioniert.

 

Und natürlich: Auf die neueste Version von Exchange updaten. Muss nicht helfen, aber es ist müßig ein Problem zu suchen, dass eventuell schon längst gefixt wurde.

[pitcare 0]

Hi Robert,

 

bezüglich Outlook, hier hatte ich die Regeln händisch aus Outlook bzw. aus OWA gelöscht, gerade aber auch nochmal per cmd, allerdings erbringt eine Neuerstellung einer Regel keinerlei Änderung. Ich erhalte auch keinerlei Fehlermeldung. Bei uns sind übrigens alle Postfächer vom alten Exchange migriert. Die Nichtfunktion der Regeln betrifft auch nur einige Postfächer. Im Eventlog sind keine Fehler zu sehen, lediglich die Info nach dem Start des Programms das die u.a Postfachregeln angewandt werden. Seltsame Geschichte. Die Regeln an sich müssten aber auch laufen wenn ich ohne Outlook arbeite, also direkt im Webinterface funktionieren, auch dort hat das löschen und Wiederhinzufügen einer Regel keine Änderung gebracht. 

 

bezüglich Symantec:

Hier habe ich die aktuelleste Version von Backup Exex 2014 Version 14.1.1786 im Einsatz, (SP1 und einem aktuellen Hotfix, bei dem es auch um einen ähnlichen Bug ging.

http://www.symantec.com/business/support/index?page=content&id=TECH225092

 

Ich werde als nächstes das CU 6 nachziehen. Vielen Dank erstmal für Deine Beitrag.

 

Stefan