none
Problème de mappage DNS sur URL de collection de site RRS feed

Réponses

  • Je ne vous comprends pas, c'est simple pourtant...

    Bon, ne vous inquiétez pas, cette question revient souvent, vous n'êtes pas la seule personne à rencontrer des difficultés avec les Alternate Access Mappings.

     

    SharePoint dispose de son propre mécanisme de gestion NLB. Vous remarquez que, lorsque vous créez une web application, SharePoint vous demande l'adresse de load balancing de l'application Web. C'est cette valeur qui est utilisée pour l'Alternate Access Mapping lors de la création de la Web App.

     

    Pour expliciter tout ceci, prenons un exemple :

     

    vous disposez d'un serveur protomoss1. Vous créez une application web sur le port 80. Votre URL de load balancing est alors http://protomoss1:80 (le 80 peut être ignoré, mais c'est la valeur que l'interface de création affiche).

     

    Lorsque vous accédez aux Alternate Access Mappings, vous pouvez constater que votre application dispose d'une URL interne et d'une URL publique. Les deux ont la même valeur : http://protomoss1.

     

    1) Vous souhaitez utiliser un nom un peu plus friendly

     

    Vous souhaitez modifier l'URL qui sera utilisée et visualisée par les utilisateurs de sorte à ce que http://protomoss1 soit remplacé par http://intranet.maboite.com.

    • Il vous faut demander une entrée (ou un alias) DNS pour que intranet.maboite.com redirige vers votre serveur.

    Dès lors, votre site SharePoint n'est plus accessible.

    • Il vous faut ensuite accéder aux Alternate Access Mappings pour modifier l'URL publique. Remplacez là par http://intranet.maboite.com et validez.

    Votre site est de nouveau accessible, mais avec l'adresse http://intranet.maboite.com. Essayez de saisir l'URL http://protomoss1 : Le site fonctionne toujours, mais votre navigateur modifie systématiquement l'URL par http://intranet.maboite.com.

     

    2) Vous ajoutez un (ou des) serveur(s) à votre ferme SharePoint.

     

    Imaginons que vous ajoutiez un serveur nommé protomoss2.

    Par défaut, l'accès à http://intranet.maboite.com ne vous redirige que sur protomoss1. Dès lors que vous ajoutez une seconde URL interne, SharePoint est en mesure de gérer les accès sur les deux serveurs. Dans un tel cas de figure, vous auriez intérêt à utiliser une solution de NLB (Cluster Windows, Big-Ip...) et associer l'URL publique à une entrée du NLB (donc définir http://intranet.maboite.com au niveau de la solution NLB, sans la mapper aux serveurs SharePoint). http://intranet.maboite.com reste donc en URL publique, et les URL protomoss1 et protomoss2 en URL internes.

     

    Répétons l'opération avec troisième serveur protomoss3. Imaginons que ce serveur n'ait pas vocation à être un serveur frontal, mais plutôt un serveur de traitement (jobs, excel services calculation, ...). Rien ne vous oblige à le définir au niveau de votre solution de NLB, ni au niveau des Alternate Access Mappings. Ainsi, vous pouvez le réserver aux traitements pour lequel il est prévu.

     

    3 ) Vous étendez une application Web pour permettre un accès Extranet.

     

    En étandant votre application Web, vous mettez à disposition des utilisateurs à second moyen d'accès à un contenu commun avec votre Intranet. Si vous ne vous servez pas des Alternate Access Mappings et que vous utilisez uniquement des solutions de reverse proxy, vos utilisateurs Extranet consulteront des pages composées de liens pointant vers l'Intranet. Même chose lors de l'envoi automatisés de mails par SharePoint : les liens insérés dans les mails pointeront vers l'Intranet, alors que les utilisateurs n'y auront pas accès.

     

    En revanche, si vous définissez une URL publique pour l'extranet (par exemple https://extranet.maboite.com), les pages consultées par les utilisateurs comporteront des liens vers des pages pointant vers l'extranet. Et même chose pour les mails.

     

    En synthèse : les Alternate Access Mappings vous permettent de gérer le load balancing et les URL d'accès à vos applications Web. Vous pouvez très bien méler ces deux aspects en réservant certains serveurs d'une même ferme à l'extranet, et d'autres à l'intranet.

     

    J'espère que ces exemples vous rassurerons sur les frontières de votre intelligence . Si jamais ce n'est pas le cas, n'hésitez pas à demander des précisions... mais je doute qu'on puisse avoir de telles frontières de toute façon.

    mardi 24 juin 2008 14:56
    Modérateur

Toutes les réponses

  • Je ne vous comprends pas, c'est simple pourtant...

    Bon, ne vous inquiétez pas, cette question revient souvent, vous n'êtes pas la seule personne à rencontrer des difficultés avec les Alternate Access Mappings.

     

    SharePoint dispose de son propre mécanisme de gestion NLB. Vous remarquez que, lorsque vous créez une web application, SharePoint vous demande l'adresse de load balancing de l'application Web. C'est cette valeur qui est utilisée pour l'Alternate Access Mapping lors de la création de la Web App.

     

    Pour expliciter tout ceci, prenons un exemple :

     

    vous disposez d'un serveur protomoss1. Vous créez une application web sur le port 80. Votre URL de load balancing est alors http://protomoss1:80 (le 80 peut être ignoré, mais c'est la valeur que l'interface de création affiche).

     

    Lorsque vous accédez aux Alternate Access Mappings, vous pouvez constater que votre application dispose d'une URL interne et d'une URL publique. Les deux ont la même valeur : http://protomoss1.

     

    1) Vous souhaitez utiliser un nom un peu plus friendly

     

    Vous souhaitez modifier l'URL qui sera utilisée et visualisée par les utilisateurs de sorte à ce que http://protomoss1 soit remplacé par http://intranet.maboite.com.

    • Il vous faut demander une entrée (ou un alias) DNS pour que intranet.maboite.com redirige vers votre serveur.

    Dès lors, votre site SharePoint n'est plus accessible.

    • Il vous faut ensuite accéder aux Alternate Access Mappings pour modifier l'URL publique. Remplacez là par http://intranet.maboite.com et validez.

    Votre site est de nouveau accessible, mais avec l'adresse http://intranet.maboite.com. Essayez de saisir l'URL http://protomoss1 : Le site fonctionne toujours, mais votre navigateur modifie systématiquement l'URL par http://intranet.maboite.com.

     

    2) Vous ajoutez un (ou des) serveur(s) à votre ferme SharePoint.

     

    Imaginons que vous ajoutiez un serveur nommé protomoss2.

    Par défaut, l'accès à http://intranet.maboite.com ne vous redirige que sur protomoss1. Dès lors que vous ajoutez une seconde URL interne, SharePoint est en mesure de gérer les accès sur les deux serveurs. Dans un tel cas de figure, vous auriez intérêt à utiliser une solution de NLB (Cluster Windows, Big-Ip...) et associer l'URL publique à une entrée du NLB (donc définir http://intranet.maboite.com au niveau de la solution NLB, sans la mapper aux serveurs SharePoint). http://intranet.maboite.com reste donc en URL publique, et les URL protomoss1 et protomoss2 en URL internes.

     

    Répétons l'opération avec troisième serveur protomoss3. Imaginons que ce serveur n'ait pas vocation à être un serveur frontal, mais plutôt un serveur de traitement (jobs, excel services calculation, ...). Rien ne vous oblige à le définir au niveau de votre solution de NLB, ni au niveau des Alternate Access Mappings. Ainsi, vous pouvez le réserver aux traitements pour lequel il est prévu.

     

    3 ) Vous étendez une application Web pour permettre un accès Extranet.

     

    En étandant votre application Web, vous mettez à disposition des utilisateurs à second moyen d'accès à un contenu commun avec votre Intranet. Si vous ne vous servez pas des Alternate Access Mappings et que vous utilisez uniquement des solutions de reverse proxy, vos utilisateurs Extranet consulteront des pages composées de liens pointant vers l'Intranet. Même chose lors de l'envoi automatisés de mails par SharePoint : les liens insérés dans les mails pointeront vers l'Intranet, alors que les utilisateurs n'y auront pas accès.

     

    En revanche, si vous définissez une URL publique pour l'extranet (par exemple https://extranet.maboite.com), les pages consultées par les utilisateurs comporteront des liens vers des pages pointant vers l'extranet. Et même chose pour les mails.

     

    En synthèse : les Alternate Access Mappings vous permettent de gérer le load balancing et les URL d'accès à vos applications Web. Vous pouvez très bien méler ces deux aspects en réservant certains serveurs d'une même ferme à l'extranet, et d'autres à l'intranet.

     

    J'espère que ces exemples vous rassurerons sur les frontières de votre intelligence . Si jamais ce n'est pas le cas, n'hésitez pas à demander des précisions... mais je doute qu'on puisse avoir de telles frontières de toute façon.

    mardi 24 juin 2008 14:56
    Modérateur
  • Réponse Ultime Smile
    mardi 24 juin 2008 14:57
    Modérateur
  • <Pas content>

    Je sais que c'est un combat perdu d'avance....

    mais quand quelqu'un prend le temps de "pondre" une réponse aussi complète et précise ce serait vraiment bien de prendre le temps de la valider comme une réponse.

    Ça m'éviterait de devoir passer derrière pour le faire et motiverait les participants à continuer à vous répondre si vite.

    Dois je vous rappeler que répondre à vos questions se fait sur notre temps personnel ?

    D'avance merci.

    </Pas content>

    Je valide la réponse
    jeudi 26 juin 2008 07:38
    Modérateur
  •  

    Encore merci pour ces informations. Cela m'a permis de mettre le doigt un problème de paramêtre d'entête http au niveau du serveur web virtuel d'une de mes applications SharePoint.

     

    :-)

    vendredi 27 juin 2008 06:52
  •  

    Vous ne m'y reprendrez plus... !

     

    Cordialement,

    vendredi 27 juin 2008 06:55
  • Lol,

    Ca ira pour cette fois Smile
    • Proposé comme réponse kraf mardi 2 février 2010 13:44
    vendredi 27 juin 2008 07:38
    Modérateur