Markus’ Messaging Blog

Ein Weblog rund um das Thema Messaging

Archiv für September 2007

Exchange 2007 "Calendaring Agent" meldet EXCDO Events 8199, 8206 und 8213 bei mehr als 1300 Serienterminen

Verfasst von Markus Mohmeyer am [28/09/2007]

Alarm Alarm

Was so sicher ist wie das “Amen in der Kirche”, das ist, dass aktuell sicher viele Exchange Systemingenieure, Administratoren und Dienstleister in Microsoft Exchange Umgebungen eine Migration von Exchange 2000/2003 auf Exchange 2007 durchführen. Dabei gibt es derzeit eine Besonderheit, in die vielleicht schon einige gelaufen sind ohne es zu wissen.

Es kam also der Zeitpunkt, dass nach einer ausführlichen und sauberen Exchange 2007 Planung, diversen Tests mit positiven Ergebnissen, auch die ersten produktiven Postfächer mit der Exchange 2007 Management Console auf den neu installierten Exchange 2007 CCR-Cluster migriert werden konnten. Unter Verwendung des “Move Mailbox Wizards” wurde jede Nacht zeitgesteuert ein Migrationsjob eingestellt, welcher anfangs eine kleine Anzahl und später auch viele Postfächer am Stück automatisiert nach Exchange 2007 migrierte.

Wir waren begeistert wie gut die Migration voran ging, bis eines Morgens das Monitoring System meldete, dass die Anzahl der Exchange Transaktionsprotokolldateien dramatisch anstieg und die Kapazität der DB Logfile-Festplatte gegen Null ging. Im letzten Blog Beitrag habe ich bereits von der Aktion mit dem vollgelaufenen Logfile-Laufwerk berichtet.

 
Such den Fehler

Ein Blick in die Windows Anwendungs-Eventlogs der beiden CCR-Cluster Knoten ließ uns “rot sehen“. Da waren endlos viele der folgenden drei Fehlermeldungen vorhanden, die sich ewig wiederholten…

Application Eventlog:

Event Type:     Error
Event Source:   EXCDO
Event Category: General
Event ID: 8199
Date:     21.09.2007
Time:     03:35:28
User:     N/A
Computer: <ClusterNodeName>
Description:
Calendaring agent failed in message save notification with error 0×800703eb on <EMailAdresse@domain.de>:

/Kalender/xxxxxyyyyyzzzzz.EML.

Application Eventlog:

Event Type:     Error
Event Source:   EXCDO
Event Category: General
Event ID: 8206
Date:     21.09.2007
Time:     03:35:28
User:     N/A
Computer: <ClusterNodeName>
Description:
Calendaring agent failed with error code 0×80040215 while saving appointment.

Application Eventlog:

Event Type:     Error

Event Source:   EXCDO

Event Category: General

Event ID: 8213

Date:     21.09.2007

Time:     03:35:28

User:     N/A

Computer: <ClusterNodeName>

Description:

Calendaring agent failed to update the free/busy cache during an appointment save or delete operation.

“Calendaring Agent” Fehlermeldungen also… ich erinnerte mich, dass wir unter Exchange 2000 schon einmal eine ähnliche Situation hatten… die Geschichte mit “MSExchangeFBPublish” und dem fehlenden Eintrag in der Registry. Eine kurze Suche in der Microsoft KnowledgeBase brachte mir dann auch wieder den Artikel, der damals geholfen hatte…

310440  You receive an “unable to perform the operation” error message when you save Calendar items in Exchange 2000 and Exchange 2003

Kurz die Werte in der Registry beider Clusterknoten überprüft und wir konnten ausschliessen, dass dies die Lösung war. Schade! Also weitersuchen…

Bei den sich wiederholenden Event IDs im Anwendungs-Eventlog war zu erkennen, dass es sich nicht nur um ein Postfach, sondern um mehrere, genau genommen um drei Postfächer handelte. Da bereits viele andere produktive Postfächer auf dem Exchange 2007 Server arbeiteten, konnten wir nicht lange experimentieren und so wurden die drei problematischen Mailboxen zurück nach Exchange 2000 verschoben.
Ich hatte die Vermutung, dass eventuell inkonsistente Elemente in den Postfächern waren und dass der “Move Mailbox Wizard” beim Zurückverschieben vielleicht diese Fehler erkennt, meldet und “korrigiert”, bzw. die möglichen defekten Elemente nicht mit verschiebt. Aber Pustekuchen! Auch nicht ein fehlerhaftes Element wurde beim zurück migrieren gefunden.

Immerhin war nach dem Verschieben der Postfächer jetzt aber Ruhe im Eventlog. Also als Gegenprobe das selbe Postfach wieder von Exchange 2000 Richtung 2007 zurück migrieren, in der Erwartung, dass der Fehler reproduziert werden kann.
Und wirklich… kaum liegt das eine der drei problematischen Postfächer wieder auf der 2007er Maschine – schon geht der Ärger wieder los und die “Calendaring Agent” Fehlermeldungen (EXCDO 8199, 8206 und 8213) kommen zurück. Nicht schön, aber immerhin ist eine Reproduktion möglich! :-)

Aufgrund der besonderen Brisanz der Situation, haben wir die folgenden Schritte gemeinsam mit MS PSS (Microsoft Product Support Services) durchgeführt.

Beim Öffnen eines Microsoft Case ist es immer von Vorteil direkt einen aktuellen ExBPA-Auszug und einen MPSReport mitzuschicken und so haben wir diese auch gleich noch schnell vorab eingesammelt.
Das Microsoft Exchange Support Team hat schnell die Brisanz der Situation erkannt. Der Case wurde entsprechend hoch priorisiert und nach wenigen Stunden und dem Durchlaufen der Standardanalysen hatten wir den passenden “Escalation Engineer” im Boot.

Wir kamen jetzt in die Situation, wo ein weiteres Postfach plötzlich begann die bekannten Fehler auf dem Exchange Server zu produzieren und auch dieses Postfach musste zur Sicherheit seinen Weg zurück nach Exchange 2000 gehen. Sehr seltsam alles… Postfächer, die offensichtlich unter Exchange 2007 erst sauber funktionieren und zu irgendeinem Zeitpunkt fehlerhaft werden und dann sogar den Server selbst stören. Alle Beteiligten forschten nun parallel in unterschiedliche Richtugen…

  1. Ich begab mich mit meinem besten “virtuellen Freund” GOOGLE auf die Suche nach dem Unbekannten
     
  2. Unser Microsoft Engineer forderte einige unserer Exchange Transaction Logs vom kritischen Zeitpunkt, um diese anhand eines interessanten Blog Artikels von Scott Oseychik hinsichtlich der Inhalte zu analysieren
     
  3. …und ein Kollege versuchte ein leeres Postfach auf Exchange 2007 mit Daten eines der kritischen Postfächer zu befüllen, um eine weitere Reproduktion zu erzielen

 
In die richtige Richtung geforscht

Kaum zu glauben, aber alle drei Richtungen in die wir forschten brachten Ergebnisse und trugen ein Puzzlestück zur Findung der Ursache bei.

Meine GOOGLE-Suche ergab, dass tatsächtlich zumindest noch ein weiterer Mensch auf dieser Welt exakt das gleiche Fehlerbild wie wir hatten. Zyg Furmaniuk aus Cambridge (Massachusetts) berichtet in seinem Blog Posting vom selben Problem und er liefert uns sogar handfeste Ergebnisse von seinen Analysen.

Der Ansatz unseres Microsoft Engineers brachte als Ergebnis, dass eine ungewöhnlich hohe Anzahl an Transaktionen zu Terminen innerhalb der Logfiles zu sehen waren…

…
576 Geburtstag von J
576 ln) [Geburtstag%3B Nat
1107 IPM.Microsoft.ScheduleData.FreeBusy
1261 anrufen nicht vergessen) [Einkaufen%3B Geburtstag%3B Nat
6457 ln) [Party%3B Hans%3B Nat
6958 Geburtstag Markus
17397 IPM.Appointment.Termin
69758 IPM.Appointment.Termin
...

Die Aktion mit dem Import der Daten aus einem kritischen Postfach brachte das gleiche Ergebnis wie in Zyg Furmaniuks Blog Beitrag. Beim Import kam genau an der Stelle, bei der mehr als 1300 Objekte im Kalender waren die folgende Speicherfehlermeldung.

Für diesen Vorgang steht nicht genügend Arbeitsspeicher zur Verfügung.

 
Die Reproduktion des Fehlers ist denkbar einfach...

  • einfach 1300 Serientermine in einem Echange 2007 Postfach erstellen
  • beim Erstellen eines weiteren Serientermins kommt dann ohne Umwege die Fehlermeldung (unten)
  • im Exchange Application Eventlog tauchen die EXCDO Calendaring Fehler auf
  • und es ist auffällig, dass für einen Moment viele Exchange Transaktionprotokolle geschrieben werden

1301-Termine

 
Aber Was ist denn nun die Ursache?

Unser Microsot Engineer stellte nun weitere Nachforschungen an.
Und tatsächlich im Code von Exchange 2007 ist offensichtlch ein Verhalten ersichtlich, das auch in der Vergangenheit schon einmal existiert hat. Bei mehr als 1300 "Recurring Appointments" (Serienterminen) hat Exchange eine feste Begrenzung im Code und übergibt Outlook einen Speicherfehler.

Das unter Exchange 2000 und 2003 bestandene Verhalten wurde bereits mit folgenden Softwareaktualisierungen bei den "alten Exchange Versionen" behoben:

Etwas seltsam ist das Verhalten von Exchange 2007 selbst mit migrierten Postfächern, die über 1300 Serientermine aufweisen. Erst an einem undefinierten Zeitpunkt (dies ist offensichtlich nicht zwingend der Zugriff per MAPI oder Exchanage ActiveSync auf den Kalender) merkt Exchange, dass sich zuviele Serientermine im Kalender befinden. Wenn Exchange dies aber erkannt hat, dann versucht der "Calendaring Agent" permanent das Objekt neu zu schreiben. Damit beisst sich die Ratte in den Schwanz zu Lasten der Anzahl an Exchange Transaktionen.

 
Problem erkannt - Gefahr gebannt?

Nun ja, zwar lässt die manuelle Reproduktion des Fehlers nicht mehr als 1300 Serientermine zu, was aber tückisch zu sein scheint ist, dass der "Exchange 2007 Move Mailbox Wizard" bei der Migration der Postfächer die Kalender mit mehr als 1300 Serienterminen erst mal anstandslos migriert.
Als Workaround bleibt uns aktuell nur das Feststellen, ob mehr als 1300 "Recurring Appointments" (Serienterminen) in einem Postfach vorliegen und dann entsprechend das Verlagern des Postfachs auf einen Exchange 2000/2003 Server.

 
Zur Analyse gibt es vier gute Ansätze:

 
1.) Prüfung eines einzelnen Postfachs direkt über Outlook selbst

Eine einfache Variante ist es, dass Postfach mit Outlook primär zu öffenen, den Kalender auszuwählen und über folgenden Weg die Ansicht des Kalenders auf "Terminserien" umzustellen:

In Outlook 2003/2007...

  • Kalender auswählen
  • Menü "Ansicht" auswählen
  • Punkt "Aktuelle Ansicht" auswählen
  • Die Ansicht "Terminserien" aktivieren

Wenn man nun "Alle Gruppen reduzieren" (Rechtsklick im rechten Fensterbereich) wählt, dann bekommt man eine Übersicht über die Anzahl der Serientemrine im Kalender

 
2.) Prüfung eines einzelnen Postfachs über ein separates Outlook Profil in Verbindung mit einem kleinen VBScript von Microsoft PSS

Const olFolderCalendar = 9
Counter =0

Set objOutlook = CreateObject("Outlook.Application")
Set objNamespace = objOutlook.GetNamespace("MAPI")
Set objFolder = objNamespace.GetDefaultFolder(olFolderCalendar)

Set colItems = objFolder.Items

Set colFilteredItems = colItems.Restrict("[IsRecurring] = TRUE”)

For Each objItem In colFilteredItems
    Set objPattern = objItem.GetRecurrencePattern
    If objPattern.PatternEndDate > Now Then
        counter = counter + 1

    End If
Next

Wscript.Echo “Counter steht auf ..” & counter

Das VBScript durchläuft den Kalender Ordner des aktuellen Outlook Profils und zählt die vorhandenen Serienterminen, welche am Ende in einem Internet Explorer Fenster ausgegeben werden…

olcheckrecurring 
 
 
3.) Prüfung aller Postfächer zentral über das VBScript “TerminCount.vbs” von Frank Carius (MS Exchange FAQ)

Frank hat uns wie immer schnell und kompetent unterstützt und eines seiner bereits bestehenden Skripte umgeschrieben, welches per CDO über alle Exchange Postfächer läuft, die Anzahl der Serientermine zählt und diese in einer XML-Datei ausgibt.

Hier gehts zum Artikel auf der “MS Exchange FAQ”:
http://www.msxfaq.de/tools/termincount.htm

So schaut das ganze während der Analyse aus…

 termincount

 
4.) Prüfung von bereits auf Exchange 2007 migrierten Postfächern mittels PowerShell Befehl

Mit dem folgenden PowerShell Befehl kann man zwar nicht die Anzahl der Serientermine festellen, aber man kann zumindest prüfen ob Postfächer mit mehr als 1300 Terminen vorliegen, die dann z.B. weiter geprüft werden können…

Get-MailboxFolderStatistics -identity “mohmeyer” | ft folderpath,foldersize,itemsinfolder -AutoSize

folder-statistic-powershell


 
Die zentrale Frage:  BUG oder Feature?

Ob sich die Developer von Exchange 2007 mit dieser Grenze etwas gedacht haben, oder ob das in Exchange 2000/2003 bereits behobene Verhalten tatsächlich ein Codierungsfehler ist, der als BUG festgestellt wird, ist aktuell in Klärung. Ich werde hier im Blog zu entsprechender Zeit darüber berichten.

Mein Tipp ist, dass Microsoft in Kürze einen Hotfix dazu liefert, der sicher auch im nächsten Update Rollup Paket für Echange 20007 und vielleicht sogar auch noch im SP1 seinen Platz finden wird. Wir werden sehen.

 
Mein Fazit

Wer aktuell ein Exchange 2007 System aufbaut oder eine Exchange 2007 Migration durchführt, der sollte dringend prüfen, ob es Postfächer mit mehr als 1300 Serienterminen in der Umgebung gibt. Gerade wenn Mitarbeiter über Jahre mit Postfächern arbeiten, die nicht archiviert werden, oder wenn z.B. Kundendaten wie wiederkehrende Geburtstage gepflegt werden, dann besteht eine hohe Wahrscheinlichkeit, dass man in diese Problematik läuft. Die oben genannten Vorgehensweisen helfen bei der Festellung und beim umgehen des Fehlers.
Es hat sich auch einmal wieder gezeigt, wie wichtig und hilfreich ein entsprechender Supportvertrag mit Microsoft beim Betrieb einer komplexen Exchange Umgebung ist. Die Aktion hat ebenso deutlich gemacht, wie wichtig eine funktionierende Überwachung der Systeme ist und dass gerade dort im Zusammenhang mit Exchange nicht gespart werden darf.

 
Links zum Thema

Blogartikel von Zyg Furmaniuk aus Cambridge, der von selbem Problem berichtet
http://calendarservermigration.blogspot.com/2007/06/how-many-recurring-appointments-does-it.html

Blogartikel “Rough and Tough” guide to identifying patterns in Transaction Logs” von Scott Oseychik
http://blogs.msdn.com/scottos/archive/2007/07/12/rough-and-tough-guide-to-identifying-patterns-in-ese-transaction-log-files.aspx

Artikel zum VBScript “TerminCount.vbs” von Frank Carius
http://msxfaq.de/tools/termincount.htm

 
Keywords:  Exchange 2007 BUG EXCDO 8199 8206 8213 Serientemrine Recurring Appointments

Technorati Tags: , , , , , ,

Veröffentlicht in Exchange, Service Pack | Verschlagwortet mit : , , , , , , , , , , , , , | 12 Kommentare »

Disk full – zu viele Exchange Logfiles – Exchange 2007 CCR verhindert NTBackup die Bereinigung

Verfasst von Markus Mohmeyer am [24/09/2007]

Ein grauer Tag im Leben eines Exchange Administrators:

Du kommst ungewohnt früh und nichts Böses ahnend morgens ins Office und noch vor dem ersten Kaffee bombardiert das Monitoring System Dein Postfach derart extrem, dass Du augenblicklich wach bist. Angeblich soll sich der Exchange Store des neuen Exchange 2007 CCR Clusters auf die Seite gelegt haben.
 
Toller Witz, denke ich! Ein Blick auf den Kalender bestätigt, dass heute nicht der 1. April ist und mit einem weiteren Blick in den Windows Cluster Administrator zeigt mir ein rotes Pfeil-Symbol frech-freundlich an, dass die Ressource “First Storage Group/Mailbox Database” offline ist.

exchange-store-down

Zeit ein paar Blicke in die Windows Eventlogs zu riskieren…

System Eventlog:

Event Type:    Warning
Event Source:    Srv
Event Category:    None
Event ID:    2013
Date:        21.09.2007
Time:        03:33:48
User:        N/A
Computer:    <ClusterNodeName>
Description:
The D: disk is at or near capacity.  You may need to delete some files.

Application Eventlog:

Event Type:    Error
Event Source:    ESE
Event Category:    Logging/Recovery
Event ID:    428
Date:        21.09.2007
Time:        03:36:34
User:        N/A
Computer:    <ClusterNodeName>
Description:
MSExchangeIS (3520) First Storage Group: The database engine is rejecting update operations due to low free disk space on the log disk.

Application Eventlog:

Event Type:    Error
Event Source:    MSExchangeIS
Event Category:    General
Event ID:    9559
Date:        21.09.2007
Time:        03:36:34
User:        N/A
Computer:    <ClusterNodeName>
Description:
The log disk is full for storage group “First Storage Group”. Attempting to unmount all databases in this storage group.

Application Eventlog:
Event Type:    Information
Event Source:    MSExchangeIS Mailbox Store
Event Category:    General
Event ID:    9539
Date:        21.09.2007
Time:        03:36:36
User:        N/A
Computer:    <ClusterNodeName>
Description:
The Microsoft Exchange Information Store database “First Storage Group\Mailbox Database” was stopped.

System Eventlog:
Event Type:    Error
Event Source:    ClusSvc
Event Category:    Failover Mgr
Event ID:    1069
Date:        21.09.2007
Time:        03:36:41
User:        N/A
Computer:    <ClusterNodeName>
Description:
Cluster resource ‘First Storage Group/Mailbox Database (<ServerName>)’ in Resource Group ‘<ResourceGroupName>’ failed.

Application Eventlog:
Event Type:    Error
Event Source:    MSExchangeIS
Event Category:    General
Event ID:    1004
Date:        21.09.2007
Time:        03:36:53
User:        N/A
Computer:    <ClusterNodeName>
Description:
Unable to start the Microsoft Exchange Information Store. Disk is full.

Schauen wir uns in einer tabellarischen Übersicht die Meldungen mal genauer an und analysieren, was genau geschehen ist…

Zeit Eventlog Event ID Quelle Event Description Erklärung
03:33:48 System 2013 Srv The D: disk is at or near capacity.  You may need to delete some files. der Server-Dienst gibt eine Warnung, dass die Platte D: kurz davor ist voll zu laufen
03:36:34 Application 428 ESE MSExchangeIS (3520) First Storage Group: The database engine is rejecting update operations due to low free disk space on the log disk. In diesem Moment nimmt der Exchange Informationsspeicher Dienst keine Daten mehr an um zu verhindern, dass Inkonsistenzen entstehen
03:36:34 Application 9559 MSExchangeIS The log disk is full for storage group “First Storage Group”. Attempting to unmount all databases in this storage group. die Disk ist voll und der Exchange Informationsspeicher Dienst versucht alle Datenbanken sauber zu beenden
03:36:36 Application 9539 MSExchangeIS Mailbox Store The Microsoft Exchange Information Store database “First Storage Group\Mailbox Database” was stopped. die Datenbank “Mailbox Database” wurde erfolgreich beendet
03:36:41 System 1069 ClusSvc Cluster resource ‘First Storage Group/Mailbox Database (MAIL06ADD)’ in Resource Group ‘mail06add’ failed. jetzt “merkt” der Cluster Dienst, dass die Ressource ungeplant auf einen Fehler gelaufen ist
03:36:53 Application 1004 MSExchangeIS Unable to start the Microsoft Exchange Information Store. Disk is full. der Exchange Informationsspeicher versucht noch einmal seinen Dienst wieder aufzunehmen… aber erfolglos!

 

Okay. Die Exchange Datenbank ist offline, weil die D: Platte vollgelaufen ist. Auf D: liegen die Exchange Transaktionsprotokolle (DB Logfiles). Vermutlich hat eine große Menge an DB Logfiles die Platte zum Überlaufen gebracht.

Die Vermutung bestätigt sich. Wir haben über 99.000 Logfiles (fast 100GB!) auf der Platte liegen und nur noch wenige Bytes frei. Einen Moment denke ich darüber nach, ob wir den Store wieder online bekommen, wenn wir den Cluster schwenken, was natürlich nicht funktioniert, denn im Exchange 2007 CCR Cluster sorgt der “Microsoft Exchange Replication Service” dafür, dass die Logfiles zeitnah auf den passiven Knoten kopiert werden. Gut, suchen wir also weiter nach dem Übel des Problems.

Ziel ist es jetzt die Logfiles zu bereinigen um Platz auf dem Laufwerk zu schaffen und dem Store die Möglichkeit zu geben wieder online zu kommen. Jeder Exchange Administrator hat in seinem ersten Exchange Kurs gelernt, dass die DB Logfiles durch eine erfolgreiche und fehlerfreie Exchange Online Datenbanksicherung bereinigt werden. Also starten wir eine solche in der Hoffnung, dass am Ende die Logs bereinigt werden.

Im Eventlog sind im Anschluss daran folgende Einträge zu sehen…

Application Eventlog:
Event Type:    Information
Event Source:    NTBackup
Event Category:    None
Event ID:    8000
Date:        21.09.2007
Time:        8:01:18
User:        N/A
Computer:    <ClusterNodeName>
Description:
Begin Backup of ‘<ServerName>\Microsoft Information Store\First Storage Group’

     Verify:  Off
     Mode:  Replace
     Type:  Normal

Application Eventlog:
Event Type:    Information
Event Source:    NTBackup
Event Category:    None
Event ID:    8001
Date:        21.09.2007
Time:        10:12:53
User:        N/A
Computer:    <ClusterNodeName>
Description:
End Backup of ‘<ServerName>\Microsoft Information Store\First Storage Group’ ‘
The operation was successfully completed.’

     Verify:  Off
     Mode:  Replace
     Type:  Normal
Consult the backup report for more details.

Soweit alles gut. NTBACKUP meldet “The operation was successfully completed.” Das ist ja erst mal schön. Jetzt staunen wir aber nicht schlecht, als wir sehen, dass keinerlei Logs bereinigt wurden. Irgendwas scheint zu verhindern, dass trotz des erfolgreichen Backups die Logs nicht bereinigt werden können.

Um nun die Exchange Datenbank wieder online zu bekommen verschiebe ich jetzt erst einmal einige der ältesten Exchange Protokolldateien in ein Verzeichnis auf einer anderen Platte. Jetzt haben wir wieder einiges an Platz und die Cluster Ressource “Mailbox Database” lässt sich wieder starten. Damit können die Benutzer erstmal wieder arbeiten.

Aufgrund der besonderen Brisanz der Situation, haben wir die folgenden Schritte gemeinsam mit MS PSS (Microsoft Product Support Services) durchgeführt.

Einen Blick ins Filesystem der beiden Cluster Nodes brachte die Erkenntnis, dass auf dem aktiven Knoten 99583 Protokolldateien und auf dem passiven 99588 vorhanden waren… ein Zustand, den ich bis heute nicht verstehe. Normalerweise sollte die Anzahl der Logfiles auf dem aktiven Knoten etwas höher sein und auf dem passiven Knoten geringer, da Exchange die Logs vom aktiven zum passiven Knoten nachführt. Wie auch immer.
Im Ordner “Inspector” finden wir das Logfile E000003A60B.log. Das letzte replizierte Logfile ist E000003A60A.log um 3:16 Uhr morgens. Damit ist klar, dass die CCR Replikation unterbrochen ist und nicht funktioniert.

Gemeinsam mit MS PSS diskutierten wir welche Gründe es geben kann, dass eine Bereinigung der Logfiles nicht funktioniert. Die folgenden beiden TechNet-Artikel geben Infos darüber, dass Exchange DB-Logs nicht bereinigt werden, wenn es Probleme mit der CCR Replikation gibt, oder wenn eine Logfile defekt ist:

http://technet.microsoft.com/en-us/library/bb123996.aspx
 
Note:

A common task during Exchange-aware backups is the truncation of transaction log files after the backup has completed successfully. The replication feature in CCR guarantees that logs that have not been replicated are not deleted. The implication of this behavior is that running backups in a mode that deletes logs may not actually free space if replication is sufficiently far behind in its log copying.

http://technet.microsoft.com/en-us/library/bb218100.aspx
 

Explanation:

This Error event indicates one of two possible events:

  • As part of replication inspection, the Microsoft® Exchange Replication (MSExchangeRepl) service cannot remove a log file that failed inspection from the inspector directory.
  • As part of replication startup, the replication service cannot clean out old unrelated log files that were in the middle of being copied and inspected during a previous replication session. This error will occur if either of the following conditions is true:
      • There is an I/O exception.
      • There are incorrect file permissions when the replication service tries to delete the log file.

Replication for the given storage group goes into a failed state when the error occurs. As soon as the error is resolved, replication resumes.

Damit wäre erklärt, dass der “Exchange Replication Service” dafür gesorgt hat, dass NTBACKUP dies Logfiles nicht bereinigen konnten, da ja die CCR Replikation der Logfiles unterbrochen war.

 
Folgender Aktionsplan wurde nun durchgeführt…

1.) Exchange Management Shell (Powershell) öffnen

2.) Ausführen des Befehls “Suspend-StorageGroupCopy” (Anhalten der “CCR Replikation”) mit entsprechenden Parametern…

Suspend-StorageGroupCopy “<CMS Name>\SG Name>”

3.) Auf dem passiven CCR Knoten alle Dateien im Ordner “First Storage Group” samt Unterordner löschen

4.) Ausführen des Befehls “update-StorageGroupCopy” mit entsprechenden Parametern in der PowerShell…

Update-StorageGroupCopy “<CMS Name>\SG Name>”

Dadurch wird ein so genanntes “CCR Reseeding” eingeleitet. Dabei wird die Mailbox Datenbank auf den passiven Knoten kopiert, was je nach Größe der Datenbank eine Weile dauern kann.

>>> SCREENSHOT FEHLT NOCH <<<

5.) Ausführen des Befehls “resume-StorageGroupCopy” mit entsprechenden Parametern in der PowerShell…

Resume-StorageGroupCopy “<CMS Name>\SG Name>”

Wenn dieser Vorgang abgeschlossen ist, werden die Exchange Transkationsprotokolle kopiert, was im Hintergrund und ohne Fortschrittsanzeige geschieht.

6.) NTBACKUP starten und eine vollständige Exchange Online Datenbanksicherung durchführen…

onlinebackup

Jetzt macht es natürlich Sinn zu prüfen, ob das Backup fehlerfrei funktioniert hat und genau das überprüfen wir als nächstes.

Im Eventlog ist folgender Einträge zu sehen…

Application Eventlog:
Event Type:    Information
Event Source:    NTBackup
Event Category:    None
Event ID:    8001
Date:        21.09.2007
Time:        14:22:53
User:        N/A
Computer:    <ClusterNodeName>
Description:
End Backup of ‘<ServerName>\Microsoft Information Store\First Storage Group’ ‘
The operation was successfully completed.’

     Verify:  Off
     Mode:  Replace
     Type:  Normal
Consult the backup report for more details.

Application Eventlog:
Event Type:    Information
Event Source:    ESE BACKUP
Event Category:    General
Event ID:    916
Date:        21.09.2007
Time:        16:32:39
User:        N/A
Computer:    <ClusterNodeName>
Description:
Information Store (3952) Deleting log files D:\exchsrvr\mdbdata\Mailbox\First Storage Group\Exxxxxxxxxx.log to D:\exchsrvr\mdbdata\Mailbox\First Storage Group\Eyyyyyyyyyy.log.

Nach gut 2 Stunden bangen und hoffen hatten wir also nun die Gewissheit, dass das Backup erfolgreich durchgelaufen ist und die Logfiles erfolgreich bereinigt wurden.

 
Mein Fazit

Ein Exchange 2007 CCR Cluster ist ein geniales und fehlertolerantes System. Gefährlich wirds, wenn die CCR Replikation aus irgendeinem Grund unterbrochen ist, da dann unter Umständen ein Exchange Onlinebackup nicht mehr die Exchage Transaktionsprotokolle bereinigen kann.
In jedem Fall ist es bei einem Exchange 2007 CCR Cluster unabdingbar eine funktionierende Überwachung samt Alarmierung zu haben. Nichts ist schöner, als wenn der Admin frühzeitig weiß, dass mit der CCR Replikation etwas nicht stimmt und dann entsprechend handeln kann.

Über den Grund, warum in so kurzer Zeit so extrem viele Exchange Logs entstanden werde ich in Kürze hier im Blog in einem separaten Posting berichten. Es lohnt sich also von Zeit zu Zeit hier mal vorbei zu schauen, oder direkt den folgenden RSS-Feed zu abonieren um über neue Beiträge informiert zu werden…


 

 

Links zum Thema

High Availability Cmdlets
http://technet.microsoft.com/en-us/library/bb124727.aspx

Planning for Cluster Continuous Replication
http://technet.microsoft.com/en-us/library/bb123996.aspx

Managing Cluster Continuous Replication
http://technet.microsoft.com/en-us/library/aa997676.aspx

The Microsoft Exchange Replication Service was unable to clean up an unneeded log file
http://technet.microsoft.com/en-us/library/bb218100.aspx

MSXFAQ: Exchange 2007 – Cluster Continuous Replication
http://www.msxfaq.de/e2007/ccr.htm

 
Keywords:  Exchange 2007 CCR Cluster Reseeding Microsoft Exchange Replication Service

Technorati Tags: , , ,

Veröffentlicht in Exchange | Verschlagwortet mit : , , , , | 2 Kommentare »

Ausgabe einer Liste aller aktiven Exchange ActiveSync Benutzer unter Exchange 2007

Verfasst von Markus Mohmeyer am [23/09/2007]

Unter Exchange 2003 war es kein leichtes Unterfangen eine Liste aller Exchange ActiveSync Benutzer herauszubekommen.
Unter Exchange 2007 ist das unter Verwendung der Exchange PowerShell (Exchange Management Shell) mit einem einzigen Befehl sehr einfach möglich.

 
Ausgabe aller Postfächer die ein mobiles Gerät in Exchange ActiveSync registriert haben

Get-CASMailbox -ResultSize Unlimited | where {$_.HasActiveSyncDevicePartnership} | select DisplayName

Als Beispiel ist dieser Befehl hilfreich, wenn Postfächer zwischen Exchange 2007 Servern verschoben werden müssen. Wenn sich unter diesen Postfächern auch ActiveSync-aktivierte befinden, dann muss die ActiveSync Policy erneut gebunden werden, denn mit dem verschieben auf einen anderen Homeserver geht die an das Postfach gebundene EAS Policy verloren.
Mit Hilfe des Befehls kann also schnell herausgefunden werden, welche Postfächer man hier berücksichtigen muss.

Die Ausgabe in der Exchange Management Shell stellt sich dann so dar:

eas-abfrage

Der Befehl liest aus der “CAS Mailbox” alle Postfächer aus, die in Exchange ActiveSync ein Gerät registriert haben.
Der Befehl “select” am Ende gibt an, welcher Wert ausgegeben werden soll. Hier wird der “Display Name” angezeigt. Die Option “-ResultSize Unlimited” wird genutzt um alle Objekte auszulesen und darzustellen. Ohne Verwendung dieser Option würden nur 1000 Objekte im Active Directory untersucht und folgender Hinweis käme in der Shell:

WARNING: By default only the first 1000 items are returned.

 
Aktuellen Status eines Postfach anzeigen lassen, das für Exchange ActiveSync aktiviert ist

Die CASMailbox hat uns also verraten welches Postfach ein Gerät registriert hat. Nehmen wir als Beispiel an man möchte jetzt wissen, wann sich ein mobiles Gerät aus der Liste von oben das letzte Mal mit EAS verbunden, bzw. das letzet Mal erfolgreich synchronisiert hat.

Mit Hilfe des “CMDLET” Get-ActiveSyncDeviceStatistics kann man die Liste der Geräte anzeigen lassen, die mit dem Postfach eines Benutzers synchronisiert werden. Der Befehl gibt eine Statistik über jedes registrierte Gerät aus und liefert erweiterte Informationen. Darüber hinaus kann man vom mobilen Gerät sogar “Device Logs” anzeigen lassen, vorausgesetzt diese Option ist in Outlook Web Access (Konfigurationsdatei: web.config) aktiviert.

Hier der entsprechende Powershell Befehl:

Get-ActiveSyncDeviceStatistics -mailbox <MailboxAlias> | FL

Die Ausgabe in der Exchange Management Shell stellt sich für mein Postfach so dar:

eas-activesyncdevicestatus

Erklärung der Felder der Ausgabe:

Parameter Beschreibung
FirstSyncTime Datum an dem das mobile Gerät das erste Mal mit Postfach des Benutzers synchronisiert hat
LastPingHeartbeat Länge des letzten Heartbeat Intervalls
LastPolicyUpdateTime Zeitpunkt an dem das mobile Gerät das letzte Mal eine Aktualisierung der ActiveSync Richtlinie bekommen hat
LastPolicyUpdateRequestTime Zeitpunkt an dem das mobile Gerät das letzte Mal eine Anfordeung für eine Aktualisierung der ActiveSync Richtlinie gestellt hat
LastSyncAttemptTime Zeitpunkt an dem das mobile Gerät das letzte Mal versucht hat sich mit Postfach des Benutzers zu synchronisieren
LastSuccessSync Zeitpunkt an dem sich das mobile Gerät das letzte Mal erfolgreich mit Postfach des Benutzers synchronist hat
LastSyncResponseStatus Der letzte Statuscode an das mobile Gerät während der letzten Synchronisation gesendet
DeviceFriendlyName Der Anzeigename der Partnerschaft, der auf dem mobilen Gerät konfiguriert ist. Nachdem der Anzeigename konfiguriert ist, speichert das Gerät diesen Namen im Postfach des Benutzers
DeviceId Die DeviceID des Geräts, die im Postfach des Benutzers gespeichert ist
DeviceModel Das Gerätemodell. Diese Information ist im Postfach des Benutzers gespeichert
DeviceOperatorNetwork Der Mobilfunkbetreiber, der vom Gerät verwendet wird. Das Gerät speichert diese Informationen im Postfach des Benutzers
DeviceOSAgent Das Clientbetriebssystem, das auf dem Gerät ausgeführt wird. Das Gerät speichert diese Informationen im Postfach des Benutzers
DeviceOSLanguage Die Sprache des Betriebssystems auf dem Gerät
LastPingHeartbeat Die Zeitspanne, die seit der letzten Antwort vom Gerät vergangen ist. Auch bekannt als “Heartbeat”
DeviceWipeSentTime Zeitpunkt an dem der letzte “Remote Wipe” Befehl vom Server gesendet wurde
DeviceWipeRequestTime Zeitpunkt an dem der “Remote Wipe” Befehl auf dem mobilen Gerät aktiviert wurde
DeviceWipeAckTime Zeitpunkt an dem der Server die letzte “Remote Wipe” Bestätigung vom Client empfangen hat
RecoveryPassword Das Wiederherstellungskennwort für das Gerät

 

Links zum Thema

Get-CASMailbox – http://technet.microsoft.com/en-us/library/bb124754.aspx
Set-CASMailbox – http://technet.microsoft.com/en-us/library/bb125264.aspx
Get-ActiveSyncDeviceStatistics – http://technet.microsoft.com/en-us/library/aa996908.aspx
Exchange Team Blog Artikel – http://msexchangeteam.com/archive/2007/05/30/439568.aspx

 
Keywords:  EAS Liste aktive Exchange ActiveSync Benutzer CASMailbox $_.HasActiveSyncDevicePartnership Powershell Management Shell

Technorati Tags: , , ,

Veröffentlicht in Exchange, PowerShell | Verschlagwortet mit : , , , , | Kommentar schreiben »

Entspannung gebraucht? – Popkorn essen!

Verfasst von Markus Mohmeyer am [20/09/2007]

Heute mal ein wenig “OFF TOPIC”…
…auch Hamster-Männer können nur eine Sache gleichzeitig. Nix Multi-Tasking! :-)

Veröffentlicht in FUN | 1 Kommentar »

Service Pack 3 für Office 2003

Verfasst von Markus Mohmeyer am [18/09/2007]

Microsoft hat heute am 18. September 2007 das Office 2003 Service Pack 3 veröffentlicht.

Das Service Pack 3 bietet wie auch die vorherigen Service Packs Verbesserungen an Sicherheit, Zuverlässigkeit und Leistung. Trotz der Verfügbarkeit von Office 2007 wird Office 2003 noch von sehr vielen Anwendern genutzt. Aus diesem Grund gibt es seitens Microsoft noch ausführliche Unterstützung dazu.

Das Service Pack 3 wird aktuell noch nicht über “Windows Update” und “Microsoft Update” und über die Funktion “Automatische Updates” verteilt. Dies wird jedoch in Kürze der Fall sein.

 
Neue Funktionen und Änderungen

  • Excel 2003:  Reparaturoption beim Offnen einer beschädigten .XLS-Datei
  • Access 2003:  Add-Ins können nun auch unter Windows Vista installiert werden
  • Word 2003:  Es können jetzt Textkopien aus Webmail-Anwendungen ohne Absturz eingefügt werden
  • Word 2003:  Die Option “Schnellspeicherung” entfällt, da diese ein Sicherheitsrisiko darstellt
  • Verschiedene Kompatibilitätsverbesserungen mit den Microsoft-Produkten Vista, Office 2007, Internet Explorer 7 und Windows Sharepoint Services

 
Probleme die vom Service Pack 3 behoben werden

Outlook 2003 http://support.microsoft.com/kb/938802/
Word 2003 http://support.microsoft.com/kb/938799/
Excel 2003 http://support.microsoft.com/kb/938790/
PowerPoint 2003 http://support.microsoft.com/kb/938801/

 

Feststellen ob das Service Pack 3 installiert ist

Im folgenden KB-Artikel wird beschrieben, wie genau man die Version von Office bestimmen kann:
http://support.microsoft.com/kb/821549/

 
Versionsnummern der Office 2003 Programmdateien je nach ServicePack…

Dateiname Datei Version SP3 Datei Version SP2 Datei Version SP1
Excel.exe 11.0.8169.0 11.0.7969.0 11.0.6355.0
Winword.exe 11.0.8169.0 11.0.7969.0 11.0.6359.0
Outlook.exe 11.0.8169.0 11.0.7969.0 11.0.6353.0
Powerpoint.exe 11.0.8169.0 11.0.7969.0 11.0.6361.0
Mso.dll 11.0.8172.0 11.0.7969.0 11.0.6361.0
Mspub.exe 11.0.8166.0 11.0.7969.0 11.0.6255.0
Msaccess.exe 11.0.8166.0 11.0.7969.0 11.0.6355.0
Infopath.exe 11.0.8165.0 11.0.7969.0 11.0.6357.0
Frontpg.exe 11.0.8164.0 11.0.7969.0 11.0.6356.0

 

Download des Service Pack 3

http://www.microsoft.com/downloads/details.aspx?FamilyID=e25b7049-3e13-433b-b9d2-5e3c1132f206&displaylang=en

 
Faustregeln zur Implementierung

  • Installation in einer nicht produktiven Testumgebung
  • Durchführung aktiver Tests (Standardfunktionen, Zusatzapplikationen, Add-Ins)
  • 2 bis 4 Wochen auf eventuelle Microsoft Meldungen hinsichtlich Problemen warten und Newsgroups lesen
  • Installation in Produktion und dokumentieren des genauen Vorgehens (vor Beginn Datensicherung)

    ! Hinweis !
    Für Probleme und Schwierigkeiten die bei oder nach der Installation des Service Pack 3 auftreten, erhält man unter folgender Adresse kostenlosen Online Support von Microsoft:  http://support.microsoft.com/oas/?&gprid=6527

  • Links zum Thema

    Microsoft Knowledgebase (KB923618)
    Microsoft Office 2003 SP3 Available Tomorrow
    Microsoft releasing Office 2003 SP3 Tuesday, disabling Word 2003’s ‘fast save’ feature
    Frequently asked questions about the Local Install Source feature (MSOCACHE) in Office 2003

     
    Keywords:  Office 2003 ServicePack 3 Service Pack 3 O2K3 SP3

    Technorati Tags: , , ,

    • Veröffentlicht in Outlook, Service Pack | Verschlagwortet mit : , , , | 2 Kommentare »

    Windows Live Translator – Texte und Webseiten übersetzen

    Verfasst von Markus Mohmeyer am [17/09/2007]

    Anfang September 2007 hat Microsoft einen neuen Übersetzungsdienst im Rahmen der Windows Live Dienste bereitsgestellt. Der “Windows Live Translator” (aktuell noch BETA!) übersetzt freigewählte Texte und komplette Webseiten in verschiedene Sprachen.
    Google war mit seinem Dienst “Google Übersetzung” zwar einige Zeit schneller, jedoch muss Microsoft sich nicht dahinter verstecken, auch wenn die Technologie von Microsoft nicht wirklich mehr eine “Vorreiter-Rolle” ist.

     
    Link zum Übersetzer

    http://translator.live.com   oder   http://www.windowslivetranslator.com

     
    Features von Windows Live Translator

    • freie Textübersetzung von bis zu 500 Wörtern
    • insgesamt 12 Sprachen frei wählbar
    • Übersetzung einer kompletten Webseite

      Beispiel: Markus Messaging Blog in Englisch…
      http://www.windowslivetranslator.com/BV.aspx?&MKT=en#http://msg-blog.de/

    • Verschiedene Ansichten wählbar
    • Option “Computerbezogener Inhalt” erzielt bessere Ergebnisse bei Übersezungstexten mit IT-Inhalten

     
    Screenshot

    image

     
    Aktuell verfügbare Sprachen

    • Arabisch – Englisch
    • Chinesisch (Traditionell) – Englisch
    • Chinesisch (Vereinfacht) – Englisch
    • Deutsch – Englisch
    • Deutsch – Französisch
    • Englisch – Arabisch
    • Englisch – Chinesisch (Traditionell)
    • Englisch – Chinesisch (Vereinfacht)
    • Englisch – Deutsch
    • Englisch – Französisch
    • Englisch – Holländisch
    • Englisch – Italienisch
    • Englisch – Japanisch
    • Englisch – Koreanisch
    • Englisch – Portugiesisch
    • Englisch – Russisch
    • Englisch – Spanisch
    • Französisch – Deutsch
    • Französisch – Englisch
    • Holländisch – Englisch
    • Italienisch – Englisch
    • Japanisch – Englisch
    • Koreanisch – Englisch
    • Portugiesisch – Englisch
    • Russisch – Englisch
    • Spanisch – Englisch

     
    Mein Fazit

    Netter Dienst, den es zwar von Google und anderen schon gab, der aber durch die Option Übersetzung von “Computerbezogener Inhalt” wirklich interessant ist und zumindest einigermaßen gut verständliche, wenn auch nicht immer einwandfreie Übersetzungen liefert.

     
    Links zum Thema

    http://www.vistablog.at/stories/14173/
    http://www.golem.de/0709/54643.html
    http://www.pcwelt.de/index.cfm?pid=1636&pk=93175

    http://translate.google.com
    http://babelfish.altavista.com/
    http://www.linguatec.net/onlineservices/pt
    http://www.worldlingo.com/en/solutions/website_translation.html

     
    Keywords:  Übersetzung Deutsch Englisch Windows Live Translator Computerbezogener Inhalt

    Technorati Tags: , , , ,

    Veröffentlicht in Web-Links | Verschlagwortet mit : , , , , | Kommentar schreiben »