locked
Articles publiés dans le cadre de l’ ‘’Appel à la contribution! Publiez un tip ou un petit tutorial (comment faire) sur la technologie que vous connaissez le mieux !’’ dans la période 15.03.2010 – 15.04.2010

    General discussion

  • Articles publiés dans le cadre de l’ ‘’Appel à la contribution! Publiez un tip ou un petit tutorial (comment faire) sur la technologie que vous connaissez le mieux !’’ dans la période 15.03.2010 – 15.04.2010

    Bonjour,

    Je vous remercie à tous ceux qui ont publié des articles, mais aussi à ceux qui ont voté comme utiles ces articles J

    Vous trouverez en bas les articles publiés dans la période 15.03.2010-15.04.2010 sur la technologie : SharePoint Services.

    L’article avec le plus de votes utiles est  celui de Steve B_ : « Comment faire une page d'association de Workflow»

    Cordialement,

    Roxana

    Monday, March 15, 2010 8:30 AM
    Owner

All replies

  • Bon, on espère que cela passe comme ça, sinon, je compte sur Roxana ;)


    Paramétrer le  « People Picker » pour plusieurs domaines Active Directory

    Attention : ce tuto ne couvre « que » le « People Picker » utilisé dans le cadre de l’authentification Windows intégrée, voire l’authentification « Basique ».
    Par défaut, le « People Picker » de SharePoint ne connait que le domaine Active Directory dans lequel le serveur a été déployé. Pour étendre le « People Picker » à d’autres domaines ou forêts, voici comment procéder.

    Collecter les informations sur le ou les domaines/forêts

    - Leur nom DNS (par exemple : mondom.local ou masociete.infra.local)
    - La présence d’une relation d’approbation : au moins unidirectionnel (le domaine auquel SharePoint appartient doit approuver le domaine ou se trouve les utilisateurs) voire bidirectionnel (cela simplifie la configuration). Dans le cas d’un domaine, il peut être de type « externe », dans le cas d’une forêt, il faut impérativement qu’il soit de type « Forêt ».
    - Optionnel : Un compte de ce domaine/cette forêt ayant suffisamment de permissions que pour lire tous les objets de type utilisateurs et groupes (c’est normalement le cas par défaut). Ce compte n’est nécessaire que dans le cas d’une relation d’approbation unidirectionnel
    - L’URL de l’application Web SharePoint sur laquelle le « People Picker » doit être paramétré (en effet, le paramétrage se fait par application)

    Paramétrer l’application web en utilisant la commande STSADM (je sais, ça fait vieillot par rapport à SP2010 ;)

    Exemples de base:

    Commande: STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local” –url http://monappli.net
    Explication: dans ce cas, le “People Picker” consultera toute la forêt « avatar.local », qu’elle possède des sous-domaines ou non.

    Commande: STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:eau.avatar.local” –url http://monappli.net
    Explication: ici, le “People Picker” consultera uniquement le domaine « eau.avatar.local ».

    Exemple de Combinaisons

    Commande: STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:eau.avatar.local;domain:feu.avatar.local” –url http://monappli.net
    Explication: en séparant chaque domaine ou forêt par un point-virgule, on peut paramétrer plusieurs combinaisons

    Exemple en cas de relation d’approbation unidirectionnelle

    Etant donné que dans ce cas, il faut fournir un utilisateur/mot-de-passe pour se connecter à l’AD distant, il faut le spécifier dans la commande et par conséquent, le stocker dans la configuration de SharePoint. Afin de le stocker de manière sécurisée, il est tout d’abord nécessaire de paramétrer une clé qui sera utilisée pour le chiffrement de ces infos. Attention, il faut répéter la commande sur chaque serveur sur lequel le « people picker » tournera.

    STSADM –o setapppassword -password MaClé

    Ensuite, on peut enfin paramétrer le “People Picker”

    Commande: STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local,AVATAR\UTILISATEUR,MOTDEPASSE” –url http://monappli.net
    Explication: l’AD-ci, l’utilisateur et le mot de passé sont séparés par des virgules

    Commande: STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:feu.avatar.local,FEU\UTILISATEUR,MOTDEPASSE; domain:eau.avatar.local,EAU\UTILISATEUR,MOTDEPASSE;” –url http://monappli.net
    Explication : ici, on combine deux domaines pour lesquels il faut fournir des utilisateurs/mots de passe explicitement pour s’y connecter. On sépare la configuration de
    chaque domaine par un point-virgule et à l’intérieure de cette configuration, les éléments sont séparés par des virgules.

    Mise en application de la configuration
    Pour mettre en place de manière effective la configuration il faut effectuer un IISRESET sur chaque serveur SharePoint sur lequel le « People Picker » sera utilisé

    Quelques informations supplémentaires :
    - La commande STSADM : http://technet.microsoft.com/fr-fr/library/cc263460.aspx

    Les articles en anglais sur mon blog :
    - http://www.marc-antho-etc.net/blog/post/2009/05/13/SharePoint-People-Picker-and-Active-Directory-Part-1.aspx
    - http://www.marc-antho-etc.net/blog/post/2009/05/13/SharePoint-People-Picker-and-Active-Directory-Part-2.aspx
    - Partie 3 à venir....


    --- Marc Lognoul [MCSE, MCTS, MVP] Heureux celui qui a pu pénétrer les causes secrètes des choses Happy is the one who could enter the secret causes of things Blog EN: http://www.marc-antho-etc.net/blog/ Blog FR: http://www.marc-antho-etc.net/blogfr/
    Monday, March 15, 2010 10:05 AM
    Moderator
  • RunWithElevatedPrivileges

    Exécution d'instruction dans un contexte d'exécution administrateur... Attention au contexte


    Un site SharePoint est généralement prévu pour accueillir un grand nombre de visiteurs. Ces derniers n'ont pas tous les mêmes droits. En effet, certains n'ont que le strict minimum alors que d'autres personnes possèdent un statut d'administrateur qui leur confère tous les droits. Cela ne pose généralement pas de problème sauf lorsque des développements personnels sont réalisés.

    Effectivement, certaines opérations requièrent des droits administrateurs pour pouvoir être exécutées. Ainsi, lorsqu'elles le sont via le compte d'un utilisateur avec des droits peu élevés, cela pose problème provoquant généralement le plantage de votre feature . Nous allons démontrer cela grâce à un event handler que nous ne développerons pas en détails ici car ce n'est pas le sujet.

    Créez donc un event handler basique et surchargez la fonction ItemAdded de cette manière :


    properties.ListItem.BreakRoleInheritance(true);  

    Cette ligne de code va simplement vous permettre de casser l'héritage des permissions de l'élément par rapport à la liste dans laquelle il est créé. Compilez et déployez ce code.

    Connectez vous maintenant à votre site SharePoint en tant qu'administrateur et placez vous sur une custom list . Ajoutez-y un élément. Une fois ceci fait, cliquez sur la petite flèche apparaissant quand vous survolez le titre de l'élément avec votre souris et choisissez Manage Permission (Gérer les permissions). Si vous regardez bien, il y a des cases à cocher devant le nom des groupes, cela signifie que l'héritage a bien été cassé.

    Connectez-vous maintenant avec un utilisateur n'ayant pas des droits administrateurs. Si vous tentez la même manipulation, vous remarquerez que l'héritage des permissions n'a pas été cassé. Naturellement, vous allez attacher le code de votre event handler au processus de SharePoint pour voir ce qui se passe et vous obtiendrez certainement ceci :



    L'erreur parle d'elle-même, vous ne possédez pas les droits d'exécuter cette opération. L'astuce consiste alors à utiliser RunWithElevatedPrivileges . Cette fonction marche très bien mais il faut être attentif à la manière de l'utiliser, sinon elle ne sert à rien. Voyez par exemple ce code :


    SPSecurity.RunWithElevatedPrivileges(() => properties.ListItem.BreakRoleInheritance(true));   


    Cette construction est utilisée pour exécuter des instructions dans un contexte de sécurité administrateur. Les instructions exécutées sont en fait à l'intérieur d'un delegate . Ici, nous pouvons raccourcir cela avec une expression lambda. Si vous testez cet exemple, vous remarquerez que rien ne change. Vous n'avez toujours pas les droits de casser l'héritage des permissions de l'élément en tant que simple membre.

    D'une manière générale, on se dit "étrange, pourtant cela s'exécute avec les droits d'administrateurs, cependant, je ne peux toujours pas casser l'héritage". C'est effectivement un bon raisonnement, malheureusement, il est incomplet. Effectivement, le souci dans le code précédent est que vous exécutez une fonction sur un objet qui a été défini en dehors du contexte de sécurité administrateur, en l'occurrence properties.ListItem . Ainsi, étant donné que cet objet a été déclaré en dehors du contexte administrateur (dans les paramètres de la fonction), celui-ci va garder son contexte utilisateur normal et vous n'aurez donc toujours pas les droits de faire l'opération voulue. Voyons maintenant ce code :


    SPSecurity.RunWithElevatedPrivileges(delegate() {  
        using (SPSite site = new SPSite(properties.WebUrl))  
        {  
            using (SPWeb web = site.OpenWeb())  
            {  
                SPList list = web.Lists[properties.ListId];  
                SPListItem item = list.GetItemById(properties.ListItemId);  
      
                item.BreakRoleInheritance(true);  
            }  
        }  
    });   
    


    Cette fois, nous ne pouvons plus utiliser d'expression lambda car il y a plusieurs instructions à exécuter. Si vous exécutez l'event handler avec ce code, vous remarquerez que maintenant, même un utilisateur normal aura le droit de casser l'héritage des permissions de l'élément. Effectivement, l'idée est de récupérer l'élément mais DANS le contexte administrateur. Nous ouvrons donc un nouvel objet SPSite et un nouvel objet SPweb . Ensuite, nous récupérons la référence de la liste grâce à son ID qui est stocké dans la propriété properties.ListId et nous récupérons l'élément grâce à la fonction GetItemById et son ID qui est stocké dans la propriété properties.ListItemId .

    Ici, cela fonctionne car nous récupérons l'élément dans le contexte administrateur. Cela ne pose pas problème d'utiliser les propriétés de l'objet properties pour récupérer cet élément tant que la référence à ce dernier, elle, est bien récupérée dans le contexte administrateur.

    D'autres tutoriels SharePoint 2007 : http://www.areaprog.com/SP2007/
    Tutoriels SharePoint 2010 : http://www.areaprog.com/SP2010/


    http://www.areaprog.com
    Wednesday, March 17, 2010 11:11 AM
  • Tutorial :WSS 3.0, créer simplement une page d’association de Workflow

    Si l’on s’en tient à la document Microsoft sur la création d’une page d’association de Workflow, chaque page devrait faire tout le boulot. Extrait du SDK (rubrique Workflow Association and Initiation Forms ) :

    The workflow developer must program what happens when the administrator submits changes to the form. In general, the custom workflow association form must perform the following actions:

    • Examine the value of the GuidAssoc parameter to determine whether the user is adding a new workflow association or editing an existing workflow association.
    • If the user is adding a new workflow association, call the AddWorkflowAssociation method to create a new workflow association.
    • If the user is editing an existing workflow association, call the UpdateWorkflowAssociation method to update that workflow association.
    • Create the task list for the workflow, if it does not already exist.
    • Use the data collected from the user to set properties of the SPWorkflowAssociation object, as appropriate.
    • Create the workflow history list, if necessary.

    Tout ça est très lourd et doit être reproduit pour chaque page d’association que vous devez créer. Il existe toutefois une solution, probablement non supportée puisque non documentée.

    Avec un petit coup de Reflector, j’ai trouvé que toutes les pages d’association de workflow héritent d’une même classe : Microsoft.SharePoint.ApplicationPages.WrkAssocPage dans l’assembly Microsoft.SharePoint.ApplicationPages.dll . Cette dernière se trouve dans le dossier « %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\CONFIG\BIN « .

    Les classes qui héritent de cette page sont partiellement obfusquées, donc j’ai du tâtonner un peu avant de trouver comment l’utiliser.

    Les avantages que cette page offre sont multiples :

    • récupération automatique des paramètres du workflow (depuis la page AddWrkfl.aspx)
    • gestion des paramètres du postback : chaque postback conserve les valeurs initiales du postback qui vous a conduit sur la page. Sans cela, il aurait fallu déclarer des champs de type HIDDEN pour conserver ses paramètres.
    • et le meilleur pour la fin, toute la création/modification des associations de workflow, incluant la création des listes de tâches / historique de workflow, etc. est gérée par la classe de base.

    Voici un petit tutorial qui explique comment utiliser cette classe.

    Exemple d’une page d’association qui utilise cette classe de base

    Créer le projet

    Pour commencer, nous allons créer un nouveau projet de type Workflow séquentiel (pour l’exemple, ça marcherait également avec un workflow de type State-Machine) :

    On choisi ensuite le site sur lequel on va débugger :

    Vu que l’objectif est d’illustrer la page d’association, choisissons de ne pas associer automatiquement le workflow :

    Le workflow est créé !

    Créer les références

    Si comme moi, vous n’avez que WSS et non MOSS sur votre environnement, il faudra supprimer la référence vers Microsoft.Office.Workflow.Tasks.dll

    Il faudra également supprimer une ligne du fichier Workflow1.cs pour la même raison :

    [csharp]using Microsoft.Office.Workflow.Utility;[/csharp]

    Enfin, toujours pour la même raison (Microsoft n’a pas pensé à ceux qui n’utilisent que WSS 3.0), supprimer du fichier feature.xml les deux lignes :

    [xml]
    ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
    ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver" [/xml]

    Terminez par rajoute la référence vers l’assembly Microsoft.SharePoint.ApplicationPages.dll qui se trouve pour rappel ici : « %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\CONFIG\BIN  »

    Créer la page d’association

    Commençons par ajouter à la racine du projet une classe « Workflow1AssocPage.cs », nous reviendrons dessus tout à l’heure.

    Ajouter à votre projet la structure de dossier 12\Template\Layouts (j’utilise l’extention WSPBuilder pour construire le package de déploiement).

    Dans ce dossier, créer un fichier de type text que vous appellerez Workflow1Assoc.aspx. Je passe par un fichier texte car le template de projet Workflow n’autorise pas l’ajout de page aspx :

    Concevez votre page comme vous le souhaitez, en héritant de la classe précédemment créée. Je préfère pour des raisons d’homogénéité conserver le look&feel SharePoint, donc je vous conseille de partir d’une page existante, ou alors de copier coller le code suivant :

    [html]<%@ Assembly Name="SharePointWorkflow1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=923dfcd42d705cc0" %>

    <%@ Page AutoEventWireup="true" Inherits="SharePointWorkflow1.Workflow1AssocPage, SharePointWorkflow1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=923dfcd42d705cc0" Language="C#" MasterPageFile="~/_layouts/application.master" Title="Choix des validateurs" %>

    <%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register TagPrefix="wssuc" TagName="InputFormSection" Src="/_controltemplates/InputFormSection.ascx" %>
    <%@ Register TagPrefix="wssuc" TagName="InputFormControl" Src="/_controltemplates/InputFormControl.ascx" %>
    <%@ Register TagPrefix="wssuc" TagName="ButtonSection" Src="/_controltemplates/ButtonSection.ascx" %>
    <asp:Content ID="Content1" ContentPlaceHolderID="PlaceHolderPageTitleInTitleArea" runat="server">
    <SharePoint:EncodedLiteral ID="EncodedLiteral1" runat="server" Text="Saisie du message" EncodeMethod=’HtmlEncode’ />
    </asp:Content>
    <asp:Content ID="Content2" runat="server" ContentPlaceHolderID="PlaceHolderMain">
    <table border="0" cellspacing="0" cellpadding="0">
    <wssuc:InputFormSection runat="server" Title="Saisie du message" id="ifsUsers">
    <template_description>Saisissez votre message</template_description>
    <template_inputformcontrols>
    <template_inputformcontrols>
    <tr valign="top">
    <td width=10>&nbsp;</td>
    <td colspan=4>
    <asp:TextBox runat="server" ID="txtMsg" />
    </td>
    </tr>

    </template_inputformcontrols>
    </template_inputformcontrols>
    </wssuc:InputFormSection>
    <wssuc:ButtonSection runat="server">
    <template_buttons>
    <asp:Button UseSubmitBehavior="false"  runat="server" Text="Ok" id="btnSubmit" onclick="btnSubmit_OnClick" />
    </template_buttons>
    </wssuc:ButtonSection>
    </table>
    <SharePoint:FormDigest ID="FormDigest1" runat="server" />
    </asp:Content>

    [/html]

    Pensez à changer votre PublicKeyToken ! (Reflector est votre ami).

    Passons maintenant à la partie code.

    Coder la page d’association

    Ouvrez le fichier Workflow1AssocPage.cs et modifiez le comme suit :

    [csharp]using System;
    using System.Collections.Generic;
    using System.Text;

    namespace SharePointWorkflow1
    {
    public class Workflow1AssocPage : Microsoft.SharePoint.ApplicationPages.WrkAssocPage
    {
    protected override void OnLoad(EventArgs ea)
    {
    base.OnLoad(ea);
    base.AssociationOnLoad(ea);
    base.PreservePostbackParameters();
    }
    }
    }

    [/csharp]

    Tout le secret se situe dans la surcharge de la méthode OnLoad.

    [csharp]base.OnLoad(ea); [/csharp]

    Pour ne pas court-circuiter le fonctionnement de la classe de base.

    [csharp]base.AssociationOnLoad(ea);[/csharp]

    Cette méthode va analyser les paramètres de l’association qui sont envoyées par la page précédente (AddWrkfl.aspx) et dans l’url.

    [csharp]base.PreservePostbackParameters();[/csharp]

    Cette méthode va régénérer les champs de type hidden, pour qu’au fil des PostBack les paramètres soient conservés.

    Ajoutons maintenant la directement using et les identifiants des contrôles de la page :

    [csharp]using System.Web.UI.WebControls;[/csharp]

    [csharp]public class Workflow1AssocPage : Microsoft.SharePoint.ApplicationPages.WrkAssocPage
    {
    protected TextBox txtMsg;
    protected Button btnSubmit;

    [/csharp]

    et enfin l’implémentation du bouton Submit :

    [csharp]protected void btnSubmit_OnClick(object sender, EventArgs e)
    {
    base.m_formData = System.Web.HttpUtility.HtmlEncode(txtMsg.Text);
    base.PerformAssociation();

    string url = base.Web.Lists[new Guid(base.Request.QueryString["List"])].DefaultViewUrl;
    base.Response.Redirect(url);
    }[/csharp]

    Comment faire plus simple ?

    La valeur du champ base.m_formData sera transmise à chaque worfkflow, dans le champ AssociationData de la propriété WorkflowProperties de l’activité OnWorkflowActivated. C’est donc dans ce champ que vous devrez passez toutes les infos utiles au fonctionnement de votre workflow (typique le choix des utilisateurs qui doivent approuver un élément).

    La méthode base.PerformAssociation est la méthode magique qui fait tout :

    • si la liste de tâche n’existe pas, elle est créée
    • si la liste d’historique n’existe pas, elle est créée
    • si c’est une nouvelle association elle est créée
    • si c’est une association qui existe déjà elle est modifiée.

    Modifions maintenant le workflow lui même. Pour l’exemple, je ne ferai que loguer ce qui est passé par la page d’association :

    Ajout d’une activité LogToHistoryActivity :

    Puis bind de la propriété HistoryOutcome de cette activité sur la valeur de la propriété AssociationData :

    Il faut ensuite modifier le fichier Workflow.xml pour indiquer quelle est la page d’association du workflow :

    [xml]<Workflow
    Name="SharePointWorkflow1"
    Description="My SharePoint Workflow"
    Id="02c4f98f-8168-4eb0-bccb-2583a182e65a"
    CodeBesideClass="SharePointWorkflow1.Workflow1"
    CodeBesideAssembly="SharePointWorkflow1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=923dfcd42d705cc0"
    AssociationUrl="_layouts/Workflow1Assoc.aspx">

    [/xml]

    Déployez tout ceci. avez une installation WSPBuilder :

    1. Compiler
    2. Déployer depuis le menu “Deploy” sur le clic droit de la solution
    3. Déployer le contenu du dossier 12 via le menu “WSPBuilder –> Copy to 12 hive”
    4. Recycler le pool d’application “WSPBuilder –> Recycle app pool”

    Vérifions que tout fonctionne :

    Sur votre site SharePoint, vérifier que la feature correspondante est bien activée (feature de collection de site) :

    Sur une liste (ici une bibliothèque de documents), ouvrez les paramètres et choisissez “flux de travail”. Vous devriez voir votre workflow :

    image

    Validez. Vous arrivez comme prévu sur votre page :

    Saisissez un texte puis validez.

    Démarrer ensuite votre flux de travail (en créant un élément, en le démarrant manuellement, tout dépend des choix faits sur la page AddWrkfl.aspx).

    Le message saisi apparait bien !

    Conclusion

    Une étape qui pouvait être assez pénible se trouve maintenant grandement facilitée, car toute la tuyauterie d’association de workflow est gérée pour vous. Cette page n’est pourtant pas documentée… ce qui est dommage. Heureusement que votre serviteur est là :)

    Sunday, March 28, 2010 9:46 PM
  • Petit Condensé de l'installation Automatisée de SharePoint (WSS3 et MOSS2007)

     

    Il existe déjà pas mal d’articles ou de de blogs traitant du sujet il est vrai. Mais ayant beaucoup travaillé pour de nombreux clients sur le sujet, j’avais envie de livrer une approche complète (toutes les étapes, y compris avant et après installation) de manière peu détaillée (lien vers de bonne sources d’informations, détaillées elles) afin de tenir dans un blog sans souffrir d’une longueur rébarbative.

    Dans l’ordre voici les étapes d’une installation complète (sans toutefois tenir compte des dépendances de type comptes techniques, Active Directory, Reverse-proxy etc…)

     

    Les Frameworks .Net

    Le niveau de version des Framework dépend du code qui tournera sur vos applications.

    Attention : il faudra tenir compte des redémarrages éventuels (et très probables).

    Les Frameworks supportes les paramètres d’installation  /q (quiet) /norestart (empêcher le redémarrage automatique si celui-ci est requis).

    N’oubliez pas d’installer les MAJ si nécessaire. Les paramètres sont identiques pour la plupart.

     

    IIS

    Installer IIS est relativement simple, la méthode dépendant de la version choisie :

    Configurer IIS peut se révéler complexe en fonction des éléments que l’on veut paramétrer et de la version utilisée

     

    SQL Server

    L’installation de SQL dépend de la version et du choix au niveau SharePoint

    Standalone : voir « Les Binaires SharePoint »

    Pour paramétrer SQL Server, il faut la plupart du temps recourir à des scripts en Transact-SQL exécutable à partir, par exemple, de SQLCMD (http://msdn.microsoft.com/en-us/library/ms162773.aspx) voir utiliser les SQL Management Objects (http://msdn.microsoft.com/en-us/library/ms162169.aspx et http://msdn.microsoft.com/en-us/library/dd206997.aspx) à travers PowerShell

     

    Les Binaires SharePoint

    L’installation des binaire consiste à installer les composants nécessaires à SharePoint grâce à une série de packages MSI. C’est à ce moment que le type de serveur peut-être spécifié : WFE (frontal) Application ou Standalone (incluant donc SQL Server). C’est également le moment ou la clé d’activation est fournie ainsi que la version exacte de MOSS (Standard ou Enterprise). Attention, la clé fournie prend le pas sur le paramètre.

    Le tout se fait grâce à la commande setup.exe et son fichier d’entrée au format XML : WSS (http://technet.microsoft.com/fr-fr/library/cc288033.aspx), MOSS (http://technet.microsoft.com/fr-fr/library/cc262897.aspx)

    Il ne faut pas oublier d’en faire de même pour la language packs (http://technet.microsoft.com/en-us/library/cc288518.aspx)

    C’est également l’occasion d’incorporer les mises à jour, grâce au répertoire « Updates » (http://technet.microsoft.com/en-us/library/cc261890.aspx)

     

    Créer ou joindre une ferme

    La commande PSCONFIG effectuera les mêmes opérations que l’assistant d’installation avec un avantage : pouvoir spécifier le nom de la base de données de contenu du Central Admin et dès lors éviter l’affreux GUID : http://technet.microsoft.com/fr-fr/library/cc263093.aspx

    C’est également PSCONFIG qui mettra en place l’application Central Admin.

     

    Paramétrage de base

     

    Paramétrage avancé

    Beaucoup d’éléments de configuration (liés aux SSP en particulier) ne sont hélas pas directement accessibles via STSADM en standard. Il vous faudra soit recourir à :

    • Des extensions de STSADM
    • Du développement .Net (applications console par ex.)
    • Des scripts PowerShell s’apparentant à du développement (usage quasi identique des API)

    Toutefois, certains paramètres avancés sont accessibles avec STSADM :

     

    Paramétrage IIS Post-Déploiement de SharePoint

    Une fois SharePoint déployé et paramétrer, la configuration IIS peut être finalisée :

    • Les Applications Pools
    • Les Paramètres spécifiques par Web Application

    Dans les deux cas, les méthodes détaillées plus haut (section IIS) s’avèreront être suffisantes dans la plupart des cas

     

    Gestion de sites et Ajout de contenu

    Pour ajouter du contenu, il est préférable de toujours recourir à l’utilisation des API, soit avec une application soit avec PowerShell :

      

    Active Directory

    Si vous utilisez Kerberos, la commande SETSPN (http://technet.microsoft.com/en-us/library/cc773257(WS.10).aspx) facilitera le paramétrage des Service Principal Names.

     

    Si le déploiement automatisé est un facteur clé de l’industrialisation de votre environnement SharePoint, il convient de le renforcer par un Framework de déploiement afin d’en faciliter la gestion.

    Le Microsoft Deployment Toolkit 2010 (http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx) peut s’avérer d’une aide précieuse. Il existe également des alternatives commerciales.

    Informations additionnelles

     

    C’est tout pour aujourd’hui, à chaque jour suffisant sa Payne, Max!

    Marc

     


    --- Marc Lognoul [MCSE, MCTS, MVP] Heureux celui qui a pu pénétrer les causes secrètes des choses Happy is the one who could enter the secret causes of things Blog EN: http://www.marc-antho-etc.net/blog/ Blog FR: http://www.marc-antho-etc.net/blogfr/
    Wednesday, March 31, 2010 11:21 AM
    Moderator