none
Sites indisponibles après mise en batterie SharePoint RRS feed

  • Question

  • Bonjour à tous,

    Après un déménagement de serveur, un problème persiste sur l'accessibilité de mes sites SharePoint remonté. Je m'explique.

    Dans le cadre du déménagement d'une plateforme SharePoint composée d'un serveur SharePoint et d'un serveur SQL, la solution apportée a été:

    - Détachement offline des bases sur la source et copie sur le serveurs de destination, attachement des bases copiées sur le nouveau serveur.

    - Installation de la nouvelle plateforme Sharepoint sur le nouveau serveur

    - Configuration à une batterie existante en pointant vers le nouveau serveur de DB.

    - Du fait qu'il cherchait son ancien serveur de DB, le fichier host a été modifié afin que ça pointe vers le nouveau serveur.

    - Configuration terminée:

    - Les DB sont remontées

    - Les services SharePoint sont actifs

    - Les sites IIS sont remontés à l'identique sur le nouveau serveur SharePoint.

    Cependant, mes sites sont indisponibles quand je pointe localhost sur le nouveau serveur SharePoint (Erreur 503: service unvailable).

    Est-ce normal ? Comment puis-je rentre mon nouveau serveur actif afin de pouvoir supprimer l'ancien ?

    mardi 14 mai 2013 18:43

Réponses

  • Pour les comptes de services, logiquement ce sont des comptes AD donc normalement les mêmes que la plateforme source, sauf si vous avez décider d'en refaire.

    Vous avez migré votre SharePoint sur une nouvelle ferme, je ne sais pas comment vous accedez à votre SharePoint habituellement mais si vous avez changé l'url il faut la renseigner dans l'alternate access mapping qui se trouve dans l'administration centrale.

    Par défaut vous en avez 2:

    - Votre web app port 80

    - Votre administration centrale.

    Pour le host header, vous le trouverez dans IIS.Vous avez par défaut 2 instances:

    - votre web app sur le port 80

    - Votre administration centrale

    Contrôler que le binding est correct sur votre web app

    Pour l'alias, c'est en effet encore possible mais peu être un peu long, en effet il faut modifier dans tout les services le nom de votre serveur db par votre alias, personnellement je trouve que refaire une BDD de config est plus judicieux et permet d'éviter les erreurs aprés tout le monde peut pas le faire...

    courage,

    valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    mercredi 15 mai 2013 11:06
  • La procédure conseillée était clairement la meilleure. Cependant, le serveur a subi de nombreuses modifications directement dans les fichiers de configuration, rendant son déplacement très difficile voire impossible.

    De ce fait, la solution la plus manuelle a été utilisée. J’ai donc ajouter le serveur à la batterie existante. Ainsi, une ferme complète était disponible comprenant l’ancien et le nouveau serveur. De là, le serveur SQL a été dupliqué par détachement/réattachement des bases et création d’un alias SQL permettant de rediriger les requêtes demandées par le nouveau serveur SP à l’ancien serveur SQL sur le nouveau serveur SQL.

    De là, de nombreux fichiers ont du tout de même être copiés à la main à cause des modifications manuelles des XML. La bonne technique consiste notamment a bien activé le verbose en cas d’erreur sur les pages Web et à chaque nouvelle erreur trouver une solution (fichiers manquants, ligne de config à remodifier, etc.)

    Même si j'ai encore parfois des problèmes à cause de ces configs manuelles (service de recherche qui ne remonte pas)

    La mise en production consistera à simplement débranché les anciens serveurs après avoir redétaché et réattaché une nouvelle fois les bases.

    Dans tous, les cas merci beaucoup pour ces précieuses informations qui m’ont fait largement progresser dans ce milieu quelque peu obscure qu’est celui de SharePoint.

    mercredi 29 mai 2013 08:19

Toutes les réponses

  • Bonjour à vous,

    Personnellement la procédure que vous avez suivi pour votre déménagement n'est pas la meilleure mais chose faites je vais essayer de vous aider :)

    Premiére chose:

    - Service IIS bien actif ?

    - Services Sharepoint Bien actifs avec les bons compte de services ?

    - des erreurs dans les logs sharepoint ? event viewer ?

    - alternate access mapping bien configuré ?

    - host header correct ?

    - pourquoi pour votre serveur de DB vous n'avez pas plutôt fait un alias ? cela permet de ne pas avoir ce soucis de pointage vers un ancien serveur.

    Valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    mercredi 15 mai 2013 08:55
  • Je sais que ce n'est pas la meilleure solution, malheureusement toutes les autres méthodes ont échouées (backup-restore powershell, réattachement des bases de contenu après installation vierge d'un sharepoint, etc.)

    - Service IIS bien actif ? Oui

    - Services Sharepoint Bien actifs avec les bons compte de services ? Ils sont actifs, cependant doivent-ils être démarrés avec de nouveau compte ou avec les mêmes comptes que ceux de la plateforme source ?

    - des erreurs dans les logs sharepoint ? event viewer ? Je regarde ça

    - alternate access mapping bien configuré ? Non, c'est à dire ?

    - host header correct ? Rien de modifié, où celà se situe t'il ?

    - pourquoi pour votre serveur de DB vous n'avez pas plutôt fait un alias ? cela permet de ne pas avoir ce soucis de pointage vers un ancien serveur. Oui cela pourrait être une meilleure solution, c'est toujours possible non ?

    mercredi 15 mai 2013 10:19
  • Pour les comptes de services, logiquement ce sont des comptes AD donc normalement les mêmes que la plateforme source, sauf si vous avez décider d'en refaire.

    Vous avez migré votre SharePoint sur une nouvelle ferme, je ne sais pas comment vous accedez à votre SharePoint habituellement mais si vous avez changé l'url il faut la renseigner dans l'alternate access mapping qui se trouve dans l'administration centrale.

    Par défaut vous en avez 2:

    - Votre web app port 80

    - Votre administration centrale.

    Pour le host header, vous le trouverez dans IIS.Vous avez par défaut 2 instances:

    - votre web app sur le port 80

    - Votre administration centrale

    Contrôler que le binding est correct sur votre web app

    Pour l'alias, c'est en effet encore possible mais peu être un peu long, en effet il faut modifier dans tout les services le nom de votre serveur db par votre alias, personnellement je trouve que refaire une BDD de config est plus judicieux et permet d'éviter les erreurs aprés tout le monde peut pas le faire...

    courage,

    valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeotwitter

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    mercredi 15 mai 2013 11:06
  • Merci pour votre réponse,

    Pour le moment la production est basée sur l'ancien serveur toujours accessible.

    à terme lors de la bascule il sera nécessaire que le nouveau soit disponible à la place de ce dernier. Je n'ai actuellement changé aucune URL et les sites sont tous disponibles par leur ancienne URL.

    Si j'ai bien compris, lors de la mise en production du nouveau serveur il faudra modifier "l'alternate access mapping" dans SharePoint ainsi que le Host Header ? Aucun paramétrage n'est nécessaire dans IIS ?

    Pour l'alias, je n'ai pour le moment rien changé dans l'admin SharePoint. Mais ayant dupliqué les bases de données, j'ai redirigé le nom de l'ancien serveur vers l'IP du nouveau puisque dans la config' il est essaye d'accéder à l'ancien serveur. Donc pour forcer l'utilisation du nouveau j'ai rajouté une règle redirigeant quoi qu'il arrive les requêtes SQL vers le nouveau serveur.


    • Modifié Chesmet mercredi 15 mai 2013 12:44
    mercredi 15 mai 2013 12:38
  • Oui en effet, il faudra modifier le alternate access mapping et le host header dans IIS si besoin.

    Oui effectivement votre méthode pour les requêtes SQL pas très clean :/

    Aprés je sais pas si vous en avez la possibilité mais je vous conseil ceci:

    - faire votre alias pour votre serveur BDD

    - refaire votre bdd de config sur votre nouvelle ferme avec cet alias.

    Vous aurez ainsi pas de probléme dans l'avenir sur des déplacements ou migration de serveur.


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeo  twitter  linkedin

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    mercredi 15 mai 2013 13:26
  • Mais si je refais ma base de données de config, comment dois-je m'y prendre ? Je la supprime et SharePoint va me demander de repartir de zéro dans ce cas ?

    Comment être sur de posséder la même configuration (certes adaptée) que l'ancien serveur ?

    Mon but premier est d'avoir quelque chose fonctionnel pour le nouveau serveur... L'ancien étant amené à être décomissionné.

    mercredi 15 mai 2013 16:09
  • Oui en effet vous allez repartir sur une nouvelle ferme.

    L'autre solution qui vous permettra peut être justement de ne pas refaire votre config et gagner du temps peut être de faire votre alias puis de changer le paramétrage de tous vos services pour pointer vers votre alias et pas votre serveur sql directement.

    un peu de doc à ce sujet:http://technet.microsoft.com/en-us/library/ff851878.aspx

    Valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeo  twitter  linkedin

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator

    jeudi 16 mai 2013 07:33
  • La procédure conseillée était clairement la meilleure. Cependant, le serveur a subi de nombreuses modifications directement dans les fichiers de configuration, rendant son déplacement très difficile voire impossible.

    De ce fait, la solution la plus manuelle a été utilisée. J’ai donc ajouter le serveur à la batterie existante. Ainsi, une ferme complète était disponible comprenant l’ancien et le nouveau serveur. De là, le serveur SQL a été dupliqué par détachement/réattachement des bases et création d’un alias SQL permettant de rediriger les requêtes demandées par le nouveau serveur SP à l’ancien serveur SQL sur le nouveau serveur SQL.

    De là, de nombreux fichiers ont du tout de même être copiés à la main à cause des modifications manuelles des XML. La bonne technique consiste notamment a bien activé le verbose en cas d’erreur sur les pages Web et à chaque nouvelle erreur trouver une solution (fichiers manquants, ligne de config à remodifier, etc.)

    Même si j'ai encore parfois des problèmes à cause de ces configs manuelles (service de recherche qui ne remonte pas)

    La mise en production consistera à simplement débranché les anciens serveurs après avoir redétaché et réattaché une nouvelle fois les bases.

    Dans tous, les cas merci beaucoup pour ces précieuses informations qui m’ont fait largement progresser dans ce milieu quelque peu obscure qu’est celui de SharePoint.

    mercredi 29 mai 2013 08:19
  • Parfait,

    Bonne continuation à vous!

    Valentin


    Mon blog sur SharePoint
    Site du Groupe AFG
    viadeo  twitter  linkedin

    MCP | Microsoft Certified Professional - SharePoint 2010 Administrator & Developer Certified

    mercredi 29 mai 2013 09:44