Planifier les mappages des accès de substitution (Windows SharePoint Services)

Mise à jour : 2009-04-23

Dans cet article :

• À propos des mappages des accès de substitution

• Publication proxy inverse

• Intégration des mappages des accès de substitution aux fournisseurs d'authentification

• Intégration des mappages des accès de substitution aux stratégies d'applications Web

• Mappage des accès de substitution et mappage des ressources externes

• Résolution des problèmes des mappages des accès de substitution

Les mappages des accès de substitution dirigent les utilisateurs vers les URL correctes pendant leur interaction avec Windows SharePoint Services 3.0 (en cours de navigation vers la page d'accueil d'un site Web Windows SharePoint Services 3.0, par exemple). Les mappages des accès de substitution permettent à Windows SharePoint Services 3.0 de mapper les demandes Web sur les applications et sites Web corrects, et ils permettent à Windows SharePoint Services 3.0 de renvoyer le contenu approprié à l'utilisateur.

Les mappages des accès de substitution ont été implémentés, car il existe des scénarios de déploiement Internet courants dans lesquels l'URL d'une demande Web reçue par les services Internet (IIS) n'est pas la même que l'URL qui a été tapée par un utilisateur final. Ceci se produit plus généralement dans des scénarios de déploiement qui intègrent la publication proxy inverse et l'équilibrage de charge.

Remarque :

Les mappages des accès de substitution doivent être configurés pour l'équilibrage de charge, même s'il ne s'applique généralement pas aux collections de sites d'en-tête d'hôte. L'adresse URL publique de la zone par défaut doit correspondre à une adresse URL de domaine dont l'affichage pour tous les utilisateurs ne vous pose aucun problème. Si vous ne configurez par le mappage des accès de substitution, les noms des serveurs Web ou leurs adresses IP risquent de s'afficher dans les paramètres transmis entre les pages dans Windows SharePoint Services 3.0.

À propos des mappages des accès de substitution

Les mappages des accès de substitution permettent à une application Web qui reçoit une demande pour une URL interne, dans l'une des cinq zones d'authentification, de renvoyer les pages contenant des liens vers l'URL publique de la zone. Vous pouvez associer une application Web à une collection de mappages entre des URL internes et publiques. Interne fait référence à l'URL d'une demande Web, telle qu'elle est reçue par Windows SharePoint Services 3.0. Publique se rapporte à l'URL d'un site Web accessible en externe. L'URL publique est l'URL de base que Windows SharePoint Services 3.0 utilise dans les pages qu'il renvoie. Si l'URL interne a été modifiée par un périphérique proxy inverse, elle peut être différente de l'URL publique.

Remarque :
Les collections de sites nommées par l'hôte ne peuvent pas utiliser les mappages des accès de substitution. Les collections de sites nommées par l'hôte sont automatiquement considérées comme étant dans la zone Par défaut, et l'URL de la demande ne doit pas être modifiée entre l'utilisateur final et le serveur.

Plusieurs URL internes peuvent être associées à une seule URL publique. Les collections de mappages peuvent contenir jusqu'à cinq zones d'authentification, mais chaque zone ne peut contenir qu'une seule URL publique. Les collections de mappages correspondent aux zones d'authentification suivantes :

• Par défaut

• Intranet

• Internet

• Personnalisée

• Extranet

Publication proxy inverse

Un serveur proxy inverse est un périphérique qui se trouve entre les utilisateurs finaux et votre serveur Web. Toutes les demandes de votre serveur Web sont d'abord reçues par le serveur proxy inverse et, si ces demandes passent le filtrage de sécurité du proxy, celui-ci transfert les demandes à votre serveur Web. Les serveurs proxy inverses peuvent effectuer des fonctionnalités avancées, telles que recevoir une demande Web sur Internet via HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) et transférer cette même demande au serveur via HTTP. Cette fonction est appelée « Arrêt de SSL sur un autre ordinateur ». Les serveurs proxy inverses peuvent transférer la demande à un autre numéro de port que celui sur lequel la demande à été reçue initialement. Ils peuvent également modifier le champ d'en-tête d'hôte HTTP.

Windows SharePoint Services 3.0 est compatible avec de nombreux serveurs proxy inverses, mais dans l'exemple suivant la règle de publication provient du logiciel de serveur proxy inverse, Microsoft Internet Security and Acceleration (ISA) Server 2006. ISA Server 2006 comporte un Assistant de publication qui vous aide à créer une règle de publication pour Windows SharePoint Services 3.0. Une fois la règle créée, vous pouvez la modifier à tout moment.

Remarque :

Certains périphériques proxy inverses peuvent modifier le chemin d'accès d'une demande (la partie de l'URL qui suit le nom d'hôte et le numéro de port) à un point tel que, par exemple, une demande envoyée par l'utilisateur à https://www.microsoft.com/fr/fr/default.aspx/sharepoint/default.aspx peut être transmise au serveur Web sous la forme https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.example.com/default.aspx. Cela s'appelle un chemin d'accès asymétrique. Windows SharePoint Services 3.0 ne prend pas en charge les chemins d'accès asymétriques. Le chemin d'accès de l'URL doit être symétrique entre l'URL publique et l'URL interne. Ceci signifie que dans l'exemple précédent la partie « /sharepoint/default.aspx » de l'URL ne doit pas être modifiée par le périphérique proxy inverse.

Configuration du serveur proxy inverse

Les deux premières figures de cet exemple illustrent une règle de publication modifiée dans laquelle l'option Transférer l'en-tête d'hôte d'origine est désactivée pour démontrer la flexibilité du mappage des accès de substitution. Si l'option Transférer l'en-tête d'hôte d'origine est activée, le nom d'hôte public sert également de nom d'hôte interne lors de la configuration du mappage des accès de substitution.

Les figures suivantes illustrent les onglets Écouteur et Nom public de la feuille de propriétés de la règle. Ces propriétés définissent l'URL à utiliser pour accéder à votre application Web. Cette URL est en réalité l'URL de votre serveur proxy inverse qui transfert la demande à votre serveur qui exécute Windows SharePoint Services 3.0.

L'URL de l'utilisateur final est composée du protocole public, du nom d'hôte public et du numéro de port public, comme le montre le tableau suivant.

Les figures suivantes illustrent les onglets Vers et Pontage de la page de propriétés de la règle. Ces propriétés définissent l'URL que le serveur proxy inverse utilise pour transférer la demande à votre serveur qui exécute Windows SharePoint Services 3.0.

L'URL du serveur qui exécute Windows SharePoint Services 3.0 est composée du protocole interne, du nom d'hôte interne et du numéro de port interne, comme le montre le tableau suivant.

À ce stade, le serveur proxy inverse est configuré pour recevoir des demandes Web des utilisateurs finaux à l'adresse https://technet.microsoft.com/fr-fr/library/cc706993.aspx et pour les transférer à votre serveur qui exécute Windows SharePoint Services 3.0 à l'adresse https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.contoso.com/.

Configuration de l'application Web SharePoint

Après avoir configuré la règle de publication du serveur proxy inverse, configurez votre application Web et les mappages des accès de substitution pour correspondre à la règle de publication. Pour ce faire, étendez une application Web existante à un site Web IIS supplémentaire spécialement pour la règle de publication proxy inverse. Vous pouvez également créer une application Web pour cette règle de publication. Les valeurs dont vous avez besoin sont les mêmes dans les deux cas.

Procédez comme suit pour étendre une application Web existante.

Étendre une application Web existante

1. Dans Outils d'administration, ouvrez le site Web Administration centrale de SharePoint.

2. Dans la page d'accueil de l'Administration centrale, cliquez sur Gestion des applications.

3. Dans la page Gestion des applications, dans la section Gestion des applications Web SharePoint, cliquez sur Créer ou étendre une application Web.

4. Dans la page Créer ou étendre une application Web, cliquez sur Étendre une application Web existante.

5. Dans la page Étendre une application Web à un autre site Web IIS, sélectionnez une application Web. Une fois l'application Web sélectionnée, entrez des valeurs pour le port, l'en-tête de l'hôte et les champs SSL, en fonction des propriétés de l'URL interne définies dans « Configuration du serveur proxy inverse » plus haut dans cet article. Dans le champ URL, entrez l'URL publique définie dans « Configuration du serveur proxy inverse », comme indiqué dans la figure suivante.

   

6. Sélectionnez une zone de mappage des accès de substitution à affecter à cette extension de votre application Web. Il existe un maximum de cinq zones disponibles pour chaque application Web. Dans cet exemple, nous utiliserons la zone Internet. Toutes les zones offrent les mêmes fonctionnalités, bien que la zone Par défaut soit toujours utilisée pour certaines fonctions, telles que l'envoi de messages électroniques administratifs aux propriétaires de collections de sites.

7. Pour créer le site Web IIS, cliquez sur OK.

Après avoir exécuté ces procédures, vérifiez que votre URL publique a été correctement créée dans les mappages des accès de substitution, puis ajoutez votre URL interne. À moins que votre URL interne ne soit identique à votre URL publique, ceci est une étape supplémentaire que vous devez effectuer manuellement.

Procédez comme suit pour afficher la page des mappages des accès de substitution.

Afficher la page des mappages des accès de substitution

1. Dans Outils d'administration, ouvrez l'Administration centrale.

2. Dans la page d'accueil de l'Administration centrale, cliquez sur Opérations.

3. Dans la page Opérations, dans la section Configuration globale, cliquez sur Mappages des accès de substitution.

4. Dans la page Mappages des accès de substitution, sélectionnez l'application Web à publier via le serveur proxy inverse.

À ce stade, vous devez voir les URL des mappages des accès de substitution affectées à votre application Web, comme illustré dans la figure suivante.

L'URL publique de la règle de publication proxy inverse a été affectée à la zone Internet de votre application Web. Procédez comme suit pour ajouter l'URL interne à partir de la règle de publication proxy inverse à la zone Internet de votre application Web.

Ajouter l'URL interne à partir de la règle de publication proxy inverse à la zone Internet de votre application Web

1. Dans la page Mappages des accès de substitution, cliquez sur Ajouter des URL internes.

2. Tapez le nom de l'URL interne et sélectionnez la même zone que vous avez utilisée pour l'URL publique. Dans cet exemple, nous utiliserons la zone Internet.

3. Cliquez sur Enregistrer.

À ce stade, vous devez voir que l'URL supplémentaire est affectée à votre application Web (dans la même zone que l'URL publique de votre règle de publication proxy inverse), comme le montre l'illustration suivante.

Lorsqu'un utilisateur accède à https://technet.microsoft.com/fr-fr/library/cc706993.aspx,/ la demande Web est reçue par le serveur proxy inverse et transmise à https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.contoso.com/. Ensuite, Windows SharePoint Services 3.0 reçoit la demande Web, constate que l'URL de la demande est https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.contoso.com/ et que cette URL est affectée à l'application Web Contoso, puis retourne le contenu de cette application Web. En outre, étant donné que l'URL https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.contoso.com/ URL est affectée à la zone Internet, Windows SharePoint Services 3.0 génère des liens sur les pages en utilisant l'URL publique de cette zone : https://technet.microsoft.com/fr-fr/library/cc706993.aspx Ceci permet de garantir que les utilisateurs finaux sont dirigés vers l'URL correcte lorsqu'ils cliquent sur les liens de la page.

Les équilibreurs de charge fonctionnent de la même manière, en particulier s'ils remplacent l'URL d'origine de l'utilisateur final par l'URL du serveur Web vers lequel la demande est en cours d'équilibrage de charge. Pour prendre en compte ces remplacements d'URL, il suffit d'ajouter les mappages des accès de substitution des URL de chaque serveur, en tant qu'URL internes, et de les associer à la même zone que l'URL publique de l'utilisateur final. S'ils conservent l'URL d'origine, faites passer simplement l'URL d'origine comme étant l'URL publique.

Intégration des mappages des accès de substitution aux fournisseurs d'authentification

Les mappages des accès de substitution vous permettent d'exposer une application Web dans pas moins de cinq zones, avec un site Web IIS différent pour la sauvegarde de chaque zone.

Remarque :
Certaines personnes pensent par erreur qu'un maximum de cinq applications Web partagent les mêmes bases de données de contenu. En réalité, il n'y a qu'une seule application Web.

Ces zones vous permettent non seulement d'utiliser plusieurs URL pour accéder à une même application Web, mais également d'utiliser plusieurs fournisseurs d'authentification pour accéder à une même application Web.

Lors de l'extension d'une application Web dans une zone, vous devez utiliser l'authentification Windows fournie par IIS. Une fois l'application Web étendue dans la zone, vous pouvez modifier la zone pour utiliser un autre type d'authentification.

Procédez comme suit pour modifier la configuration d'authentification pour une zone.

Modifier la configuration d'authentification pour une zone

1. Dans Outils d'administration, ouvrez l'Administration centrale.

2. Dans la page d'accueil de l'Administration centrale, cliquez sur Gestion des applications.

3. Dans la page Gestion des applications, dans la section Sécurité des applications, cliquez sur Fournisseurs d'authentification.

4. Dans la page Fournisseurs d'authentification, sélectionnez votre application Web, répertoriée dans la zone Application Web.

5. Cliquez sur le nom de la zone dont vous souhaitez modifier la configuration d'authentification.

   Remarque :
   Vous avez la possibilité de faire votre choix parmi les zones qui disposent d'un site Web IIS de sauvegarde. Ces zones ont été affectées d'un site Web IIS au cours de la procédure « Étendre une application Web existante ».

6. Dans la page Modifier l'authentification, dans la section Type d'authentification, sélectionnez le type d'authentification que vous souhaitez utiliser pour cette zone :

   • Authentification Windows

   • Authentification par formulaires

   • Authentification unique Web

7. Modifiez tous les autres paramètres de configuration d'authentification que vous souhaitez modifier et cliquez sur Enregistrer.

À ce stade, vous pouvez également modifier les paramètres de configuration d'authentification pour une autre zone. Vous pouvez configurer des paramètres d'authentification complètement indépendants pour différentes zones accédant à un même contenu. Par exemple, vous pouvez configurer un contenu pour qu'il soit accessible de manière anonyme, tandis qu'un autre contenu nécessite des informations d'identification ; ou configurer une zone de sorte à activer l'accès anonyme et à désactiver toutes les autres formes d'authentification, ce qui permet de garantir que seul le contenu anonyme sera accessible. En même temps, l'accès anonyme peut être désactivé sur une autre zone, tandis que l'authentification NTLM est activée, ce qui permet de garantir que seul l'accès authentifié sera autorisé. En outre, différents types de comptes peuvent accéder à un même contenu : une zone peut être configurée pour utiliser des comptes Windows Active Directory, tandis qu'une autre zone peut être configurée pour utiliser des comptes non Active Directory avec l'authentification par formulaires ASP.NET.

Intégration des mappages des accès de substitution aux stratégies d'applications Web

Les stratégies d'applications Web permettent aux administrateurs d'accorder ou de refuser l'accès aux comptes et aux groupes de sécurité pour tous les sites exposés via une zone. Ceci peut s'avérer utile dans un grand nombre de scénarios.

Par exemple, le robot de recherche de Windows SharePoint Services 3.0 doit parcourir la même infrastructure d'autorisation que tout le monde : il peut uniquement analyser le contenu auquel il a accès. Or, des utilisateurs souhaiteraient que la recherche analyse le contenu à accès restreint afin que les utilisateurs autorisés puissent trouver ce contenu dans les résultats de la recherche. Le service de recherche utilise alors une stratégie Lecture totale sur les applications Web pour accorder à son robot l'autorisation de lire tout le contenu de cette application Web. Ainsi, il peut analyser et indexer le contenu existant et futur, même celui auquel l'administrateur de site n'a pas explicitement donné accès.

Un autre exemple est le personnel du support technique qui a besoin d'un accès administratif aux sites Windows SharePoint Services 3.0 afin de pouvoir aider les utilisateurs. Pour ce faire, vous pouvez créer une stratégie d'application Web qui accorde aux comptes du personnel du support technique l'autorisation Contrôle total pour qu'ils aient un accès administratif complet à tous les sites actuels et futurs sur l'application Web.

Étant donné que les stratégies sont liées aux applications Web et à leurs zones, vous pouvez garantir que la stratégie que vous avez appliquée à une zone n'affecte pas les autres zones. Ceci peut s'avérer utile si vous avez du contenu qui est exposé à la fois sur le réseau d'entreprise et sur Internet. Supposez, par exemple, que vous avez accordé au compte du personnel du support technique l'autorisation Contrôle total sur une zone d'une application Web qui a été affectée au réseau d'entreprise. Si un utilisateur tente d'utiliser ce compte pour accéder au site par le biais d'Internet, cette stratégie Contrôle total ne s'applique pas, car elle reconnaît que l'URL se trouve dans une autre zone. Par conséquent, le compte ne reçoit pas automatiquement l'accès administratif au site.

Mappage des accès de substitution et mappage des ressources externes

Windows SharePoint Services 3.0 vous permet d'étendre la fonctionnalité de mappage des accès de substitution à du contenu qui n'est pas hébergé dans la batterie de serveurs Windows SharePoint Services 3.0. Pour configurer cette fonctionnalité, accédez à la page Mappages des accès de substitution et cliquez sur Mapper sur les ressources externes. Vous êtes ensuite invité à créer une entrée pour une ressource externe que vous pouvez considérer comme une autre application Web. Dès que vous obtenez la ressource externe, vous pouvez lui affecter différentes URL et zones de la même façon que vous le faites pour les applications Web. Cette fonctionnalité n'est pas utilisée dans Windows SharePoint Services 3.0, mais les produits tiers créés sur la base de Windows SharePoint Services 3.0 peuvent y avoir recours.

Par exemple, la technologie de recherche de Office SharePoint Server 2007 est en mesure d'analyser du contenu externe à la batterie de serveurs, tel que des partages de fichiers et des sites Web. Si ce contenu est disponible à différentes URL sur différents réseaux, vous pouvez souhaiter que la recherche renvoie les résultats en utilisant les URL appropriées sur le réseau actuel de l'utilisateur. Grâce à la technologie du mappage des ressources externes du mappage des accès de substitution, la recherche peut remapper les URL externes dans ses résultats pour correspondre à la zone de l'utilisateur.

Résolution des problèmes des mappages des accès de substitution

Suivez les conseils ci-dessous pour éviter les six erreurs les plus fréquentes faites par les administrateurs en matière de mappage des accès de substitution.

Erreur 1 : en partant du principe qu'il ne vous est pas nécessaire de configurer les mappages des accès de substitution, à moins que vous ne déployiez SharePoint de manière inhabituelle

La cause la plus courante de problèmes liés aux mappages des accès de substitution est que les administrateurs ne réalisent pas qu'ils doivent configurer les mappages des accès de substitution initialement. Cela est bien compréhensible dans la mesure où les mappages des accès de substitution sont une nouvelle fonctionnalité de Windows SharePoint Services 3.0. Tous les administrateurs de Windows SharePoint Services 3.0 doivent s'assurer que les mappages des accès de substitution sont correctement configurés, même pour un déploiement simple.

Vos mappages des accès de substitution risquent de ne pas être correctement configurés si vous rencontrez l'un des problèmes suivants.

• Vous constatez des images dégradées sur votre site.

• Si vous rencontrez des messages d'erreur DNS ou des messages d'erreur indiquant qu'un serveur est introuvable lorsque vous naviguez vers un site sans spécifier de nom de fichier (tel que http://nom_ordinateur/nom_site), mais que vous êtes en mesure d'accéder au site si vous naviguez directement vers un fichier spécifié dans le site (tel que http://nom_ordinateur/nom_site/default.aspx), il est possible que des mappages des accès de substitution incorrectement configurés soient la cause du problème.

• Vous êtes redirigé vers http://nom_ordinateur lors de la navigation vers votre site. Si Windows SharePoint Services 3.0 reçoit une demande en provenance d’une adresse URL non reconnue (ou d’une adresse URL non configurée pour les mappages des accès de substitution) et que vous avez installé la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0, Windows SharePoint Services 3.0 essaye de déterminer l’application Web appropriée et répond à la demande en utilisant la même adresse URL de base dans les liens de la page renvoyée. Si la demande provient d’une adresse URL qui n’a pas été configurée pour les mappages des accès de substitution et que vous avez installé la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0, Windows SharePoint Services 3.0 crée également une erreur critique dans le journal des événements Windows et dans les journaux ULS de Windows SharePoint Services pour signaler à l’administrateur de Windows SharePoint Services qu’il doit configurer les mappages des accès de substitution pour l’adresse URL non reconnue.

Remarque :

Le fait d'installer la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0 dans une batterie de serveurs Windows SharePoint Services 3.0 utilisant des mappages des accès de substitution avec un serveur proxy inverse ou un équilibreur de charge réseau, comme dans un déploiement extranet, peut rendre certaines URL publiques inopérantes. Microsoft est conscient de ce problème et développe actuellement une solution. Avant d'installer la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0, les clients qui utilisent cette configuration doivent utiliser un environnement de test pour vérifier que les URL publiques demeurent accessibles une fois la mise à jour installée.

Pour que Windows SharePoint Services 3.0 fournisse une API stable et robuste capable de fonctionner sur plusieurs ordinateurs, même sur ceux sur lesquels l'application Web n'est pas en cours d'exécution, la résolution des URL à des sites ne peut pas compter sur les fichiers Hosts, le système DNS ou les liaisons IIS. Au contraire, lorsque Windows SharePoint Services 3.0 recevra une demande, il utilisera uniquement les mappages des accès de substitution pour effectuer la résolution des URL. Bien qu'il soit nécessaire de vérifier que vos fichiers Hosts, le système DNS et les liaisons IIS soient correctement configurés pour s'assurer que les demandes Web peuvent atteindre le serveur Windows SharePoint Services 3.0, il est également nécessaire de configurer les URL pour les mappages des accès de substitution, comme illustré dans les exemples suivants.

Nom de domaine complet

Si vous utilisez une URL de nom de domaine complet pour atteindre votre application Web, configurez ce nom de domaine dans DNS. Configurez également une URL correspondante pour les mappages des accès de substitution. S'il s'agit d'une URL que les utilisateurs finaux utiliseront pour atteindre votre site, rendez-la publique. S'il s'agit d'une URL qu'un serveur proxy inverse utilisera pour envoyer les demandes à votre site, faites-en une URL interne.

Remarque :
Si l'URL est interne, assurez-vous d'avoir configuré l'URL de l'utilisateur final comme étant l'URL publique dans la même zone.

Localhost

Localhost est un nom d'hôte spécial qui vous permet de taper https://localhost/ dans votre navigateur pour atteindre le site Web hébergé sur votre ordinateur local. Toutefois, étant donné que localhost est rendu disponible en accédant au fichier hosts de l'ordinateur, Windows SharePoint Services 3.0 ne peut pas automatiquement en tirer parti. Si vous avez besoin que https://localhost/ soit une URL valide pour Windows SharePoint Services 3.0, entrez https://localhost/ en tant que mappage des accès de substitution.

Adresses IP

Même si vous êtes dans un environnement dans lequel il n'existe pas de résolution de noms DNS ou Hosts et que vous utilisez simplement des URL avec des adresses IP, entrez ces URL en tant que mappages des accès de substitution.

Erreur 2 : en partant du principe que vous pouvez utiliser la fonctionnalité de traduction des liens du serveur proxy inverse au lieu du mappage des accès de substitution

Bien que certains administrateurs comprennent que les mappages des accès de substitution permettent de corriger les liens dans les pages et de garantir que les utilisateurs finaux sont dirigés vers l'URL publique correcte, ils peuvent supposer que, dans la mesure où la fonctionnalité de traduction des liens de leur serveur proxy inverse effectue une fonction similaire, les mappages des accès de substitution ne sont pas forcément nécessaires. Voici les raisons pour lesquelles cette hypothèse peut se révéler fausse :

• Dans les tests de compatibilité, aucune fonctionnalité de traduction de liens à partir de n'importe quel serveur proxy inverse, y compris un serveur ISA Server 2006, n'est suffisante pour corriger tous les liens Windows SharePoint Services 3.0 pour utiliser l'URL publique. Windows SharePoint Services 3.0 incorpore ses URL dans de nombreux endroits et dans des codages très variés. Actuellement, les serveurs proxy inverses ne sont pas suffisamment sophistiqués pour rechercher et corriger toutes les URL.

• Il existe des fonctions Windows SharePoint Services 3.0 qui ne passent pas par le biais des règles de publication des serveurs proxy inverses, par exemple, les alertes de messagerie électronique. C'est uniquement à l'aide des mappages des accès de substitution que vous pourrez vous assurer que les liens de vos alertes de messagerie utilisent les URL correctes pour vos utilisateurs.

  Important :
  Si vous exposez l'Administration centrale à l'aide d'une règle de publication, assurez-vous que la fonction de traduction des liens est désactivée pour cette règle. Si la traduction des liens n'est pas désactivée, elle peut interférer avec votre capacité à configurer le mappage des accès de substitution.

Erreur 3 : tentative de réutilisation d'une même URL dans le mappage des accès de substitution ou non-alignement d'URL sur une même zone

Il s'agit d'une erreur qui se produit fréquemment lors de la configuration de Windows SharePoint Services 3.0 pour exposer une application Web à la fois sur le réseau interne et sur Internet. Par exemple, si vous avez configuré une application Web sur votre réseau d'entreprise avec « https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx » comme étant votre URL de zone Par défaut et que vous souhaitez l'exposer sur Internet sous la forme https://www.microsoft.com/fr/fr/default.aspx, vous avez peut-être configuré votre serveur proxy inverse pour qu'il transfert les demandes à https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx, puis ajouté https://www.microsoft.com/fr/fr/default.aspx en tant qu'URL publique à la zone Internet. C'était une erreur. En effet, bien que l'accès au site à partir du réseau d'entreprise continue de fonctionner comme prévu, vous pourrez constater que l'accès à partir d'Internet ne fonctionne pas correctement et que plusieurs liens pointent vers https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx. Cela est dû au fait que les deux URL ont été entrées dans des zones de mappage des accès de substitution différentes et qu'elles ne sont par conséquent pas associées l'une à l'autre.

Une URL ne peut être utilisée qu'une seule fois dans les mappages des accès de substitution et dans l'exemple précédent l'URL https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx URL était déjà en cours d'utilisation sur votre réseau d'entreprise. Pour transférer vos demandes Internet à une même application Web, utilisez une autre URL interne pour votre règle de publication proxy inverse, telle que https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.contoso.com/. Vous pouvez laisser https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx dans les mappages des accès de substitution tout en ajoutant https://www.microsoft.com/fr/fr/default.aspx comme votre URL publique dans la zone Internet. Ajoutez https://sharepoint/supplierlogin.aspx?returnurl=%2fsupplierdefault.aspx.perimeter.contoso.com/ comme URL interne supplémentaire dans la même zone que votre URL publique https://www.microsoft.com/fr/fr/default.aspx, votre zone Internet. En utilisant les deux dans la même zone, Windows SharePoint Services 3.0 peut générer les liens corrects à l'aide de l'URL publique pour cette zone.

Remarque :
Nous vous recommandons d'étendre une application Web à un nouveau site Web IIS pour chaque zone que vous souhaitez utiliser. Ceci permet d'obtenir un site Web IIS de sauvegarde. Nous vous déconseillons de réutiliser un même site Web IIS pour plusieurs zones, sauf si Microsoft vous demande spécifiquement de le faire.

Erreur 4 : en partant du principe que les mises à jour effectuées dans les mappages des accès de substitution mettent automatiquement à jour les liaisons IIS

Dès qu'une application Web est étendue à une zone, Windows SharePoint Services 3.0 ne tente pas de modifier ses liaisons IIS. Si vous modifiez ces liaisons dans IIS en ajoutant une liaison d'en-tête d'hôte, en modifiant un numéro de port ou en ajoutant un port SSL, Windows SharePoint Services 3.0 ne sera pas informé des modifications et ne mettra pas à jour les URL des mappages des accès de substitution. De même, une mise à jour des URL des mappages des accès de substitution pour ajouter une URL SSL ne mettra pas automatiquement à jour vos liaisons IIS correspondantes.

Si vous devez modifier vos liaisons IIS, supprimez l'application Web de la zone en utilisant le lien Supprimer SharePoint à partir d'un site Web IIS dans la page Gestion des applications.

Remarque :
Cette action supprime uniquement un site Web IIS et sa zone à partir de l'application Web. Elle ne supprime pas l'application Web proprement dite, ou les bases de données de contenu de l'application Web.

Ensuite, vous pouvez étendre à nouveau l'application Web vers la zone à l'aide de vos liaisons mises à jour. Ceci est également valable si vous souhaitez ajouter un port SSL. Nous vous déconseillons de réutiliser un même site IIS pour l'hébergement HTTP et SSL. Il est préférable d'étendre un site Web HTTP dédié et SSL dédié, chacun d'eux affecté à sa propre zone et URL de mappage des accès de substitution.

Erreur 5 : oubli de la configuration de votre environnement pour activer la recherche afin d'analyser vos sites

Si vous avez configuré les mappages des accès de substitution et votre réseau pour permettre aux utilisateurs finaux d'atteindre vos sites, vos devez également configurer les mappages des accès de substitution et votre réseau pour la recherche Windows SharePoint Services 3.0. Le service Recherche Windows SharePoint Services 3.0 navigue dans vos applications Web pour analyser leur contenu et doit être en mesure d'accéder à vos URL publiques. Assurez-vous que l'ordinateur qui exécute le service d'indexation de recherche peut atteindre ces URL publiques. Ceci est particulièrement important pour tous les ordinateurs qui utilisent l'authentification NTLM. Si nécessaire, configurez les paramètres proxy de votre compte de service de recherche Windows SharePoint Services 3.0 pour utiliser vos serveurs proxy. Pour ce faire, connectez-vous à l'ordinateur sous ce compte et modifiez les paramètres de connexion au réseau local dans Internet Explorer.

Procédez comme suit pour modifier les paramètres de connexion au réseau local dans Internet Explorer.

Modifier les paramètres de connexion au réseau local dans Internet Explorer

1. Dans le Panneau de configuration, ouvrez Options Internet .

2. Dans l'onglet Connexions, dans la page de propriétés Options Internet, cliquez sur Paramètres réseau.

3. Modifiez les paramètres de connexion au réseau local dans la boîte de dialogue Paramètres du réseau local, puis cliquez sur OK.

Erreur 6 : erreurs typographiques

Assurez-vous que les URL des mappages des accès de substitution sont correctement entrées. Si vous utilisez un serveur proxy inverse, vérifiez que les URL des mappages des accès de substitution correspondent aux URL de votre règle de publication.

Télécharger ce livre

Cette rubrique est incluse dans le livre téléchargeable suivant pour une lecture et une impression plus faciles :

• Planification et architecture de Windows SharePoint Services 3.0, 2e partie (en anglais)

Consultez la liste des livres disponibles à l’adresse Livres à télécharger pour Windows SharePoint Services.

Voir aussi

Concepts

Configurer le mappage des accès de substitution (Windows SharePoint Services)