Edgar Maucourant - Expert / Formateur SharePoint

Aller au contenu | Aller au menu | Aller à la recherche

SharePoint 2010

Fil des billets - Fil des commentaires

samedi 19 mai 2012

Erreur lors de la création d'une connexion pour la synchro des profiles

Par Edgar le samedi 19 mai 2012, 10:43

Bonjour à tous,

Imaginons que vous souhaitiez synchroniser votre magasin de profils (User Profile Application ou UPA) avec votre Active Directory (AD), vous allez alors recourir à la création d'une connexion pour synchroniser vos annuaires dans SharePoint via FIM (ForeFront Identity Manager). Cependant au moment de la création de votre connexion vous recevez le message suivant :

err_synch_conn.png

Et le message donné dans les Logs ne vous aidera pas beaucoup plus.

Il existe un nombre important de raisons pour lesquelles vous recevez ce message, en voici quelques unes :

  • Le compte utilisé pour la synchro n'a pas les bons droits
  • Certains affirment que le compte de synchro doit être administrateur de la machine qui fait la synchro (je n'ai pas constaté ce point)
  • Vous n'avez pas appliqué les patchs : KB 2475880 et 2475878
  • Des objets non-conformes sont présents dans votre A.D.

Dans mon cas rien de tout ça n'a fonctionné, heureusement il existe une autre raison bien plus simple : le nom de votre connexion ne respecte pas la convention de nommage !

En effet, après avoir cherché sur le net et testé de nombreuses "solutions" différentes, je me suis rendu compte que le nom de ma connexion contenait un accent et une apostrophe qui sont tous les deux interdits dans le nom de la connexion.

Evidemment, c'est toujours après avoir trouvé la solution que l'on trouve des posts s'y rapportant, comme celui-ci : http://danmyhre.wordpress.com/2011/02/12/error-unable-to-process-create-message/

Bref avant de vous lancer dans des modifications (parfois farfelues) de votre ferme, vérifiez que vos noms de connexion soient simples !

Bon code à tous, Edgar

aucun commentaire aucun rétrolien

vendredi 11 mai 2012

Les 3 règles d'or pour toutes personnes travaillant avec SharePoint

Par Edgar le vendredi 11 mai 2012, 07:53

Bonjour à tous,

Cela fait quelques mois maintenant que je souhaite écrire ce post, le temps m'a manqué, mais aujourd'hui je me lance !

De mes pérégrinations dans le monde magique de SharePoint, j'ai pu au fil du temps établir 3 règles qui me semblent indispensables pour chaque personne travaillant sur cet outil. Il s'agit là bien évidemment d'un sentiment personnel lié à ma propre histoire avec ce produit, cependant j'ai expérimenté ces règles sur plusieurs types de profils lors de mes formations, coaching, etc... et je dois dire qu'elles se révèlent très souvent efficaces !

Ces règles sont valables pour tous profils : expert, consultant, architecte, développeur, administrateur, gestionnaire de sites, commercial, chef de projet, et même l'utilisateur occasionnel ! J'espère qu'elle pourront vous permettre de mieux appréhender cette plate-forme.

Les règles sont classées par ordre d'importance, les explications sont données en suivant :

  • Règle n°1 : Avec SharePoint, ne jamais présumer.
  • Règle n°2 : Avec SharePoint, Google (ou Bing) n'est pas toujours ton ami, ni la MSDN ni le Technet.
  • Règle n°3 : Avec SharePoint, se méfier de ses expériences passées

Voici à présent pour chaque règle, une explication plus détaillée de mon propos.

Règle n°1 : Avec SharePoint, ne jamais présumer

Lorsque l'on débute avec SharePoint, ou lorsque l'on aborde un sujet nouveau (il y en a toujours, même pour les experts), on est tenté de ce dire que telle ou telle action ou fonctionnalité doit agir comme ceci ou comme cela. De mon expérience la plupart des fois où j'ai raisonné ainsi mes présomptions se sont révélées fausses ou partiellement fausses. Je pourrais mettre en cause ma manière de raisonner ou mes capacités intellectuelles, mais d'autres ont eu le même résultat que moi, peut-être sommes-nous tous nuls, mais j'en doute :) Toute personne ayant déjà travaillé avec cet outil sait à quel point la logique utilisée dans SharePoint est... floue. Parfois cela est dû à l'organisation interne du produit et en creusant on comprend le pourquoi du problème en surface, parfois on se demande si le produit n'a tout simplement pas été codé avec les pieds... (Au moins en partie).

Règle n°2 : Avec SharePoint, Google (ou Bing) n'est pas toujours ton ami, ni la MSDN ni le Technet.

Internet est une révolution, personne ne le niera, c'est une mine d'or incroyable d'expériences échangées, de bugs remontés, d'explications et d'entraide. Cela a révolutionné notre manière de travailler. Ainsi aujourd'hui n'importe quel informaticien qui rencontre un problème et qui dispose d'Internet à proximité va faire une recherche sur Google (ou Bing) pour trouver une réponse ou au moins un peu d'aide. Sauf que dans le cas de SharePoint ce n'est pas forcément la meilleure idée. On trouve en effet beaucoup de bêtises à son sujet sur Internet, des informations fausses, des informations partielles où l'on a omis la partie problématique de la solution, des méthodes qui relèvent franchement de la bidouille et d'autres qui s'appuient sur des mauvaises pratiques... Même des sources d'information supposées "sûres" ne le sont pas, ainsi la MSDN et le Technet, bien qu'améliorés, ont encore des pages de documentation fausses, ou ambiguës. Il est par exemple possible de rencontrer des articles contradictoires où l'un préconise telle action alors que l'autre indique de ne surtout pas le faire. Ou bien encore, des articles dans lequel les tournures de phrases masquent une difficulté du produit (ex : quid de la sauvegarde à chaude de la base de configuration ?)

Règle n°3 : Avec SharePoint, se méfier de ses expériences passées

SharePoint est un outil complexe, parce que vaste, il couvre un nombre important de fonctionnalités et de cas d'usage. De cette richesse survient un soucis : la multiplicité des cas "similaires" mais pas identiques. Ainsi lorsque l'on réfléchis à un problème sur cet outil, il faut se méfier de ses expériences passées, car ce qui a fonctionné dans tel cas ne fonctionnera pas forcément dans tel autre. Par exemple des fonctions disponibles dans le site de publication, ne le sont pas dans le site d'équipe, pire les comportements diffèrent entre le site vide et le site d'équipe qui sont pourtant basés sur la même définition. De même ce qui fonctionnait en SharePoint 2007, n'est peut être plus valable en SharePoint 2010 ou seulement en partie. Ainsi quand vous développez, ce qui fonctionne sur un site racine peut ne pas fonctionner dans un sous-site, ou dans un site contenu sous un chemin managé. Avant de vous aventurez sur les chemins tortueux du chiffrage SharePoint gardez cela à l'esprit...

J'espère que ces règles pourront vous aider dans votre travail avec cette plate-forme. Il n'existe à mon sens qu'un moyen de pouvoir contourner les problèmes suggérés par ces règles : Tester, tester et retester. Cela peut paraître simpliste et "puriste" mais si vous vous aventurez à parler d'un sujet que vous ne connaissez pas dans SharePoint sans avoir ces règles à l'esprit, vous risque au mieux de vous planter, au pire de vous planter ET de passer pour un vaniteux incompétent ;)

Bon code à tous
Edgar

2 commentaires aucun rétrolien

mardi 21 février 2012

SharePoint, PowerPivot, Datafeed & erreur 401

Par Edgar le mardi 21 février 2012, 13:04

Bonjour à tous,

Dans PowerPivot, vous pouvez utiliser un flux Atom en tant que source de données pour une table. Si vous souhaitez exposer votre fichier PowerPivot dans SharePoint, il est nécessaire de disposer d'un ficheir ".atomsvc" accessible au travers d'un répertoie partagé ou d'une url accessible (par exemple une bibliothèque SharePoint). Si ce fichier n'est pas accessible au service PowerPivot il ne sera alors pas possible de rafraîchir les données du cube PowerPivot.

Le Problème

C'est ici que votre erreur 401 intervient. En effet il est possible que lors du rafraîchissement programmé du cube, l'erreur suivante apparaisse :


Errors in the high-level relational engine. The following exception occurred while the managed IDbConnection interface was being used: The remote server returned an error: (401) Unauthorized.. A connection could not be made to the data source with the DataSourceID of '48ffbe38-adeb-48ae-a20d-b32a99b03ebb', Name of 'List_Name'. An error occurred while processing the 'TableName' table. The operation has been cancelled.

Après avoir vérifié que vous avez accès à la liste indiquée, que votre compte de rafraîchissement (PowerPivotDataRefresh) a accès à la liste, que le compte PowerPivotDataRefresh et vous avez accès aux fichiers ".atomsvc" concernés, vous êtes sur le point de menacer votre serveur de le priver de courant s'il n'optempère pas sur le champ...

La solution

Mais il y a toujours une solution plus douce... En effet si vous avez installé votre instance PowerPivot selon les recommandations Microsoft, vous devriez avoir séparé les comptes de services pour chaque service (hormis l'application de service PowerPivot sur SharePoint qu'il est recommandé de faire tourner avec le compte système de la ferme). Vous devriez donc avoir en plus de votre compte de rafraîchissement des données, un compte pour le moteur "analysis service vertipaq". Un rapide coup d'oeil avec NetMon vous indiquera que c'est le compte de ce service qui nécessite l'accès aux fichier ".atomsvc" et vous envoie une erreur 401 s'il n'a pas les autorisations pour cela.

Donc pour que cette erreur "401" disparaisse n'oubliez pas de donner accès aux fichiers ".atomsvc" au compte exécutant le moteur AS de PowerPivot. Et rebranchez-moi cette prise....

Bon code à tous,
Edgar

aucun commentaire aucun rétrolien

dimanche 11 septembre 2011

Ajouter une PJ à un élément de liste par modèle objet client dans SharePoint 2010

Par Edgar le dimanche 11 septembre 2011, 17:09

Bonjour à tous,

Ceux qui l'ont déjà expérimenté le savent bien, il y a des choses que le modèle objet client de SharePoint 2010 sait faire à merveille et d'autres qui semblent avoir complètement été oubliées, y compris les plus basiques....

Comme vous l'aurez compris au titre de ce post, l'une d'elles est la possibilité d'ajouter une pièce jointe à un élément de liste. Il semble que Microsoft n'est pas envisagé ce cas, ou que pour des raisons obscures ils ne l'aient pas implémenté.

Qu'à cela ne tienne, voici deux méthodes pour les ajouter, une n'est utilisable que si vous avez déjà au moins une pièce jointe attachée à votre élément, l'autre est utilisable tout le temps mais fait référence aux WebServices de SharePoint...


Première méthode :

Cette méthode ne fonctionne que si le répertoire contenant les pièces jointes de l'élément existe déjà, sinon vous recevrez une erreur "409 : Erreur de conflit"

Vous remarquerez au passage que Microsoft n'a toujours pas amélioré son système de message d'erreur. D'un point de vue développeur il ne s'agit pas d'un conflit mais de l'absence du répertoire pour stocker la pièce jointe.

Le seul moyen que ce répertoire existe est que vous ayez ajouté une ou plusieurs pièces jointes à votre élément, soit par l'interface utilisateur, soit par le deuxième méthode ci-dessous.

Ne cherchez pas à créer ce répertoire, j'ai testé toutes les méthodes que j'ai pu trouvé sur Internet et aucune ne fonctionne pour créer un sous-répertoire dans le répertoire "Attachments" de la liste. Il semble que ce soit un comportement confirmé par Microsoft...


string uploadLocation = string.Format("{0}/Lists/{1}/Attachments/{2}/{3}", webName, listName, itemId, Path.GetFileName(fileName));
Microsoft.SharePoint.Client.File.SaveBinaryDirect(clientContext, uploadLocation, fileStream, true);

Dans ce code :

  • webName est le nom (url) du site Web,
  • listName est le nom (url) de la liste,
  • itemId est l'Id (int) de l"élément sur lequel ajouter la pièce jointe,
  • filename est le nom de la pièce jointe,
  • clientContext représente le context client pour le site web contenant la liste,
  • enfin fileStream correspond au contenu du fichier représenté sous forme de stream.

Deuxième méthode :

Cette méthode fonctionne à tous les coups mais nécessite de faire une référence web au webservice de liste de SharePoint.


ListsWebService.Lists listsWS = new ListsWebService.Lists();
listsWS.UseDefaultCredentials = true;
byte[] buffer = new byte[fileStream.Length];
fileStream.Read(buffer,0,(int)fileStream.Length);
fileStream.Close();
listsWS.AddAttachment(listName, itemId.ToString(), fileName, buffer);

Dans ce code :

  • ListsWebService et le nom de la classe proxy vers le webservice de listes de SharePoint (http://urldevotresite/_vti_bin/lists.asmx),
  • fileStream représente le contenu de la pièce jointe sous forme de Stream,
  • listName est le nom de la liste,
  • enfin itemId correspond à l'ID (int) du listitem auquel ajouter la pièce jointe.

Bonus :

Aller parce que je suis sympa (les fleurs sont pas chers en ce moment), je vous donne la méthode complète pour ajouter l'élément de liste et la première pièce jointe. La petite difficulté vient du fait que lors de l'ajout de l'élément à la liste, l'ID de celui n'est pas connu et qu'il est nécessaire de le recharger ensuite pour le connaître.


using (ClientContext clientContext = new ClientContext(siteUrl))
{
   var list = clientContext.Web.Lists.GetByTitle(listName);
   clientContext.Load(list);
   ListItemCreationInformation itemInformation = null;
   ListItem listItem = list.AddItem(itemInformation);
   listItem["Nom"] = Nom;
   listItem["Prenom"] = Prenom;
   listItem["email"] = Email;
   listItem.Update();
   clientContext.ExecuteQuery();
   CamlQuery query = new CamlQuery();
   query.ViewXml = @"
         <Query>
            <Where>
               <And>
                  <And>
                     <Eq>
                        <FieldRef name="Nom" />
                        <Value type="Text">" + Nom + @"</Value>
                     </Eq>
                     <Eq>
                        <FieldRef name="Prenom" />
                        <Value type="Text">" + Prenom + @"</Value>
                     </Eq>
                  </And>
                  <Eq>
                     <FieldRef name="email" />
                     <Value type="Text">" + Email+ @"</Value>
                  </Eq>
               </And>
            </Where>
         </Query>
      </View>";
   var refreshedItem = list.GetItems(query);
   clientContext.Load(refreshedItem);
   clientContext.ExecuteQuery();
   if (refreshedItem.Count != 1)
   {
      // TODO Manage Error
   }
   if (!string.IsNullOrEmpty(fileName) && fileStream.Length > 0)
      {
         ListsWebService.Lists listsWS = new ListsWebService.Lists();
         listsWS.UseDefaultCredentials = true;
         byte[] buffer = new byte[fileStream.Length];
         fileStream.Read(buf,0,(int)fileStream.Length);
         fileStream.Close();
         listsWS.AddAttachment(listName, refreshedItem[0].Id.ToString(), fileName, buffer);
      }
}


Bon code à tous ! Edgar

aucun commentaire aucun rétrolien

dimanche 7 août 2011

SharePoint 2007&2010 : Limite de taille de fichier qui ne fonctionne pas en mode explorateur ?

Par Edgar le dimanche 7 août 2011, 17:45

Bonjour à tous,

Vous est-il déjà arrivé de sombrer lentement dans la folie à l'utilisation de SharePoint ? (Si vous répondez non c'est que vous ne l'utilisez pas depuis assez longtemps :p).

Cela pourrait bien vous arriver si un jour vous modifier la taille maximum d'un fichier pouvant être téléchargé dans SharePoint (au niveau de la Web Application) mais que ce comportement ne semble pas être pris en compte lorsque vous travaillez en mode Explorateur... Après avoir vérifié la configuration de votre SharePoint maintes fois, vous commencez à vous demandez si la vie vaut encore la peine d'être vécue... Quand tout à coup, vous avez l'éclair de génie (ouais bon il aura fallut du temps mais saluons tout de même votre pugnacité) : Si le problème ne vient pas du serveur c'est qu'il vient du client !

Eurêka !

En effet, le WebClient notamment utilisé par l'explorateur client en mode WebDav limite par défaut les fichiers transférable à environ 50 000 000 Bytes soit approximativement 47 Mo. Pour modifier cela il faut depuis l'ordinateur utilisant le mode explorateur (et non le serveur), modifier une clé de registre pour augmenter la taille maximum supportée. Pour cela :

  • Ouvrir Regedit
  • Aller dans le dossier : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
  • Faire un clic droit sur le fichier : FileSizeLimitInBytes
  • Passer en mode décimal et saisir votre valeur en octects ! (Valeur Max : 4294967295 soit 4 Go).
  • Valider votre saisie et fermer Regedit
  • Redémarrer le service WebClient (en utilisant la console de services Windows)
  • Fermer puis réouvrir tout explorateur Windows

Et voilà vous pouvez à présent transférer des fichiers de la taille maximum indiquée ou de celle fixée dans SharePoint (suivant celle qui est la plus petite).

Bon code à tous

Edgar

aucun commentaire aucun rétrolien

samedi 28 mai 2011

SharePoint 2010 & DPM 2010 : Pourquoi je ne vois pas SP dans la console ?

Par Edgar le samedi 28 mai 2011, 21:05

Bonjour à tous,

Tout d'abord,

DPM c'est quoi ? (sautez ce passage si vous savez ;))

Quiconque souhaite sauvegarder son système SharePoint doit nécessaire passer par un outil externe, les possibilités de sauvegarde intégrées à l'outil n'étant vraiment pas assez fiables. Il existe plusieurs outils intéressants et parmi ceux-là Microsoft fournit même son propre outil : Data Protection Manager dit DPM. Ce n'est pas un outil de sauvegarde dédiée à SharePoint mais plutôt une solution de sauvegarde générale capable de sauvegarder des serveurs, des postes clients, des VMs Hyper-V, Exchange, SQL Server, et SharePoint (entre autres). Nous en somme à la version 2010, et c'est de cet outil et d'un problème de configuration dont je vais vous parler à présent.

Quel est le problème ?

Lorsque vous installez le client DPM sur un serveur SharePoint afin de procéder à sa sauvegarde, vous avez un certain nombre d'étapes à réaliser (je ne vais pas les donner ici, de nombreux tutoriaux sont disponibles). Lorsque tout se passe bien, vous devez apercevoir dans la console DPM, sur au moins un des serveurs, un onglet SharePoint vous permettant de sauvegarder celui-ci. Cependant il arrive que cet onglet n'apparaisse pas, vous empêchant ainsi de pouvoir sauvegarder SharePoint. Le plupart du temps il s'agit du service VSS (Virtual Shadow Service) qui n'est pas complètement opérationnel sur le serveur à sauvegarder (bien que souvent démarré).

Quelles sont les causes ?

Les causes peuvent être multiples mais voici l'une des plus vicieuses que j'ai vue (car totalement non documentée). Parmi les services de SharePoint Server (donc pas foundation ni wss) il existe deux services de recherche, le service de recherche SharePoint et le service de recherche d'aide SharePoint (appelée également recherche SharePoint Foundation ou WSS). La recherche d'aide comme son nom l'indique n'est utilisée que dans la fenêtre d'aide de SharePoint. Pour toutes les autres recherches (sur SharePoint Server) c'est le service de recherche SharePoint qui est utilisé. Cette recherche d'aide peut être démarrée sur plus d'un serveur, et c'est cela qui pose problème pour DPM. Visiblement si vous démarrez le service de recherche d'aide sur plus d'un serveur, le service VSS de SharePoint se mélange les pinceaux et ne s'enregistre pas en tant que "VSS Writer" (nécessaire pour que DPM puisse savoir quel type de sauvegarde sont possibles sur ce serveur). Bien évidemment aucun message d'erreur, ni aucune indication ne vous ai donné, le service VSS de SharePoint démarre sans problème mais il ne s'enregistre pas, ce qui implique que DPM ne le "voit" pas et n'affiche pas la possibilité de sauvegarder SharePoint.

A titre d'information voici les autres causes possibles que je ne détaille pas car on trouve sur internet plusieurs articles à leur sujet :

  • Absence de configuration du service SharePoint (ConfigureSharePoint.exe -EnableSharePointProtection),
  • Service SharePoint VSS non enregistré correctement (stsadm -o enablewsswriter, atention c'est bien écrit wss et non vss),
  • Service SharePoint VSS Writer non démarré,
  • Compte exécutant VSS incorrect (défini par ConfigureSharePoint.exe).
Il en existe sûrement d'autres mais celles-ci sont les plus communes.

Comment résoudre le problème décrit ?

La résolution du problème est simple : n'activez le service de recherche d'aide que sur un seul serveur de la ferme, idéalement le serveur d'application qui héberge l'admin centrale comme c'est le cas dans la plupart des fermes multi-serveurs. Pensez à redémarrer le service SharePoint VSS Writer après cette modif et tout devrait rentrer dans l'ordre. Le service de recherche d'aide étant en général peu sollicité dans une ferme, l'avoir sur un seul serveur ne devrait pas être (trop) gênant.

Je n'ai testé cette manip que sur un environnement SharePoint 2010, je ne sais pas si le problème était le même avec MOSS 2007, mais il est probable que oui, si quelqu'un à l'info je suis preneur ;)

Bon code à tous,
Edgar

4 commentaires aucun rétrolien

mercredi 11 mai 2011

SharePoint 2010 et Windows Server 2008 R2 SP1 : Attention [MAJ 28/05/2011 : Pb résolu]

Par Edgar le mercredi 11 mai 2011, 09:24

Bonjour,

Mise à jour du 28/05/2011 : Problème résolu, Cf. en bas de l'article pour le détail et la résolution


Comme vous l'avez peut-être remarqué je n'ai plus bloggué depuis quelques temps, ce ne sont pourtant pas les sujets qui manquent mais le temps pour les traiter avec qualité (enfin je l'espère ;). Le problème ci-dessous est assez important pour que je le poste malgré ma faible investigation sur la résolution possible.

Chez un des mes clients suite à l'installation du SP1 de Windows Server 2008 R2, sur un environnement multiserveurs (2 frontaux virtualisés), nous avons constaté des problèmes qui sont résumés ci-dessous :

  • Le service NLB ne fonctionne plus (pb déjà identifié par les équipe de TMG, mais qui visiblement s'applique aussi sans ce produit). Le Workaround est d'arrêter puis redémarrer le service sur chaque frontal (un reboot du serveur ne corrige pas le problème) : "net stop wlbs" puis "net start wlbs" (attention de ne pas faire cette manip en Terminal server sous peine de se couper une patte et de ne plus pouvoir accéder à la machine...)
  • La réplication des index du serveur d'indexation vers les serveurs de requête (query) ne s'opére plus, en cause un décryptage des tickets Kerberos qui foire et qui empêche l'authentification entre les services SharePoint. Le Workaround a été d'installer le rôle de requête sur le serveur d'indexation et de couper le rôle de requête sur tous les autres serveurs.
  • Excel Services ne répond plus entre machine, problème visiblement lié lui aussi à l'authentification Kerberos entre service (WCF). Le workaround a été de couper Excel Services sur l'un des noeuds et de ne le laisser que sur un seul (pourquoi cela fonctionne avec un seul noeud, reste un mystère).

Ma recommandation est donc de ne pas installer le SP1 de Windows Server 2008 R2 sur un environnement SharePoint 2010 pour le moment tant que ces points ne seront pas réglés. Je n'ai pas testé sur d'autres fermes, ni sur un environnement MOSS 2007. Il est cependant problable que le problème NLB soit le même pour les autres problème rien n'est sûr. Nous avons ouvert un call chez MS pour élucider ces problèmes, et vérifier que le SP1 est bien en cause. Si je trouve des meilleurs workarounds ou que le problème peut-être résolu je vous tiendrai au courant.

Mise à jour du 28/05/2011 : Le problème venait d'une mauvaise configuration des cartes réseaux sur la partie IPV6 qui ne posait aucun problème avant le SP1 mais qui suite à l'installation de celui-ci provoquait des erreurs de déchiffrement des ticket Kerberos. Ces problèmes de ticket Kerberos étaient à l'origine du problème de communication entre les noeuds et donc entre les différents service SharePoint.

Résolution : nous avions pensé que la couche IPv6 des cartes réseaux serait désactivée en décochant ce protocole dans les propriétés de la carte réseau, mais ce n'était pas suffisant et a amené la configuration réseau dans un mode non supporté par MS. Même si vous ne souhaitez pas faire d'IPv6 il est préférable de laisser ce protocole actif car de nombreux services Windows reposent sur celui-ci en priorité. Notre action a donc été de recocher le protocole IPv6 sur toutes les cartes réseaux et de forcer Windows à utiliser IPv4 en priorité en enregistrant la clé de registre "DisabledComponents" d'IPv6 à la valeur 0x20 (plus d'infos là : http://support.microsoft.com/kb/929852/en-US, attention l'article anglais contient plus de "fix-it" que sa traduction française automatique.). Après un redémarrage, nous avons constasté que tous les services fonctionnaient correctement, et nous avons pu répartir à nouveau nos services SharePoint entre les différents serveurs de la ferme.

J'espère que ceci vous permettra d'éviter une rupture de service sur votre infrastructure, ce problème nous a montré qu'il est toujours important de bien se renseigner sur l'action d'une case à cocher qui peut paraître anodine mais à complètement mis notre ferme K.O., IPv6 : 1, Edgar : 0 ;)

Bon code à tous,
Edgar

aucun commentaire aucun rétrolien

jeudi 4 février 2010

SP2010 : Assistant de configuration ? Pas besoin j'suis un pro ! A moins que...

Par Edgar le jeudi 4 février 2010, 16:18

Bonjour à tous,

Si vous êtes comme moi et que vous aimez bien vous passer d'assistant pour mettre en place les choses vous-même, vous serez sûrement confronté à un problème avec l'installation de SharePoint Server 2010.

En effet une fois l'installation de SharePoint terminée (elle ressemble comme deux gouttes d'eau à celle de MOSS 2007), il reste encore à paramètrer la ferme, et là c'est plus du tout pareil qu'en version 2007. Heureusement Microsoft a mis en place un nouvel assistant (rien à voir avec l'assistant de configuration lancé pour créer la ferme qui existe toujours d'ailleurs). Cet assistant vous aidera à paramétrer et déployer les services d'applications dans votre ferme.

Sauf que moi je voulais les déployer à la main pour bien comprendre chacun d'eux et leur dépendance, et là c'est le drame... (ouais j'aime bien l"effet mélodramatique pour encourager à lire la suite...)

Lire la suite...

aucun commentaire aucun rétrolien