Étiquette : moss

SharePoint : La suppression d'une colonne provoque une "erreur inconnue"

L’un connu, l’autre pas.
Symptôme : Le fait de supprimer la colonne d’une liste provoque une erreur inconnue. La trace est la suivante :
w3wp.exe (0x0AA8) 0x044C Windows SharePoint Services General 8dzz High Exception Type: System.Web.HttpException Exception Message: Unable to validate data.
Diagnotic : Certaines pages systèmes (dans /_layouts/*.aspx) ne supportent pas la présence d’une webpart de recherche dans la page maître. Article détaillé.
Solution : Si la page maître d’application “application.master” contient une webpart de recherche, il faut la supprimer (édition dans un bloc note, puis publication dans la galerie des pages maitres du site).

SharePoint : déploiement global d'une solution

Pour qu’une solution soit déployable globalement, il faut qu’elle réunisse les conditions suivantes :
– Elle ne doit pas contenir de web controls.
– Elle ne doit pas contenir de web parts.
Pourquoi ? Parce que ce type d’éléments provoque une modification du fichier web.config, d’où la nécéssité de cibler explicitement les web app concernées.

SharePoint sous IIS 7 : "Ouvrir avec l'explorateur Windows" ne fonctionne pas

Explorer View
Symptômes : Il peut y avoir de multiples raisons pour que la vue « Explorer » d’une bibliothèque ne fonctionne pas, avec de multiples solutions (souvent côté client) disponibles sur Internet.
Cependant le problème peut être côté serveur, notamment dans le cas d’un hébergement sous Windows Server 2008 et IIS 7 (+ client IE8).
Explication : SharePoint possède son propre moteur WebDAV via un filtre ISAPI. Il faut donc désactiver le rôle « serveur WebDAV » par défaut de Windows 2008.
Solution : Aller sur le « Gestionnaire de serveur » > « Rôles » > « Supprimer des services de rôles » > « Publication WebDAV ».
KB Microsoft
Article très complet
Sujet sur forum technet

SharePoint : Exception lors de la mise à jour de la configuration d'une application web

Le dysfonctionnement d’un serveur frontal perturbe la propagation de la configuration SharePoint.
Symptôme
L’erreur suivante peut survenir lors de la mise à jour d’une application web via l’administration centrale (mappage, accès anonyme, extension de site, etc.) :
Un objet de type Microsoft.SharePoint.Administration.SPWebApplicationProvisioningJobDefinition appelé « Provisioning xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx » existe déjà sous le parent Microsoft.SharePoint.Administration.SPWebService appelé «  ». Renommez votre objet ou supprimez l'objet existant.
Explication
Ceci peut être du au fait qu’un serveur de la ferme (web frontal) n’est plus accessible par l’administration. Du coup, les jobs de propagation de configuration restent en échec.
Résolution

  •   Vérifier pourquoi l’un des serveurs n’est plus accessible, et régulariser la situation.
  •   Supprimer tous les jobs de type « Job provisionning » via l’administration centrale > Opérations > Définitions des travaux du minuteur > « Mise en service de l’application web… »…
  •   … ou avec l’outil SharePoint Manager 2007, sous « <ROOT>/Services/Application Web de Windows SharePoint Services > Job Definitions ».

NB : Même topo pour les exceptions concernant SPWebApplicationUnProvisioningJobDefinition.

WSS / MOSS : Quelques problèmes connus à propos du service de recherche

Bien configurer les services de recherche dans une ferme SharePoint…
MOSS + SSP – Symptôme : L’indexation échoue, la recherche sur les sites ne renvoie rien, etc.
Il faut faire attention à ne pas dédier un frontal pour l’analyse des requêtes. (« Administration centrale > Opérations > Services sur le serveur > Paramètres du service Office SharePoint Server Search »). Cette configuration doit être justifiée, et en plus nécessite des pré-requis précis. Voir ce billet MSDN.
 
WSS ou MOSS – Symptôme : Echec de l’indexation. Erreurs 2424 et 2436 dans le journal des événements.
Un update de sécurité des serveurs Windows (2003 / 2008) rend les resolutions d’adresses locales impossibles. Du coup le service d’indexation n’arrive pas à résoudre les URL de son propre serveur !
2 solutions possibles : Changer la valeur de la clé de registre « DisableLoopbackCheck », ou lister les URL autorisées en base de registre.
Billet complet sur ce problème
KB de Microsoft
 
WSS – Symptôme : Une recherche sur un site renvoie : « Impossible d’effectuer la recherche car ce site n’est affecté à aucun indexeur »
Il faut configurer le serveur de recherche pour cette appli web : « Administration centrale > Gestion des applications > Bases de données de contenu »
Sélection l’application web concernée, cliquer sur la BDD, et sélectionner le « Serveur de recherche » dans la liste déroulante.
Cliquer sur « OK ».

MOSS 2007 : Changer la masterpage

Oui Maître !
Si la feature « Infrastructure de publication Office SharePoint Server » ou « Publishing Infrastructure » est activée, il est possible d’accéder au menu « Page maitre » dans « Actions du site > Paramètres du site > [Aspect] Page Maitre ».
Il suffit alors d’ajouter une master page dans la galerie (toujours via les « paramètres du site »), et il devient alors facile de créer son propre thème de site.
Dans le cas d’un site WSS sans la feature de publication (donc pas d’IHM pour modifier la masterpage), il est toujours possible de créer sa propre feature qui va modifier la masterpage du site.
 

SharePoint : Bug natif dans le modèle de liste "Forum de discussion"

Un paquet de CAML !
Quelque soient les droits des utilisateurs dans un forum de discussion SharePoint, le lien « Afficher les propriétés » apparait pour chaque message. Or ce lien redirige vers les propriétés du message, où il est possible de le modifier, le supprimer…
Résultat : l’utilisateur va se retrouver devant une page d’erreur quand il tentera ces actions.
Pour corriger ce dysfonctionnement natif, le mieux et de créer son propre modèle de liste DiscussionList (en copiant-collant l’original), et de corriger le fichier %FEATURE%DiscussionsListDiscussschema.xml
Dans notre cas, on va simplement afficher ce lien uniquement aux utilisateurs qui sont l’auteur du message. A la ligne 351du fichier, il faut remplacer le code défécteux par celui-ci (entre le </Switch> de la ligne 351 et le <IfHasRights> de la ligne 354) :
          <HTML><![CDATA[<td style="border-style:none" nowrap="TRUE"><div>]]></HTML>
<IfEqual>
<Expr1>
<Column Name="Author"/>
</Expr1>
<Expr2>
<UserID></UserID>
</Expr2>
<Then>
<HTML><![CDATA[<a id="DisplayLink]]></HTML>
<Field Name="ID" />
<HTML><![CDATA[" href="]]></HTML>
<URL Cmd="EDIT" />
<HTML><![CDATA[" ONCLICK="GoToLink(this);return false;" target="_self">]]></HTML>
<HTML><![CDATA[<NOBR>Afficher les propriétés</NOBR></a>]]></HTML>
</IfHasRights>
</Then>
</IfEqual>


Bien sûr, tout ceci peut être libre de toute fantaisie !

XSL / Sharepoint : "L'affichage spécifié n'est pas valide"

C’est pas du 16/9ème ?
… ou encore en anglais : « The specified view is invalid ».
Cette erreur peut intervir lorqu’on créé une DataFormWebPart (DFWP) sous le SharePoint Designer (en partant d’une webpart native (ListViewWebPart), et en la convertissant en vue XSL).
Lorsqu’on va exporter cette webpart, et l’intégrer dans une page, l’erreur va survenir. Il va alors falloir aller dans la page de maintenance et supprimer la WP.
Certains forums donneront cette solution : Editer le fichier *.webpart dans un bloc-note, et supprimer la propriété « viewflag« . Mais cette action à des effets de bord bien plus perfides.
Je pense (pour l’instant) que la meilleure chose à faire et de partir d’une source de données (au lieu d’une webpart native) pour créer sa DFWP.
 

XSL / Sharepoint : Doublons des entrées dans les filtres (DataFormWebParts)

La chose faite d’houblon.
Dans le cas de DataFormWebParts à sources de données aggrégées, il se peut que les filtres des en-têtes contiennent plusieurs fois les mêmes valeurs.
Ce petit bug d’affichage est corrigible en allant manipuler le code XSL de la page (via le SharePoint Designer).
Dans le template nommé « dvt.filterfield« , trouver une boucle for-each qui appelle le template « filteroption » :
     <xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />
</xsl:call-template>

La boucle qui appelle ce template est censée faire un « distinct » sur les données à lister, mais ça ne fonctionne pas toujours.
Les données sont cependant triées, on va donc autoriser l’affichage de la donnée à chaque fois qu’on change de valeur dans la boucle. Pour cela, il suffit d’encadrer cet appel par la condition suivante :
     <xsl:variable name="OptionValue" select="ddwrt:NameChanged(string(.), 0)" />
<xsl:if test="string-length($OptionValue)">

          <xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />           </xsl:call-template>
     </xsl:if>
 
NB : NameChanged teste si une valeur change depuis sa dernière affectation.