Paslatek Blog

Accès refusés lors de l’indexation de mon SharePoint

lionel.limozin@bewise.fr — Wed, 04 Apr 2012 09:10:01 +0200

Je reviens sur ce Post que j’avais fait fin d’été dernier : Accès impossible à une application web SharePoint depuis le serveur (erreur 401) / Accès impossible à une application web SharePoint depuis le serveur (erreur 401)
Pour trois raisons :
- Je me suis rendu compte que j’avais carrément oublié une clé registre à positionner (en tout cas d’après MSDN)
- mon Post n’était pas assez précis sur le format des informations à renseigner dans le registre. Je me suis fait moi même “avoir” quand j’ai été de nouveau confronté à ce problème et que j’ai suivi ma propre procédure…. qui ne fonctionnait pas.
- enfin j’ai rencontré ce souci ainsi qu’un collègue (quasiment en même temps, les grands esprits se rencontrent) sur le cas du moteur de recherche SharePoint dans une config de ferme “Small Farm” assez classique. Je pense qu’il est donc intéressant d’en remettre une couche sur ce cas particulier

Ma ferme est donc composée de 2 frontaux, 1 serveur applicatif ayant le rôle d’indexeur (crawler) et 1 serveur SQL. J’ai aussi un loadbalancer hardware qui se charge de router les clients sur l’un ou l’autre des frontaux. A la base le serveur ayant le rôle d’indexeur se comporte comme un client final, c’est à dire que le serveur DNS lui indique que www.intranet.fr pointe sur l’IP virtuelle prise en charge par le loadbalancer. Donc chaque requête HTTP réalisée par l’indexeur est traitée par l’un ou l’autre des WFE. Dans cette configuration je n’avais pas de souci.

Puis j’ai décidé de faire une configuration légèrement différente qui consiste à modifier le fichier HOST du serveur APP pour lui dire que finalement www.intranet.fr pointe sur sa propre IP. En effet le crawler est tout à fait capable de servir lui même les pages de l’intranet. Ainsi mon serveur APP travaille plus mais mes frontaux ne sont pas pénalisé par l’indexation (hormis l’impact sur le SQL Server) :

Et bien c’est exactement dans ce cas de figure que vous rencontrerez le même problème que moi. Le compte d’accès au contenu utilisé pour l’indexation, bien qu’ayant une “User Policy” à “Full Read'” sur votre site SharePoint va recevoir des erreur “401 Access Denied” en continu et n’arrivera plus à indexer quoique ce soit. Pour rappel les conditions à réunir pour reproduire le problème:
- Appel http depuis le serveur sur un nom de domaine différent du nom du serveur
- Authentification nécessaire (en tout cas en anonyme évidement ça passe)
- La requête http arrive directement sur le serveur (127.0.0.1 ou une des IP du serveur)

Dans ce cas, c’est IIS qui renvoi un 401, pour des raisons de sécurité au cas où vous pensiez effectivement accéder à un site externe et qu’un virus ou autre pirate aurais fait en sorte de faire tourner un site de type “pishing” sur votre serveur pour y récupérer des informations types login/password.

Bref je vous redonne la procédure, complète cette fois ci.

- Sur le serveur en question (le crawler) ouvrez le registre
- Ouvrez la clé HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
- ajoutez une valeur de type DWORD avec le nom DisableStrictNameChecking et pour valeur 1
- ouvrez la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
- ajoutez la clé de type multistring (si elle n’existe pas déjà) nommée BackConnectionHostNames
- alimentez cette clé avec les noms d’hôtes à autoriser en local :
- un nom pour chaque web application à autoriser
- le nom est le nom de domaine SANS le protocole, par exemple : intranet.fr (et pas http://www.intranet.fr) ou encore app1.domaine.com (et pas http://app1.domaine.com)
- Redémarrez le service IISADMIN

Sources : http://support.microsoft.com/kb/896861/en-us et http://support.microsoft.com/kb/281308

Suivez moi sur Twitter

lionel.limozin@bewise.fr — Sun, 11 Mar 2012 13:11:36 +0100

Mieux vaux tard que jamais pour se mettre aux technos 2.0 . Donc voilà ça c’est fait et c’est ici que ça ce passe : Suivre @LimozinLionel

Webcasts Techdays 2012

lionel.limozin@bewise.fr — Fri, 09 Mar 2012 09:38:45 +0100

Les Webcast des Techdays 2012 sont en ligne ! Vous pouvez les retrouver tous ici : http://www.microsoft.com/france/mstechdays/programmes/parcours.aspx#&fbid=6Ru1UeiZP86. Concernant la session que j’ai animé avec Alain Marty voici un lien direct : http://www.microsoft.com/fr-fr/showcase/details.aspx?uuid=d6d73a39-a080-42e9-b87a-03ff2b025660

Techdays 2012 ou l’année des 12 sessions SharePoint

lionel.limozin@bewise.fr — Thu, 02 Feb 2012 15:02:28 +0100

Cette Année SharePoint tiens encore une place importante aux Techdays. Pas moins de 12 Sessions ! Retrouvez ici un détail complet. Bien sûr vous devez privilégier ma session

Rejoignez moi aux Techdays’12

lionel.limozin@bewise.fr — Fri, 27 Jan 2012 13:56:35 +0100

Information de dernière minute ! Je serais finalement speaker aux Techdays de cette année ! Bien sûr le sujet est SharePoint. Cette année on va la jouer “gentil” et donc pas de Dev ! juste une bonne session de découverte sur les aspect GED de SharePoint 2010.
---> Le détail ici <--- .
Je serais aussi présent aux stands “Ask the expert” sur la partie “efficacité individuelle et collective” le Mardi 7 et Mercredi 8 février. N’hésitez pas à venir me passer un p’tit bonjour

MVP SharePoint Server

lionel.limozin@bewise.fr — Mon, 02 Jan 2012 16:01:39 +0100

Pour bien commencer l’année j’ai eu le grand plaisir et honneur d’être nommé MVP ( c’est une première pour moi ! ) et ceci pour récompenser mes diverses participations au sein de la communauté, française, SharePoint Server. Bien sûr je vais faire en sorte de bien défendre ce titre tout au long de l’année en continuant à partager au maximum mes trucs, astuces, retours d’expériences, etc. sur ce blog. Donc comme on dit : “Stay Tuned !”

La réussite de vos projets SharePoint passe par une intégration continue

lionel.limozin@bewise.fr — Mon, 21 Nov 2011 11:53:37 +0100

Connaissez-vous l'intégration continue ? Avez-vous des doutes sur ses intérêts et avantages ? Je ne chercherais pas à répondre à ces questions dans cet article car vous en trouverez certainement des dizaines voire même des centaines bien plus pertinents que le mien. Malgré tout, afin de planter un minimum le décor, voici pour faire simple la définition de Wikipédia :

« L'intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l'application en cours de développement. »

Par contre, une fois que vous aurez fait ces recherches, je ne doute pas que vous soyez au moins autant convaincu que moi. Alors peut-être à ce moment vous vous demanderez : « Comment mettre en place ce type de processus d'intégration continue avec des projets SharePoint ? ». Dans ce cas, cet article est pour vous !

Je vais vous guider sur les outils à utiliser et comment les utiliser pour mettre en place une compilation, un déploiement et des tests, tout ceci de manière automatique, pour vos projets dédiés à la plateforme SharePoint 2010.

Ce processus fera appel à la plateforme Team Foundation Server, en particulier l'aspect "Build" automatique permettant de séquencer un ensemble d'actions telles que « compilation », « exécution de processus externe », « création de WorkItems », « exécution de tests unitaires ».

Retrouvez l’article complet sur labs.bewise.fr : Partie 1 et Partie 2

Le getter de la mort

lionel.limozin@bewise.fr — Fri, 18 Nov 2011 08:31:28 +0100

Nous utilisons très souvent des propriétés public sur des classes, que ce soit en get ou set. SharePoint et son SDK ni manque pas non plus. Cependant méfiez vous de certains pièges où on pense que le getter ne renvoi qu’une variable interne ! ce n’est pas toujours vrai ! Le getter peu faire beaucoup de chose avant de vous renvoyer le résultat… Les performances de votre application peuvent donc en pâtir, mais vous pouvez carrément avoir des “bugs”. Un bon exemple avec le SPWeb.RootFolder :

Scénario : Vous devez modifier la WelcomePage d’un SPWeb par code. Par défaut on aurait tendance à faire ça :

SPWeb w = ….. // je ne m’attarde pas sur la récupération du SPWeb

w.RootFolder.WelcomePage = “toto.aspx”

w.RootFolder.Update();

Comme beaucoup de classes dans le SDK de SharePoint, il faut appeler la méthode Update pour valider la mise à jour. Mais il se trouve que ça ne marche pas ! (pas de plantage mais la page d’accueil ne sera pas changée) pourquoi ? Regardons l’implémentation de RootFolder avec Reflector :

public SPFolder RootFolder { get { return new SPFolder(this, ""); } }

Et oui ! une nouvelle instance à chaque fois ! du coup l’appel à Update n’est pas fait sur la même instance de SPFolder et on perd donc la modification de la WelcomePage.

Solution : Dans ce cas il faut faire ça :

SPFolder f = w.RootFolder;

f.WelcomePage = “toto.aspx”

f.Update();

Et le tour est joué !

Conclusion : ne soyons pas trop flemmard à déclarer des variables intermédiaires…

Problème sur le Cumulative Update Octobre pour MOSS 2007 SP3

lionel.limozin@bewise.fr — Fri, 04 Nov 2011 09:27:52 +0100

Attention à ceux qui souhaiterais installer le CU d’octobre sur un MOSS 2007 ! si votre Moss est déjà en SP3 ça ne sera pas possible !… http://blogs.technet.com/b/stefan_gossner/archive/2011/10/29/be-careful-when-planning-to-install-moss-2007-october-2011-cu-and-service-pack-3.aspx. Il semble qu’il faille installer ce CU avant le SP3. Et pour ceux qui ont déjà le SP3 … pas de solution ?

SPContext et SPServiceContext dans le mauvais Contexte ou le piège du singleton masqué

lionel.limozin@bewise.fr — Wed, 02 Nov 2011 09:13:13 +0100

Sous couvert de ce titre en jeux de mots je souhaite vous parler d’un sujet inspiré de deux problèmes rencontrés avec du code pour SharePoint.
(EDIT 18/11/2011 : J’ai modifié mon code car j’utilisais le Thread.CurrentPrincipal pour assigner le User du HttpContext. Dans le cas d’une application console, ce CurrentPrincipal est “vide”. J’ai donc corrigé pour utiliser “new WindowsPrincipal(WindowsIdentity.GetCurrent())” à la place)

1 - L’erreur de départ

Concrètement ces deux “erreurs” apparaissent dans un contexte particulier qui est celui d’une application Windows (batch, powershell, client lourd) utilisant le SDK de SharePoint :

1er cas : c’est la cas “facile”. En tentant de construire une instance de UserProfileManager vous utilisez la ligne de code suivante :

UserProfileManager mana = new UserProfileManager(SPServiceContext.Current);

et vous obtenez l’exception suivante :

System.ArgumentNullException : Value cannot be null. Parameter name: serviceContext

at Microsoft.Office.Server.UserProfiles.ProfileManagerBase..ctor(SPServiceContext serviceContext)
at Microsoft.Office.Server.UserProfiles.ProfileManagerBase..ctor(SPServiceContext serviceContext, Boolean ignorePrivacy)
at Microsoft.Office.Server.UserProfiles.UserProfileManager..ctor(SPServiceContext serviceContext, Boolean IgnoreUserPrivacy, Boolean backwardCompatible)
at Microsoft.Office.Server.UserProfiles.UserProfileManager..ctor(SPServiceContext serviceContext, Boolean IgnoreUserPrivacy)

2nd cas : c’est la cas “vicieux”. En utilisant un SPLimitedWebPartManager pour modifier ou consulter les propriétés de webparts, en particulier des ContentByQueryWebPart ayant des XSLT customs attachés (ItemXslLink et/ou MainXslLink) vous récupérez uniquement des Microsoft.SharePoint.WebPartPages.ErrorWebPart avec comme erreur par exemple :

An error occurred while setting the value of this property: Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart:ItemXslLink - Exception has been thrown by the target of an invocation.

2 – L’analyse

Alors bien sûr vous vous en doutez, la raison est globalement la même, il s’agit du context qui est mal initialisé car nous sommes dans un contexte client lourd et pas application web, c’est logique…

Mais quel contexte ? SPServiceContext, SPContext, HttpContext ?

Et puis d’abord comme ça se fait que le singleton SPContext.Current ne se débrouille pas tout seul pour être correctement construit ?!

Instinctivement j’aurais tendance à dire que le SPServiceContext.Current utilise le SPContext.Current qui à son tour utilise le HttpContext.Current. Vérifions avec une bonne vielle décompilation :

SPServiceContexT.Current:

public static SPServiceContext Current 
{ 
    get 
    { 
        SPServiceContextScope currentScope = SPServiceContextScope.CurrentScope; 
        if (currentScope != null) 
        { 
            return currentScope.Context; 
        } 
        return GetContext(HttpContext.Current); 
    } 
}

et SPContext.Current :

public static SPContext Current 
{ 
    get 
    { 
        SPContext context = null; 
        if (HttpContext.Current != null) 
        { 
            try 
            { 
                if (SPControl.GetContextWeb(HttpContext.Current) == null) 
                { 
                    return null; 
                } 
            } 
            catch (InvalidOperationException) 
            { 
                return null; 
            } 
            try 
            { 
                context = GetContext(HttpContext.Current); 
            } 
            catch (FileNotFoundException) 
            { 
            } 
            catch (InvalidOperationException) 
            { 
            } 
        } 
        return context; 
    } 
}

On constate que dans les deux cas il faut que le HttpContext.Current soit initialisé. Sur la cas du SPContext c’est d’autant plus flagrant qu’un premier test vérifie que le HttpContext fourni n’est pas null.

Du coup cette imbrication de propriétés, toutes statiques, masquent un peu un besoin nécessaire au bon fonctionnement des classes du SDK : un contexte d’application web, donc une requête http sur une url. Quelque part cela ne me “choque pas” sur le principe que SharePoint est avant tout utilisé dans un contexte web. Donc l’utiliser dans un autre contexte peut nécessiter des actions supplémentaires. Ce qui me gène c’est que dans certains cas, l’utilisation du SPContext est faite en interne par le biais d’autres classes et méthodes et dans mon cas la remontée d’erreur n’est pas forcement très explicite.

Par exemple ma seconde erreur est due au fait que j’utilise un ContentByQueryWebPart qui lui même hérite d’un CmsDataFormWebPart qui notamment dans le cas du setter de certaines propriétés (comme celle concernant le Xsl) appelle une méthode nommée MakeSiteRelativeUrl.

Que fait cette méthode ? Je vous le donne en mille :

private static string MakeSiteRelativeUrl(string xslServerRelativeUrl) 
{ 
    string serverRelativeUrl = SPContext.Current.Site.ServerRelativeUrl; 
...
}

Et évidement si je n’ai pas de HttpContext, je n’ai pas non plus de SPContext, et donc pas de Site et encore moins de ServerRelativeUrl.

Et pour finir, lors de l’analyse de la page par le SPLimitedWebPartManager, le webpart est chargé comme si il était rendu dans la page web, donc le XslLink est fixé lors du CreateChildControl et donc en cascade la fameuse méthode est appelée, elle plante, SharePoint prends ça en charge et remplace le webpart par un ErrorWebPart…

3 – La résolution

La solution est simple me diriez vous ! Il suffit d’instancier un HttpContext dans le cas d’une application qui ne tournera pas en application web ! Ok très bien allons y. Pour instancier un HttpContext il nous faut une HttpRequest qui a besoin d’une url et d’une HttpResponse.

Concernant l’url il me semble judicieux de fournir celle du SPWeb que l’on souhaite ouvrir ou du SPFile par exemple, je rajoute donc la ligne suivante juste après l’ouverture d’un SPWeb nommé web :

HttpContext.Current = new HttpContext(new HttpRequest("", web.Url, ""), new HttpResponse(new StringWriter()));

Et malheureusement ça ne suffit pas !

Et pour comprendre pourquoi le mieux et de retourner voir le code de la propriété SPContext.Current, en particulier la méthode SPControl.GetContextWeb :

private static SPWeb SPWebEnsureSPControl(HttpContext context) 
{ 
   SPWeb web = (SPWeb) context.Items["HttpHandlerSPWeb"]; 
    if ((web == null) && (context.Items["HttpHandlerSPSiteNotFound"] == null)) 
    { 
        if (context.User == null) 
        { 
            context.Items["HttpHandlerSPSiteNotFound"] = "1"; 
            throw new InvalidOperationException(); 
        } 
        if (SPSecurity.ImpersonatingSelf || SPSecurity.RunAsUserInProgress) 
        { 
            throw new InvalidOperationException(); 
        } 
        try 
        { 
            SPSite site; 
            context.Items["HttpHandlerSPSite"] = site = SPSiteFromContextNoCache(); 
            if (site == null) 
            { 
                context.Items["HttpHandlerSPSiteNotFound"] = "1"; 
                return null; 
            } 
            web = site.OpenWeb(); 
            context.Items["HttpHandlerSPWeb"] = web; 
            if (!SPRequestUsageMonitoredScope.s_FirstBrowseHasOccured) 
            { 
                SPRequestUsageMonitoredScope.s_FirstBrowseHasOccured = true; 
            } 
            if (SPSecurity.ApplicationPrincipal == null) 
            { 
                site.InitUserToken(EnsureSPWebRequest(web)); 
            } 
            else 
            { 
                site.InitUserToken(null); 
            } 
            SPRequestModule.InitContextWeb(context, web); 
            if (SPContext.GetShouldInitThreadCultureWhenContextWebIsInited(context)) 
            { 
                web.SetThreadCultureAfterInit(); 
            } 
            ULS.CorrelationAdd("Site", site.ServerRelativeUrl); 
        } 
        catch (FileNotFoundException) 
        { 
            context.Items["HttpHandlerSPSiteNotFound"] = "1"; 
        } 
    } 
    return web; 
}

A mon sens il y a dans cette méthode deux choses importantes à ne pas louper :

1- on essai d’abord de récupérer un SPWeb à partir d’un Item du HttpContext nommé “HttpHandlerSPWeb”

2- si cet SPWeb n’est pas présent, on tente de le créer, mais à condition notamment d’avoir un User sur le HttpContext courant. A défaut on recevra une InvalidOperationException.

le SPWeb quand à lui sera crée à partir du SPSite crée lui même à partir d’une méthode SPSiteFromContextNoCache qui au final va chercher une url dans le HttpContext sous l’Item “Microsoft.SharePoint.Administrtion.ContextUri", qui dans notre cas n’est très probablement pas renseignée.

Je vais donc rajouter deux lignes de codes supplémentaire juste après l’ouverture de mon SPWeb pour initialiser correctement le HttpContext:

Pour être sûr que le SPWeb puisse être construit dans le SPContext :

HttpContext.Current.User =  new WindowsPrincipal(WindowsIdentity.GetCurrent());

Tant qu’à faire, ayant déjà un SPWeb sous la main, pour gagner du temps :

HttpContext.Current.Items["HttpHandlerSPWeb"] = web;

Bien sûr cela n’est pas du tout conseillé dans un contexte web, donc à ne PAS faire systématiquement, mais bien dans le cas précis d’une application qui est exécutée sur le serveur, avec une identité “choisie”.

Avec ces 3 lignes de codes, mon application console fonctionne à merveille !

Pour me simplifier un peu la vie, j’ai crée quelques extensions de méthodes :

public static class SPSiteExtensions
{
	public static void EnsureContext(this SPSite site)
	{
	    if (HttpContext.Current == null)
	    {
	        HttpContext.Current = new HttpContext(new HttpRequest("", site.Url, ""), new HttpResponse(new StringWriter()));
	        //en principe suffisant
	        HttpContext.Current.User =  new WindowsPrincipal(WindowsIdentity.GetCurrent());
	    }
	}
}
public static class SPWebExtensions
{
    public static void EnsureContext(this SPWeb web)
    {
        if (HttpContext.Current == null)
        {
            HttpContext.Current = new HttpContext(new HttpRequest("", web.Url, ""), new HttpResponse(new StringWriter()));
            //en principe suffisant
            HttpContext.Current.User =  new WindowsPrincipal(WindowsIdentity.GetCurrent());
            //pour gagner du temps
            HttpContext.Current.Items["HttpHandlerSPWeb"] = web;
        }
    }
    public static SPWeb OpenWeb(this SPSite site,bool loadHttpContext)
    {
        SPWeb w = site.OpenWeb();
        if (w == null) return null;
        w.EnsureContext();
        return w;
    }
}

Et l’utilisation est du coup assez simple :

static void Main(string[] args)
{
    string url = "http://root.paslatek.com/SitePages/testCQWP.aspx";
    using (SPSite site = new SPSite(url))
    {
        //première façon de faire si on va pas plus loin que le SPSite
        site.EnsureContext();
   //ouverture SPWeb avec la metode d'extension
        using (SPWeb web = site.OpenWeb(true))
        {

            //autre manière d'assurer le context avec le SPWeb
            web.EnsureContext();
           ////test 1
            UserProfileManager mana = new UserProfileManager(SPServiceContext.Current, true);
            foreach (UserProfile u in mana)
                Console.WriteLine(u.DisplayName);
            //test 2
            SPFile f = web.GetFile(url);
            var wpMana = f.GetLimitedWebPartManager(System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared);
            foreach (System.Web.UI.WebControls.WebParts.WebPart wp in wpMana.WebParts)
                Console.WriteLine(wp.GetType().ToString());
        }
    }
}

4 – La conclusion

Le SPContext.Current c’est le mal ? Il ne faut pas l’utiliser ?

De manière générale j’ai envie de dire oui, pour vous éviter ce genre de cas tordu où par un enchainement d’appels, à travers un tas de classes, vous arriviez sur un cas identique au mien. En effet dans mon cas, les codes utilisant le UserProfileManager et du SPLimitedWebPartManager étaient dans le un FeatureReceiver, à l’activation de la feature. Ce code à très bien fonctionné tant qu’on activait la feature par l’interface web. Jusqu’au jour où j’ai eu besoin d’utiliser une application console qui parcourais un bon millier de sites et activait la feature en question de manière automatique. E là c’est le drame !

Mais au final de toute façon tout cela ne dépends pas que de vous, puisque comme nous l’avons vu, certains composants de ce, riche, Framework qu’est SharePoint utilisent eux mêmes le SPContext. De plus j’ai rencontré ici deux cas particuliers, mais rien ne dit que vous ne tomberez pas sur un autre problème dont la source est la même sur d’autres webparts par exemple. Donc vous n’y pourrez pas grand chose d’autre que d’utiliser un contournement comme celui que je vous ai proposé dans cet article.

Ce qui est marrant c’est que la documentation MSDN est assez claire sur le sujet, entre autre parce qu'elle dit bien que le SPContext n’a pas de sens dans le cas d’une application console…

Merci aussi à SanDeep pour son article sur le SPLimitedWebPartManager et la création du HttpContext