PROBLEM
Was geschieht mit den ATP-Konfigurationen beim Upgrade auf ESG 5.6, und wie baue ich die Konfiguration wieder auf, die ich in 5.5 hatte?
LÖSUNG
Was sich geändert hat und warum eine Migration erforderlich ist
In 5.5 wurde jede ausgehende Beschränkung manuell eingetragen, Richtlinie für Richtlinie. In 5.6 klassifiziert die Appliance die Absender zusätzlich selbst, und zwar auf Grundlage des Datenverkehrs, den sie tatsächlich erzeugen, und ordnet sie einem Quota level zu. Die Regeln, die Sie selbst schreiben, sind nicht verschwunden: Sie sind in den Abschnitt Quotas Override verschoben worden, wo sie weiterhin Vorrang vor allem haben, was die Engine entscheidet.
Da die beiden Modelle Beschränkungen auf unterschiedliche Weise beschreiben, können die benutzerdefinierten Nachrichtenquoten aus 5.5 nicht automatisch konvertiert werden. Alles Übrige wird übernommen. Während des Upgrades werden Access Control-Richtlinien, Gruppen und deren Mitglieder migriert, und es wird ein Migrationsbericht erzeugt. Der Bericht ist für Administratoren zugänglich, enthält die bisherige ATP-Konfiguration und ist die Referenz, aus der Sie alles Weitere wieder aufbauen.
Nach dem Upgrade hängt der Status des ATP-Moduls davon ab, was Sie vorher hatten. Es bleibt aktiviert, wenn bereits Access Control-Richtlinien konfiguriert waren, und bleibt deaktiviert, wenn keine eingerichtet waren. In beiden Fällen sollte der Administrator das Modul durchgehen und konfigurieren.
Cloud-Appliances
Bei Cloud-Appliances wird die Migration von unserem Team durchgeführt. Wir gehen die vorhandene Konfiguration durch, entscheiden gemeinsam mit Ihnen, welche Richtlinien weiterhin benötigt werden und welche durch die automatische Engine ersetzt werden können, und bauen sie nach dem Upgrade wieder auf. Sie müssen nichts manuell neu erstellen, und wir wenden uns an Sie, sobald für eine Richtlinie eine Entscheidung Ihrerseits erforderlich ist.
On-Premise-Appliances
On premise übernimmt die Upgrade-Prozedur nur Gruppen, Mitglieder und Access Control-Richtlinien. Die Quota-Richtlinien müssen vom Administrator neu erstellt werden, entsprechend den folgenden Schritten und unter Verwendung des Migrationsberichts als Referenz.
Erstellen Sie vor dem Start einen Snapshot der Appliance bzw. jedes Knotens, falls Sie einen Cluster betreiben, und bewahren Sie eine Kopie der aktuellen Seiten Policies, Policy Groups und Message Quotas auf. Wenn das Upgrade bereits abgeschlossen ist und Sie den Migrationsbericht nicht finden, eröffnen Sie ein Ticket im Support-Portal mit den Angaben zur Appliance, und wir extrahieren ihn für Sie.
Migration auf Basis des Berichts
Ausgehende Richtlinien
Mit dem Upgrade wird ein automatisiertes System für ausgehende E-Mails eingeführt, das Mitglieder anhand ihres Verkehrsvolumens in Quota levels einordnet. Die Quota levels sind im Reiter Quota konfigurierbar und relaybasiert.
- Standardkonfiguration Absender werden automatisch dem passenden Quota level zugeordnet, und ihre Grenzwerte folgen ihrem Datenverkehr im Laufe der Zeit.
- Ausnahmekonfiguration Absender wie Newsletter, Informationsmails oder manuelle Ausnahmen erfordern eine manuelle Migration. Diese müssen im Abschnitt Quotas Member einem Quota level zugeordnet werden.
Ein Unternehmen versendet zum Beispiel einen wöchentlichen Newsletter an 10.000 Empfänger. Das ist ein individuelles Verkehrsmuster mit hohem Volumen und erfordert daher eine Ausnahme. Der Administrator kann das Quota level massive auf 10.000 Nachrichten setzen und die Absenderadresse des Newsletters im Reiter Quotas Member zuweisen.
Weitere Richtlinien
Richtlinien, die das automatische System nicht abdeckt, etwa eingehende oder benutzerdefinierte Richtlinien, werden über den Abschnitt Quotas Override migriert, wobei die bisherige Konfiguration aus dem Migrationsbericht als Referenz dient. Dort können Sie:
- eine Quote mit einem Priority-Wert definieren, wobei ein niedrigerer Wert Vorrang hat;
- einen Tracker, die Period und die Beschränkungen festlegen, etwa Message count oder Nachrichtengröße;
- das Verdict angeben, zum Beispiel defer, reject oder delete;
- die Regel als letzte kennzeichnen, sodass danach keine weitere Richtlinie mehr angewendet wird.
Source und Destination bestimmen, für welchen Datenverkehr die Regel gilt, und auf beiden Seiten können Gruppen verwendet werden.
Eine Abteilung erhält zum Beispiel große Mengen umfangreicher Anhänge. Es wird ein Quotas Override erstellt, der während der Geschäftszeiten 50 MB pro Stunde für alle Empfänger zulässt.
Abschließende Schritte
Sobald alles migriert ist, aktivieren Sie das Policy Quota Module, falls es deaktiviert war, aktivieren Sie Automatic Quotas und wenden Sie alle ausstehenden Änderungen an. Das System erzeugt daraufhin Konfigurationen für alle bisher nicht verwalteten Mitglieder.
Die Funktion Automatic Quota benötigt einen Nachrichtenverlauf von mindestens 14 Tagen, um die Mitglieder korrekt zu befüllen; auf neu erstellten Appliances werden daher keine Quota Members befüllt.
Rückkehr zum Verhalten von 5.5
Die vorstehenden Schritte führen zu einer Konfiguration, in der die automatische Engine alle Absender außer den von Ihnen definierten Ausnahmen verwaltet. Wenn stattdessen ausschließlich Ihre eigenen Beschränkungen gelten sollen, genau wie in 5.5, ist noch ein weiterer Schritt erforderlich.
Quota-Entscheidungen werden von vier Ebenen getroffen, die in der Reihenfolge ihrer Priority ausgewertet werden, wobei jede Ebene nur dann erreicht wird, wenn die darüberliegende nicht zugetroffen hat.
Die automatischen Quota levels sind die Basisschicht dieser Kette. Das Kennzeichen Automatic Quotas entscheidet darüber, ob Absender zwischen den Stufen höher- oder herabgestuft werden, es entfernt jedoch diese Basisschicht nicht: Datenverkehr, auf den keine Ihrer Quotas-Override-Regeln zutrifft, erreicht sie weiterhin und wird dort ausgewertet. Die Regeln neu zu erstellen genügt daher allein nicht.
Die Kette wird durch eine abschließende Regel unter Quotas Override geschlossen, die auf alles Übrige zutrifft und eine Beschränkung enthält, die niemals erreicht werden kann. Die Regel blockiert nichts. Ihre einzige Aufgabe besteht darin, zu verhindern, dass Datenverkehr zu den automatischen Stufen durchfällt.
| Feld | Wert |
| Name | ein Name, der den Zweck der Regel angibt, zum Beispiel CatchAll |
| Priority | 99, damit die Regel die letzte ist und danach keine weitere Richtlinie angewendet wird |
| Tracker | Sender user@domain |
| Period | 60 Minuten |
| Message count | 999999 |
| Verdict | Defer |
| Source | default |
| Destination | default |
Dass Source und Destination auf default gesetzt sind, ist das, was die Regel auf jede Nachricht zutreffen lässt. Der Message count liegt absichtlich außer Reichweite; wählen Sie daher einen Wert, den kein Absender in der festgelegten Period erreichen kann, und erhöhen Sie ihn, wenn Ihr Datenverkehr um ein Vielfaches wächst. Denken Sie daran, die ausstehenden Änderungen anzuwenden.
Prüfen Sie anschließend die Seite Quota Tracking: Der Datenverkehr sollte zuerst auf Ihre tatsächlichen Regeln zutreffen, und nur das, was Sie bewusst unangetastet lassen wollten, sollte unter der Catch-All-Regel erscheinen. Wenn dort ein Absender auftaucht, den Sie begrenzen wollten, trifft die Regel, die ihn erfassen sollte, nicht zu, und deren Source und Destination müssen überprüft werden.
Wenn Sie sich später entscheiden, die automatischen Quota levels zu verwenden, löschen Sie die Regel. Ihre manuellen Regeln behalten ihren Vorrang, und alles Übrige geht wieder an die Engine.
Eine Verbesserung ist geplant, mit der das Kennzeichen Automatic Quotas für sich allein wirksam wird. Sobald sie veröffentlicht ist, wird diese Regel nicht mehr benötigt.
Zu den Einstellungen der automatischen Quota-Engine siehe Automatic Quota im Artikel Policy.