Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SharePoint Grib's Lair

Journal technique de Sébastien PICAMELOT

Quand Reporting Services vient taquiner MOSS

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 !

Cannot use 'partitionResolver' unless the mode is 'StateServer' or 'SQLServer'

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 !

La versionde Windows SharePoint Services exécutée sur le serveur est ultérieure à la version de SharePoint Designer

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 :

Microsoft.SqlServer.SmoEnum : rsAccessDeniedToSecureData

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 !

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: dimanche 5 octobre 2008 23:43 par Gribouillon
Classé sous : ,

Commentaires

themit a dit :

AAAAAAAAAAAaaaaaaaaaaahhhh

Bienvenue au Club du "Non pas le localhost"

Je partage ta joie/peine sur les installs par défaut sur le localhost

Bien d'accord, mais bon, on aura beau prévenir les gens d'utiliser des hostnames ou des ports séparés, ils continueront encore et encore

Mais un jour, eux aussi ils changeront et nous suivrons

Pour un Default Site Libre !

Free the Default Site !!!

:)

# octobre 7, 2008 01:11
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