Serveur SharePoint 2010 : Surcharge de la mémoire

Le bac à sable, pour le garde des sceaux
Symptôme : La RAM atteint une consommation inquiétante (et incrémentielle).
Diagnostic : La multiplication des processus SPUCHostService.exe et SPUCWorker*.exe pollue la mémoire. Ces processus correspondent aux solutions qui fonctionnent en mode “bac à sable”. Cela permet d’exécuter du code utilisateur sans risque pour le processus IIS w3wp.exe.
Solution : Relancer le service “Service de code en mode bac à sable Microsoft SharePoint Foundation” (via l’administration centrale ou Powershell (ci-dessous).
Se connecter au serveur avec le compte d’installation de la ferme.
Lancer une fenêtre POWERSHELL sur le serveur (en tant qu’administrateur), et de lancer les commandes suivantes :
Get-SPServiceInstance | Where-Object {$_.TypeName -like "Service de code en mode bac*"}
Copier la valeur de l’ID affichée, et entrer les commandes suivantes :
Stop-SPServiceInstance -Identity "id_copié_précédemment"
Start-SPServiceInstance -Identity "id_copié_précédemment"
 
Aller plus loin : Déterminer quelle solution en mode bac à sable provoque cette multiplication des processus.

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 2010 : Renommer une URL de sous-site et c'est le drame…

Renommer une URL de sous-site provoque une perte des données.
Symptôme : Dans SharePoint 2010, dans “Actions du site > Paramètres du site > Titre”, il est possible de modifier l’URL d’un sous-site. Après la modification, le site devient inaccessible, ou tout son contenu est perdu.
Diagnotic : L’URL donnée au sous-site est déjà utilisée (par une collection de sites par exemple). SharePoint a failli à sa tâche de prévenir l’utilisateur.
Solution : Restaurer la base de données de contenu. Puis au choix : Renommer l’URL du sous-site sous un autre nom. OU (si la collection de site est obsolète) supprimer la collection de sites ET le chemin d’accès géré, et renommer le sous-site comme voulu.