Sharepoint 2010 : Silverlight un logiciel préalable ou facultatif sur le poste client ?

Sharepoint 2010 offre de base un nouveau Web Part soit le Silverlight Web Part. Ce dernier permet d’insérer et diffuser aisément du contenu média ou même une application riche à même Sharepoint. En supposant qu’une organisation ne désire pas utiliser ce nouveau Web Part, on peut se demander s’il est nécessaire de déployer le logiciel sur les postes clients.

L’article Technet « Configuration matérielle et logiciel requise » précise que Microsoft Silverlight 3 est facultatif sur le poste client. A première vue, il est donc raisonnable de conclure qu’on n’a pas besoin de Silverlight sur les postes clients. Et c’est vrai. Par contre, on va passer à côté de quelques améliorations notables au niveau de l’expérience utilisateur.

Le premier exemple se situe au niveau de la création d’une liste. Ci-dessous, l’interface de création sans Silverlight. Vous noterez au passage le message sur fond jaune qui ne manque pas de rappeler que ce serait mieux avec Silverlight.

Ci-dessous la même action mais avec Silverlight. La différence est frappante. Une fenêtre de dialogue propre à la création d’une liste avec des icônes et même effet « rollover » lorsqu’on passe sur ceux-ci avec la souris.

La situation est la même pour la création d’un site. Enfin un dernier exemple pour vous convaincre des bienfaits de Silverlight se situe au niveau de l’explorateur d’organisation, sous le profil de l’utilisateur. À nouveau, un message nous indique que ce serait mieux avec Silverlight.

Ci-dessous, la même interface avec Silverlight. Bien que ma machine de test ne dispose pas d’une structure organisationnelle, l’image vous démontre quand même que l’expérience utilisateur sera grandement rehaussée. L’explorateur d’organisation permet de naviguer visuellement dans la structure hiérarchique de l’organisation.

En conclusion, bien qu’il soit juste de dire que Silverlight est un logiciel optionnel dans le contexte d’un déploiement Sharepoint 2010, je crois qu’il faut sérieusement se poser la question avant de prendre la décision de ne pas déployer le logiciel. Pour ma part, il est certain que si on me donne le choix en tant qu’utilisateur, je choisis l’expérience rehaussée avec Silverlight.

Sharepoint 2010 : Les nouveautés pour les administrateurs

Sharepoint 2010 apporte un grand nombre de nouveautés et d’améliorations pour les administrateurs.

Voici la présentation que j’ai donné à l’interne chez DMR la semaine dernière :

Vous pouvez consulter toutes mes présentations sur SlideShare ou par le biais de ma page Présentation sur ce blogue.

Sharepoint 2010 : L’analyseur d’intégrité – Partie 3

La première partie de cette série a introduit l’Analyseur d’intégrité, la seconde partie  a présenté plus en détail les divers éléments relatifs aux règles proprement dites et cette dernière descend un peu plus dans le détail pour comprendre comment cela fonctionne par en-dessous.

La vérification d’une règle s’effectue par l’entremise d’un travail du minuteur. Lors de la vérification de la règle vous trouverez des messages dans l’ULS log. Ces message indiquent que Sharepoint débute la vérification de la règle, termine la vérification et lorsque c’est le cas, qu’il y a eu une erreur.

Pour voir et modifier les travaux du minuteur se rapportant aux règles de l’Analyseur d’intégrité, le chemin le plus simple est de passer par le menu « Analyse »  puis « Configurer la collection des données d’utilisation et d’intégrité » dans la rubrique « Rapports » puis « Planification de la journalisation d’intégrité » dans la section « Collecte des données d’intégrité ». Un écran similaire à celui ci-dessous s’affichera :

Les travaux encadrés en bleu sont ceux qui traitent les règles d’intégrité. Vous noterez au passage, qu’il y a un travail par combinaison d’étendue et planification sauf pour la combinaison « mensuel / tous les serveurs ».

Cette courte série de trois articles nous a permis de découvrir ce nouvel outil qui avouons-le est très intéressant.

Sharepoint 2010 : L’analyseur d’intégrité – Partie 1
Sharepoint 2010 : L’analyseur d’intégrité – Partie 2
Sharepoint 2010 : L’analyseur d’intégrité – Partie 3

Sharepoint 2010 : L’analyseur d’intégrité – Partie 2

La première partie de cette série a introduit l’Analyseur d’intégrité. Cette seconde partie présentera plus en détail les divers éléments relatifs aux règles proprement dites.

Les différentes règles peuvent être consulté et modifié par l’entremise du menu « Analyse –> Vérifier les définitions de règles ». Les différentes règles sont regroupées en 4 catégories : Sécurité, Performances, Disponibilité et Configuration. De base le produit installe 31 règles avec l’édition Sharepoint Foundation et 64 sous l’édition Entreprise.  Vous pouvez d’ailleurs télécharger un document énumérant la liste des règles par l’entremise du lien suivant : Liste_Regles_Analyseur_Integrite_SP2010. L’image ci-dessous présente la vue par défaut de la liste :

L’ajout de produits supplémentaires à Sharepoint (comme Project Server ou FAST) ou l’installation d’un service pack pourrait entraîner l’ajout de règle supplémentaire. Il est aussi possible de développer des règles personnalisées. Pour ce faire, je vous suggère de lire la documentation relative à ce sujet sur le site MSDN : http://msdn.microsoft.com/fr-fr/library/ee538249(v=office.14).aspx.

À l’instar de toute liste Sharepoint, il est possible de modifier les caractéristiques d’une règle.

Il est possible de modifier tous les éléments même le titre mais il n’y a pas vraiment d’intérêt à la faire. Par contre, c’est intéressant de pouvoir changer la planification et même d’être en mesure d’activer ou désactiver complètement l’exécution de la règle. Il est aussi possible de planifier la vérification de la règle « Toutes les heures », « Tous les jours », « Toutes les semaines », « Tous les mois » et même « À la demande ». Important de noter le fait que de cocher la case « Réparer automatique » n’aura aucun effet si la règle n’a pas été conçue pour prendre en charge la réparation du problème.

Sharepoint 2010 : L’analyseur d’intégrité – Partie 1
Sharepoint 2010 : L’analyseur d’intégrité – Partie 2
Sharepoint 2010 : L’analyseur d’intégrité – Partie 3

Sharepoint 2010 : L’analyseur d’intégrité – Partie 1

Sharepoint Foundation 2010 inclut un nouvel outil qui se nomme l’analyseur d’intégrité. Ce dernier exécute des règles sur les serveurs de la ferme permettant de surveiller et prévenir des problèmes potentiels. Chaque règle exécute un test et retourne un résultat. Lorsque ce dernier est négatif, un rapport est ajouté à la liste « Rapports de l’Analyseur d’intégrité » et un message apparaît sur la page d’accueil de l’administration centrale. La couleur du message reflétera la sévérité du message. L’image ci-dessous présente un avertissement avec le fond jaune. Un message sévère s’affichera avec un fond rouge.

Lorsqu’on clique sur le lien « Affichez ces problèmes », on est immédiatement dirigé vers la liste « Rapports de l’Analyseur d’intégrité » qui nous présente visuellement l’ensemble des règles ayant échouées. Dès cet instant, il est facile pour l’administrateur d’effectuer un diagnostic rapide et prendre action pour corriger la situation.

Afin d’avoir plus de détail sur les raisons de l’échec, il suffit de cliquer sur le nom de la règle. Un écran similaire à celui ci-dessous s’affiche expliquant les raisons de l’échec  et des pistes de solutions. Après avoir appliqué un correctif, il est même possible d’exécuter à nouveau la règle pour s’assurer que le problème est véritable disparu.

L’analyseur d’intégrité permet de renforcer le suivi des bonnes pratiques.

Sharepoint 2010 : L’analyseur d’intégrité – Partie 1
Sharepoint 2010 : L’analyseur d’intégrité – Partie 2
Sharepoint 2010 : L’analyseur d’intégrité – Partie 3

Intégration entre la suite Office 2007 et Sharepoint Server 2007 sans créer Mon Site

Récemment, on m’a demandé si c’était possible que les applications de la suite Office 2007 puissent présenter la liste des sites auxquels l’utilisateur appartient sans avoir à déployer tout de suite le « MonSite » pour tous les utilisateurs.

La réponse est oui, mais avant de vous montrer comment faire, regardons un peu plus en détail ce qui se passe dans le cas d’une utilisation normale de « Mon Site ».

 Tout d’abord, tant qu’un utilisateur n’a pas enregistré son « Mon Site » comme site par défaut, Sharepoint lui présente la possibilité de le faire tel que vous pouvez le voir dans l’image ci-dessous.

Lorsque l’utilisateur clique sur « Définir comme Mon site par défaut », une clé de registre « PersonalSiteURL » est ajoutée sur le poste dans la branche  suivante :

HKEY_CURRENT_USER\Software\AppDataLow\Microsoft\Office\12.0\Common\Portal (XP et Vista)
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Portal (Windows Server 2003)

La valeur de la clé est l’URL du site de l’utilisateur : http://HoteDeMonSite/personnel/code_usager/

Lorsque l’utilisateur va ouvrir la boîte de dialogue « Ouvrir » ou « Enregistrer » d’une application cliente Office, Word par exemple, celle-ci appelle un Web Service obtient la liste des sites auxquels l’utilisateur est membre. Cette liste est enregistrée localement sur le poste dans le répertoire « C:\Documents and Settings\code_usager\Local Settings\Application Data\Microsoft\Office\Mes sites SharePoint ». La liste est rafraîchit une fois par jour.

L’image ci-dessous présente le résultat dans Office. On peut voir que l’utilisateur en membre du site « TestSite1 » en plus de posséder son « Mon Ste ».

Donc la seule chose nécessaire est d’enregistrée la clé de registre et le tour est joué. On a donc décidé de forcer pousser la clé de registre avec un autre URL tel que présenté ci-dessous :

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Portal]
"PersonalSiteURL"="http://HoteDeMonSite/"

 Ça fonctionne très bien, le client Office va chercher la liste des sites sans afficher de « MonSite » tel que présenté dans l’image ci-dessous.

J’ai réalisé mes sur un poste de travail avec Office 2007 et le système d’exploitation Windows Server 2003. Les premiers essais avec Windows Vista semblent aussi indiquer que ça fonctionne bien.

Je recommande toutefois de réaliser vos propres essais afin de confirmer le bon fonctionnement de cette astuce avec votre configuration car il y a des différences au niveau du comportement selon la version du système d’exploitation et de la version de la suite Office. Par exemple, dans certains autres blogues qui traitent du sujet, on fait mention de certaines clés de registre supplémentaires. Soit dit en passant cette solution sera utilisée pour permettre à l’organisation de se donner le temps de bien planifier le déploiement du « Mon Site ». Elle ne sera pas utilisée sur une base permanente.

En terminant, voici quelques les quelques liens qui m’ont mis sur la piste pour trouver cette astuce :

http://www.wssdemo.com/Blog/Lists/Posts/Post.aspx?List=b853926a%2Db04e%2D4620%2D94e4%2D88a5d56cb262&ID=447&Web=d47402ad%2D1767%2D42ba%2Da072%2D133479a9bb5a

http://www.paulliebrand.com/2009/08/25/publishing-links-to-office-2007-without-enabling-my-sites-in-sharepoint/

http://blogs.msdn.com/sudeepg/archive/2009/09/03/published-links-to-office-client-applications-do-not-show-up-in-file-open-or-save-dialogs.aspx

Les limites reliées à la mise à jour d’une solution

La mise à jour d’une solution à l’aide de la commande “stsadm-o upgradesolution” comporte certaines limitations.

Afin de bien comprendre les limitations précisées un peu plus loin, il est important d’expliquer ce qui se passe vraiment lors de l’exécution de la commande. En fait, c’est bien simple, Sharepoint supprime les fichiers contenus dans la version précédente et installe les fichiers contenus dans la nouvelle version de la solution. Aucune autre opération ne sera effectuée sauf le recyclage du ou des applications pools impliqués dans l’opération.

Une fois ceci bien compris, il est maintenant facile de comprendre qu’il ne faut pas effectuer les opérations suivantes sur la solution :

• Ajout ou suppression d’un feature
• Changement au niveau de l’assembly qui est utilisé comme récepteur d’événement (event receiver)
• Modification, ajout ou suppression d’une propriété d’un feature ou changement au niveau de l’identifiant d’un feature
• Ajout ou suppression d’élément d’un feature (Element.xml)

Si jamais vous rencontrez une des situations énumérées ci-dessus, il sera nécessaire de faire une rétractation complète de solution précédente et effectuer un déploiement de la nouvelle solution.

Solution : Kerberos et BlobCache provoque une fermeture inexpliquée de la connexion TCP

Avec la sortie du Cumulative Update de décembre pour WSS et MOSS vient le correctif pour le problème de fermeture de la connexion TCP dont j’avais parlé le 5 février dernier.

En effet selon le KB97023, le correctif est inclus. Voici un bref extrait en anglais de la description du problème provenant de l’article :  

You enable BLOB Caching on an Office SharePoint Server 2007 site. Then, you use NTLM authentication on this SharePoint site. When a client sends a GET response with the If-None-Match header, Office SharePoint Server 2007 responds with an “HTTP 304″ response and a “Connection: Close” header. This causes two more unnecessary requests for NTLM authentication.

Ça risque de prendre quelques temps avant que je puisse faire les essais mais j’ai d’excellentes raisons de croire que la problématique sera résolue.

Erreur “HTTP/1.1 404 Connection: close” lors de la création de Mon Site

Cette après-midi, je faisais des essais pour la création de Mon Site sous Sharepoint 2007. J’ai donc supprimé Mon Site afin de pouvoir le créer à nouveau. À partir de ce moment, j’obtenais toujours l’erreur suivante lors de ma tentative de recréation de Mon Site :

HTTP/1.1 404 Connection: close Date: Tue, 15 Dec 2009 20:15:59 GMT Server: Microsoft-IIS/6.0 MicrosoftSharePointTeamServices: 12.0.0.6219 X-Powered-By: ASP.NET

Pas d’erreur dans le journal des événements de Windows et pas d’erreur dans le log de Sharepoint. J’ai aussi vérifié que j’étais authorisé à créer un Mon Site dans le SSP. Tout me semble correct partout et pour les utilisateurs qui possédait déjà un MonSite, c’était fonctionnel.

Il fallait donc que ce soit un élément de mon profil qui était corrompu. Je suis donc aller voir le détail de mon profil dans le SSP en utilisant l’item de menu “Propriétés et profil utilisateur”.

Quel ne fût pas ma surprise de constater que le champ “Site personnel” contenait encore une valeur même site Mon Site avait été supprimé.

J’ai retiré la valeur du champ, sauvegardé mon profil et par la suite j’ai été en mesure de créer à nouveau Mon Site.

Messages d’erreurs lors de l’exécution d’une commande STSADM

Est-ce qu’il vous est déjà arrivé d’avoir l’un des messages suivants lorsque vous tentez d’exécuter une commande STSADM :

• Access is denied.
• Cannot connect to the configuration database.
• Login failed for user ‘(null)’. Reason: Not associated with a trusted SQL Server connection. (Error code: 18452).

Pas plus tard que la semaine dernière, c’est arrivé lorsque je préparais un travail planifié de backup d’une collection de sites Sharepoint. Le compte de service qu’on m’avait fournit et que j’ai utilisé pour configurer le travail planifié ne possédait tout simplement pas les permissions requises pour effectuer l’opération.

Il faut savoir que pour effectuer la plupart des commandes STSADM, il faut posséder les permissions suivantes :

• Être administrateur local du serveur sur lequel on exécute la commande;
• Être administrateur de la ferme Sharepoint (farm administrator);

En plus, il faut aussi posséder les bonnes permissions dans SQL Server. En effet, puisque la commande STSADM s’exécute sous l’identité du compte avec lequel on la lance, il est requis que ce compte soit reconnu par SQL Server.

L’article  KB896148 présente deux méthodes pour attribuer les privilèges dans SQL Server :

1. Placer le compte membre du groupe Administrateur local du serveur SQL;
2. Donner au compte les rôle “Administrateur de la sécurité” et “Créateurs de bases de données” dans SQL Server et les rôles “public” et “db_owner” sur chaque banque SQL utilisées par Sharepoint.

Il va s’en dire que dans un organisme où les banques de données sont créées par l’administrateur SQL, seulement les rôles “public” et “db_owner” de chaque banque SQL utilisées par Sharepoint seront attribués au compte.

Pour en revenir à mon travail planifié, c’était justement les permissions dans SQL Server qui n’étaient pas adéquates.

J’espère ainsi vous éviter de précieuses minutes de recherche.