Edgar Maucourant - Expert / Formateur SharePoint

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

Tag - SharePoint Server 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

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

dimanche 7 août 2011

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

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

samedi 28 mai 2011

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

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

mercredi 11 mai 2011

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

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

jeudi 4 février 2010

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

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