Простой вопрос - как лучше всего реализовать веб-приложение sharepoint, которое должно быть доступно через два доменных имени (имена хостов, например, abc123.com и www.abc123.com)?
По моему опыту варианты следующие: -
Дайте мне знать ваше мнение по этому поводу и если вы знаете другой вариант, независимо от того, лучше они или хуже.
Заранее спасибо Рассел
Русь,
Вообще говоря, правильный способ сделать это - вариант №1: расширение веб-приложения. На это есть несколько серьезных причин:
Вероятно, самая важная причина использования варианта №1 была упомянута Му в его сообщении (выше): настройки, которые поддерживаются в IIS (например, заголовки узлов), также отслеживаются в SharePoint. Если нет другого способа обработать конкретный параметр IIS из SharePoint (хорошим примером является привязка сертификата SSL), настоятельно рекомендуется управлять всеми изменениями IIS с помощью действий и конфигурации в SharePoint. Внесение изменений в IIS без обновления конфигурации резервного копирования SharePoint часто приводит к чрезвычайно странному поведению. Одна из задач службы SPAdmin (служба настройки Windows SharePoint Services) заключается в применении изменений, внесенных вами в SharePoint, к IIS и в ферме (если она состоит из нескольких серверов); лучше всего позволить этой службе делать свою работу.
При расширении веб-приложения вы связываете новый URL-адрес с определенной зоной (Интернет, Экстранет, Интранет или Пользовательская). При создании ссылок на другие сайты SharePoint в ферме SharePoint попытается использовать URL-адрес для сайта, который соответствует вашей текущей зоне. Например, если вы должны расширить веб-приложение A до зоны экстрасети, а веб-приложение A содержит ссылки на веб-приложение B, тогда SharePoint попытается использовать ссылки зоны экстрасети для веб-приложения B, если они доступны, а не зону по умолчанию. ссылки. Если веб-приложение B не распространяется на зону экстрасети, существует резервный процесс (вплоть до зоны по умолчанию), который используется для назначения ссылки ... но важно знать, что это происходит за -сцены.
Альтернативный подход - связать дополнительное имя хоста с URL-адресом зоны по умолчанию, который у вас уже есть, с помощью встроенной в платформу функции альтернативного сопоставления доступа (AAM). Однако, прежде чем делать это, следует иметь в виду одно очень важное соображение: каждая зона (опять же: по умолчанию, интрасеть, экстранет, Интернет или пользовательская) может иметь только связанный с ней общедоступный URL. В вашем примере abc123.com - это общедоступный URL-адрес зоны по умолчанию. Вы можете использовать AAM для сопоставления www.abc123.com в качестве дополнительной точки входа в зону по умолчанию ... но когда вы это сделаете, все ссылки на странице будут ссылаться на abc123.com. Итак, запрос первой страницы может поступить через www.abc123.com, но нажатие на любую из ссылок на странице, которая отправляет обратно на сайт, отправит запросы на abc123.com. По сути, это делает AAM полезным только для первого вызова (если вы не используете что-то вроде функции публикации SharePoint в ISA Server - но это уже другая история и не по теме).
Я скептически отношусь к тому, что вариант №2 сработает. Если SharePoint не знает имя хоста, связанное с сайтом (т. Е. Оно назначается только в IIS), у него нет возможности узнать, откуда должен быть взят контент с этого сайта. SharePoint не работает как традиционный веб-сайт с файловой поддержкой; URL-адрес анализируется виртуальным перенаправителем SharePoint для извлечения контента из соответствующей базы данных контента, поддерживающей сайт. Если у IIS есть имя хоста, но SharePoint ничего об этом не знает, я бы ожидал, что контент не будет извлечен и возникнет ошибка.
Я не тестировал его, но ожидаю, что вариант №3 сработает при первом входе на сайт. После этого все запросы страниц и ссылки перейдут на перенаправленную цель.
Надеюсь, это поможет!
Я бы использовал вариант 3, потому что это гарантирует, что любые метаданные или ссылки, хранящиеся в SharePoint, предназначены для одного имени хоста - таким образом, если вы решите удалить вторичное имя хоста позже по какой-либо причине, у вас не будет проблемы с мертвыми ссылками.
Если единственное, что вам нужно для этого второго имени хоста, - это перейти прямо на этот сайт sharepoint, я бы лично использовал вариант 2, его быстро и легко, и он отправит этот URL прямо на этот сайт, но это изменение IIS, поэтому sharepoint знает ничего об этом. Если вам нужно, чтобы sharepoint знал об этом URL-адресе, вы можете использовать один из двух других optiosn.