Dynamische Quotaeinstellungen

Jeder Server ein Grenzen, die nicht überschritten werden können. Neben der verfügbaren CPU-Leistung und HauptspeicherAusbau, die beide recht flexible gehandhabt werden können, gibt es mit dem Massenspeicher eine begrenzende Komponente, die nicht so einfach verändert werden kann. Wenn eine Festplatte "voll" ist, dann stört dies den Betrieb und im Extremfall funktioniert der Server nicht mehr.

Exchange stellt daher das Mittel der "Quotas" bereit, über welche auf Datenbankebene oder pro Benutzer verschiedene Obergrenzen umgesetzt werden können. Nun können Sie aber nicht einfach den verfügbaren Platz nach dem Gießkannenprinzip auf alle Postfächer verteilen. Meist nutzen 10-20% der Postfächer den Großteil des Platzes und viele Postfächer sind nur wenige Megabytes groß.

Selbst Google und andere Provider versprechen zwar, dass jedes Postfach z.B. 1 oder 2GB groß sein kann, aber die Festplatten dafür hat noch kein Provider auf Vorrat gekauft. Ein Betrieb ohne Quotas wäre aber mehr als leichtsinnig.

Dynamik statt statisch

Als Betreiber einer Exchange Umgebung habe ich weniger Probleme mit großen Postfächern als vielmehr mit einem ungeplanten explosiven Wachstum, das vielleicht sogar unbemerkt bleibt. Auf der anderen Seite möchte ich nicht als "Verhinderer" da stehen, wenn ein Anwender seine individuelle Grenzwerte erreicht und beim Helpdesk anruft. Eine manuelle Anpassung kostet Zeit und Geld und für Firmen ist es schlimmer, wenn die Benutzer sich nach Alternativen (z.B. PST-Dateien) umschauen. Insofern halte ich mich lieber an die Regel eines Dienstleisters:

Ein Kunde bekommt seinen Wunsch erfüllt, solange es technisch möglich ist und die Kosten abgedeckt sind. Allerdings darf er damit nicht andere Kunden auf dem gleichen System beeinträchtigen oder gefährden.

Aus dem Grund werden natürlich Quotas eingesetzt, damit ein Nutzer nicht die Festplatten bis "0 Bytes Free" auffüllt oder die Transaktionsprotokolle nicht überlaufen. Allerdings passen sich die Quotas an die Verwendung des Postfach dynamisch an. Dies erfordert natürlich auch eine Kostenabrechnung, damit Personen mit sehr großen Postfächern auch angemessen an den Kosten für den Betrieb beteiligt werden. Wobei auch ich weiß, dass nicht jede Firma intern eine Verrechnung nach Speicherplatz betreibt oder benötigt.

Lösungsansatz

Aus dem Grund könnte seit Exchange 2007 ein PowerShell-Script jede Nacht einfach die Quotas anhand bestimmter Kriterien setzen. Folgende Logik wäre denkbar.

WarnQuota = min((aktuelle Mailboxgröße + 100 MB), 2000MB)
SendQuota = min((aktuelle Mailboxgröße + 120 MB), 2200MB)
StopQuota = min((aktuelle Mailboxgröße + 150 MB), 2300MB)

Die drei Werte ermitteln sich einfach anhand der aktuellen Postfachgröße zzgl. dem maximal erlaubten täglichen Wachstum, darf aber eine absolute Grenze nicht überschreiten. Denkbar wäre natürlich auch, das tägliche Wachstum über OUs/Gruppen unterschiedlich zu gestalten oder prozentual zum aktuellen Postfachbedarf zu steuern. Auch die fest Obergrenze könnte natürlich von verschiedenen Kriterien (z.B. Abteilung, Firma) abhängig gemacht werden. Bei den meisten Firmen ist aber eine statische Verschiebung schon passend. Interessant ist in diesem Zug auch ein Bericht, wenn eine Quota deutlich angehoben wurde. Die Quotas sollte aber auch so weit vom aktuellen Stand entfernt sein, dass der Anwender nicht dauernd die Warnmeldungen bekommt oder in OWA der Belegungsstatus angezeigt wird.

Achtung Exchange 2010 SP1
2480474 users do not receive quota warning messages after applying SP1 für Exchange 2010
Exchange prüft nur noch Postfächer, in denen ein Flag gesetzt wird. Dieses wird vom Store gesetzt, wenn bei einer eingehenden Mail die Größe auf 50% des "Senden Verbieten" gesetzt wurde. Wenn dann eine Nachricht erstellt wurde, wird das Flag wieder gelöscht und bei der nächsten Mail wieder gesetzt. Wurde aber nie ein "Senden Verbieten" gesetzt oder ist die erst "Warnung" auf weniger als 50% der Senden-Verbieten, gesetzt, dann löst der Trigger nicht aus.

Ab Exchange 2010 gibt es natürlich noch den Dumpster. Denken Sie daher auch an die Option „RecoverableItemsQuota“ für den Dumpster. Die Standardwerte sind da mit 20 GB für eine Warnung und 30 GB als harte Grenze relativ hoch angesetzt

Ergebnis

Eine solche dynamische Quota-Regelung liefert gleich mehrere Vorteile

  • Schutz gegen Loops mit Weiterleitungen
    Wie oft leitet jemand eine Mail an einen privaten Account (z.B. t-online o.ä.) weiter und es kommt zu nicht erkennbaren Mailschleifen. Sehr schnell wird damit ein Postfach sehr groß und letztlich kann es die Funktion stören, wenn dies nicht erkannt wird. Da Exchange 2007/2010 eine Mail ablehnen, wenn die "Stop"-Quota überschritten ist, wird die Schleife unterbrochen.
  • Schutz für Systemmailboxen
    Viele Firmen nutzen Postfächer für den Empfang von Systemmeldungen, z.B.: Backupreports, ISA-Reports etc. Auch diese Postfächer können wachsen und es wäre nicht das erste mal, dass ein Exchange Server "Voll" ist und das größte Postfach gerade das des Administrators ist.
  • Schutz gegen Resend-Versuche aufgrund von Fehlern
    Mindestens ein Supportcall hatte sich damit zu beschäftigen, dass eine alte Outlook Version versuchte, Mails zu senden und dies immer und immer wieder fehlschlug. Die Datenbank und die Transaktionsprotokolle wuchsen immer weiter bis die Festplatte voll war. Letztlich kam Outlook mit der Fehlermeldung nicht zurecht.
  • Schutz gegen übergroße Mails (z.B. ISO per Mail)
    Wenn ein Benutzer sein Postfach bis 2 GB ausschöpfen kann und aktuell nur 200 MB drin hat, kann natürlich problemlos mal schnell 600 MB per Mail versenden oder im Postfach zwischenlagern (und per OWA dann von extern wieder herunter laden). Solchem Missbrauch wird natürlich ein Riegel vorgeschoben, wenn die Grenze "nahe" ist.

Auch wenn eine "enge Quota-Regelung" diversen Missbrauch und Fehlfunktionen in die Grenzen weißt, so sollten Sie nicht über das Ziel hinaus schießen. Eine sinnvolle Wahl der Abstände von Quotas zur aktuellen Postfachgröße ist erforderlich, damit ..

  • .. Benutzer sich nicht eingeschränkt fühlen
    Führt schnell zu "schlechter Presse" und Verstimmung und Gegenwind.
  • .. Benutzer sich keine umgehung suchen
    z.B. (PST-Datei Export, Public Folder)
  • ... Benutzer die Quota nicht merken
    weil Sie noch keine Warnmeldungen oder Einblendungen über den Postfachstatus erhalten
  • ... nur bei starker Grenzüberschreitung gewarnt wird
    Die Warnmeldungen bleiben weiter Intakt, um Benutzer rechtzeitig auf die Grenzen hinzuweisen-.

Dann fehlt nur noch das Skript

Skript

Das Skript geht von der aktuellen Postfachgröße der Benutzer aus und setzt basierend der Regeln dann die neuen Postfachgrenzen. Dazu kommt das Commandlet Get-MailboxStatistics zum Einsatz, welches u.a. folgende Werte liefert:

Get-Mailboxstatistics
Database                    Property
DatabaseName                Property
DeletedItemCount            Property
DisplayName                 Property
ItemCount                   Property
LegacyDN                    Property
MailboxGuid                 Property
StorageGroupName            Property
StorageLimitStatus          Property
TotalDeletedItemSize        Property
TotalItemSize               Property

Interessant ist hierbei der LegacyDN, welcher das Postfach eindeutig beschreibt und später bei Set-Mailbox verwendet werden kann und der Wert für TotalItemSize. Optional könnten später noch die TotalDeletedItemSize, die Datenbank oder der Server für die Berechnung der Quotas herangezogen werden. Aber das stelle ich ihnen frei. Basierend auf den ersten beiden Werten setze ich dann die Quotas.

Hier ein Beispiel: Der Trick vorher mit "Get-Mailbox" eine Liste der Mailboxen zu erstellen erspart mir die Fehlerbehandlung für Systempostfächer, die nicht so verarbeitet werden können. Über Get-Maibox können Sie natürlich auch filtern z.B. mit "-OrganizationalUnit" etc.

get-mailbox | get-mailboxstatistics | % {
	write-host Processing $_.Displayname
	$mailboxname = $_.Displayname
	$currentsize = $_.TotalItemSize

	$WarnQuota = (($currentsize + 100MB), 500MB | measure-object -Maximum).Maximum
	$SendQuota = (($currentsize + 120MB), 600MB | measure-object -Maximum).Maximum
	$StopQuota = (($currentsize + 150MB), 700MB | measure-object -Maximum).Maximum
	$StopQuota = (($StopQuota,2000MB) | measure-object -minimum).minimum

	if (($WarnQuota -$currentsize)-le 20MB) {
		write-host -backgroundcolor red "User $mailboxname bis auf 20 MB gewachsen"
	}

	set-mailbox -identity $_.legacydn `
		-UseDatabaseQuotaDefaults $false `
		-IssueWarningQuota  $WarnQuota `
		-ProhibitSendQuota   $SendQuota `
		-ProhibitSendReceiveQuota   $StopQuota
}

Dieses Skript können Sie quasi jeden Abend laufen lassen, ehe der Exchange System Aufsicht die Warnmeldungen generiert, so dass die Benutzer von Tag zu Tag ohne Meldung bis zu 100 MB zunehmen dürfen aber bei 120 MB Zunahme nicht mehr senden und ab 150 MB fest blockiert werden. Bei 2000MB ist aber dann absolut auch Schluss.

Weiterentwicklung

Natürlich ist das nur die Minimalfunktion einer solchen dynamischen Quota-Lösung. Es ist in PowerShell natürlich sehr einfach, melden über hohe Quota-Erhöhungen per Mail oder Eventlog zu "versenden" oder die effektiven Quota-Einstellungen an Datenbanken, OUs oder anderen Kriterien fest zu machen. Ihren Wünschen sind hier kaum Grenzen gesetzt.

Zudem ist das Skript nicht gerade schnell, wenn für jedes Benutzerobjekt getrennt die Größe gezogen werden muss. Diese Information hat nämlich der Mailboxserver. Wer also "ganz viele" Benutzer bearbeiten will, geht besser zuerst die Server durch um sich in einem Rutsch dort die Daten erst mal in eine Hashtabelle zu holen und dann die Werte anzupassen. Wer jedoch "verteilte Server" hat, wird dies wieder unterteilen wollen.

Weitere Links