Vous n’êtes pas sans savoir que le SP1 de SharePoint 2010 est sorti il y a déjà deux semaines et vous êtes peut être en train de planifier un déploiement de ce dernier.
Cet article est un retour d’expérience de déploiement du SP1 sur un certain type de topologies : les installations en mode ferme avec des bases de données mises en mirroir (voir mes précédents sujets à ce propos)
Dans ce cas de figure, voici les deux problèmes que vous pourrez rencontrer :
Après l’installation des binaires, lorsque vous lancez le wizard de configuration des produits SharePoint (psconfig ou psconfigUI) pour mettre à jour le contenu et les webapp déployées, ce dernier échoue à la 9eme étape/10 à 15/30%
Une fois que le wizard s’est bien passé, lorsque vous vous rendez sur la section base de données de la ferme vous voyez certaines bases avec un message d’alerte du type « schéma de base de données trop ancien ou trop récent, procédez à un upgrade »
Première erreur :
Vous avez donc cliqué sur le lien du log, lu et relu ce dernier sans trouver d’explication complète sur ce qui a fait échouer l’installation. A partir de là et pour ma part j’ai ouvert les logs SharePoint (grâce au SharePoint log viewer) et je me suis rendu compte qu’il n’arrivait pas à procéder à l’upgrade d’une des bases de données (l’Usage Application dans mon cas).
Il m’a suffi d’arrêter le mirroring sur cette base et de relancer le wizard pour qu’il arrive à se terminer.
Seconde erreur :
Deux cas de figure, ou bien vous êtes chanceux et les bases de données en échec d’upgrade sont des bases données de contenu (SPContentDatabase) et dans ce cas il suffit de procéder à un Upgrade-SPContentDatabase depuis powershell. Si ca ne passe pas, coupez le mirroring et refaites le après l’upgrade.
Second cas de figure pour les moins chanceux (et j’en fais partie) les bases de données ne sont pas des bases de contenu. Cet état de base de données a souvent tendance à causer tout un tas de problèmes sur la ferme : Services bloqués au démarrage ou à l’extinction, timerjobs plantés/bloqués, applications de services non fonctionnelles ou pire, impossible à supprimer…
Dans ce second cas de figure c’est un peu plus compliqué donc, vous pouvez essayer d’arrêter le mirroring sur toutes les bases de données en échec, relancer le psconfig et refaire le mirroring ensuite.
Si ça ne fonctionne toujours pas, il faut arrêter tous les jobs et services liés à ces bases et les refaire (donc refaire une bonne partie de la configuration de ce qui tourne au-dessus).
Au final, je conseille à tous les administrateurs dans ce cas de figure de supprimer le mirroring sur les bases de données le temps de passer le SP1 (juste avant le psconfig) puis de les remettre en mirroir ensuite une fois qu’il aura été vérifié que toutes les bases de données se sont upgradées correctement.
Si quelqu’un a l’explication du « pourquoi le mirroring met le bazard ? » qu’il n’hésite pas à commenter cet article J
Bon déploiement à tous !