Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Le blog de Patrick [MVP Office 365]

Partage d'informations sur yOS (Yammer, Office 365, SharePoint), Azure et +...

Actualités









  • Mon blog en ANGLAIS - English blog :

    Versions :
    14.0.4730.1010 SharePoint 2010 RC
    14.0.4762.1000 SharePoint 2010 RTM
    14.0.6029.1000 SharePoint 2010 SP1
    ​14.0.7015.1000 SharePoint 2010 SP2

    15.0.4128.1014 SharePoint 2013 Preview
    15.0.4420.1017 SharePoint 2013 RTM
    15.0.4569.1509 SharePoint 2013 SP1

    Les derniers CU pour SharePoint 2010...
    Les N° de version pour SharePoint 2013...


[ #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 :

image

1°) Identification du bon niveau de patch 

Ce n’est pas la partie la plus simple ! Sourire

imageEn 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 ! Triste 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 à jourPouce levé. De même que Update Center for Microsoft Office, Office Servers, and Related ProductsPouce levé

On pourra également s’appuyer sur les excellents sites non-officiels suivants :

Le site de Todd Carterimage
Premier Field Engineer for SharePoint
Le blog de Stefan Gossner
Senior Escalation Engineer for SharePoint
SNAGHTML64dc5cf SNAGHTML650cf31

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 ! Sourire)

 

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 :

  1. 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é” :

SNAGHTML6a82934

mais les bases de données ne sont pas mises à jour (état “Database is in compatibilty range and upgrade is recommended”

image

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

SNAGHTML6ad698e

image

Le statut des bases a changé :

image

La version de la base de configuration est bien celle attendue :

image

      2. une ferme complexe (multi-serveurs)

Dans ce cas, il y a 3 scénarios possibles qui sont décrit ici :

SharePoint Foundation 2010 Installer une mise à jour logicielle
SharePoint Server 2010 Installer une mise à jour logicielle

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 :

Mise à jour sur place avec compatibilité descendante

À 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 :

Phase de mise à niveau d’une mise à jour logicielle sur place

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 ! Sourire

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 :
Posted: mardi 17 avril 2012 15:38 par Patrick Guimonet

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01