Retours d’expérience Installations SharePoint Foundation…
Ayant eu l’occasion de superviser plusieurs installations SharePoint Foundation 2010 ces derniers temps, j’ai pu constater que la documentation disponible sur le Net était largement moins fournie que pour SharePoint Server, c’est pourquoi je voudrais en profiter pour vous faire part de quelques problèmes fréquemment rencontrés.
Problème n°1 : L’installation de SQL Server (Express ou STD ou Enterprise) se bloque sur le compte de service. Le message d’erreur ressemble à cela : 
Cela se produit même lorsque le mot de passe saisi est correct et lorsque l’on exécute l’installeur sur un compte ayant les privilèges “Administrateur local” mais qui n’est pas le compte de domaine. En effet, dans ce cas le compte local bien qu’il soit de niveau “Administrateur”, n’a pas accès aux ressources du domaine et ne peut pas valider le compte de domaine.
Tout rentre dans l’ordre si l’on se délogue et on se relogue en utilisant le compte de domaine cible (ici Admin SQL du domaine SP) :
Morale : il faut se connecter avec un compte de domaine si l’on veut affecter un compte de domaine à SQL Server.
Problème n°2 : Ce problème se manifeste de différentes façon après l’installation principale de SharePoint Foundation. Les symptômes que j’ai relevés sont :
- absence du menu “Configurer la collection des données d’utilisation et d’intégrité” (comme sur la copie d’écran ci-dessous) :
- impossibilité d’accéder à l'écran de configuration des services (Administration Centrale / Paramètres système / Gérer les serveurs de cette batterie / <nom du serveur>
- impossibilité de gérer les paramètres de sécurité d’IE9
Ces symptômes disparaissent dès que l’on désactive l’UAC :
Ainsi l’administration Centrale redevient :
Problème n°3: sur le serveur “intranet.masociete.com”, l’accès au site http://intranet.masociete.com est impossible mais http://intranet et http://intranet.masociete.local sont OK
Eh bien, il faut savoir que ce comportement (qui peut être déroutant) est tout à fait normal !!!
Le problème vient du fait que le comportement d’IE sur ce cas de figure est le même que lorsque l’on tape le mot de passe d’accès au compte avec une erreur : il représente la fenêtre de login au site.
En utilisant un autre navigateur, on constate que l’erreur remontée est une erreur 401 :
HTTP 401.1 - Non autorisé : Échec de l'ouverture de session
De plus, le problème ne se produit que si vous essayez de parcourir le site Web directement sur le serveur. Si vous accédez au site Web à partir d'un ordinateur client, le site Web fonctionne comme prévu.
Il s’agit en fait à l’origine d’un blocage de sécurité pour éviter certains exploits utilisant un compte local pour attaquer un site situé sr le même serveur.
Mais cela peut avoir des effets plus ou moins pervers sur une configuration SharePoint :
- pas d’indexation si l’indexeur est situé sur le serveur frontal
- pas de connexion si une tâche tente de se connecter sur un site
- pas de connexion possible pour un code dédié se connectant depuis le serveur
Reste donc 4 possibilités d’actions :
- Configurer la clé de registre “DisableLoopBackCheck” dans la ruche
“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa”. Cependant cela est FORTEMENT DECONSEILLE sur une machine de production !
- Configurer une liste d’adresses qui doivent être exclues de la vérification
- Créer des URLS d’accès distincts (dans mon exemple http://intranet fonctionne alors que http://intranet.masociete.com est bloqué)
- Modifier l’architecture
Pour plus de détails sur ce problème, je vous recommande les deux liens suivants :
En espérant que ces quelques éléments vous permettrons de gagner un peu de temps ! 
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 :
