PROBLÈME
Que deviennent les configurations ATP lors de la mise à niveau vers ESG 5.6, et comment reconstruire la configuration dont on disposait en 5.5 ?
SOLUTION
Ce qui a changé et pourquoi une migration est nécessaire
En 5.5, chaque limite sortante était saisie manuellement, politique par politique. En 5.6, l'appliance classe également les expéditeurs d'elle-même, en fonction du trafic qu'ils produisent réellement, et les affecte à un Quota level. Les règles définies par l'administrateur n'ont pas disparu : elles ont été déplacées dans la section Quotas Override, où elles conservent la priorité sur toute décision du moteur.
Comme les deux modèles décrivent les limites de manière différente, les quotas de messages personnalisés de la 5.5 ne peuvent pas être convertis automatiquement. Tout le reste est repris. Pendant la mise à niveau, les politiques Access Control, les groupes et leurs membres sont migrés, et un rapport de migration est généré. Ce rapport est accessible aux administrateurs, contient l'ancienne configuration ATP et constitue la référence à partir de laquelle le reste est reconstruit.
Après la mise à niveau, l'état du module ATP dépend de la configuration précédente. Il reste activé si des politiques Access Control étaient déjà configurées, et reste désactivé si aucune n'avait été définie. Dans les deux cas, il est recommandé que l'administrateur parcoure le module et le configure.
Appliances cloud
Sur les appliances cloud, la migration est prise en charge par notre équipe. Nous examinons la configuration existante, décidons avec vous quelles politiques sont encore nécessaires et lesquelles peuvent être remplacées par le moteur automatique, puis nous les reconstruisons après la mise à niveau. Vous n'avez rien à recréer manuellement, et nous vous contactons chaque fois qu'une politique nécessite une décision de votre part.
Appliances on premise
En on premise, la procédure de mise à niveau ne reprend que les groupes, les membres et les politiques Access Control. Les politiques de quota doivent être recréées par l'administrateur, en suivant les étapes ci-dessous et en utilisant le rapport de migration comme référence.
Avant de commencer, effectuez un instantané de l'appliance, ou de chaque nœud si vous utilisez un cluster, et conservez une copie des pages Policies, Policy Groups et Message Quotas actuelles. Si la mise à niveau est déjà effectuée et que vous ne trouvez pas le rapport de migration, ouvrez un ticket sur le portail d'assistance en indiquant les détails de l'appliance : nous l'extrairons pour vous.
Migrer à partir du rapport
Politiques sortantes
La mise à niveau introduit un système automatisé pour le courrier sortant, qui classe les membres en Quota levels selon leur volume de trafic. Les Quota levels sont configurables dans l'onglet Quota et dépendent du relais.
- Configuration par défaut Les expéditeurs sont automatiquement affectés au Quota level approprié, et leurs quotas suivent l'évolution de leur trafic dans le temps.
- Configuration d'exception Les expéditeurs tels que les newsletters, le courrier informatif ou les exceptions manuelles nécessitent une migration manuelle. Ils doivent être associés à un Quota level dans la section Quotas Member.
Par exemple, une entreprise envoie une newsletter hebdomadaire à 10 000 destinataires. Il s'agit d'un profil de trafic particulier avec un volume élevé, une exception est donc nécessaire. L'administrateur peut définir le Quota level massive à 10 000 messages et affecter l'adresse d'expéditeur de la newsletter dans l'onglet Quotas Member.
Autres politiques
Les politiques que le système automatique ne couvre pas, comme les politiques entrantes ou les politiques personnalisées, sont migrées via la section Quotas Override, en utilisant l'ancienne configuration issue du rapport de migration comme référence. Vous pouvez y :
- définir un quota avec une valeur Priority, la valeur la plus basse étant prioritaire ;
- définir un Tracker, une Period et les limites, telles que Message count ou la taille des messages ;
- indiquer le Verdict, par exemple defer, reject ou delete ;
- marquer la règle comme dernière, afin qu'aucune autre politique ne soit appliquée ensuite.
Source et Destination déterminent le trafic auquel la règle s'applique, et des groupes peuvent être utilisés de part et d'autre.
Par exemple, un service reçoit d'importants volumes de pièces jointes volumineuses. Une règle Quotas Override est créée pour autoriser 50 Mo par heure pendant les heures ouvrées pour tous les destinataires.
Dernières étapes
Une fois tout migré, activez le Policy Quota Module s'il était désactivé, activez Automatic Quotas et appliquez toutes les modifications en attente. Le système génère alors des configurations pour tous les membres qui n'étaient pas encore gérés.
La fonctionnalité Automatic Quota a besoin d'au moins 14 jours d'historique de messages pour renseigner les membres avec précision : elle ne renseigne donc pas les Quota Members sur les appliances nouvellement créées.
Retrouver le comportement que vous aviez en 5.5
Les étapes ci-dessus aboutissent à une configuration dans laquelle le moteur automatique gère tout le monde, à l'exception des exceptions que vous avez définies. Si vous souhaitez au contraire que seules vos propres limites s'appliquent, exactement comme en 5.5, il reste une chose à faire.
Les décisions de quota sont prises par quatre niveaux, évalués par ordre de priorité, chaque niveau n'étant atteint que si celui qui le précède n'a pas correspondu.
Les Quota levels automatiques constituent la couche de base de cette chaîne. L'indicateur Automatic Quotas détermine si les expéditeurs sont promus ou rétrogradés entre les niveaux, mais il ne supprime pas cette couche de base : le trafic qui ne correspond à aucune de vos règles Quotas Override y parvient donc toujours et y est évalué. Recréer vos politiques ne suffit donc pas à lui seul.
Pour fermer la chaîne, il faut une règle finale sous Quotas Override qui corresponde à tout le trafic restant et qui porte une limite impossible à atteindre. La règle ne bloque rien. Son seul rôle est d'empêcher le trafic de retomber vers les niveaux automatiques.
| Champ | Valeur |
| Name | un nom indiquant à quoi sert la règle, par exemple CatchAll |
| Priority | 99, afin que la règle soit la dernière et qu'aucune autre politique ne soit appliquée ensuite |
| Tracker | Sender user@domain |
| Period | 60 minutes |
| Message count | 999999 |
| Verdict | Defer |
| Source | default |
| Destination | default |
C'est le réglage de Source et Destination sur default qui fait correspondre la règle à tous les messages. Le Message count est volontairement hors d'atteinte : choisissez donc une valeur qu'aucun expéditeur ne peut atteindre dans la période définie, et augmentez-la si votre trafic croît fortement. N'oubliez pas d'appliquer les modifications en attente.
Ensuite, consultez la page Quota Tracking : le trafic doit correspondre d'abord à vos règles réelles, et seul ce que vous vouliez laisser de côté doit apparaître au regard de la règle attrape-tout. Si un expéditeur que vous souhaitiez limiter y figure, c'est que la règle censée le capter ne correspond pas, et ses champs Source et Destination doivent être revus.
Si vous décidez par la suite d'utiliser les Quota levels automatiques, supprimez la règle. Vos règles manuelles conservent leur priorité et tout le reste revient au moteur.
Une amélioration est prévue afin que l'indicateur Automatic Quotas soit effectif à lui seul. Une fois publiée, cette règle ne sera plus nécessaire.
Pour les paramètres du moteur de quota automatique, voir Automatic Quota dans l'article Policy.