Exchange System Aufsicht - System Attendant mailbox

Hinweis:
Die Systemaufsicht ist in Exchange 2010 entfallen. Die System Mailbox gibt es aber weiterhin.

Dieser Artikel ist besonders interessant, wenn ihre System Attendant Mailbox mehrere Megabyte groß geworden ist.

Grundlagen

Jeder Exchange 2000/2003/2007 hat immer "genau eine" System Attendant mailbox". Sie wird im Moment der Installation des Servers in einer Datenbank angelegt. Wird die Datenbank später gelöscht, dann wird die SA-Mailbox nach dem nächsten Start des MSExchangeSA-Diensts in eine andere Datenbank auf dem Server verschoben.

Leeren Sie die Datenbank, z.B. indem Sie die EDB-Datei einfach löschen, dann wird beim nächsten Start das Postfach wieder angelegt. Den Active Directory Eintrag zur Systemmailbox können Sie in der Regel nicht versehentlich löschen, da er in der Configuration-Partition unter dem Server liegt.

 

Dieses "Postfach" stört entgegen anderslautender Artikel im Internet nicht bei der Deinstallation von Servern.

In der Regel ist dieses Postfach "leer" oder hat nur temporär einige Mails, die aber durch die Systemaufsicht verarbeitet werden. Nur wenn hier etwas "klemmt", dann kann das Postfach größer und größer werden, bis es irgendwann an die Quotas des Postfachs kommt und andere Dienste dann nicht mehr gehen oder zumindest Warnungen und Fehlermeldungen im Eventlog hinterlassen.

Einsatzbereich

Diese Mailbox hat einige Funktionen, die oft nicht sofort erkannt werden, aber irgendwann dann stören.

Das sind die wesentlichen Funktionen des System Attendant-Postfachs. Gerade die letzte Aufgabe ist oft auch Auslöser für Probleme. Denn wenn die Systemaufsicht diese FreeBusy-Mails nicht abarbeiten kann, dann wird das Postfach immer größer und größer bis es irgendwann "voll" ist und andere Dienste dann auch nicht mehr arbeiten.

Problem erkennen

Es gibt zwei Wege, eventuelle Probleme mit der Systemaufsicht zu erkennen. So kann schon allein die Anzeige der "Elementanzahl" im Postfach ein Hinweis auf ein Problem sein. In Exchange 2003 können Sie die Anzahl der Elemente schon in der GUI einfach erkennen.

Verwechseln Sie die Systemaufsicht nicht mit den beiden anderen Systempostfächern des Exchange 2000/2003 SMTP-Connectors und des Mailboxstore, die es auch mehrfach geben kann.

In Exchange 2007 ist das über die Powershell möglich. Der "Name" der Mailbox ist dabei immer der Servername mit einem "-SA" als Suffix.

Get-MailboxServer | %{get-mailboxstatistics "$_-SA"}

DisplayName                  ItemCount StorageLimitStatus LastLogonTime
---------------------------- --------- ------------------ -------------------
Microsoft System Attendant   0         BelowLimit         27.07.2011 12:25:50

Bei Exchange 2010 kann es hingegen sein, dass niemand die Mailbox bislang genutzt hat und daher folgende Meldung erscheint

Get-MailboxStatistics nawex001-sa
WARNING: The user hasn't logged on to mailbox 'nawex001-sa' ('301cdd86-c2e1-44b3-b80f-5bbf480b2a2a'), so there is no data to return. After the user logs on, this warning will no longer appear.

Wenn die Anzahl der Elemente hier "klein" ist, dann brauchen Sie nun nicht weiter zu suchen, denn anscheinend funktioniert alles wie gewohnt

Der Blick in in die Mailbox

Wenn aber die Anzahl der Elemente hoch ist (also hunderte), dann liegt der Verdacht nahe, dass ein Prozess hier Mails hinein sendet, aber niemand diese verarbeitet. Dann steht ein Blick in die Mailbox an. Das ist nun gar nicht so einfach aber mit MFCMAPI durchaus möglich.

Leider ist es nun nicht ganz so einfach, in den vielen Ordnern die Elemente zu finden. Ich laufe in der Regel also die Ordner einfach nacheinander durch und schaue mir rechts den "Item-Count" an. Ordner, die hier keine "0" haben, verdienen genauer betrachtet zu werden. Hier ein Beispiel:

In den meisten Fällen sind es aber Elemente in dem besonderen Ordner "SpecialPrivateFolderForFreeBusyStorage"

Test-ExchangeSearch

Ein Exchange Commandlet, welches die System Attendant Mailbox nutzt, ist Test-ExchangeSearch. Das Commandlet legt hier eine besondere "eindeutige" Mail ab, die es dann per Volltextsuche versucht zu finden. Wenn die Mailbox nicht i.O. ist, dann erhalten Sie z.>B. folgenden Fehler.

[PS] C:\>Test-ExchangeSearch
Test-ExchangeSearch : The operation could not be performed because the user mailbox could not be opened 
(MapiExceptionShutoffQuotaExceeded: Unable to save changes. (hr=0x80004005, ec=1245)

Da man dieses Commandlet natürlich nicht immer ausführt, ist der Fehler aber erst mal für viele sekundär, da er ja keine Funktion einschränkt. Wobei die Meldung schon einen Hinweis darauf gibt, dass die Mailbox schlicht "voll" ist.

Hub/Transport Fehler

Wenn die Mailbox "overQuota" ist, dann haben aber auch andere Prozess Probleme, diese Mailbox zu öffnen. So protokolliert der Informationsspeicherdienst, dass hier die EdgeTransport-Rolle nicht auf das Postfach zugreifen kann:

Log Name:      Application
Source:        MSExchangeIS Mailbox Store
Date:          20.07.2010 13:40:55
Event ID:      1022
Task Category: Logons
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SVR01.msxfaq.de
Description:
Logon Failure on database "SG1\DB1 " - Windows account MSXFAQ\SVR01$; 
mailbox /o=msxfaq/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration
/cn=Servers/cn=SRV01/cn=Microsoft System Attendant.
Error: 1245 
Client Machine: SRV01
Client Process: edgetransport.exe 
Client ProcessId: 0 
Client ApplicationId: Client=Hub Transport

Auch wieder vermutlich verursacht durch ein volles Postfach.

Quota erhöhen

Glauben Sie bitte nicht, dass eine Änderung der Quota-Einstellungen an dem Postfach irgendetwas langfristig verbessern würde. Sicher können Sie damit die Einschränkungen für eine Zeit umgehen, aber der Prozess, der bislang die Mailbox aufgefüllt hat, wird damit auch munter weitermachen. Insofern ist die Information, wo die Quotaeinstellungen zu finden und zu ändern sind, nur Teil einer temporären Lösung:

Der Standardwert ist hier 100000, d.h. 100 MegaByte als mDBOverHardQuota und sollte später wieder hergestellt werden.

Free/Busy Einträge

Interessant ist hier immer der Ordner "SpecialPrivateFolderForFreeBusyStorage" der unter Exchange 2007 und früher eine besondere Bewandtnis hat. Bestimmte Prozess schreiben Änderungen nicht direkt an die richtigen Stellen, z. B: weil sie geografisch entfernt auf anderen Servern laufen oder das Warten auf den Abschluss solcher Funktionen die Performance ungünstig beeinflussen würde. Das ist bei Frei/Belegt-Zeiten der Fall, die früher in öffentlichen Ordnern gespeichert wurden.

Solange früher die Anwender einfach mit "Outlook 2003 und früher gearbeitet haben, konnte der Client seine "Frei/Belegt-Zeiten selbst in "seinem" Schedule Free/Busy-Ordner aktualisieren. Hier im Bild legt Outlook (1) einen Termin (2) direkt im Kalender des Benutzerpostfach ab und aktualisiert auch den Eintrag im Free/Busy-Ordner (3).

Durch die zusätzliche Nutzung von Outlook Web Access, Mobile Geräte und der AutoAccept-Agent gibt es aber weitere Clients, die Termine für Anwender anlegen und managen. Entsprechend müssten diese Clients nun ebenfalls die Frei/Belegt-Zeiten in den öffentlichen Ordnern aktualisieren. Die können das aber zum Teil nicht oder sollen dies nicht aus verschiedenen Gründen nicht tun. Und hier kommt die System Mailbox und der System Agent zum Einsatz. Jede Änderungen an Terminen über OWA (4) werden zwar direkt in dem Benutzerkalender vorgenommen, aber die Pflege der Frei/Belegt-Zeiten erfolgt indirekt. OWA sendet eine Mail (5) an die Systemaufsicht des Servers und der Prozess "MSExchangeFBPublish", welcher als Teil der Systemaufsicht ca. alle 5 Minuten startet, verarbeitet diese Anfragen und aktualisiert den Eintrag des Benutzers im öffentlichen Ordner.

Fehler und Ursachen

Wenn Sie schon mit MFCMAPI in der System Attendant Mailbox sind und den Ordner "SpecialPrivateFolderForFreeBusyStorage" als Platzfresse ausfindig gemacht haben, dann können Sie auch gleich mal dort hinein schauen:

Sie sehen hier dann vermutlich tausende von "IPM.SchedulePlus.FreeBusy.Binarydata", die aber nur ganz wenig Rückschlüsse zulassen. Ein Doppelklick auf dieses Element öffnet bei installiertem Outlook einfach nur eine Mail. Klicken Sie aber einen Eintrag nur einmal an und dann im unteren Feld das Property "0x84EA0102", dann kommen Sie der Spur schon näher.

In der Detailansicht sehen Sie z.B. den LegacyExchangeDN des betroffenen Benutzers

Und damit ist schon mal klar, wo sie schauen müssen: Zu diesem LegacyExchangeDN muss es natürlich einen passenden "Schedule Free/Busy"-Ordner geben, was sie in der Exchange Verwaltungskonsole schon mal schnell prüfen können

Es kann nun mehrere Gründe haben, warum es hier kein passendes Gegenstück gibt oder die Systemaufsicht diesen Ordner nicht nutzen kann

csvde -f test.txt -r "(legacyexchangedn=*)" -l samaccoun tname,legacyexchangedn

Get-PublicFolder -Server mb-01 "\non_ipm_subtree\SCHEDULE+ FREE BUSY" | fl replicas* 

Get-PublicFolder -Server mb-01 "\non_ipm_subtree\SCHEDULE+ FREEBUSY" | Get-PublicFolderClientPermission -Server mb-01

Identity                   User                       AccessRights
--------                   ----                       ------------
\NON_IPM_SUBTREE\SCHEDU... Default                    {Author}
\NON_IPM_SUBTREE\SCHEDU... Anonymous                  {None}


Get-PublicFolder -Server mb-01 "\non_ipm_subtree\SCHEDULE+ FREE BUSY" | add-PublicFolderClientPermission -Server cl-de-exmb-01 -User default -AccessRights deleteallitems,editallitems

Identity                   User                       AccessRights
--------                   ----                       ------------
\NON_IPM_SUBTREE\SCHEDU... Default                    {Editor}

Eventlog

Wenn Sie mit all diesen Hinweisen noch nicht ans Ziel gekommen sind und das Postfach der Systemaufsicht sich nicht wieder leert, dann kann ihnen das Eventlog helfen. Sie können den Level anheben.

# Anzeige der aktuellen Einstellung
Get-EventLogLevel "MSExchange System Attendant Mailbox\General"
Identity                                                             EventLevel
--------                                                             ----------
MSExchange System Attendant Mailbox\General                          Lowest

#Setzen auf Maximum
set-EventLogLevel "MSExchange System Attendant Mailbox\General" -Level expert

In vielen Fällen können Sie dann im Application Eventlog zusätzliche Informationen erhalten.

 

Wenn all das nicht funktioniert, dann bleibt immer noch die weitere Analyse mit Programme wie Procmon, Filemon, Regmon., ADInsight, Debugview etc., um mehr über die möglichen Probleme zu ermitteln.

Leider gibt es da aber immer weniger Informationen, weil diese Funktion mit Exchange 2010 komplett entfallen ist und auch in früheren Versionen diese Komponente kaum Beachtung zuteil wurde.

Weitere Links

Keywords:MSExchangeSA Systemaufsicht, FreeBusy