Nouvelle fonction d'archivage

Bonjour,

Tout d'abord, je trouve cette version d'Exchange absolument fantastique. J'ai débuté avec Exchange 5.5, quasiment zappé Exchange 2000, travailler à 90 % sur Exchange 2003, je suis à peine accroché à Exchange 2007, bien que je l'apprécie néanmoins... Mais là, le choc, Exchange 2010 est excellent, j'ai hâte de le mettre chez mes clients et je le teste dans tous les sens depuis sa sortie en BETA.

Mais voilà, j'ai quand même une interrogation... L'archivage ! Si j'ai tout compris, ceci est censé remplacé les PST ? Normalement, lorsque l'on demande à un utilisateur de créer un PST, c'est parce que sa BAL est trop grosse, et qu'il faut la vider pour soulager la base...

Hors, dans ce cas, pourquoi est ce que la fonction d'archivage se fait dans la même base ? Quel intérêt dans ce cas ? Autant tout laisser dans la BAL ? OK, on peut utiliser des stratégies pour gérer l'archivage, mais à part ça... Peut être qu'en version finale, il sera possible de les mettre dans une autre base ? J'y verrais dans ce cas plus d'intérêts...

En plus, pas très sympa d'avoir mis cette fonction en version entreprise... alors que cette fonctionnalité est présentée comme une des grandes nouveautés de cette version d'Exchange...

Merci d'avance de m'aider à comprendre le but de cet archivage...

Lionel.

Bonjour,

Excellente question !

L'archive est une seconde BAL attachée au compte utilisateur. L'utilisateur à donc deux boites aux lettres, la primaire accessible en mode online et offline, et la BAL d'archive qui elle n'est accessible qu'en mode online. La BAL d'archive réside donc dans une BAL séparée, par contre elle se trouve bien dans la même base que la première (.edb). En tout cas ce sera ce fonctionnement pour la RTM.

L'intérêt ? Déjà supprimer les .pst et la gestion hasardeuse qui y est associée. C'est une avancée énorme vu les difficultés pour sauvegarder les .PST par exemple. Deuxième point d'un point de vue performance: vue que l'archive n'est pas accessible en mode offline, il n'y pas de fichier .OST associé à l'archive. Du coup cela permet de désengorger la BAL primaire et passer dans l'archive tous les vieux emails. Au lieu d'avoir une seule BAL de 10Go, -un fichier .OST de 10Go dans Outlook- cela permet de conserver une taille correcte pour la BAL primaire (genre 2Go-3Go) et passer les 7Go/8Go restant en mode offline dans l'archive. L'utilisateur n'accède à son archive que s'il est connecté sur Outlook ou via OWA.

Frédéric

Bonjour,

merci pour cette réponse.

Mais mon problème principal reste que la taille de la base est toujours égale à la totalité des messages, qu'ils soient dans la boite d'archive ou dans la boite principale... Ce qui peut faire grossir rapidement la taille.

Hors, travaillant pour des PME, les moyens techniques ne sont pas toujours capables de gérer des bases de 100 Go ou plus... pas idéal pour une restauration de mails via le storage recovery group... C'est pourquoi (outre le fait par exemple que de nombreux clients ont un exchange 2003 standard avec une base unique limitée à 73 Go), on force les utilisateurs à faire des PST, pour libérer la base.

Lionel.

Je comprend, déjà avec Exchange 2007 la taille maximale des bases recommandée est de 200Go. Avec Exchange 2010 les bases seront encore (beaucoup) plus grosses...

Question backup il existe des alternatives :
- sauvegarder depuis la basse passive par exemple, pour éviter d'impacter les utilisateurs de prod (et donc lancer un backup en pleine journée sans soucis de perfs sur la prod),
- en cas de suppression d'emails utiliser la restauration des éléments supprimés, accessible directement par les utilisateurs pendant 14 jours par défaut,
- en cas de suppression d'une BAL utiliser la restauration des BALs,
- en cas de suppression de la base entière, basculer sur la base passive,
- configurer le DAG pour avoir plusieurs copies avec des délais de réplication différents,

Bref il est de moins en moins nécessaire de recourir à des sauvegardes classiques.

Super fonctionnalité que les DAGs d'ailleurs... J'ai commencé sur Exchange 2007 avec un cluster CCR... incomparable !

Mais toujours pour des PME, il faut pouvoir se payer 2 serveurs...

Donc le mieux reste de faire plusieurs petites bases, avec les archives activées, pour limiter la taille des OST sur les postes...