Bonjour,

Mise à jour du 28/05/2011 : Problème résolu, Cf. en bas de l'article pour le détail et la résolution


Comme vous l'avez peut-être remarqué je n'ai plus bloggué depuis quelques temps, ce ne sont pourtant pas les sujets qui manquent mais le temps pour les traiter avec qualité (enfin je l'espère ;). Le problème ci-dessous est assez important pour que je le poste malgré ma faible investigation sur la résolution possible.

Chez un des mes clients suite à l'installation du SP1 de Windows Server 2008 R2, sur un environnement multiserveurs (2 frontaux virtualisés), nous avons constaté des problèmes qui sont résumés ci-dessous :

  • Le service NLB ne fonctionne plus (pb déjà identifié par les équipe de TMG, mais qui visiblement s'applique aussi sans ce produit). Le Workaround est d'arrêter puis redémarrer le service sur chaque frontal (un reboot du serveur ne corrige pas le problème) : "net stop wlbs" puis "net start wlbs" (attention de ne pas faire cette manip en Terminal server sous peine de se couper une patte et de ne plus pouvoir accéder à la machine...)
  • La réplication des index du serveur d'indexation vers les serveurs de requête (query) ne s'opére plus, en cause un décryptage des tickets Kerberos qui foire et qui empêche l'authentification entre les services SharePoint. Le Workaround a été d'installer le rôle de requête sur le serveur d'indexation et de couper le rôle de requête sur tous les autres serveurs.
  • Excel Services ne répond plus entre machine, problème visiblement lié lui aussi à l'authentification Kerberos entre service (WCF). Le workaround a été de couper Excel Services sur l'un des noeuds et de ne le laisser que sur un seul (pourquoi cela fonctionne avec un seul noeud, reste un mystère).

Ma recommandation est donc de ne pas installer le SP1 de Windows Server 2008 R2 sur un environnement SharePoint 2010 pour le moment tant que ces points ne seront pas réglés. Je n'ai pas testé sur d'autres fermes, ni sur un environnement MOSS 2007. Il est cependant problable que le problème NLB soit le même pour les autres problème rien n'est sûr. Nous avons ouvert un call chez MS pour élucider ces problèmes, et vérifier que le SP1 est bien en cause. Si je trouve des meilleurs workarounds ou que le problème peut-être résolu je vous tiendrai au courant.

Mise à jour du 28/05/2011 : Le problème venait d'une mauvaise configuration des cartes réseaux sur la partie IPV6 qui ne posait aucun problème avant le SP1 mais qui suite à l'installation de celui-ci provoquait des erreurs de déchiffrement des ticket Kerberos. Ces problèmes de ticket Kerberos étaient à l'origine du problème de communication entre les noeuds et donc entre les différents service SharePoint.

Résolution : nous avions pensé que la couche IPv6 des cartes réseaux serait désactivée en décochant ce protocole dans les propriétés de la carte réseau, mais ce n'était pas suffisant et a amené la configuration réseau dans un mode non supporté par MS. Même si vous ne souhaitez pas faire d'IPv6 il est préférable de laisser ce protocole actif car de nombreux services Windows reposent sur celui-ci en priorité. Notre action a donc été de recocher le protocole IPv6 sur toutes les cartes réseaux et de forcer Windows à utiliser IPv4 en priorité en enregistrant la clé de registre "DisabledComponents" d'IPv6 à la valeur 0x20 (plus d'infos là : http://support.microsoft.com/kb/929852/en-US, attention l'article anglais contient plus de "fix-it" que sa traduction française automatique.). Après un redémarrage, nous avons constasté que tous les services fonctionnaient correctement, et nous avons pu répartir à nouveau nos services SharePoint entre les différents serveurs de la ferme.

J'espère que ceci vous permettra d'éviter une rupture de service sur votre infrastructure, ce problème nous a montré qu'il est toujours important de bien se renseigner sur l'action d'une case à cocher qui peut paraître anodine mais à complètement mis notre ferme K.O., IPv6 : 1, Edgar : 0 ;)

Bon code à tous,
Edgar