Intégrer les outils clients Office avec un extranet SharePoint est un besoin récurent qui trouve malheureusement peu de solutions. L’équipe SharePoint a récemment annoncé sur son blog une solution côté client qui ne pourra cependant pas satisfaire tout le monde.

Pour m’être intéressé à cette intégration à plusieurs reprises, j’ai souhaité présenter quelles étaient précisément les raisons de la limitation et comment les contourner. Et c’est au travers de mon article sorti ce matin sur TechHeadBrothers que vous trouverez tout ça.

A noter au passage : vous pourrez retrouver une solution similaire sur le projet CodePlex CKS. Bonne lecture !

Annoncé il y a deux jours sur le blog de l’équpe Groove, la prochaine version de Groove portera le nom de SharePoint Workspace 2010 !

Information qui dépasse le strict cadre du nom de produit, car bien qu’aucun détail précis ne soit communiqué il est vraisemblable que Groove prenne une dimension tout autre.

En effet, outil collaboratif décentralisé par excellence, Groove est annoncé comme étant client de la solution collaborative centralisée MS par excellence (à savoir SharePoint). Bref, une affaire à suivre de près pour la prochaine version !

Suite du post d’hier ou j’indiquais que l’installation du SP2 sur une VPC m’avait posé quelques soucis, j’ai poursuivi mes test et j’ai pu déceler d’autres logs que ceux référencés par l’assistant. Ces logs comportaient entres autres ces quelques lignes :

[SPManager] [ERROR] [4/29/2009 10:53:18 PM]: ReflexiveUpgrade [SPServer Name=office12-server Parent=SPFarm Name=SharePoint_Config] failed.
[SPManager] [ERROR] [4/29/2009 10:53:18 PM]: The system cannot find the path specified.

[SPManager] [ERROR] [4/29/2009 10:53:18 PM]:    at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   at Microsoft.SharePoint.Administration.SPIisApplicationPool.get_PeriodicRestartMemory()
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.EnableMemoryBasedAppPoolRecycling(SPIisApplicationPool local)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.EnableMemoryBasedAppPoolRecycling(String applicationPoolId)
   at Microsoft.SharePoint.Upgrade.EnableMemoryBasedAppPoolRecycling.Upgrade()
   at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()
[SPManager] [ERROR] [4/29/2009 10:53:18 PM]: Action 3.1.3.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed.
[SPManager] [ERROR] [4/29/2009 10:53:18 PM]:    at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)

Vous pourrez entres autres noter les erreurs "The System cannot find the path specified” et “Action 3.1.3.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed.”

Si SPIisWebSiteWssSequence ne me parle pas nécessairement, la classe SPIisWebSite correspond à ce que j’ai manipulé récemment et dont j’ai commencé à parler sur ce post : Gestion des Applications Web SharePoint et sites IIS : Best Practices. Bref, j’ai rapidement compris que l’erreur venait d’un problème au niveau de mon site IIS . L’erreur "The System cannot find the path specified” n’indique pas la véritable erreur, puisque le chemin IIS existe bien. Il n’empêche, la VPC sur laquelle j’ai tenté la migration était celle que j’avais utilisé aux TechDays, et pour laquelle j’avais fais quelques modifications en dur (comme pour les entêtes d’hote par exemple).

Bref, je n’ai pas respecté mes propres recommandations (sur une VPC de démo, hum, y’a pas mort d’homme non plus)…

J’ai finalement supprimé les sites IIS concernés avant de les “re-provisonner” proprement : au final, la mise à jour MOSS SP2 + Language Pack s’est bien passée :-)

J’enfonce donc encore un peu le clou  pour souligner l’importance de modifier les paramètres SharePoint depuis l’API et non depuis les éléments autour.

Je viens tout juste de tenter une installation du SP2 de SharePoint fraîchement sorti. Vous trouverez les liens pour télécharger les Office Server Service Packs sur le blog de David.

Préalablement à l’installation de ces Service Packs, il vous faudra installer ceux de Windows SharePoint Services :

• Les SP2 WSS : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=79bada82-c13f-44c1-bdc1-d0447337051b 
• Le Language Pack SP2 x86 : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=085e5ac8-58f6-4cf9-8012-33b95ee36c0f
• Le Language Pack SP2 x64 : http://www.microsoft.com/downloads/details.aspx?FamilyId=2C2B6CAF-B46D-45EB-AC4D-DEAAA48C3A2C

Vous retrouverez une également une version SlipStream de WSS :

• La version d’installation x86 avec le SP2 : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=ef93e453-75f1-45df-8c6f-4565e8549c2a
• La version d’installation x64 avec le SP2 : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=2c2b6caf-b46d-45eb-ac4d-deaaa48c3a2c

Mais avant toute chose, pensez à sauvegarder vos données. Ce n’est pas une recommandation spécifique : c’est à faire systématiquement avant une mise à jour. Je vous recommande également de (re)lire la page du Technet Deploy software updates for Windows SharePoint Services 3.0 avant de précéder à la mise à jour.

Enfin, notez pour l’avenir qu’il est de bon ton de garder une version d’installation SP2+ Ready avec vous en réutilisant l’astuce que j’avais relayé sur la création de version SlipStream. SP2+ car cette astuce vous permettra d’incorporez les éventuelles KB intermédiaires. Personnellement, je m’en sers chez mes clients de façon à garder une version slipstream en phase avec ce qu’ils ont en production.

Ma VM n’ayant pas aimé la mise à jour, je vous ferai un retour sur l’installation un peu plus tard.

Une des choses que j’aime avec SharePoint, c’est de voir que la frontière exploitation/développeurs est souvent moins marquée qu’ailleurs.

Moins marquée parce que SharePoint fait appel à tellement de systèmes différents qu’un développeur ne pourra pas s’en sortir bien longtemps sans s’intéresser à des problématiques un peu plus connotée infrastructure/système/réseau qu’à son habitude.

Moins marquée également car les admins se mettent à s’intéresser au monde du développement. Et j’insiste sur ce point, car je l’ai vu plusieurs fois : les admins veillent de plus en plus souvent aux fuites mémoire et sont aussi souvent conscient que des Best Practices de développement (l’appel au Dispose) peuvent les réduire considérablement. Mieux que ça : j’en ai vu se mettre à coder, dans Visual Studio (chose plutôt rare), ou via PowerShell  (chose déjà bien plus courante).

Bref, la frontière se réduit par endroit et c’est une très bonne chose. Il n’empêche… certaines vielles habitudes persistent de chaque côté et impliquent des difficultés d’administration et/ou des dysfonctionnement dont je viens parler ici.

Problèmes concrets :

La souplesse de SharePoint fait qu’une batterie de serveurs peut s’élargir facilement, pour mieux tenir la charge par exemple, ou encore pour assurer une continuité de service. Lorsqu’un nouveau serveur est ajouté à la batterie de serveurs, SharePoint réalise automatiquement un certain nombre d’opérations sur le nouveau serveur :

• Création des applications pools
• Création des sites IIS
• Déploiement des fichiers de solution contenus dans le magasin de solutions SharePoint (fichiers dans le répertoire 12, déploiement dans le GAC/BIN, …)
• Mise à jour des fichiers web.config en fonction des modifications gérées par SharePoint (SafeControls, SPWebConfigModification, …)

Bref, en théorie un site est opérationnel dès que le serveur est rattaché à la batterie de serveurs. En pratique, ce mécanisme est très souvent insuffisant car les développeurs et/ou les administrateurs ont introduit des changements à faire manuellement : le mécanisme automatique de SharePoint ne les réalise donc pas… et c’est le drame !

Quelques exemples de problèmes vécus :

• Ajout manuel de paramètres dans le fichier web.config :

Les développeurs ont ajouté manuellement des paramètres dans le fichier web.config. Une ConnectionString par exemple, ou encore n'importe quel paramètre, référence à une ressource externe, etc. Lorsque l’utilisateur se connecte à l’Application Web SharePoint, le mécanisme de load balancing détermine quel serveur traite la demande. Dans certain cas le serveur qui répondra aura les bons paramètres… de temps en temps ce sera le serveur à qui il manque des paramètres. Dans le dernier cas, les utilisateurs ont de forte chance de tomber sur une page d’erreur.

• Déploiement manuel de WebParts / Features / Ressources.

Les développeurs ont déployés les WebParts, Features et/ou ressources en les copiant manuellement dans le répertoire 12 puis en utilisant la commande stsadm –o installfeature. Le nouveau serveur sera dépourvu de ces éléments et tout utilisateur dirigé vers ce serveur sera confronté à une page d’erreur SharePoint.

• Modification du port ou changement de host header directement depuis IIS

Qui n’a jamais voulu changer le port ou les host headers après la création d’une application Web SharePoint (pour un changement de DNS par exemple) ? Ces paramètres sont bien connus des admins qui savent les modifier depuis IIS. Lorsque cette opération est réalisée via IIS, elle reste locale. En d’autres termes, SharePoint créé automatiquement les sites IIS sur le nouveau serveur mais les modifications réalisées manuellement sur les autres serveurs ne sont pas propagées. Les utilisateurs peuvent alors tomber sur d’autres sites que ceux demandés ou sur des erreurs 404.

• Paramétrage des pools d’applications

Assez similaire aux sites IIS. Vous pouvez souhaiter les paramétrer pour prendre en compte des modifications sur les comptes de service. Dans ce cas spécifique SharePoint ne vous laissera pas faire… en tout cas pas longtemps. En effet, SharePoint changera automatiquement le compte associé au pool d’application pour lui fixer sa propre valeur. Pour les autres paramètres du pool d’application, toute modification sur IIS reste locale.

Comment éviter ces problèmes / Les Best Practices :

Le fichier Web.Config

Les développeurs ASP.Net ont l’habitude de modifier manuellement le fichier web.config d’une application web pour y ajouter des paramètres. Avec SharePoint il faut cependant privilégier un autre moyen : la classe SPWebConfigModification. J’ai cependant souvenir de propos négatifs concernant cette classe, tels que '”tout le monde sait qu’il ne faut pas l’utiliser”. Et bien pourtant si ! Les détracteurs lui reprochent de compromettre le fichier web.config. Je répond que NON. Ces personnes ont tout simplement rencontré des problèmes avec des fichiers web.config qu’elles avaient modifiés manuellement et qu’elles voulaient modifier, en plus, via la classe SPWebConfigModification. Les problèmes potentiels ne sont à imputer qu’aux modifications manuelles et pas à la classe SPWebConfigModification. Bref, passer par cette classe pour modifier le fichier web.config est un Best Practice. A chaque fois qu’un développeur fait le choix d’une modification manuelle, il induit une difficulté supplémentaire pour les admins (en cas d’ajout ou de restauration d’un serveur SharePoint) et pour les prochains développeurs (qui ne pourront plus utiliser cette classe sans avoir de problème).

Déploiement de WebParts / Features / Ressources.

Les copier/coller sont à proscrire. Utilisez des solutions SharePoint. SharePoint stocke alors vos solutions dans le magasin de solutions et sait quelles sont les opérations à rejouer pour les déployer sur de nouveaux serveurs. En outre, ce procédé évite de toucher aux éléments natifs de SharePoint (je l’ai encore vu récemment).

Modification des paramètres IIS

Ce point est un peu plus délicat. En effet, l’interface d’administration SharePoint n’offre pas la possibilité de modifier ces paramètres sans détruire puis recréer l’application Web à partir d’une base de données existante. Ce mécanisme est (trop) lourd et peu envisageable. Il existe cependant une alternative, discrète : modifier les paramètres IIS depuis le modèle objet SharePoint à l’aide de la classe SPIisSettings. Un petit exemple avec du code ajoutant un host header au site IIS :

System.Uri uri = new Uri("http://localhost");
SPWebApplication webApplication = SPWebApplication.Lookup(uri);
SPIisSettings settings = webApplication.IisSettings[SPUrlZone.Default];

SPServerBinding binding = new SPServerBinding();
binding.Port = 80;
binding.HostHeader = "gribs.virtualdomain.com";
settings.ServerBindings.Add(binding);

webApplication.IisSettings[SPUrlZone.Default] = settings;

webApplication.Update();
webApplication.Unprovision();
webApplication.Provision();

Les paramètres IIS modifiables sont nombreux. Autre exemple : inutile de modifier le fichier metabase.xml à la main pour passer en Kerberos, un simple settings.DisableKerberos = false; suffit. Idem pour modifier le répertoire du site IIS : le recours à settings.Path règle le problème.

Bref, il reste à passer ce type de code en PowerShell pour ce que soit exploitable plus facilement par des admins (hum… Fabrice ? :-))

Modification de l’Application Pool

Très similaire à IIS avec la classe SPApplicationPool.

Conclusions :

Ces Best Practices se résument facilement : il FAUT passer par les mécanismes natifs SharePoint pour toute modification impactant les déploiements. Je regrette qu'il soit cependant parfois si complexe de les mettre en pratique : pour le SPWebConfigModification, par exemple, dès lors que d’autres développeurs ont fait le choix des modifications manuelles. Pour les modifications IIS également, car il n’y a pas d’interface (ça ne sautait tarder… je suis en train d’en faire une :-)).

Il n’empêche : faire l’impasse sur ces recommandations impliquera nécessairement une difficulté d’exploitation plus importante.

Quelques nouveauté en vrac pour ce mois ci (ou presque) :

VseWSS 1.3

- La CTP de mars pour les extensions Visual Studio pour WSS 1.3 est disponible et téléchargeable ici.

Vous y retrouverez quelques améliorations par rapport à la version 1.2, dont le support du 64 bits.

J'ai lu ça sur le blog de Paul Andrew... mais ce que j'y ait décelé d'interessant surtout, c'est ce lien : SharePoint tools support in Visual Studio.

Bref, ce qui semble être un apperçu de Visual Studio 10 et de la vue d'une feature de WorkFlow !

AKS 2.0

L'Accessibility Kit for SharePoint nous arrive en version 2. Pour rappel, ce Kit a pour but d'aider à réaliser des sites respectant les WCAG 2.0 AA, c'est à dire plus accessibles. L'utilisation d'un tel kit ne rend pas pour autant les choses toutes roses, mais le principal frein à son utilisation pour nous, francophones, c'était le fait qu'il ne supportait pas notre chère langue. C'est maintenant chose faite avec la version 2.

Disponible sous licence MS-PL, il est téléchargeable sur le site d'HiSoftware. A noter qu'HiSoftware en a profité pour sortir de nouveaux composants riches pour MOSS 2007.

Cumulative Updates de février

Vous commencez certainement à connaître ces updates. Les derniers en date sont ceux de février et sont disponbiles sur le site du support Microsoft :

• pour WSS : http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961755
• pour MOSS : http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961756

Rappelez vous que vous ne devez les considérer que s'ils répondent à des problèmes que vous rencontrez.

Vous trouverez un rappel sur la manière de les appliquer sur le blog de Share Young.

Sachez enfin que je n'ai toujours pas de date pour le SP2 de SharePoint, mais bon... je mise sur le fait qu'il ne devrait pas trop tarder .

@#

Mon tout premier Summit s'achêve et déjà je regrette qu'il ait été aussi cours tellement il fut intéressant. Et ce à plusieurs niveaux.

Pour moi, c'était mon premier voyage hors d'Europe. Ca peut paraître banal pour pas mal de personnes, mais pour moi prendre l'avion plus de deux heures était une grande première (Air France, c'est pas mal du tout :-)). Voir les grandes avenues américaines, les voitures d'une autre dimension (au sens litteral, hein...), la douane aussi... Bref, j'étais vraiment impressionné par tout ça.

Le Summit : comment ça se passe ?

Côté journées, le summit fut essentiellement rythmé par les sessions :

• 7h30 : petit déjeuner
• 8h00 : départ pour le campus Microsoft
• 17h00 / 18h00 : retour à l'hotel
• 19h00 : soirée MS ou entre MVPs.

Pour ceux qui ne connaissent pas le Campus Microsoft... en quelques mots... c'est gigantesque :-) Jugez en par vous même avec Virtual Earth.

Et pour ce qui est du dialogue sur place, il fut évidemment essentiellement en anglais... ce qui s'est avéré moins évident que je ne le pensais. Mais ce qui fut rassurant pour moi, c'est que je me sentais nettement plus à l'aise au bout de trois jours (le simple fait de se poser moins de questions).

La communauté MVP

Viens ensuite ce que j'ai pu voir sur place. Un nombre très important de MVP de tous horizons. Peut être 1500, pas mal de technologies différentes du coup. Des RD aussi. Bref, un nombre impressionnant de personnes passionnées, dont énormément se connaissant déjà selon les communautés. Ca a été l'occasion de voir Steve Balmer également. L'effet dans la salle était vraiment saisissant ! Enfin et surtout (pour moi), ce fut l'occasion de rencontrer des "légendes" de la communauté SharePoint... genre Andrew Connell, Bob Fox, Ted Pattison, et tout plein d'autres géants.

Côté technique

En ce qui concerne le contenu des sessions, je ne peux évidemment pas vous en parler. Je peux en revanche vous dire que je n'ai suivi que des sessions concernant SharePoint, et que je devais systématiquement faire un choix car plusieurs se tenaient simultanément. Un rapide retour néanmoins : j'aime travailler avec SharePoint, et ce que j'ai vu m'aide à vous dire que ce n'est pas prêt de s'arrêter !

Et si vous insistez pour avoir des infos... non, je ne peux raisonnablement pas vous en donner :-) ... mais je me permet de relayer quelques infos officielles reprises du blog d'Arpan Shah :

• Visual Studio 2010 supportera les développements SharePoint “14”.
• SharePoint “14” sera uniquement 64 bits.
• La SharePoint Conference 2009 sera LA conférence ou vous devriez commencer à découvrir SharePoint “14”.
• Le SP2 de SharePoint 2007 approche. Aucune date précise, mais les rumeurs parlent de fin avril.

Le fun !

PaintBall

Pour nous, SharePointeurs, le Summit est également synonyme de PaintBall... énorme moment !

• Phil & moi... équipe de choc
• Ben Robb, Bob Fox et Andrew Connell (de gauche à droite)
• Le SpeedBall à 20, ça rocks !

Fléchettes

Et pour quelques francophones cette année, certaines soirées auront eu une certaine connotation "fléchette" (cf le post de Renaud)

En quelques mots, voilà ce qu'il y a sur les photos :

• Gaëtan ne tire pas toujours SUR la cible...
• Le GameWorks, des jeux de partout, juste en face du Sheraton Hotel.
• Quand Phil n'est pas précis, il m'en met quand même plein la tête.
• Le chiffre favori de Fabrice N'EST PAS le 18 :-).
• Renaud dit qu'il ne sait pas viser, mais il ment !
• Là, c'est moi. :-)
• Bien qu'ayant participé à quelques parties, Pierre est un couche tôt (la preuve, il n'est même pas sur les photos).

Remerciements

Cet événement était vraiment superbe ! Et j'y ai participé grace à plusieurs personnes / entités que je souhaite vraiment remercier :

• Microsoft, pour la fabueluse opportunité, l'événement en lui même et une bonne partie de la logistique
• Martine Thiphaine, MVP Lead France, pour l'organisation, les infos, les visites...
• Winwise qui m'a libéré du temps et qui a financé le voyage à Seattle.

Merci !

Nombreux sont les développeurs qui sont passés à SharePoint récemment. Beaucoup de projets, encore trop peu de développeurs SharePoint... et bien souvent les mêmes questions : "Par où commencer le développement SharePoint ?". "De quoi ais-je besoin pour développer pour SharePoint ?". Et finalement, "Qu'est ce qu'on peut faire avec SharePoint ?". Et le nombre de personnes qui se posent ces questions ne désempli pas, bien au contraire.

Si vous êtes dans ce cas, ou si vous êtes simplement sceptique quand on vous parle des technologies SharePoint, venez me voir à la session Introduction au développement SharePoint et cas pratiques des TechDays 2009. J'ai en effet l'honneur de co-animer cette session avec Master Bouveret (aka Gat) mardi, de 13h à 14h.

Voici le résumé de cette session niveau 100 :

Cette session commencera par vous présenter les bases du développement pour la plateforme SharePoint (WebParts, workflows, événements, …) ainsi que les bonnes pratiques de déploiement. Nous aborderons ensuite leur mise en application au travers de plusieurs projets communautaires innovants et largement utilisés (Podcasting Kit for SharePoint, Community Kit for SharePoint, Blueprint for SharePoint, WSPBuilder, ...)

@tout à l'heure !

Les TechDays 2009 approchent à grand pas. Ce sera l'occasion de voir et d'apprendre pas mal de choses au travers des 300 sessions et ateliers. L'occasion, aussi, de voir et de discuter avec des experts hors session sur les stands partenaires par exemple, mais aussi sur les stands Microsoft.

Si vous ne vous êtes pas déjà enregistré pour participer à cet événement gratuit, je vous invite à vous connecter au site des TechDays 2009.

Les SharePointers connaissent probablement déjà le projet Codeplex "Features" référençant de nombreuses Features SharePoint orientées Développeurs, Administrateurs et même utilisateurs. Scot Hillier a récemment mis à jour ce projet pour référencer de nouvelles Features, dont une des miennes : "Site Creation in Target Database ".

Que fait cette Feature ?

Comme son nom l'indique, cette Feature permet de choisir la base de données dans laquelle créer une nouvelle collection de sites SharePoint.

Pourquoi une telle Feature ?

Par défaut, SharePoint ajouter associe automatiquement la collection de sites créée à la base de données disponible contenant le moins de collections de site. Ce mécanisme, mêlé à celui des quotas de collections de sites, permet habituellement de contrôler la taille des bases de données lorsque le process de création de sites est industrialisé, comme lorsque le "site creation self service" est activé par exemple.

Il arrive cependant que l'on souhaite garder la maîtrise des bases de données associées aux sites SharePoint. La première demande qui m'a été faite dans ce sens visait à séparer les sites SharePoint dans un contexte multi-sites physiques (le client disposait d'antennes distantes les unes des autres et souhaitait se réserver la possibilité d'intervenir sur les bases SharePoint d'une de ses antennes sans pour autant impacter les autres). Réunir les collections de sites dans une base de données spécifique en fonction de critères métiers peut également faciliter la séparation des sites SharePoint en plusieurs Applications Web voire en plusieurs fermes SharePoint.

Bref, la seule réponse à ce besoin reposait jusqu'à présent sur l'intervention préalable d'administrateurs pour modifier les quotas de collections de sites avant la création d'une nouvelle collection.

Comment se présente cette Feature ?

Le déploiement de la Feature ajoute une Custom Action sur la console d'administration centrale "Create  site collection (with db selection)" dans la rubrique "SharePoint Site Management".

Ce lien permet d'accéder à une page d'administration similaire à la page de création de collection de sites standard, à la différence prêt qu'elle comporte une liste déroulante permettant de sélectionner la base de données de contenu.

Une Feature multilingue

Cette Feature est intégralement multilingue. Aujourd'hui, seules deux langues sont gérées, à savoir l'anglais et le français.

Comment fonctionne cette Feature ?

Cette Feature modifie le statut des bases de données pour les passer automatiquement "Offline" ou "Online" selon la sélection qui est faite, de sorte qu'une seule base de données ne puisse être choisie par SharePoint.

Quelles sont les conséquences de ce mode de fonctionnement ? Et bien tout simplement la non prise en compte des actions réalisées simultanément par un autre biais (écran de création standard, stsadm, création de collection de sites self service via un annuaire des sites, ...).  Bref, cette Feature n'est pas nécessairement compatible avec le plan de gouvernance en place sur votre plateforme SharePoint, notamment si vous avez activé la création de collections de sites en mode self service. Veuillez donc à vous assurer de ne pas être dans les cas précités avant d'utiliser cette Feature.

Où télécharger cette feature ?

A tout hasard, si vous l'avez raté : http://www.codeplex.com/features

Si l'indexation des fichiers PDF sur une plateforme SharePoint 64 bits ne pose plus de problème depuis le iFilter proposé par FoxIt, il existe désormais une autre solution proposée directement par Adobe.

L'installeur est téléchargeable ici : http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025

Il est surtout interessant de noter qu'un document d'installation est disponible et qu'il indique les modifications à réaliser dans la base de registres ainsi que les redémarrages de services nécessaires.

Le document en question est disponible ici : Configuring PDF iFilter for MS Sharepoint 2007.pdf

Cette information provient du site FromTheField.

Lorsque je donne des formations sur la partie BI de SharePoint, je fais généralement un tour sur le site rapports standard du modèle portail collaboratif MOSS Entreprise. Et la dernière fois que j'ai donné cette formation, j'ai eu le droit à ce beau message d'erreur durant ma démo... pas glop !

Heureusement, seul le poste du formateur était affecté et je n'ai pas été bloqué... il n'empêche, c'est moi le formateur, et sans y passer la journée pour autant j'ai essayé de comprendre l'erreur ce jour là, mais en vain.

Le temps passe et me viens à l'idée de mettre à jour la VPC utilisée pour la formation. Je teste le site "Rapports"... aucun problème. Je lance un windows update sans faire de détail. Je teste le site "Rapports"... et blam, le message d'erreur ci dessus fais son retour. C'est louche !

Je commence l'analyse du message d'erreur. Comme on le voit ci dessus, il me faut passer en mode SQLServer ou StateServer et je suis... déjà en mode SQLServer. Ca s'annonce bien. Quelques recherches sur Internet indiquent un lien avec Reporting Services 2005. Ca m'étonne un peu, car le site "rapports" n'exploite pas Reporting Services... mais soit, je modifie le fichier web.config de reporting services pour passer le mode d' "InProc" à "SQLServer". Je teste à nouveau... et j'obtiens une erreur 404 indiquant que la page ou une de ses dépendances est manquante. Habitué à ce genre d'erreurs, je décide de me connecter au site à l'aide de SharePoint Designer histoire de voir si j'obtiens le même message d'erreur... et non, encore un autre !

Message étrange, puisque le SP1 de SharePoint Designer a été appliqué. Ma version est donc up-to-date, et fonctionne d'ailleurs très bien avec tous les autres sites que le site "Rapports".

Je tente alors une connexion à Reporting Services via le Management Studio... et voilà ce que j'obtiens :

Hum hum... quelques recherches plus tard, je pars à la recherche du WebServiceAccount nommé dans ce message... pour constater qu'il référence le compte "Network Services"... ce qui semble tout à fait normal.

Bref, j'en pers même le latin que je n'ai jamais appris ! Le temps d'en parler à un collègue qui connaît bien mieux RS que moi, de parcourir la configuration RS... de lui expliquer que mon site "Rapports" est à l'URL reports et que ce n'est pas le site reporting services mais bien mon site SharePoint... pour finalement passer sur la console IIS et comprendre que le problème est... que l'application "Reports" de reporting services est présente dans mon site SharePoint ! L'URL /reports est utilisée par mon site SharePoint ET par reporting services. Comment est-ce possible ?

Lors de l'installation, j'ai modifié le port du site et des web services reporting services pour utiliser le 90 plutôt que le 80, et j'ai gardé le 80 pour mon application web SharePoint. Et tout fonctionnait très bien jusqu'à cette mise à jour Reporting Services via Windows Update. La mise à jour à réinscrit des composant RS sur le port 80 (au lieu de rester sur le port déjà utilisé). Du coup, l'appel au sous site /Reports de mon portail SharePoint conduisait tout droit sur Reporting Services au lieu du site SharePoint prévu, le tout avec un mauvais fichier de config... Bref, j'ai résolu le problème en déplaçant les applications liées à RS sur le port 90.

Ce n'est pas une légende... laissez le "site web par défaut" tranquille... désactivez le si besoin, mais ne le modifiez pas. Pour vos autres sites, ne faites pas comme pour cette VPC, utilisez les host headers !

Le souhait de mettre en place des stratégies de gouvernance,  évoqué par certains de mes clients, et notamment sur les créations de site, m'a conduit à travailler sur les modèles de site et plus particulièrement sur leur disponibilité. Cela m'a donné une idée : présenter quels moyens permettant de filtrer les Site Templates utilisables SharePoint met à disposition. Une problématique qui trouve plusieurs réponses présentant toutes des avantages différents.

Je vous propose donc de découvrir les moyens de filtrage existant en lisant mon article sur ASP-PHP :

• Filtrer l'affichage des modèles de site dans SharePoint 2007

J'en profite pour remercier Fabrice qui m'a aidé à mettre en ligne ma première publication sur ce site.

Bonne lecture ;-)

Vous en avez peut être déjà entendu parler, la date de la Winwise Solution Conference approche à grand pas. Pour ceux qui seraient passé entre les annonces, elle se tiendra le 10 septembre 2008 au Centre de Conférences Microsoft, 148, rue de l’université dans le 7 ème arrondissement de Paris. Je vous rappelle que cet événement est ouvert à tous et entièrement gratuit.

Au programme, un keynote et 15 sessions techniques articulées autour des dernières technologies Microsoft.

Pour ma part, je co-animerai avec Pascal Laforest une session intitulée Utilisation de MOSS comme portail décisionnel. Plutôt orientée fonctionnel, cette session vous permettra de voir ce qu'il est possible de faire avec 3 aspects technologiques Microsoft récents. Pourquoi 3 ? Et bien SharePoint d'une part, toute la partie BI (Analysis Services, Reporting Services, Performance Point...) d'autre part, et... une surprise pour le troisième aspect :-) Que vous soyez à l'aise ou non avec le domaine de la BI, que vous connaissiez SharePoint de prêt, de loin, voire pas du tout, cette session vous permettra de voir ce qu'il est possible de créer en mêlant les dernières technologies Microsoft.

Je vous donne donc rendez vous le 10 septembre prochain de 10h30 à 11h30, au Centre de Conférences Microsoft. N'oubliez pas de vous inscrire au préalable sur le site de la conférence.

Le projet CodePlex SharePointOfView propose un framework pour les développeurs SharePoint. Entres autres, des classes de base pour les WebParts. Vous retrouverez la WebPartBase, déjà présentée précédemment, mais également une WebPart de transformation XSL nommée tout naturellement XSLTransformWebPart.

Pourquoi une WebPart de transformation XSL ?

Depuis SharePoint 2003 (et sur les conseils de Gat), j'utilise de très souvent la transformation XSL dans mes WebParts. Dans la version 2007, on en retrouve d'ailleurs un peu partout. La transformation XSL présente de nombreux avantages dans SharePoint :

D'une part, le XSL en lui même peut être stocké de plusieurs façons différentes :

• Directement en paramètre de la WebPart,
• Sous forme de fichier externe,
• Sous forme de fichier dans une bibliothèque SharePoint (auquel cas on bénéficie même de versionning sur le XSL).

D'autre part, les modifications demandées par le client qui veut toujours une petite adaptation après la mise en prod deviennent bien plus simples, puisqu'il suffit juste de modifier un paramètre ou un fichier. Pas d'interruption de service non plus, puisque le code ne change pas.

D'autre part, le rendu XSL peut être travaillé par une autre personne que le ou les développeurs SharePoint. Lorsque l'équipe qui travaille sur un projet commence à être de bonne taille (qui a dit plus d'une personne ?), cette possibilité de découpage peut s'avérer très utile.

XslTransformWebPart ("...and in the darkness bind them.")

La WebPart de transformation XSL permet donc de séparer le fond de la forme. Le mécanisme gérant la forme étant identique d'une WebPart à l'autre, autant le centraliser dans une seule et même WebPart. Les différences d'affichage se font en modifiant la valeur de la propriété XSL.

Côté fond, il vous suffira d'hériter de la WebPart XSLTransformWebPart puis de surcharger la méthode GetData() pour reccupérer vos données sous forme XML.

L'appel à la méthode GetData ainsi que la transformation XSL est faite depuis la méthode OnPreRender de la WebPart. L'affichage se fait quand à lui avec la méthode RenderWebPart issue de la WebPartBase, évidemment. Ce qui implique du même coup la gestion d'erreur dans la WebPart de transformation XSL. Enfin, cette WebPart est entièrement localisée, aussi bien en ce qui concerne les messages que la WebPart peut elle même afficher, qu'en ce qui concerne les propriétés de l'EditorPart. A ce jour, les ressources gérées sont l'anglais et le français.

CAMLQueryWebPart : Sample de transformation XSL

Pour illuster cette WebPart, le projet SharePointOfView.Samples met à disposition une WebPart de requête CAML héritant de la classe XSLTransformWebPart. Cette WebPart de requête CAML se contente de réaliser la requête dans la méthode GetData() d'une manière similaire au code présenté ci dessous :

protected override string GetData()
{
    SPQuery camlQuery= new SPQuery();
    camlQuery.Query = ""; // requête CAML attendue
    SPList list = SPContext.Current.Web.GetListFromUrl(ListURL);
    return list.GetItems(camlQuery).Xml;
}

Vous pourrez donc utiliser ce sample pour tester la WebPart XslTransformWebPart.

Le tout en images

Comme pour la WebPart précédente, j'ai réalisé une vidéo présentant les points essentiels de la WebPart. Je vous invite à consulter ces quelques minutes de présentation :

N'oubliez pas que le projet SharePointOfView reste ouvert à ceux qui souhaitent contribuer au projet.

Sur le papier, le déploiement de contenu de SharePoint a de quoi séduire. Malheuresement, nombreux sont ceux qui se sont heurtés à des difficultés avec le Job d'import SharePoint pendant ces déploiements. Si vous n'avez pas eu l'occasion de tester le déploiement de contenu, peut être avez vous bloqué sur la commande stsadm -o import avec des messages de même nature, du type Violation of PRIMARY KEY constraint, ou encore d'autres erreurs.

Les posts recensant les problèmes et les pièges à éviter, comme celui de Stefan Goßner, sont nombreux.

Ces problèmes ont désormais une solution Microsoft, puisqu'un KB a été récémment publié.

Je viens seulement d'en prendre connaissance grâce au blog de Joel Oleson, car ce correctif date du 20 mai.

Vour retrouverez sur le site du support Microsoft :

• La KB détaillant le rollup.
• Le formulaire de demande de hotfix.

Bref, du très très bon pour les sites nécessitant un déploiement de contenu.

PS :Si vous ne connaissez pas le Content Deployment dans SharePoint, je vous invite à consulter la partie Staging de la présentation Gestion de contenu Web que j'ai co-animé avec Gaëtan lors des TechDays 2008

Le framework SharePointOfView que Phil a récemment annoncé comporte un namespace nommé SharePointOfView.WebControls. Au menu de ce namespace, des customs controls, évidemment, et pour commencer deux WebParts.

Pourquoi des customs controls ?

Aux cours de vos développements SharePoint, combien de bouts de code avez vous copié/collé d'un contrôle existant vers un nouveau contrôle ? Combien de Try...Catch pour éviter qu'une erreur provoque un dysfonctionnement complet des pages ? Personnellement, je l'ai fait bien trop souvent. J'ai fini par me faire une WebPart de base dont mes nouvelles webparts héritent, histoire d'y insérer le code que je réutilise le plus souvent. Ont suivi d'autres WebParts que j'ajoutais à mes projets Visual Studio au fil des besoins. C'est donc très naturellement que j'ai souhaité les ajouter au framework SharePointOfView. L'idée est donc de proposer des bases de WebParts riches et génériques.

A ce jour, déjà deux WebParts ont déjà été intégrées au framework, et voici la première d'entres elles :

WebPartBase ("One WebPart to rule them all...")

L'idée de cette WebPart, c'est (essentiellement pour le moment) de permettre aux développeurs de s'affranchir de la gestion d'erreur dans leurs développements, et de la centraliser.

Trois comportements sont incorporés à cette WebPart :

• Comportement simple :

En cas d'erreur, la WebPart indique simplement qu'une erreur s'est produite. L'affichage de la page n'est pas bloqué. Au delà de l'affichage, la WebPart inscrit la StackTrace dans les fichiers de log SharePoint (à l'aide de la classe d'écriture de logs du framework SharePointOfView)

• Comportement étendu :

En plus du comportement simple, cette gestion ajoute un lien qui permet de visualiser la StackTrace. Je réfléchis à y indiquer également l'heure de l'erreur. Cette gestion n'est faite que lorsque l'utilisateur courant est administrateur de la collection de sites. On peux facilement imaginer l'utilisation qui pourrait être faite de ce fonctionnement : le responsable fonctionnel / chef de projet (administrateur de la collection de sites ici) est rapidement averti qu'une erreur se produit, réalise une simple capture d'écran et l'envoi aussitôt au(x) développeur(s).

Démonstration :

Parce qu'une petite démo vaut mieux qu'un long discours, je vous propose de regarder tout ça en images :

Fonctionnement

La WebPartBase est marquée comme abstract, et réécrit les méthodes de rendu habituelles pour y incorporer cette gestion d'erreur.

/// <summary>Base method that renders the web part.</summary>
/// <param name="writer">the output stream Html writer</param>
protected sealed override void RenderContents(HtmlTextWriter writer)
{
    try
    {
        base.EnsureChildControls();
        base.RenderContents(writer);
        RenderWebPart(writer);
    }
    catch(Exception ex)
    {
        // Rendering a simple error message instead of the WebPart and logging the real exception
        ManageError(ex).RenderControl(writer);
        SharePointOfView.Diagnostics.ULS.WriteError(ex.ToString(), "WebPartBase : RenderContents");
    }
}

Les méthodes réécrites sont marquées comme sealed de sorte à empêcher toute réécriture de ces méthodes par la suite, et donc la perte de la gestion d'erreur. Il vous faudra donc utiliser l'une des deux méthodes marquées virtual en lieu et place des traditionnelles RenderContents et CreateChildControls :

/// <summary>
/// Virtual method that replace RenderContents method, so as to ensure error handling.
/// If a failure occurs, a standard message will be shown to the users, and the error will be logged.
/// Besides, the exact exception stack trace will be displayed to the sites collection administrators.
/// </summary>
/// <param name="writer">the output stream Html writer</param>
protected virtual void RenderWebPart(HtmlTextWriter writer)
{

}

/// <summary>
/// Virtual method that replace CreateChildControls method, so as to ensure error handling.
/// If a failure occurs, a standard message will be shown to the users, and the error will be logged.
/// Besides, the exact exception stack trace will be displayed to the sites collection administrators.
/// </summary>
protected virtual void CreateWebPartControls()
{

}

Cette WebPart devrait évoluer pour localiser le message d'erreur standard. N'hésitez pas à laisser un commentaire si vous avez des remarques ou des suggestions sur cette WebPart.

Pour conclure, je vous rappelle que le projet SharePointOfView est disponible sur codeplex.

Aux cours de mes interventions chez les clients, je fréquemment rencontré des installations de SharePoint par défaut (pour WSS surtout, et dans une moindre mesure MOSS). L'interface d'installation de SharePoint est certes simple et conviviale, mais elle ne propose pas toutes les options d'installation. C'est après avoir eu plusieurs retours liés à des problèmes d'installation (en clientèle, en formation et sur le forum MSDN) que j'ai compris l'importance de communiquer sur les options d'installation avancées. Quel intérêt concrètement ? Quelques exemples :

• Voir qu'il n'est pas nécessaire de réinstaller SharePoint lorsque le rôle défini pour le serveur n'est pas le bon, ou que des features sont manquantes
• Voir qu'il n'est pas nécessaire de réinstaller SharePoint lorsque la console d'administration centrale ne fonctionne plus,
• Voir qu'il est possible de créer la base de configuration sur un serveur SQL accessible via authentification SQL,
• Automatiser l'installation,
• ...

La commande PSConfig

Tout comme stsadm.exe, PSConfig.exe est situé dans le répertoire 12\BIN.

Le détail complet de la commande PSConfig est bien sûr disponible sur le Technet.

Quel intérêt pour cette commande ?

• Création de la base de données de configuration à l'aide d'une authentification SQL

L'écran de connexion à la base de données de configuration de l'assistant ne propose que 4 paramètres. En comparaison, l'opération de connexion à la base de données de configuration via PSConfig permet d'en gérer 9 (si on omet les options permettant la création, la connexion ou la déconnexion à la base de données de configuration, qui sont également implicitement gérés par l'assistant)

PSCONFIG.EXE -cmd configdb [-create] [-disconnect] [-connect] [-server <SqlServerName>] [-database <SqlDatabaseName>] [-dbuser <value>] [-dbpassword <value>] [-user <Domain\User>] [-password <Password>] [-addomain <value>] [-adorgunit <value>] [-admincontentdatabase <SqlAdminContentDatabaseName>]

Notez au passage les paramètres dbuser et dbpassword qui vous permettront de spécifier un compte SQL et non un compte de domaine comme c'est nécessairement le cas via l'assistant de configuration. Egalement, notez le paramètre admincontentdatabase : celui ci permet de nommer la base de données du site d'administration de SharePoint. Personnellement, lassé d'avoir plusieurs bases nommées AdminContent_<GUID> sur mes serveurs SQL, j'opte pour l'installation en ligne de commande ne serait ce que pour cette raison.

Au final la commande donnera donc ceci :

• Changement de licence de MOSS Standard vers MOSS Entreprise

Outre la clé de licence à changer, il vous sera nécessaire d'installer les features liées à la version entreprise. L'instalaltion de ces features peut se faire via la commande PSConfig -cmd installfeatures qui enregistre l'intégralité des features disponibles sur le serveur ou est exécuté la commande (équivalent à installfeature sur l'ensemble des features non installées).

• Activation des services d'indexation et de recherche

La commande PSConfig -cmd services vous permet d'ajouter la prise en compte de ces services au serveur sur lequel est exécuté la commande (activation et démarrage).

• Création de la console d'admin centrale

En cas d'anomalie sur la console d'administration centrale, il y a une solution simple : la désinstaller puis la réinstaller, toujours à l'aide de PSConfig.

psconfig.exe -cmd unprovision

psconfig.exe -cmd adminvs -provision -port 21121 -windowsauthprovider onlyusentlm

Notez au passage que cette commande permet de fixer le port qui sera utilisé par le site, tout comme le permet l'assistant... à la différence prêt que le nom du répertoire créé dans InetPub ne sera pas le même. En effet, lorsque vous modifiez le port à l'aide de l'assistant, celui ci créé un répertoire pour stocker les fichiers du site et lui donne le nom du port qui était sélectionné par défaut, avant modification. (ce qui donne lieu à des consoles d'admin sur le port 10000, mais situées dans un répertoire 17892 par exemple...). Quoi qu'il en soit, le paramètre -port de la commande PSConfig permet de fixer le port ET le nom du répertoire où seront stockés les fichiers. 

Le fichier Config.xml

Le fichier Config.xml permet de spécifier les paramètres d'installation que le setup de SharePoint utilisera. Ce fichier est présent dans les répertoires x86\Files\Setup et x64\Files\Setup du CD d'installation de SharePoint. On y retrouve les paramètres par défaut pour WSS et pour MOSS. L'astuce consiste donc à modifier ces paramètres et en ajouter d'autres pour piloter l'installation de SharePoint. Les paramètres dont il est question permettent (entres autres) :

• une installation silencieuse
• la définition de paramètres d'installation communs lors d'une installation sur plusieurs serveurs (ou en cas de restauration après un crash du serveur)
• Le lancement d'une commande externe avant installation
• Le changement du chemin d'installation
• ...

Il vous est donc possible de faire vos propres CD d'installation de SharePoint (n'oubliez pas d'y intégrer le SP1 si vous ne l'avez pas déjà sur vos CD) ou même d'indiquer votre propre fichier Config.xml en argument du setup. Ex: setup.exe /config c:\MaConfig\config.xml.

Le schéma et sa description, là aussi, disponible sur le Technet.

Vous trouverez le post dont je tire les informations sur cette commande sur le blog de Ben Curry. 

La commande PSConfigUI

Cette commande est associée au lien SharePoint Products and Technologies Configuration Wizard du bouton démarrer. Elle vous sera utile si le raccourci n'est plus présent. Elle permet donc de relancer l'assistant et donc de se connecter / déconnecter de la base de données de configuration, mais aussi de finaliser la configuration de SharePoint en cas de mise à jour (Service Pack ou KB).

Bien que mes essais pour lui passer des arguments soient restés vains, l'utilisation de Reflector sur la commande indique qu'ils sont bien gérés (peut être pour une utilisation future). Je vous laisse au passage noter les traces générés dans la classe CommandLine :

Installation avec un compte administrateur de domaine

Petite particularité lorsque l'installation est réalisée avec un compte ayant les droits d'écriture sur l'AD : il devient possible pour SharePoint d'écrire dans l'Active Directory. Notamment pour créer de nouveaux utilisateurs, changer les mots de passe, synchroniser les profils dans les deux sens... bref, beaucoup de choses qui, mêmes si elles ont un gros intérêt, inquiètent les services d'exploitation (ce qui peut largement se comprendre). Concrètement, je ne l'ai jamais vu utilisé en entreprise. De manière générale, je recommande de ne pas utiliser un compte administrateur de domaine pour installer SharePoint.

Lorsque vous utilisez l'assistant d'installation, vous notterez le bouton Advanced Settings qui est généralement désactivé. Le bouton d'aide de l'écran indique que ce bouton n'est disponible que pour les serveurs n'hébergeant pas la console d'administration centrale.

Advanced settings To create new unique user accounts automatically by using the Active Directory directory service, you must enable Active Directory account creation mode. Because at least one Central Administration Web application is required for each server farm, in the first server in the server farm, the Central Administration Web application is automatically installed and only one set of fields, for the Active Directory domain and the Active Directory organizational unit, are presented. When you run the configuration wizard on other servers in the farm, you will see the option on this screen to create the Central Administration Web application. If you want to create a load-balanced URL for Central Administration or to provide redundancy, you can create more than one Central Administration Web site. However, in most installations this is unnecessary. To enable Active Directory account creation mode   On the Advanced Settings page, select Enable Active Directory Account Creation Mode. In Active Directory Domain, type your domain name. In Active Directory Organizational Unit, type your SharePoint organizational unit. To return to the Completing the SharePoint Products and Technologies Configuration Wizard page, click OK. Warning  If you enable this option, you might not be able to upgrade from Windows SharePoint Services to other products based on SharePoint Products and Technologies. If you have trouble installing products based on SharePoint Products and Technologies on this computer, run the SharePoint Products and Technologies Configuration Wizard again to clear this option.