Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SharePoint Grib's Lair

Journal technique de Sébastien PICAMELOT

Et vous, côté certifications, où en êtes vous ?

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.

Evenement TechDays 2009 - Certifiez Vous !

MCT(rgb)
 
Pour ma part je serai présent sur le stand des Certifications avec l’équipe Microsoft Learning France le mercredi, après la pleinière. Je serai là pour parler des certifications avec vous et vous aider à comprendre ce qu'elles peuvent vous apporter sur votre carrière professionnelle. Quel impact pour vous ? Comment vous y préparer ?
Ce sera l'occasion pour moi de vous apporter des témoignages sur des certifications SharePoint, bien sûr, mais également sur les certifications de développement en général, de vous donner des informations sur ce que j'ai pu trouver dans les formations, en ligne, etc.
 

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.

Mots clés Technorati : ,
[SharePoint] Choisir sa base de données lors de la création d'une nouvelle collection de sites

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

Create Site Collection (with database selection)


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.

Page de création contenant une liste déroulante permettant de sélectionner la base de données


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

Sortie de la release du iFilter Adobe PDF 64 bits pour SharePoint

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.

Quand Reporting Services vient taquiner MOSS

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 !

Cannot use 'partitionResolver' unless the mode is 'StateServer' or 'SQLServer'

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 !

La versionde Windows SharePoint Services exécutée sur le serveur est ultérieure à la version de SharePoint Designer

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 :

Microsoft.SqlServer.SmoEnum : rsAccessDeniedToSecureData

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.

Moralité :

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 !

Article sur le filtrage des modèles de site SharePoint

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.

CreateSite

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

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

Bonne lecture ;-)

Mots clés Technorati : ,,,
Un mélange ambitieux des dernières technologies Microsoft présenté à la WSC

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.

Winwise Solution Conference - Inscrivez vous !

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.

Découvrez la WebPart de transformation XSL du framework SharePointOfView

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.

SharePoint : Enfin des solutions pour le Content Deployment

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 :

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

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

Petit jeu pour bonne nouvelle : trois lettres à deviner
Question
WebControls SharePoint : une classe de base plus riche pour vos WebParts avec SharePointOfView

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.

/// Base method that renders the web part.
/// the output stream Html writer
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 :

///
/// 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.
///
/// the output stream Html writer
protected virtual void RenderWebPart(HtmlTextWriter writer)
{

}

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

Plus loin dans l'installation de SharePoint 2007

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.

PSCONFIG.EXE –cmd configdb <parameters>
–cmd helpcollections <parameters>
–cmd secureresources <parameters>
–cmd services <parameters>
–cmd installfeatures <parameters>
–cmd adminvs <parameters>
–cmd evalprovision <parameters>
–cmd applicationcontent <parameters>
PSCONFIG.EXE –help <commandname>

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

Specify Database Settings

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 :

PSConfig -cmd -configdb -create -server database_servername -database SharePoint_Config -user domain/username -password password
-dbuser sql_user -dbpassword sql_password -admincontentdatabase myAdminContent

  • 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
  • ...
<Configuration>
<Package Id="sts">
...
</Package>

<Package Id="spswfe">
...
</Package>
</Configuration>

Il vous est donc possible de faire vos propres CD d'installation de SharePoint (n'oubliez pas d'yinté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 :

PreventMistake

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

Completing the SharePoint Product and Technologies Wizard 

SPFieldCollection.Add : comment cibler tous les types de contenu ?
anonymous coworker

Sous couvert d'anonymat, un collègue m'a récemment confié sa surprise concernant l'ajout d'un SPField à une liste SharePoint.

En ajoutant un SPField à un forum de discussion, ce mystérieux collègue s'est heurté à un comportement auquel il ne s'attendait pas : son champ n'était présent que dans les sujets, mais jamais dans les réponses. Pour voir d'où cela provient, il active la gestion des types de contenu au niveau de la liste, jette un coup d'oeil aux champs, et constate que son champs n'est présent que pour le type de contenu "Discussion" et pas pour celui "Message".  En effet, en utilisant tout simplement la méthode SPFieldCollection.Add, le champs n'est lié qu'au type de contenu par défaut associé à la liste

Il me demande mon avis. Je lui donne une solution bancale dont je ne me vanterai pas ici... je réfléchis quelque secondes (le temps de me dire que je l'ai déjà fait il y a un bout de temps)... et je lui dit de jeter un coup d'oeil à la méthode AddFieldAsXml : Eurêka !

Une des deux signatures de la méthode AddFieldAsXml prends trois paramètres : string schemaXml, bool AddToDefaultView, SPAddFieldOptions op

avec l'énumération SPFieldOptions comme suit :

SPAddFieldOptions.AddToAllContentTypes

J'en ai (presque) immédiatement profité pour m'inspirer du blog de Phil pour tester les Extension Method :

Extension Method : utilisation de AddFieldWithXml

Certes, ce n'est pas vraiment plus évolué que d'utiliser le Fields.AddFieldAsXml directement, mais au moins j'ai pu tester les Extension Methods.

Merci Phil ! (oups !)

Comment étendre les données utilisateur SharePoint ?

Background

J'ai récemment cherché à stocker des métadonnées concernant la fréquentation des utilisateurs sur une collection de site. Récupérer des données statistiques sur la fréquentation se fait à l'aide de la méthode GetUsageData() :

SPWeb.GetUsageData (SPUsageReportType, SPUsagePeriodType)
SPWeb.GetUsageData (SPUsageReportType, SPUsagePeriodType, Int32, DateTime)

Seulement voilà, cette méthode est propre à la classe SPWeb. Récupérer des statistiques globales au niveau du SPSite demande donc une agrégation de données en parcourant la liste des sites. Et dans ce cas, aller chercher toutes les données et les filtrer en temps réel n'est pas vraiment performant. J'ai donc choisi de réaliser un Job SharePoint afin d'agréger toutes les données la nuit, puis de les stocker quelque part... mais où ?

Problématique

Bien que ce ne soit pas l'option que j'ai retenue, j'ai tout d'abord pensé aux données utilisateurs déjà présentes sur la collection de site. Petit rappel : les sites SharePoint exposent des données relatives aux utilisateurs de ses sites. Ces données sont accessibles à l'aide du contrôle welcome.ascx placé sur la masterpage default.master.

UserControl welcome.ascx


Ce contrôle permet d'accéder à la page userdisp.aspx (du dossier SharePoint LAYOUTS) affichant les données concernant les utilisateurs.

Page UserDisp d'origine

Le lien avec le modèle objet semble évident, et j'imagine ne pas être le seul à penser instinctivement « SPUser ». Il m'est donc venu la question suivante : peut-on étendre la classe SPUser ?

L'enquête

Après avoir cherché un peu sur Internet et sur le MSDN, il apparait que non. Mais il me semblait pourtant bien avoir vue une structure différente de cette page sur deux environnements différents... et après vérification, il est bien possible d'avoir une structure différente pour décrire les utilisateurs.
J'ai donc investigué à l'aide de Reflector à partir de la classe UserDisplayPage (dont « hérite » la page UserDisplay.aspx) et je suis tombé sur cette ligne là :

this.UserListForm.ListId = base.Web.SiteUserInfoList.ID;

Et je m'en suis voulu de ne pas y avoir pensé plus tôt. Si vous avez parcouru les listes de vos sites avec le modèle objet, ou bien à l'aide d'un outil comme le CAML Query Builder ou un logiciel comme Access, vous avez surement du remarqué une List nommée « UserInfo »ou « Liste d'informations utilisateur ». Et c'est dans cette liste que sont stockées toutes les données affichées sur la page UserDisp.aspx. 

Les tests

Un rapide test avec le modèle objet pour rajouter des champs :

SPFieldCollection fields = web.Lists["Liste d'informations utilisateur"].Fields;
fields.Add("URL du blog", SPFieldType.URL, false);
StringCollection choices = new StringCollection();
choices.Add("http://www.sharepointofview.fr/gat");
choices.Add("http://blogs.developpeur.org/phil");
choices.Add("http://blogs.developpeur.org/themit");
choices.Add("http://blogs.sharepointofview.fr/julien");
choices.Add("http://blogs.developpeur.org/fabrice69");
string fieldName = fields.Add("Blogosphere", SPFieldType.MultiChoice, false, true, choices); 
 

Et voilà le résultat sur la page useredit.aspx : 

La page UserEdit.aspx après les modifications

... et sur la page userDisp.aspx

La page UserDisp.aspx après les modifications

Conclusions

Bref, sans pour autant étendre un SPUser, la notion d'utilisateur de site est bien élargie. A noter toutefois :

  • que la sécurité sur ces données utilisateur est basée sur celle des listes, donc pas nécessairement adaptée pour stocker du contenu personnel (pour cela, préférez les profils MOSS)
  • que ces données sont propres à la collection de sites. La structure réservée aux données utilisateur reste donc différente dans les autres collections de site.
  • que cette structure permet de stocker des pièces jointes.

Modifier la structure des données décrivant un SPUser se fait donc très simplement... il fallait juste y penser Wink

Google Search Appliance et SharePoint... un an après

Il y a de celà un peu plus d'un an, j'avais comparé le moteur de recherche de la Google Search Applicance (GSA) à celui de Microsoft Office SharePoint Server (MOSS). Pour rappel, en dehors de la partie recherche sur laquelle chaque outil avait ses avantages et ses faiblesses, la GSA se voyait quasi inutilisable en authentification silencieuse dans un contexte SharePoint (notamment...). Depuis pas mal de choses ont changées, avec des nouvelles fonctionnalités du côté de la GSA, et de nouveaux produit côté Microsoft (je pense à Search Server).

Les évolutions de la GSA :

L'OS et la partie logicielle de la Google Search Applicance sont en perpetuelle évolution. La version 5 de la box Google est sortie durant l'été dernier... et elle n'est pas venue seule. Google avait mis à disposition un projet open source depuis un bon moment, visant à répondre au problème de sécurité. Ce projet, nommé "Access Connector", était basé sur une sorte de serveur web proxy utilisant le protocole SAML, chargé de garantir l'identité de l'utilisateur requêtant la Google Box. La documentation autour de ce projet était très pauvre, voire erronée, et le support très loin de ce à quoi on aurait pu s'attendre (ah oui, open source signifie de plus en plus projet sans engagement...)

Au final, j'avais pu mettre en place une solution de recherche Google dans SharePoint présentant les caractéristiques suivantes :

  • Une grosse lenteur pour obtenir le résultat des requêtes (environ 30s)
  • Des Timeouts très fréquents (une fois sur trois)
  • Parfois des pages de résultats vides

Bref, ce n'est jamais passé en production même si, effectivement, lorsque les résultats étaient enfin obtenus, je savais pourquoi j'aime bien Google.

Le temps est donc passé, La GSA est passée en version 5 et une nouvelle version de l'Access Connector est apparue. Résultat des courses :

  • Plus de timeout
  • Des résultats s'affichant sous 8 à 10 secondes en général (grumpf)
  • Plus d'incohérence sur les résultats

Quelles difficultés avec la GSA ?

Si l'authentification de vos sites SharePoint n'est pas en Kerberos, vous pouvez oublier la GSA. Dans le cas contraire, votre AD est-il bien en mode full 2003 ? Et dans ce cas, pouvez vous activer la délégation (Trusted for delegation) pour vos serveurs ? Sachez que toutes ces manipulations m'ont pris pas mal de temps, et même entouré du département éxploitation de mon client, j'ai fini par avoir une interruption de service non prévue sur les serveurs indexés.

Je savais que la mise en place de la GSA n'était pas chose aisée... et je ne comprends toujours pas pourquoi, même au sein de la SharePoint Conference 2008 la GSA est présentée comme un produit plug'n'play. L'occasion pour moi de vous montrer un bout de slide qui m'a fait bondir :

La GSA présentée à la SharePoint Conference 2008

C'est n'importe quoi !

Evidemment, on peut considérer que c'est beaucoup plus simple si on ne se préoccupe pas des droits ni si on pense que les utilisateurs peuvent bien se logger avant chaque recherche... ces contraintes ne sont pas vraiment dans ma conception de ce qu'est un portail d'entreprise...

Les atouts de la GSA

Toujours les mêmes qu'il y a un an... la possiblité d'étendre les données indexées, de jouer sur les associations de données à remonter lors des recherches... et puis la pertinence. Que c'est bon d'avoir une interface de recherche simple qui remonte ce que l'on cherche sans avoir besoin de faire de recherche avancée. D'autres atouts encore, comme le multilangue et beaucoup d'autres choses. D'autant que d'autres outils sont apparus (comprenez open source)... je pense à des connecteurs visant à ramener des données de systèmes externes, dont SharePoint ! Autrement dit, enfin la possibilité d'utiliser la GSA intelligemment avec les sites SharePoint. Bon, ne nous emballons pas... je n'ai certes pas poussé très loin les tests, mais une journée complète ne m'aura pas permi d'obtenir quoi que ce soit ce connecteur

Alors, GSA avec SharePoint à présent ou pas ?

Difficile à dire, ça dépend de beaucoup d'éléments. Force est de constater que l'obtention des resultats de recherche reste lent et que ça ne risque pas de s'améliorer (c'est le fonctionnement normal de la GSA en mode authentifié). Côté fonctionnalités, la moindre chose demande un gros effort d'intégration. Certes, la Google Box peut faire plein de choses merveilleuses, mais pas toute seule. . Bref, je reste très mitigé sur l'utilisation de la GSA dans SharePoint... mais même si Google va lentement sur ce coup là, il semble aussi y aller surement si je me fie aux bonnes évolutions depuis l'année dernière. C'est donc à suivre pour moi.

Côté interface, c'est du XSL donc aucun soucis à l'intégrer pleinement dans son portail (comme l'illustre ma capture ci dessous... désolé pour le floot, je ne pouvais pas faire autrement)

Les résultats de recherche de la GSA dans SharePoint

Sous le floot se cache des résultats de recherche Google

Et le moteur de recherche de MOSS alors ?

Et bien c'est un vrai bon moteur de recherche. On est loin des incohérences du moteur SPS2003... loin au point de se demander pourquoi prendre un autre moteur de recherche (sauf recherche spécialisée évidemment). Cependant, le moteur de recherche de MOSS a connu quelques soucis techniques (je pense au memory leak pré SP1) et en connais encore quelques uns par moment. Côté fonctionnel, des choses toutes simples, OOB dans la recherche SPS 2003 ne sont plus possibles nativement dans MOSS 2007. Je pense à la recherche de personnes. La notion de distance sociale est excellente, certes. Mais lorsque les fonctionnels ne veulent pas en entendre parler et veulent retrouver leur classement par ordre alphabétique comme sous 2003, ça se corse. Bref, tout n'est pas rose du côté MOSS, mais ça reste quand même bien clair, directement intégré aux sites SharePoint, customisable, pertinent, et ça gère des stats de recherche...

Egalement, en version entreprise MOSS est capable d'indexer des données provenant de WebServices et de bases de données... là ou la GSA s'arrête à du DB2.

Conclusion

Pas de vainqueur ni de vaincu, comme vous deviez l'imaginer avant de lire ce post, car tout dépend de votre système d'information en place. Sachez toutefois que les deux solutions sont techniquement possible. La Google Search Appliance reste très lourde à mettre en place et demande un temps énorme s'intégrer aux sites SharePoint au même niveau que MOSS le fait, pour une rapidité d'éxécution moins bonne au final, mais une pertinence qui a fait la renommée de Google. De son côté, MOSS bénéfice de la recherche OOB et de formulaires de recherche extensibles et propices à une bonne recherche en entreprise. Dans le cas ou vous êtes sur WSS et que vous vous posez la question du moteur de recherche, sachez que vous avez également la solution Microsoft Search Server et la Google Mini Big Smile

FunkyPoint : Nouveau bloggeur... à suivre absolument !

Vous avez peut être remarqué les nombreuses références à un certain Julien Chomarat à la fin de mes posts ces derniers temps... et bien ce fameux Julien vient enfin d'ouvrir son blog FunkyPoint sur la plateforme SharePointOfView.

C'est un blog à suivre absolument. Pourquoi ? Parce que :

  • Julien a souvent de très bonnes infos SharePoint
  • Les blogs traitant d'Office Live ne sont pas nombreux (y'en avait t-il seulement avant ?).
  • Julien a coutume de placer la barre assez haut... de quoi assurer des posts de qualité.

Bref, un RSS a reccupérer ASAP.

 

Disponibilité des WebCasts TechDays 2008
TechDays

Ca y est, cette fois ci c'est la bonne !

Les webcasts des sessions TechDays 2008 qui se sont déroulés à Paris en février dernier sont disponibles sur le site des TechDays.

Vous retrouverez, entres autres, la session que j'ai co-animé avec Gat, intitulée Publication de sites Internet avec SharePoint 2007.

Performances désastreuses sur vos Serveurs SharePoint ?

40 ou 50 secondes pour charger une page SharePoint relativement épurée sur un de vos postes client ? Et ce phénomène est d'autant plus étrange si votre page SharePoint ne contient aucun code custom, et que vous êtes le seul à y accéder. Alors que tout se passait bien sur un environnement virtuel, ce phénomène m'est arrivé lors du passage sur les serveurs de production... tous flambant neufs et largement dimensionnés.

un peu plus de détails sur le problème

Une requête depuis un poste client nécessite de 40 à 50 secondes avant d'afficher la page. Les éléments affichés sur la page correspondent tout à fait à ce qui était prévu. Lorsque le client raffraîchi la page, la requête aboutit nettement plus rapidement, en moins de 2 secondes lors de mes tests. Et si le cache IE est vidé, la requête prends à nouveau entre 40 et 50 secondes. Bref, lorsque les données sont en cache côté client, tout va bien, autrement c'est le drame ! ("almost" copyright Gat)

En regardant en détail à l'aide de HttpWatch, il apparaît que l'appel au WebResource.axd est très différent avec et sans le cache côté client.

Détail de la requête : Appel au WebResource.axd lorsque les donnés sont en cache

Cette capture illustre un cas ou tout va bien. La ressource est obtenue en moins d'une seconde. Mais lorsque le cache est vidé, l'appel au WebResource.axd prends bel et bien plus de 40 secondes.

Dans quel cas le problème se produit-il ?

Le problème provient des networks adapters et du TCP Chimney Offload. Qu'est ce que le TCP Chimney Offload ? Vous trouverez cette définition sur le site du Technet :

"TCP Chimney Offload (allègement de la pile TCP). TCP Chimney Offload transfère de façon automatique le traitement du trafic TCP (Transmission Control Protocol) avec état à un adaptateur réseau spécialisé qui met en œuvre un « moteur de déchargement TCP » (TOE – TCP Offload Engine). Pour les connexions à longue durée de vie mettant en œuvre des paquets de grande taille, comme les connexions avec un serveur de fichiers, de stockage ou de sauvegarde, ou pour d'autres applications sollicitant fortement le réseau, TCP Chimney Offload réduit largement la charge du processeur en délégant à l’adaptateur réseau le traitement des paquets du réseau, y compris la fragmentation et le réassemblage des paquets. En utilisant TCP Chimney Offload, vous allégez le processeur qui peut se concentrer à d’autres tâches comme permettre davantage de sessions utilisateurs ou traiter les requêtes des applications en réduisant la latence."

Pour de plus amples informations sur le TCP Chimney Offloading, je vous invite à consulter ce white paper : http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/TCP_Chimney.doc

Bref, le TCP Chimney Offload permet d'optimiser le traitement lié au traffic réseau. Cette fonctionnalité fait son apparition sous Windows Server 2003 avec le SP2.

Ce problème de performance ne concerne que les serveurs frontaux SharePoint sous Windows Server 2003 SP2... mais pas tous ! C'est là qu'interviennent les network adapters. En effet, le TCP Chimney Offloading n'est pas géré de la même façon selon les interfaces réseau. Dans mon cas, le problème s'est produit avec des serveurs HP.

Comment résoudre le problème ?

Sur le principe, il suffit de désactiver le TCP Offloading. Techniquement, il y a plusieurs façons de procéder :

  • En executant la commande netsh int ip set chimney disabled

         Cette commande vous permettra de tester le comportement de vos serveurs une fois le TCP Offloading désactivé. en cas de problème, relancez la commande en remplaçant ll paramètre disabled par enabled, ou redémarrez votre serveur.

  • En modifiant la base de registre. Accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters et fixez la valeur de EnableTCPChimney à 0. Redémarrez ensuite votre serveur. Je vous conseille d'utiliser cette solution une fois le comportement validé avec la solution précédente.
  • En appliquant la KB Microsoft 948496 : http://support.microsoft.com/kb/948496/en-us. Il vous faudra ensuite redémarrer vos serveurs. Attention cependant, cette KB désactive également le RSS (Receive Side Scaling) Offloading.
  • En vérifiant la disponibilité d'une nouvelle version de vos pilotes d'interface réseau, corrigeant le problème.

Conclusion

Une fois le TCP Chimney Offloading désactivé, les requêtes client sur des sites SharePoint redeviennent tout à fait normales, même lorsque le cache du navigateur est vidé. Ce problème reste néanmoins très spécifique. S'il ne se produit pas sur votre plateforme, ne désactivez pas le TCP Chimney Offloading.


Comme d'habitude, merci à Julien Chomarat (avec qui j'ai découvert ce problème).

SharePoint 2007 : Réussir sa mise à jour vers le SP1

J'ai encore très récemment pu voir une question sur le forum MSDN concernant une plateforme SharePoint de production inaccessible suite à l'application du Service Pack 1 pour MOSS 2007. Je le rappelle et je le rappellerai encore, avant d'installer un service Pack :

  • Faites toujours un backup de votre plateforme
    • Stsadm -o backup pour la plateforme SharePoint
    • Backup des bases SQL, notamment celles de configuration et d'administration.
    • Backup des serveurs avec des outils adaptés.
  • Prenez le temps de tester la mise à jour sur un environnement de validation
  • Planifiez la mise à jour, considérez le pire scénario, et prévoyez le temps qu'il vous faudra pour tout rétablir si cela vous arrive.

Pour résumer : ne faites pas de mise à jour si vous n'êtes pas en mesure de faire un retour arrière !

Et parce que le risque 0 n'existe pas, nous sommes nombreux à avoir rencontré des problèmes lors de cette mise à jour (voir le billet de Fabrice Romelard à ce sujet).

Si un retour arrière est possible dès lors que tous les points précédemment cités ont été respectés, il reste à trouver comment recommencer l'opération avec plus de succès. Dans mon cas, c'est une approche systémique qui m'a apporté la solution. Pourquoi une approche systémique ? Tout simplement parce que l'application du Service Pack 1 effectue des modifications Sur les serveurs SharePoint ET Sur les bases de données. Et je suis parti de ce constat pour mettre à jour ces deux éléments séparément : d'abord les serveurs, puis les bases de contenu? et séparément, ces deux mises à jour sont moins complexes qu'une mise à jour globale.

Voici comment procéder :

Avant de commencer

  1. Faites tous les backups listés précédemment
  2. Assurez vous que votre serveur SQL ait suffisamment d'espace disque.

Première étape : détacher les bases de contenu

  1. Connectez-vous à la console d'administration centrale de SharePoint.
  2. Cliquez sur l'onglet « Application management »
  3. Sélectionnez votre application Web
  4. Détachez une à une toutes vos bases de contenu
  5. Répétez l'opération pour chacune de vos applications Web (hors celle d'administration)

Remarque : vous pouvez également détacher vos bases de contenu à l'aide de la commande

stsadm -o deletecontentdb -url http://computername -databasename

Seconde étape : appliquer les SP1 à la plateforme SharePoint

  1. Exécutez le SP1 WSS sur chacun de vos serveurs.
  2. Suivez l'assistant jusqu'à ce que le pop-up ci-dessous apparaisse. Si votre ferme est constituée de plusieurs serveurs, ne cliquez surtout pas sur le bouton « OK ». Répétez cette étape pour chacun des serveurs de la ferme.

    SharePoint Products and Technologies Configuration Wizard

  3. Une fois que vos serveurs ont tous déroulé l'assistant, cliquez sur le bouton OK.
  4. Connectez-vous à la console d'administration centrale et regardez le numéro de version indiqué sur la page /_admin/FarmServers.Aspx. La version 12.0.0.6219 indique que la mise à jour s'est bien déroulée

En cas d'anomalie pendant la mise à jour, vous pourrez la retenter en exécutant la commande :

psconfig -cmd upgrade -inplace b2b -wait -force

  1. Si vous utilisez des packs de langue, installez les services packs spécifiques pour chacun de vos packs de langue.
  2. Si votre plateforme SharePoint est une plateforme MOSS, répétez les opérations 1 à 5 avec le Service Pack 1 de MOSS (Il vous faudra donc installer le SP1 de WSS dans tous les cas).

Troisième étape : rattacher et mettre à jour les bases de contenu.

  1. Connectez-vous à la console d'administration centrale de SharePoint.
  2. Cliquez sur l'onglet « Application management »
  3. Sélectionnez votre application Web
  4. Rattachez une à une toutes vos bases de contenu. Les modifications du service Pack impacteront les bases de données pendant l'opération.
  5. Répétez l'opération pour chacune de vos applications Web

Remarque : vous pouvez également attacher vos bases de contenu à l'aide de la commande

stsadm -o addcontentdb -url -databasename -databaseserver

Il est alors possible que votre environnement soit mis à jour et pleinement opérationnel. Pourquoi seulement « possible » ? Parce que si vous êtes sous MOSS, il est probable que l'opération ait désynchronisé vos bases de contenu avec celles du SSP, auquel cas vous retrouverez pas mal d'erreurs dans vos logs et un site répondant? parfois bien mal.

Pour remédier, exécutez la commande

stsadm -o preparetomove -contentdb dbname -oldcontentdb

où est le GUID de référence de votre base de contenu dans SharePoint. Il vous faudra donc les lister à l'aide de la commande

stsadm -o sync -listolddatabases 1

Etape optionnelle :

Si vous aviez installé des hot fixes antérieurs au SP1, il est possible qu'ils ne soient plus actifs (tous les hot fixes publié auparavant ne sont pas inclus dans le SP1, et certain d'entre eux disparaissent purement et simplement avec la mise à jour du SP1). Comme je vous le disais dans mon précédent post, c'est l'occasion d'appliquer les hot fixes post SP1 :

Remarque : lors de l'application des hot fixes posts SP1, votre plateforme SharePoint passera en version 12.0.6301.5000.

Ressources complémentaires :

... et merci à Julien Chomarat avec qui j'ai fait cette mise à jour ;-).

Sortie de deux Hot Fixes WSS 3.0 et MOSS 2007 post-SP1

Deux hot fixes (un pour WSS et un pour MOSS) viennent tout juste d'être publiés par Microsoft.

Si vous aviez installé les hot fixes antérieurs au SP1, sachez que certains d'entre eux étaient tout simplement écrasés lors de l'installation du SP1. Ces nouveaux hot fixes sont donc l'occasion de retrouver toutes les corrections qui avaient été perdues lors de l'installation du SP1. Au delà de ça, de nouvelles corrections font leur apparition... et elles sont très nombreuses.

Vous les trouverez les hot fixes et la liste des corrections à ces adresses :

N'oubliez pas que si vous êtes sur MOSS, ces deux hot fixes vous concernent.

Merci à Julien Chomarat (l'homme qui ne blog toujours pas... mais ça ne saurait tarder, hum ? ) pour m'avoir informé de la disponibilité de ces rollups.

SharePoint : baser un LookUp Field sur des données d'un autre site

Le champ LookUp est un excellent moyen d'intégrer du relationnel dans SharePoint. La création d'un champ de ce type dans une liste SharePoint donne la possibilité de référencer un champ d'une autre liste du même site. Mais malheuresement cette possibilité amène parfois une frustration car bien souvent les données que nous souhaiterions référencer ne se trouvent pas dans le même site.

Il existe pourtant un moyen simple de résoudre ce problème, comme l'illustre Box Mixon dans son blog. Je m'excuse par avance pour ce second billet de la soirée sans grande contribution de ma part, mais compte tenu de la clarté de ce qu'a publié Bob, je ne pouvais pas ne pas le relayer.

Challenge

En effet, Box Mixon illustre avec des schémas on ne peut plus simple comment une approche globale, via les Content Types et les colonnes de site, permettent de mettre en oeuvre ce mécanisme. Vous l'aurez noté, que ce soit des ContentTypes ou des colonnes de site, le scope de ces éléments s'étend à toute la collection de sites et non au site uniquement. En d'autres terme, c'est en utilisant une colonne de site de type LookUp dans vos listes que vous pourrez référencer des données externes à votre site.

Outre les explications de son blog, Bob Mixon a rédigé un excellent document, particulièrement accessible, indiquant step by step comment créer une telle colonne LookUp dans les listes SharePoint. Vous le trouverez à cette adresse : http://www.iterasi.net/openviewer.aspx?sqrlitid=pc7s-tywv0-savezfq8aew



Les 10 derniers blogs postés

- SharePoint 20XX: Script PowerShell pour exporter en CSV toutes les listes d’une ferme pour auditer le contenu avant migration par Blog Technique de Romelard Fabrice le 03-28-2017, 17:53

- Les pièges de l’installation de Visual Studio 2017 par Blog de Jérémy Jeanson le 03-24-2017, 13:05

- UWP or not UWP sur Visual Studio 2015 ? par Blog de Jérémy Jeanson le 03-08-2017, 19:12

- Désinstallation de .net Core RC1 Update 1 ou SDK de Core 1 Preview 2 par Blog de Jérémy Jeanson le 03-07-2017, 19:29

- Office 365: Ajouter un utilisateur ou groupe dans la liste des Site collection Administrator d’un site SharePoint Online via PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-24-2017, 18:52

- Office 365: Comment créer une document library qui utilise les ContentTypeHub avec PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-22-2017, 17:06

- [TFS] Supprimer en masse les dépendances à SQL Enterprise ou Developer avant de procéder à une migration par Blog de Jérémy Jeanson le 02-20-2017, 20:30

- Office 365: Attention au volume utilisé par les fichiers de Thèmes de SharePoint Online par Blog Technique de Romelard Fabrice le 02-07-2017, 18:19

- [SCVMM] Supprimer une machine bloquée par Blog de Jérémy Jeanson le 01-31-2017, 21:22

- Microsoft .Net Challenge 2017 par Le Blog (Vert) d'Arnaud JUND le 01-30-2017, 15:25