Augmenter l’espace libre des disques qui hébergent les fichiers des bases de données SharePoint

Dans l’Administration centrale de SharePoint, sur la page « Examiner les problèmes et solutions » de SharePoint 2010, le message « Les lecteurs risquent de manquer d espace libre » est apparu. Ce message d’avertissement prévient que l’espace disque disponible est inférieur à cinq fois la valeur de la mémoire physique. Cette situation est dangereuse, car cela signifie qu’il n’y a pas assez de place pour une image mémoire complète.

Ce problème a été rapidement résolu par l’ajout de l’espace disque supplémentaire nécessaire.

Toutefois, il a été décidé de mener une analyse plus approfondie de l’espace disque consommé par SharePoint. Probablement par manque de compétences sur SQL Server, les administrateurs ne supervisaient pas son fonctionnement.

L’analyse a mis en évidence un autre problème encore plus préoccupant, bien que sans rapport avec le message de l’Analyseur d’intégrité: le serveur qui hébergeait les instances SharePoint de SQL Server avait son espace libre disque qui diminuait très rapidement.

Pourtant le volume de données « utilisateurs » était relativement faible. La proportion était de l’ordre de 15 Go consommés pour 1 Go de nouvelles données utilisateurs.

Ce n’est pas si surprenant car les données étaient mises à jour très fréquemment et en masse dans la journée à cause de nombreux traitements automatiques : import de référentiels, etc.

En l’absence d’une surveillance ad’hoc et des outils adaptés, le client s’est retrouvé avec 100 Mo de disque libre sur un disque dur de 100 Go.

La solution est simple et connue. L’application de la commande Transact-SQL DBCC SHRINKDATABASE sur toutes les bases de données a permis de réduire la taille des fichiers de données et, surtout, des journaux de transactions.

En effet, compte tenu de leur mode de fonctionnement, ce sont les journaux de transactions qui consommaient le plus de place.

L’espace libre est remonté de 100 Mo à 75 Go.

Ensuite, la commande T-SQL a été encapsulée dans un package dtsx qui a été répliqué sur toutes les instances.

 

Un lien vers un fichier PDF d’un site SharePoint propose de l’enregistrer plutôt que de l’ouvrir

Suite à la création d’une nouvelle collection de sites dans une nouvelle application web SharePoint, un utilisateur a remarqué un changement de comportement à l’ouverture d’un fichier au format PDF.

Lorsqu’il ouvrait un fichier PDF, stocké dans une bibliothèque SharePoint, l’affichage du document se faisait dans le client Acrobat Reader. Ce comportement convenait parfaitement à l’utilisateur.

En revanche, lorsque l’utilisateur recevait par la messagerie un email qui contenait un lien vers un fichier PDF stocké dans une bibliothèque SharePoint et qu’il cliquait sur ce lien, il lui été proposé d’enregistrer le fichier sans pouvoir le lire directement.

Dans les deux cas, l’utilisateur souhaitait lire le fichier PDF directement soit dans Acrobat Reader, soit dans le navigateur Web.

La première idée a été de chercher à résoudre le problème en réduisant les exigences de sécurité.

Concrètement, il suffit de modifier les paramètres généraux de l’application web pour basculer l’option Gestion des fichiers par les navigateurs (Browser File Handling) de Strict à Permissif.

Modification du paramètre Gestion des fichiers par les navigateurs.

Quelles sont les conséquences de la modification de la gestion des fichiers par les navigateurs?

Extrait de la documentation Microsoft:

« Gestion des fichiers par les navigateurs indique si d’autres en-têtes de sécurité doivent être ajoutés aux documents envoyés aux navigateurs Web. Ces en-têtes indiquent qu’un navigateur doit afficher une demande de téléchargement pour certains types de fichiers (.html, par exemple) et utiliser le type MIME spécifié du serveur pour les autres types de fichiers.

Permissif: Spécifie qu’aucun en-tête ne doit être ajouté, ce qui offre un environnement plus compatible.

Strict: Ajoute des en-têtes forçant le navigateur à télécharger certains types de fichiers. Le téléchargement forcé renforce la sécurité du serveur grâce au refus de toute exécution automatique du contenu Web téléchargé par les collaborateurs. »

Autrement dit, une meilleure solution consisterait à rajouter le type MIME des fichiers PDF à la liste des fichiers autorisés, plutôt que de modifier le paramètre Gestion des fichiers par les navigateurs au détriment de la sécurité.

Pour connaître les types MIME autorisés, il faut lancer les commandes PowerShell suivantes, à partir de SharePoint 2010 Management Shell (exécutées en tant qu’Administrateur):
$webapp = Get-SPWebApplication http://urlsite
$webapp.AllowedInlineDownloadedMimeTypes

Vous obtenez une liste assez longue (extrait):

  • application/directx
  • application/envoy
  • application/fractals
  • application/internet-property-stream
  • application/liquidmotion
  • application/mac-binhex40
  • application/ms-infopath.xml
  • application/msaccess
  • application/msword
  • etc.

Pour rajouter le type MIME des fichiers PDF, il faut lancer les commandes PowerShell suivantes, à partir de SharePoint 2010 Management Shell (exécutées en tant qu’Administrateur):
$webapp = Get-SPWebApplication http://urlsite #Mettre la bonne URL
$webapp.AllowedInlineDownloadedMimeTypes.Add(« application/pdf ») #Ajout
$webapp.AllowedInlineDownloadedMimeTypes #Pour vérifier l’ajout MIME
$webapp.Update() #Mise à jour obligatoire

Cette solution est plus rassurante.

 

SharePoint: les documents d’un dossier s’affichent uniquement lors d’un changement d’affichage

Lors de la mise en place d’un nouveau site, l’utilisateur a demandé la création de dossiers dans chaque bibliothèque de son site.

Nous savons tous que c’est une mauvaise habitude d’utiliser les dossiers dans une bibliothèque SharePoint, et qu’il est préférable d’utiliser des métadonnées. Les métadonnées gérées sont particulièrement efficaces pour caractériser un document.

Petit rappel: une métadonnée est une propriété. Par exemple, le titre ou la date d »un document sont des métadonnées. Les métadonnées gérées sont des listes de valeurs.

Dans ce cas particulier, les utilisateurs du site venaient de pays différents et il fallait trouver un dénominateur commun et surtout aller vite !

Dans un des dossiers, les documents s’affichaient uniquement lors d’un changement d’affichage.

A l’ouverture du navigateur, les documents n’apparaissaient pas et il s’affichait uniquement le message habituel: « Aucun élément à afficher dans cet affichage de la bibliothèque de documents. Pour ajouter un élément, cliquez sur Nouveau ou sur Télécharger ».

En réalité, le site étant multilingue, il s’affichait dans la langue par défaut (anglais): « There are no items to show in this view of the document library. To add a new item, click New or Upload ».

Un autre problème est apparu dans le même dossier. Le menu « Open with Explorer » ne fonctionnait plus alors qu’il avait fonctionné la veille. Il avait été utilisé pour charger les documents.

Comble de malchances, les documents chargés étaient tous des fichiers au format PDF d’Acrobat. L’utilisateur pensait que cela venait de ce format.

En fait, il n’en était rien. Le problème venait de la configuration vérolée du dossier dans la base SharePoint.

La résolution du problème a consisté à :

  • sauvegarder les fichiers présents
  • supprimer le dossier déficient
  • recréer le dossier avec le même nom
  • recharger le dossier avec les fichiers sauvegardés
  • refaire la navigation (qui était gérés manuellement…)

Un argument de plus pour limiter l’utilisation des dossiers.