Dans le cadre de site Intranet corporate de Publishing, il arrive régulièrement que l’on développe un modèle de site que l’on copie à volonté. L’avantage évident de ce mode de fonctionnement est de simplifier le travail de conception et de design, en préparant un jeu de pages modèles que l’on devra juste compléter le moment venu. Dans cette préparation, on ajoute dans ces pages les WebParts que l’on souhaite retrouver dans la version finale, on devra changer simplement le texte ou les liens. Ainsi, un modèle de site pourra contenir : Plusieurs Layout pages avec des webparts telles que : Content editor WP, pour la description de la page WP Liste de liens en rapport avec la page en question WP de personne pour les responsables de cette page … … Lorsque l’on le site pour une division, il nous faut simplement partir de ce modèle et le copier et coller au bon endroit via l’outil de Gestion de SharePoint : Ce travail n’est pas le sujet de ce message, je vous conseille de consulter les ...

  Lorsqu’on travaille sur des projets SharePoint, il arrive que l’on déploie les premières versions de son travail via un simple BackUp & Restore. Le fait est que ce mode de transfert crée des erreurs dans les logs si le niveau de configuration n’est pas exactement le même entre les deux fermes (ferme de développement et ferme de production). Par exemple, le cas classique est celui suivant : Ferme de développement : MOSS Enterprise (license MSDN) Ferme de production : MOSS Standard Entre ces deux versions, certains composants ne sont pas disponibles dans la version Standard, de plus il est courant d’installer des modules dans les environnements de test, sans forcément effectuer de nettoyage. Quoi qu’il en soit, une fois qu'on a transféré notre site de test en production, les traces de ces modules sont toujours dans les bases de données et poluent les fichiers de log ULS, comme on le voit sur l’exemple suivant : Avec le texte suivant : …… Failed to determine definition for featu...

  Microsoft a mis à la disposition des utilisateurs la nouvelle version Beta de Windows Live Essentials 2011 : Programme Installation Windows Live en version bêta Cette version est disponible d’ailleurs dans de nombreuses langues dont le  Français , et permets d’avoir par défaut tout un ensemble de produits tels que : Windows Live Mail Windows Live Messenger Windows Live Galerie de photos Windows Live Movie Maker Windows Live Writer Windows Live Contrôle parental et Devices … Nous parlerons du cas spécifique de la version Windows Live Mail 2011 qui apporte une grande avancée dans les comptes supportés par défaut. Il est désormais possible d’ajouter nativement un compte  GMAIL  comme le montre l’interface d’ajout : Il suffit bien sur dâjouter son adresse mail GMAIL ainsi que le mot de passe et ensuite configurer le support IMAP sur le site GMAIL comme indiqué ici : Enabling IMAP A ce moment, au bout d’un certain temps nécessaire à la synchronisation, vous aurez alors ...

  Ce service est responsable en autres actions de l’enregistrement des logs de SharePoint sur le serveur courant. Ainsi, une ferme multi Front End aura ce processus actif sur chacun des Web Front End qui enregistreront chacun les logs d’activité du moteur. Or, dans 90% des cas, ces logs ne sont pas nécessaires et le principal intérêt de ceux-ci est de trouver la raison d’une erreur. Je vous propose donc de modifier le paramétrage des logs au minimum. Pour ceci, il faut aller dans la rubrique “ Operations ” de la “ Central Administration ”, et cliquer sur “ Diagnostic logging ” Dans la rubrique “ Event Throttling ”, on va sélectionner la catégorie “ Timer ” et choisir les valeurs : Least critical event to report to the event log:  Error Least critical event to report to the trace log:  Unexpected On valide la modification par OK. Il est aussi envisageable de spécifier ces valeurs directement pour toutes les catégories, via la valeur de la catégorie “ All ”. Il vous sera né...

  Dans la continuité des modifications permettant d’améliorer les performances d’une ferme SharePoint, nous allons voir le cas particulier de   l’entête HTTP ETag : HTTP ETag 14 Header Field Definitions - Chapter 14.19 Ce paramètre ajouté directement par le serveur WEB permet d’avoir une “datation” du flux envoyé par celui-ci. L’idée est donc de permettre au client WEB la possibilité de comparer directement la date de chargement de deux objets. Si on trouve une différence entre ces deux objets, un rechargement est fait, sinon le cache du navigateur est utilisé. On trouve une explication de ce mécanisme avec Internet Explorer : You may experience poor Web performance when you use Internet Explorer 6 to try to access a Web application that is hosted on Internet Information Services 6.0 High Performance Web Sites: Rule 13 – Configure ETags IIS7 Deployments calls for ETag Usage Review if using Problème en cas de clustering Dans le cas d’une ferme SharePoint, on peut avoir  pl...

  Lorsqu’on administre une ferme SharePoint, il est courant de réceptionner des appels d’utilisateurs signalant qu’ils ne reçoivent plus d’alerte. Nous avions vu dans un article précédent le fonctionnement de cette fonctionnalité de base : Les alertes dans SharePoint 2007 Ainsi, dans ce contexte, on sait que les solutions restent souvent les mêmes avec les explications dans la page suivante : Problèmes potentiels avec les alertes La plus utilisée restant l’exécution des commandes pour redémarrer le service NT SPTimer : NET STOP SPTIMERV3 NET START SPTIMERV3 Mais, il est possible de savoir avant les utilisateurs que ce fonctionnement est à relancer, ce qui évite à ceux-ci d’avoir une mauvaise image du produit et donc une meilleure confiance en la solution globale. Pour cela, il faut aller dans le site de la “ Central Administration ” de SharePoint dans la rubrique “ Operations ”, et cliquer sur le lien “ Timer job status ” On trouve alors la liste de tous les jobs en activité dans l...

  Lorsqu’on met en place un site   SharePoint MOSS 2007   basé sur le   modèle de publishing   on obtient un site de base avec deux menus à plusieurs niveaux : Ainsi un site vide avec peu de niveaux de profondeur n’aura pas de grand soucis lors de l’affichage de ces deux menus. En revanche, lorsque la structure des données commence à devenir conséquente : Plusieurs niveaux hiérarchiques  (Départements, Services, Unités, Localités, …) Plusieurs pages par niveaux Ces deux menus commencent à devenir conséquent. Imaginons par  exemple  une structure simple de hiérarchisation : 4 niveaux 6 items par niveaux On obtient un arbre sous la forme : Niveau 0 Niveau 1 - 1 Niveau 2 - 1 Niveau 3 - 1 Niveau 4 - 1 Item 1 Item 2 … Niveau 4 – 1 … Le calcul du nombre d’items est donc : 6 * 6 * 6 * 6 = 1296 items Cela devient rapidement un nombre conséquent, qu’il faut maintenant rapprocher avec le volume pris dans le fichier HTML pour chaque Item, car cela ne vient p...

  Toujours dans la suite des articles sur l’optimisation des performances de sites basés sous Microsoft Office SharePoint Server 2007, voilà une des fonctionnalités intéressantes : Disk-Based Caching for Binary Large Objects Le BlobCache Cette  fonctionnalité est disponible uniquement pour une ferme basée sur MOSS , en effet, l’activation du BlobCache sur une ferme WSS provoque une erreur : Mais qu’est-ce que ce principe ? Dans un site SharePoint, tout ce qui n’est pas dans le répertoire “ 12 ” est en base de données. Le résultat de cette logique n’est pas dramatique en soit, mais on voit très rapidement que de  nombreux fichiers de Design  peuvent se trouver dans cette base de données : Les fichiers de script (.JS) Les fichiers de design (.CSS) Les images Lorsque chaque utilisateur arrive sur la page par défaut, il y a un  grand nombre de requêtes SQL qui sont exécutées pour uniquement extraire ces fichiers  et les associer au rendu HTML transmis à cet uti...

  Dans mon précédent article, j’avais évoqué le lancement d’une série sur les optimisations possibles pour améliorer les perfomances d’un site SharePoint de type Publishing (Portal Intranet Corporate) : SharePoint : Optimisations des performances d’un site Intranet de type Publishing Après quelques jours de test, voici un bilan sur le résultat de cette modification. Tout d’abord,  l’usage du ViewState en ASP.NET  permet d’éviter des rechargements intempestifs de toute la page lors de la modification de certaines parties de cette page. Le cas classique est le formulaire avec des listes déroulantes en cascade. Dans le cas spécifique du menu de SharePoint (Objet  SharePoint:AspMenu ), le chargement de ce composant et donc de l’ensemble des liens peut être séparé en deux cas précis : Site de Publishing Internet public Site de Publishing Intranet ou Extranet En effet, le comportement de ce menu lors de son chargement est de tester les permissions pour l’utilisateur connec...

  Dans le cadre de la liste des articles sur l’amélioration des performances de sites SharePoint : SharePoint : Retour d’usage sur la désactivation du ViewState dans un site de Publishing SharePoint : Optimisations des performances d’un site Intranet de type Publishing Nous allons voir une modification qui permet d’améliorer les performances d’un site SharePoint, mais en réalité qui fonctionne sur tout site WEB Intranet et Extranet. En effet, un site Intranet ou Extranet est essentiellement destiné à un public spécifique et nécessite moins d’informations en terme de retour marketing (surtout pour des Team Sites). Ainsi, deux informations enregistrées par les serveurs IIS (non cochées par défaut) dans les logs ne sont pas nécessaires,  même pour les analyses statistiques  : Cookies (cs(Cookie)) Referer (cs(Referer)) En effet, dans le cadre de sites Intranet ou Extranet La notion de  Referer  est peu, voire pas utile puisque, globalement, ce ne seront que des lien...