[ #SharePoint 2010 ] Déploiement de mises à jour cumulatives ou CU (Cumulative Update)…
La mise à niveau de SharePoint avec les derniers patches cumulatifs est une activité régulière qu’il convient de maitriser car pouvant avoir des répercutions sur la disponibilité de la ferme ou ses fonctionnalités.
Le processus peut se décomposer en trois étapes :
1°) Identification du bon niveau de patch
Ce n’est pas la partie la plus simple ! 
En effet, le site Technet français correspondant : Mises à jour pour les produits SharePoint 2010 est quasiment laissé à l’abandon puisque il en est resté à la mise à jour d’août 2011 ! 
Il en va de même du Centre de mise à jour pour Microsoft Office, serveurs Office et produits associés…
Le site américain Updates for SharePoint 2010 Products correspondant est lui tenu à jour
. De même que Update Center for Microsoft Office, Office Servers, and Related Products
On pourra également s’appuyer sur les excellents sites non-officiels suivants :
Meilleures pratiques :
- Je recommande d’installer le dernier niveau de CU lors d’une installation nouvelle.
- Par contre, sur une installation déjà en place, je recommande de n’installer le dernier CU (Cumulative Update) qu’après des tests approfondis de non-régression et en cas de problème spécifique à régler.
- Dans les autres cas (installation déjà en place mais sans problème spécifique), dans le cadre d’une maintenance régulière, je recommande de n’installer que l’avant-dernière version du CU, ce qui laisse le temps éventuellement à Microsoft de corriger des problèmes de régression qui pourrait surgir (cela n’est pas rare et s’est produit régulièrement sur l’année passée…)
Par exemple, à ce jour le dernier CU publié est celui de Février 2012. On ne l’installera, dans le cadre d’une maintenance régulière, qu’à la sortie du CU d’Avril (qui ne devrait plus tarder maintenant ! )
2°) Tests de non-régression sur un environnement de pré-production ou de qualification
A mener avec le plus de rigueur et de complétude possible…
3°) Déploiement sur les serveurs de production
On distingue 2 cas de figure :
- une ferme simple (mono-serveur)
L’installation se passe en trois étapes :
a) exécution du binaire fourni
A l’issue de cette exécution, le produit est “installé” :
mais les bases de données ne sont pas mises à jour (état “Database is in compatibilty range and upgrade is recommended”
b) passage de l’assistant de configuration des produits SharePoint 2010 ou de la ligne de commande suivante (ou similaire) :
1: PSConfig.exe -cmd upgrade -inplace b2b -force `
-cmd applicationcontent -install -cmd installfeatures
Si b2b est spécifié, il effectue alors une mise à niveau de build à build.
c) vérification du résultat
Le statut des bases a changé :
La version de la base de configuration est bien celle attendue :
2. une ferme complexe (multi-serveurs)
Dans ce cas, il y a 3 scénarios possibles qui sont décrit ici :
|
Sur place sans compatibilité descendante : la mise à jour est installée simultanément sur tous les serveurs de la batterie de serveurs et le contenu est mis à niveau sans utilisation de la compatibilité descendante.
|
Principal inconvénient de cette méthode : la batterie de serveurs entière est arrêtée.
|
| Sur place avec compatibilité descendante pour réduire le temps mort : la mise à jour est installée par étapes et utilise une mise à niveau différée avec compatibilité descendante pour réduire le temps mort. |
Ce scénario tire parti de la compatibilité descendante de SharePoint Server 2010 et de la fonctionnalité de mise à niveau différée pour réduire le temps mort nécessaire au déploiement d’une mise à jour logicielle. Toutefois, le temps mort n’est pas complètement éliminé. Les sites et les services ne sont pas disponibles pendant la mise à niveau du contenu. |
|
Liaison de bases de données pour une haute disponibilité du contenu : cette mise à jour utilise deux batteries de serveurs pour garantir une haute disponibilité du contenu existant.
|
Nécessite la création d’une seconde ferme. |
Le 2e scénario est le plus fréquent. Il se décompose en deux phases :
Phase de mise à jour :
À ce stade du processus, les bases de données et les autres composants, tels que les paramètres, les fonctionnalités et les données au niveau du site, n’ont toujours pas été mises à niveau, car l’Assistant Configuration des produits SharePoint n’a été exécuté sur aucun des serveurs de la batterie de serveurs.
Phase de mise à niveau :
L’utilisation de la commande Upgrade-SPContentDatabase permet d’introduire un degré de parallélisme dans les opérations qui réduit le temps d’indisponibilité général.
Voilà qui devrait vous aider dans vos mises à jour !
Et quelques liens intéressants sur ce sujet :
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
