SharePoint (2007/2010) : Echec de l'élévation de privilèges dans un EventReceiver.

Au rez-de-chaussée, c’est ‘.
Dans un EventHandler de ce type (ou d’un autre !) :
public override void ItemAdded(SPItemEventProperties properties){
   SPSecurity.RunWithElevatedPrivileges(delegate()   {
  // Actions nécessitant des privilèges.
});
Dans le code exécuté avec privilèges, il NE FAUT PAS utiliser directement les objets présentés par l’objet properties (.List, .Web, etc.). Il faut retrouver ces objets avec leur ID (.ListID, .SiteID, etc.). Sinon il y a de grandes chance d’avoir des valeurs ‘ ou des exceptions d’accès.
SPSite monSite = new SPSite("url.com");
SPList maListe = monSite.Lists[properties.ListID];
SPItem monItem = maListe.GetItemById(properties.ListItemId);
etc…
 

SharePoint : Déplacer une liste / bibliothèque d'un site WSS/MOSS vers SharePoint 2010

  • Enregistrer la liste source en tant que modèle (fichier STP), avec les données.
    • Si la taille des données est trop importante, autoriser exeptionnellement une taille de modèles supérieure : "C:Program FilesFichiers communsMicrosoft Sharedweb server extensions12BINSTSADM.exe" -o setproperty -pn max-template-document-size -pv 52428800
  • Récupérer ce fichier STP.
  • Renommer le fichier en .CAB.
  • Extraire les fichiers.
  • Editer le fichier manifest.xml, et modifier la valeur de <ProductVersion> à 4.
  • ré-empaqueter le(s) fichier(s) dans une archive .CAB :
    • Utiliser makecab.exe si il n’y a qu’un seul fichier (manifest.xml).
    • Utiliser iexpress.exe si il y a plusieurs fichiers.
  • Renommer le fichier en .STP
  • Utiliser ce fichier comme modèle de liste dans le site de destination.

Source

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 : "stsadm -o backup" renvoie des erreurs KeyNotFoundException

Où sont passées les clés ?
Symptôme : Lors d’un backup catastrophique de la ferme, l’erreur “KeyNotFoundException” peut survenir, notammanent pour les objets liés à la recherche SSP (“Index de recherche partagé” ou la base de données associée).
Explication : Plusieurs causes sont envisageables. Notamment un index déféctueux ou obsolète. Le mieux est de vérifier si les services de recherche sont bien configurés et démarrés (dans l’admin centrale, mais aussi dans les services partagés).
Solution 1 : Purger les index.

  • Accéder au serveur d’administration incriminé.
  • Ouvrir l’Administration centrale de SharePoint 3.0
  • Accéder au site des services partagés
  • Cliquer sur « Administration de la recherche »
  • A gauche, cliquer sur « Réinitialiser tout le contenu analysé ».
  • Cliquer sur le bouton « Réinitialiser maintenant », confirmer par “OK”.
  • La sauvegarde ne devrait plus retourner d’erreurs.

Solution 2 : Dans le cas où le script ne fonctionne toujours pas, on redémarre les services de recherche en vérifiant leur bonne configuration.

  • Aller dans l’administration centrale
  • Cliquer sur « Opérations », puis « Services sur le serveur »
  • Arrêter le service « Service de recherche Office SharePoint Server », et confirmer.
  • Démarrer ce même service
  • Cliquer sur « Opérations », puis « Services sur le serveur »
  • Cliquer sur « Recherche d’aide Windows SharePoint Services » (ou « recherche d’aide… » selon la version).
  • Confirmer le compte et mot de passe du « compte d’accès au contenu », cliquer sur OK.
  • Cliquer sur « Administration de services partagés »
  • Faire « Modifier » sur le service partagé, et lui associer le serveur d’indexation.
  • Le service de recherche SSP devrait fonctionner, et le script de sauvegarde ne devrait plus retourner d’erreurs.

La solution 2 a fonctionné dans un cas précis. Seul problème : on perd ses index, et dans le cas de fermes SharePoint conséquentes, d’autres solutions sont à envisager.

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 : Attention à l'héritage des droits de l'accès anonyme !

Lorsqu’un site est ouvert en anonyme, cela correspond à déclarer l’utilisateur « AUTORITE NTutilisateurs authentifiés » avec l’autorisation « Accès limité » (cf. /_layouts/user.aspx).
Du coup, l’ensemble des utilisateurs qui se connecteront au site auront au moins les droits liés à « accès limité ». Quelque soit le(s) groupe(s) ou les autorisations qu’on leur a explicitement associés.

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 ».