Comme toute solution informatique, SharePoint ou Outlook sont des produits magiques pour les utilisateurs. Ainsi, il arrive bien souvent qu’un utilisateur clique sur un bouton, un lien, un menu, …, sans aucune idée sur les impacts réels de cette action. L’exemple classique est la connexion entre Outlook et une liste SharePoint (Calendar, Contact, Task, …) qui va être persistante sans que l’utilisateur n’ai conscience de la présence. Ceci n’est pas particulièrement grave si l’utilisateur n’a que les droits de lecture, mais devient beaucoup plus risqué si celui-ci a bien les droits d’écriture sur la liste. En effet, lors de la synchronisation entre le client riche et la liste SharePoint, Outlook peut alors ouvrir tous les éléments de cette liste sans modifier le contenu, mais en créant une nouvelle version de chaque Item. Ainsi dans le cas d’une Task List avec des Alertes et des items attribués à différentes personnes, ce sont des centaines de messages Emails qui partent dans tous ...

  Tout fermier SharePoint est confronté un jour ou l’autre à cette question d’arrêt de serveur. Il est évident que pour une infrastructure Stand Alone (1 serveur) ou Small farm (2-3 serveurs), cela se fera très simplement et ne posera pas de soucis particulier, tant que le serveur SQL est arrété en dernier. Le cas devient plus délicat lorsqu’on commence à gérer plusieurs Large Farm (plus de 4 serveurs) dans un ou plusieurs DataCenter. Le script suivant permet donc de stopper les machines, en utilisant la commande standard de Windows “Shutdown /s”, suivant l’ordre donné dans la liste des machines. # Specific parameters $ServersList = "SPWEBSERVER1", "SPWEBSERVER2", "SPWEBSERVER3", "SPEXCELSERVER1", "SPSEARCHSERVER2", "SPAPPSERVER2", "SPDBSERVER1", "SPDBSERVER2" $Logfile = "C:\SHAREPOINT_SERVERS_STOP.log" # Generic parameters [int]$WaitTime = 20 [int]$Counter = 0 [DateTime]$mydate = get-date [string...

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