Edgar Maucourant - Expert / Formateur SharePoint

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

Tag - Administration

Fil des billets - Fil des commentaires

dimanche 4 mars 2012

SharePoint 2007 (et 2010 ?) : suppression d'un serveur de BDD impossible

Bonjour à tous,

Imaginons que vous n'ayez pas installé votre ferme SharePoint selon les bonnes pratiques, et qu'au lieu d'utiliser un alias SQL Server vous ayez directement saisi le nom du serveur pour la création des services (c'est ballot mais c'est courant...).

Imaginons maintenant que vous souhaitiez refaire les choses bien et que vous recréiez les services avec un alias (c'est un bon consultant ça ! oh oui un bon consultant...).

Il est probable qu'ensuite vous souhaitiez supprimer le serveur de BDD référencé dans la section "Servers in farm".

Sage décision, le ménage ça fait toujours du bien (ma femme m'a obligé à mettre cette phrase...), cependant lorsque vous cliquez pour supprimer le serveur vous obtenez le message suivant :


An object in the SharePoint administrative framework, "SPDatabaseServiceInstance Name=NOMINSTANCE Parent=SPServer Name=NOMSERVEUR", could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objects are as follows :

Grosso modo, il existe des objets dépendant de celui-ci, et SharePoint ne peut pas le supprimer. Cependant la section listant les objets concernée est vide !! (Bizarre ça ne m'étonne même plus, je dois être trop habitué à SharePoint...)

Après un rapide tour sur Internet, vous trouvez un certain nombre de posts qui vous encouragent à aller faire une requête sur la base de données pour voir les objets dépendants et à les supprimer, par exemple : http://www.mylifeinaminute.com/2008/07/23/manually-removing-servers-in-moss-2007/

Pas de chance, cette requête ne retourne rien... On aurait pu s'en douter puisque c'est sûrement la même requête qui a été utilisée dans le message d'erreur ci-dessus.

En allant un peu plus loin vous pourriez tomber sur un post comme celui-ci : http://www.jeremytaylor.net/2010/01/09/sharepoint-moss-shared-services-ssp-delete-unprovisioning/ qui vous encourage à supprimer directement les objets par l'utilisation de STSADM, ce qui semble plus propre mais revient au même : la suppression d'une ligne directement dans la base. Pas de chance là également car l'exécution de cette commande vous renvoie exactement le même message que précédemment...

Dans votre quête de connaissance, vous continuez à chercher et tombez sur ce post : http://sharepointwillem.blogspot.com/2010_06_01_archive.html. Cette fois-ci on va encore plus loin dans le risque pour modifier temporairement la structure de la base de données SharePoint....(L'aaaaaamour du risque, Jonathan et Jennifer... tout ça, tout ça)


STOP !!!!


Bon honnêtement, là j'ai pas pu, je me suis dit qu'il devait y avoir un autre moyen... Et en regardant les contraintes de clés étrangères que le post précédent expliquait comment faire sauter (tout en disant qu'il ne faut pas le faire :o/), je me suis rendu compte qu'il y avait une autre forme de dépendance plus implicite (parce que non indiquée dans la table "dependencies") : la relation Parent / Enfant. En effet les tables des Objets SharePoint donne pour chaque objet quel est l'id de son parent (dont il dépend donc).

J'ai donc fait une recherche rapide sur les objets dont le parent est mon instance SQL Server (après avoir récupéré son Id), et j'ai trouvé le problème : la base de données du service de recherche d'aide WSS était encore stockée sur cette instance... Après avoir redéployée ma base de données du service de recherche d'aide via mon alias, j'ai pu supprimer ma référence de serveur sans soucis...

Ce cas illustre encore une fois le risque de suivre les actions données sur Internet, surtout si celles-ci vont à l'encontre des bonnes pratiques : on ne doit pas toucher aux bases SharePoint !!! Microsoft ne supporte même pas les requêtes SELECT sur ces bases, il ne s'agit donc pas juste de modifier la base, mais rien que lire les données de cette base en dehors des API SharePoint n'est pas supporté... Notez que pour SharePoint 2010 il me semble avoir lu que MS supporte la lecture, mais toujours pas évidemment l'écriture en direct dans les bases (sauf peut-être celle de logging, à vérifier)


Bon code à tous,
Edgar


Note : les plus perspicaces d'entre-vous se seront rendu compte que ma requête pour retrouver les objets parent n'est donc pas supportée... Gardez cela à l'esprit si vous suivez cette démarche (bon en même temps je ne pense pas que cela gêne quoi que ce soit sur la table Objects...).

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