Exchange 2013 : les cycles de mise à jour par Cumulative Update

Dans le modèle de mise à jour d’Exchange 2013, chaque Cumulative Update (CU) comprend l’intégralité des binaires d’installation d’Exchange, un Cumulative Update peut donc aussi bien servir à installer un nouveau serveur Exchange, comme mettre à jour un serveur existant.

On peut s’attendre à la sortie d’environ 4 Cumulative Update par an (un tous les 3 mois environ), dont l’un est classé Service Pack. Il n’y a pas de différence fondamental entre un Cumulative Update et un Service Pack, la dénomination Service Pack est utilisée dans le modèle du cycle de vie du produit. Certains partenaires qui garantissent la compatibilité de leurs propres produits avec Exchange ne peuvent pas suivre le cycle des Cumulative Update, trop rapide, et garantissent la supportablité par rapport aux Service Pack.

Il est possible de mettre à jour un serveur Exchange 2013 RTM directement avec le dernier Cumulative Update en date, cependant il faut prendre en compte un autre facteur, moins connu mais très important : les Cumulative Update ne sont supportés que jusqu’à la version N-2. La mise à jour vers le Cumulative Update 5 par exemple n’est supportée et surtout testée que pour les 2 précédant Cumulative Update, soit le Cumulative Update 4 (qui correspondant au Service Pack 1) et le Cumulative Update 3. Rien n’empêche de réaliser une mise à jour depuis la RTM, le Cumulative Update 1 ou 2, cependant ces chemins de mise à jour n’ont pas été validés par Microsoft. Dans la pratique, cela peut engendrer un certain nombre de problèmes, des étapes portées par les Cumulative Update intermédiaires ne sont pas forcément joués comme prévus.

Il existe des patchs indépendants, en général liés à des problèmes critiques, et qui sont intégrés dans le prochain Cumulative Update.

Pour la mise à jour de l’infrastructure, il n’y a pas d’ordre particulier, les nouveaux rôles Exchange 2013 n’ont presque pas d’affinités avec la version utilisée, un FrontEnd en CU4 peut toujours communiquer avec un BackEnd CU5 par exemple.

Un seul cas particulier à ma connaissance, si vous avez un DAG mise à jour vers un CU particulier, vous pouvez toujours joindre à ce DAG un serveur dans un CU inférieur, mais si il y a une mise à jour du schéma des bases de données entre les deux versions, le nouveau membre n’arrivera pas à répliquer les bases.

Leave a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*
*