SharePoint : Attention à la configuration des fichiers de Trace (ULS)

 Pour les fermiers SharePoint, le paramètre des logs est un casse tête chinois. En effet, il faut sans arrêt arbitrer entre :

• Combien de jours de dois historiser pour revenir en cas de soucis à la date en question, sans pour autant massacrer mon volume disque pour rien ?

Cette qquestion est encore plus épineuse lorsque l’on voit les options de configuration possibles (avec un net avantage pour SP2010 et 2013 pour la compréhension de l’utilisateur) :

SharePoint 2013 : Monitoring > Configure diagnostic logging

SharePoint 2010 : Monitoring > Configure diagnostic logging

SharePoint 2007 : Operation > Diagnostic logging

On voit dans les deux versions 2010 et 2013, qu’il faut entrer le nombre de jours d’historisation dans le champs, sans aucune idée sur le volume que cela donnera pour l’intervalle choisie.

Dans la version 2007, la configuration semble plus fine sur ce point, mais au final le problème reste entier, car cette configuration ne conservera que XX fichiers de log par tranche de temps choisie.

Pour faire simple, dans le cas de 2007, la configuration entrée donne :

• 100 [fichiers rotatifs] * 0.5 [Heure par fichier] = 50 [Heures de log] / 24 [Heures par jour] = environ 2 [jours de log]

Ce point est crucial, car dans le cas d’un soucis rencontré le vendredi soir, vous n’avez plus de trace le lundi matin, ce qui est génant pour le Debug à suivre. Il est préférable de choisir une valeur permettant une historisation de 7 jours glissant.

Outre la correction de cette configuration pour conserver un minimum d’une semaine de Log, ce qui donne dans le cas de notre version 2007 :

• Number of minutes to use a log file: 60 min
• Number of log files: 24*7 = 168

Il faut surtout compresser automatiquement le répertoire de ces logs via Windows (quelque soit la version de SharePoint).

Ceci peut se faire simplement via:

Windows, avec les propriétés avancées du répertoire

ou via PowerShell, avec la fonction suivante basée sur les articles disponibles à ces adresses:

• http://www.humanstuff.com/2010/6/24/how-to-compress-a-file-using-powershell
• http://blogs.technet.com/b/heyscriptingguy/archive/2010/05/22/hey-scripting-guy-weekend-scripter-using-windows-powershell-to-compress-folders.aspx

---

Function CompressFolder ($folder)
{
    # Replace \ with \\ for WMI
    $wmiPath = $folder.Replace("\","\\")
    $wmiDirectory = Get-WmiObject -Class "Win32_Directory" -Namespace "root\cimv2" -ComputerName $env:COMPUTERNAME -Filter "Name='$wmiPath'"
    # Check if folder is already compressed
    If (!($wmiDirectory.Compressed))
    {
        Write-Host -ForegroundColor White " - Compressing $folder and subfolders..."
        $compress = $wmiDirectory.CompressEx("","True")
    }
    Else {Write-Host -ForegroundColor White " - $folder is already compressed."}
}

---

Ce qui donne dans le cas d’un serveur SharePoint 2013 de test un résultat comme suit :

Romelard Fabrice [MBA Risk Management]