Lorsque je donne des formations sur la partie BI de SharePoint, je fais généralement un tour sur le site rapports standard du modèle portail collaboratif MOSS Entreprise. Et la dernière fois que j'ai donné cette formation, j'ai eu le droit à ce beau message d'erreur durant ma démo... pas glop !
Heureusement, seul le poste du formateur était affecté et je n'ai pas été bloqué... il n'empêche, c'est moi le formateur, et sans y passer la journée pour autant j'ai essayé de comprendre l'erreur ce jour là, mais en vain.
Le temps passe et me viens à l'idée de mettre à jour la VPC utilisée pour la formation. Je teste le site "Rapports"... aucun problème. Je lance un windows update sans faire de détail. Je teste le site "Rapports"... et blam, le message d'erreur ci dessus fais son retour. C'est louche !
Je commence l'analyse du message d'erreur. Comme on le voit ci dessus, il me faut passer en mode SQLServer ou StateServer et je suis... déjà en mode SQLServer. Ca s'annonce bien. Quelques recherches sur Internet indiquent un lien avec Reporting Services 2005. Ca m'étonne un peu, car le site "rapports" n'exploite pas Reporting Services... mais soit, je modifie le fichier web.config de reporting services pour passer le mode d' "InProc" à "SQLServer". Je teste à nouveau... et j'obtiens une erreur 404 indiquant que la page ou une de ses dépendances est manquante. Habitué à ce genre d'erreurs, je décide de me connecter au site à l'aide de SharePoint Designer histoire de voir si j'obtiens le même message d'erreur... et non, encore un autre !
Message étrange, puisque le SP1 de SharePoint Designer a été appliqué. Ma version est donc up-to-date, et fonctionne d'ailleurs très bien avec tous les autres sites que le site "Rapports".
Je tente alors une connexion à Reporting Services via le Management Studio... et voilà ce que j'obtiens :
Hum hum... quelques recherches plus tard, je pars à la recherche du WebServiceAccount nommé dans ce message... pour constater qu'il référence le compte "Network Services"... ce qui semble tout à fait normal.
Bref, j'en pers même le latin que je n'ai jamais appris ! Le temps d'en parler à un collègue qui connaît bien mieux RS que moi, de parcourir la configuration RS... de lui expliquer que mon site "Rapports" est à l'URL reports et que ce n'est pas le site reporting services mais bien mon site SharePoint... pour finalement passer sur la console IIS et comprendre que le problème est... que l'application "Reports" de reporting services est présente dans mon site SharePoint ! L'URL /reports est utilisée par mon site SharePoint ET par reporting services. Comment est-ce possible ?
Lors de l'installation, j'ai modifié le port du site et des web services reporting services pour utiliser le 90 plutôt que le 80, et j'ai gardé le 80 pour mon application web SharePoint. Et tout fonctionnait très bien jusqu'à cette mise à jour Reporting Services via Windows Update. La mise à jour à réinscrit des composant RS sur le port 80 (au lieu de rester sur le port déjà utilisé). Du coup, l'appel au sous site /Reports de mon portail SharePoint conduisait tout droit sur Reporting Services au lieu du site SharePoint prévu, le tout avec un mauvais fichier de config... Bref, j'ai résolu le problème en déplaçant les applications liées à RS sur le port 90.
Moralité :
Ce n'est pas une légende... laissez le "site web par défaut" tranquille... désactivez le si besoin, mais ne le modifiez pas. Pour vos autres sites, ne faites pas comme pour cette VPC, utilisez les host headers !
