Question

Quand notre Sharepoint a été migré de Sharepoint 2003 à Sharepoint 2007 (les deux versions entièrement libérées), les consultants qui l'ont réalisé étendu chaque application Web en deux sites / zones IIS (par exemple, l'application Web d'origine était http: // intranet , puis http: // newintranet et < a href = "http: // intranet" rel = "nofollow"> http: // intranet serait créé pour Sharepoint 2007 - chacun avec son propre site IIS). L'idée était que, pendant la période de migration, nous montions DNS pour pointer l'ancienne URL pour SP2003 serveurs et le nouveau à SP2007, puis une fois la migration terminée, faire un changement de DNS de sorte que le SP2007 serait recevoir les demandes de la http: //. intranet URL de type

Malheureusement, les entrepreneurs ne sont pas ranger les extensions d'application et les sites IIS après la migration, et pendant un certain temps les deux URL ont été utilisés, ce qui dans de nombreux liens vers des documents pointant vers la page http: // newintranet URL de type. Cela signifie que je besoin de maintenir ces URL.

En raison d'une ReJig de structure organisationnelle nous avons maintenant besoin de déplacer certains sites Sharepoint, et je voudrais utiliser le RDA Collaboration fonctionnalité Sharepoint URL Redirector. Toutefois, une limitation est que cela ne fonctionne pas pour les applications Web qui ont été étendues en plusieurs zones. J'ai donc besoin de ranger la situation que nos consultants laissé derrière eux.

Je pense que la bonne chose à faire est d'utiliser l'option « Supprimer Sharepoint du site Web IIS » page d'administration centrale pour supprimer la zone pour les sites de type newintranet, et sélectionnez l'option pour supprimer également l'IIS site. Cela devrait conduire à avoir IIS pas des sites d'écoute pour http: // newintranet URL de type. Est-ce la bonne procédure?

Une fois que je l'ai fait que je dois mettre en place Sharepoint pour recevoir des demandes envoyées aux http: // newintranet URL de type afin qu'ils continuera à travailler. Je ne sais pas si je devrais faire ceci:

  • Mappages alternatives d'accès à l'aide ou,
  • en ajoutant un en-tête d'hôte au site IIS ou,
  • créer un site IIS non Sharepoint pour chaque http: // newintranet URL de type et utiliser IIS redirection pour transmettre les demandes au nouvelle URL en utilisant les variables pour passer le chemin vers le site Sharepoint.

Est-ce que quelqu'un a des idées sur ces options, ou tout autre moyen d'y parvenir?

Sharepoint 2007 est en cours d'exécution sur Windows 2003 avec IIS6. Nous n'avons pas actuellement des plans / budget pour passer à Sharepoint 2010.

Était-ce utile?

La solution

Le but d'étendre une application Web est d'avoir des sites Web IIS distincts pour exposer le contenu à différents groupes d'utilisateurs si oui - unextending votre application Web et en sélectionnant l'option de suppression devrait supprimer le site IIS et demande à la « étendue » site URL cessera de travailler.

En réponse à votre deuxième question, vous devez noter que l'ajout d'un en-tête d'hôte au site IIS signifie que les demandes ne fonctionnera que pour l'en-tête d'hôte URL - IIS ignorera les autres demandes.

Que vous laisse avec deux options: ou IIS redirection AAM. Étant donné les URL que vous avez fournis Je suppose que les utilisateurs au sein d'un intranet et vous ne publiez pas via un serveur proxy inverse -. Dans ce cas, IIS redirection peut être votre itinéraire le plus direct

Todd Klindt a publié un article utile sur ce http: / /www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=48 dos façon de en 2007. Vous pouvez vouloir vérifier que son toujours pertinent (peut-être donner un coup dans un environnement de test), mais Je crois que cela devrait faire le travail.

scroll top