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.

  • Mailbox Move, Systemanmeldungen etc.
    Es gibt Prozess, die auf Postfächer und öffentliche Ordner in der Datenbank zugreifen wollen. Damit Exchange natürlich die Berechtigungen überprüfen kann, muss es wissen, "wer" da zugreift, insbesondere wenn der Zugriff per MAPI passiert. Und genau diese Dienste melden sich quasi an das "Postfach" der Systemaufsicht an, und greifen dann auf andere Postfächer zu.
    So meldet sich der Exchange 2007 HubTransport auch an dieses Postfach an, um dann in den Postfächern der Anwendern neue Mails aus dem Postausgang auszulesen oder im Posteingang abzulegen.
  • Test-Commandlets
    Auch diverse Testfunktionen von Exchange, namentlich das "Test-Mailflow" nutzt dieses Postfach, indem Sie Statusmails von Server zu Server senden und die Laufzeit müssen. Auch das "Test-ExchangeSearch"-Commandlet legt als Prüfung hier ein eindeutig erkennbares Element ab, welches es nach Indexierung dann sucht und finden muss.
  • FreeBusy mit Ordner SpecialPrivateFolderForFreeBusyStorage
    Es gibt Prozesse, die können in Exchange 2007 und früher noch nicht direkt die Aktionen durchführen. Dazu gehört, z.B. die Eintragung eines Termins in OWA. OWA kann hier nicht die Frei/Belegt-Zeiten in öffentlichen Ordnern aktualisieren. Daher sendet OWA eine Mail an die Systemaufsicht, welche dann asynchron diese Tätigkeit nachholt.
  • Exchange Unified Messaging
    Die System-Mailbox wird von der UM Rolle genutzt, um die Masterkopie von benutzerdefinierten Ansagen für Dialpläne und Auto-Attendants zu halten und speichert zudem bis zu 90 Tage die "Call reports". Das können also auch schon mal ein paar Megabyte sein.

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

  • Falscher LegacyExchangeDN
    Der Name des Ordners muss mit dem LegacyExchangeDN des Benutzers übereinstimmen. Es wäre nicht das erste mal, dass Drittprodukte oder Administratoren auch am LegacyExchangeDN rumschrauben" ohne die Folgen zu bedenken.
    Suchen Sie doch einfach nach AD-Objekten und lassen Sie sich den LegacyExchangeDN mal ausgeben. Ein einfacher CSVDE-Befehl reicht da schon aus, um eine CSV-Datei zur weiteren Analyse zu erhalten.

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

  • Kein Replikat
    Dies ist ein durchaus üblicher Fall, wenn z.B.: von älteren Exchange Versionen migriert wird und bei der Umstellung der öffentlichen Ordner diese Systemordner "vergessen" wurden.

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

  • Ordner aus unkenntnis gelöscht
    Oft ist es auch "nicht wissen", dass ein Administrator zwar problemlos eine "Administrative Gruppe" in Exchange 2000/2003 anlegen und wieder löschen kann, aber die Benutzer, die dort angelegt wurden, auch diesen Namen als LegacyExchangeDN behalten, selbst wenn Sie verschoben wurden. Allerdings wird so eine irrtümliche "Ordnerlöschung" zumindest von Anwendern mit Outlook 2003 und älter sehr schnell bemerkt. (Outlook kann die Frei/belegt-Zeiten nicht aktualisieren)
    284200 Schedule+ Free/Busy system folder is missing
    275171 How to reset system folders on an Exchange 2000 Server
  • Keine Rechte
    Eher selten ist der Fall, dass die Systemaufsicht einfach keine ausreichenden Berechtigungen auf diese Ordner hat. Dies passiert, wenn jemand per Skript seine Ordner "sicher" machen wollte und "Default" erst mal entfernt oder zurückgestuft hat. Erforderlich ist schon "Editor"
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}
  • Kein Siteserver
    Ein letzter Punkt, den aber auch ExPBA schon findet ist das Fehlen eines korrekten "Site Servers" für eine administrative Gruppe. Auch das betrifft eher die Firmen, die von Exchange 2003/2000 migrieren und irgendwann die alten Exchange 2000/2003 administrativen Gruppen "geleert" haben. aber die Anwender weiterhin den alten LegacyExchangeDN tragen.

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