Планирование альтернативных сопоставлений доступа (службы Windows SharePoint Services)

Содержание:

• Об альтернативных сопоставлениях доступа

• Публикация обратного прокси-сервера

• Интеграция альтернативного сопоставления доступа со службами проверки подлинности

• Интеграция альтернативного сопоставления доступа с политиками веб-приложений

• Сопоставление альтернативного доступа и сопоставление с внешним ресурсом

• Устранение неполадок в альтернативных сопоставлениях доступа

Альтернативные сопоставления доступа направляют пользователей на правильный URL-адрес в процессе их взаимодействия с Windows SharePoint Services 3.0 (например, во время просмотра домашней страницы веб-сайта Windows SharePoint Services 3.0). Они также позволяют Windows SharePoint Services 3.0 сопоставлять веб-запросы с верными веб-приложениями и веб-сайтами. Кроме того, благодаря их использованию Windows SharePoint Services 3.0 может предоставлять пользователям требуемый контент.

Использование альтернативных сопоставлений доступа обусловлено тем, что существуют распространенные сценарии развертывания Интернета, в которых URL-адрес веб-запроса, полученный службами IIS отличается от URL-адреса, указанного пользователем. Чаще всего это происходит в сценариях развертывания, включающих публикацию обратного прокси-сервера и балансировку нагрузки.

Об альтернативных сопоставлениях доступа

Альтернативные сопоставления доступа позволяют веб-приложению, получающему запрос на внутренний URL-адрес в одной из пяти зон проверки подлинности, отобразить страницы, содержащие ссылки на общедоступный URL-адрес этой зоны. Веб-приложение можно связать с набором сопоставлений между внутренними и общедоступными URL-адресами. Внутренним называется URL-адрес веб-запроса, полученного Windows SharePoint Services 3.0, а общедоступным — URL-адресу веб-сайта, доступного извне. Общедоступный URL-адрес — это базовый URL, используемый Windows SharePoint Services 3.0 в возвращаемых страницах. Если внутренний URL-адрес изменен обратным прокси-сервером, он может отличаться от общедоступного URL-адреса.

Несколько внутренних URL-адресов могут быть связаны с одним общедоступным URL-адресом. Наборы сопоставлений могут включать в себя до пяти зон проверки подлинности, однако для каждой зоны может быть назначен только один общедоступный URL-адрес. Наборы сопоставлений соответствуют следующим зонам проверки подлинности:

• Default (По умолчанию)

• Intranet (Интрасеть)

• Internet (Интернет)

• Custom (Настраиваемая)

• Extranet (Экстрасеть)

Публикация обратного прокси-сервера

Обратным прокси-сервером называется устройство, находящееся между пользователями и веб-сервером. Все запросы к веб-серверу вначале поступают на обратный прокси-сервер, а затем, если эти запросы проходят фильтрацию безопасности прокси-сервера, они передаются на веб-сервер. Обратные прокси-серверы поддерживают ряд расширенных функциональных возможностей, таких как получение веб-запроса через Интернет по протоколу HTTPS, но передают они запрос на сервер по протоколу HTTP. Эта возможность называется "автономным завершением SSL". Обратные прокси-серверы могут направлять запрос на порт, номер которого отличается от номера порта, на котором был этот запрос был изначально получен. Кроме того, обратные прокси-серверы могут менять поле заголовка узла HTTP.

Windows SharePoint Services 3.0 совместим со многими обратными прокси-серверами, но в следующем далее примере используется правило публикации ПО обратного прокси-сервера Microsoft Internet Security and Acceleration (ISA) Server 2006. ISA Server 2006 содержит мастер публикаций, помогающих при создании правила публикации для Windows SharePoint Services 3.0. Созданное правило можно изменить в любое время.

Настройка обратного прокси-сервера

На первых двух рисунках в этом примере демонстрируется измененное правило публикации, в котором отключен параметр Пересылать исходный заголовок узла, что позволяет показать гибкость альтернативного сопоставления доступа. При выборе параметра Пересылать исходный заголовок узла общедоступное имя узла также выступает в качестве внутреннего имени узла при настройке альтернативного сопоставления доступа.

На следующих рисунках изображены вкладки Прослушиватель и Общедоступное имя на странице свойств для правила. Эти свойства определяют URL-адрес для доступа к веб-приложению, который в действительности является URL-адресом обратного прокси-сервера, пересылающий запрос на сервер, где запущено приложение Windows SharePoint Services 3.0.

URL-адрес конечного пользователя включает в себя публичный протокол, общедоступное имя узла и номер публичного порта, как показано в следующей таблице.

На следующих рисунках изображены вкладки Кому и Использование моста на странице свойств для правила. Эти свойства определяют URL-адрес, используемый обратным прокси-сервером для пересылки запроса на сервер, на котором запущено приложение Windows SharePoint Services 3.0.

URL-адрес сервера, на котором работает Windows SharePoint Services 3.0, состоит из внутреннего протокола, внутреннего имени узла и номера внутреннего порта, как показано в следующей таблице.

На этом этапе обратный прокси-сервер настраивается для получения веб-запросов от пользователей с веб-сайта https://technet.microsoft.com/ru-ru/library/cc706993.aspx и пересылки их на сервер, на котором работает Windows SharePoint Services 3.0, по адресу http://sharepoint.perimeter.contoso.com/.

Настройка веб-приложения SharePoint

После завершения настройки правила публикации обратного прокси-сервера соответствующим образом настройте веб-приложение и альтернативные сопоставления доступа, чтобы они соответствовали правилу публикации. Для этого можно расширить существующее веб-приложение и включить в него дополнительный веб-сайт IIS, специально предназначенный для правила публикации обратного прокси-сервера. Кроме того, для этого правила публикации можно создать новое веб-приложение. В обоих случаях используются одинаковые значения.

Для расширения существующего веб-приложения используйте следующую процедуру.

Расширение существующего веб-приложения

1. В меню Администрирование откройте веб-сайт центра администрирования SharePoint.

2. На странице центра администрирования нажмите Управление приложениями.

3. В разделе Управление веб-приложениями SharePoint страницы "Управление приложениями" щелкните Создание или расширение веб-приложения .

4. На странице "Создание или расширение веб-приложения" щелкните Расширить существующее веб-приложение.

5. На странице Расширение веб-приложения в другой веб-сайт IIS выберите веб-приложение. После этого укажите значения для полей порта, заголовка узла и SSL, основываясь на свойствах внутреннего URL-адреса, заданных ранее в разделе "Настройка обратного прокси-сервера" этой статьи. В поле URL-адреса укажите общедоступный URL-адрес, определенный в разделе "Настройка обратного прокси-сервера", как показано на следующем рисунке.

   

6. Выберите зону альтернативного сопоставления доступа, которой следует назначить это расширение веб-приложения. Для каждого веб-приложения доступно не более пяти зон. В этом примере используется зона "Интернет". Набор функций всех зон совпадает за исключением зоны "По умолчанию". Она всегда используется для выполнения определенных функций, таких как отправка административных сообщений электронной почты владельцам семейств веб-сайтов.

7. Чтобы создать веб-сайт IIS, нажмите кнопку ОК.

После завершения этих процедур проверьте правильность созданного общедоступного URL-адреса в альтернативных сопоставлениях доступа, а затем добавьте внутренний URL-адрес. Если внутренний URL-адрес не совпадает с общедоступным адресом, этот дополнительный шаг придется выполнить вручную.

Для просмотра страницы "Сопоставления альтернативного доступа" используйте следующую процедуру.

Просмотр страницы "Сопоставления альтернативного доступа"

1. В меню Администрирование откройте центр администрирования.

2. На домашней странице центра администрирования щелкните пункт Операции.

3. На странице "Операции" в разделе Глобальная конфигурация выберите Сопоставления для альтернативного доступа.

4. На странице "Сопоставления альтернативного доступа" выберите веб-приложение, которое будет публиковаться через обратный прокси-сервер.

На этом этапе должны отображаться URL-адреса альтернативного сопоставления доступа, назначенные веб-приложению, как показано на следующем рисунке.

Общедоступный URL-адрес из правила публикации обратного прокси-сервера был назначен зоне Интернета веб-приложения. Чтобы добавить внутренний URL-адрес из правила публикации обратного прокси-сервера в зону Интернета своего веб-приложения, выполните следующую процедуру.

Добавьте внутренний URL-адрес из правила публикации обратного прокси-сервера в зону Интернета веб-приложения

1. На странице "Сопоставления альтернативного доступа" щелкните Добавить внутренние URL-адреса .

2. Введите имя внутреннего URL-адреса и выберите ту же зону, которая использовалась для общедоступного URL-адреса. В этом примере используется зона Интернета.

3. Нажмите кнопку Сохранить.

На этом этапе должны отображаться дополнительные URL-адреса, назначенные веб-приложению (в той же зоне, что и общедоступные URL-адреса правила публикации обратного прокси-сервера), как показано на следующем рисунке.

Когда пользователь переходит на веб-сайт https://technet.microsoft.com/ru-ru/library/cc706993.aspx, обратный прокси-сервер получает веб-запрос и переадресует его на http://sharepoint.perimeter.contoso.com/. Затем этот запрос получает Windows SharePoint Services 3.0, видит URL-адрес запроса (http://sharepoint.perimeter.contoso.com/), выясняет, что этот URL-адрес сопоставлен веб-приложению Contoso и возвращает контент веб-приложения. Кроме того, поскольку URL-адрес http://sharepoint.perimeter.contoso.com/ относится к зоне Интернета, Windows SharePoint Services 3.0 будет создавать на страницах ссылки, используя общедоступный URL-адрес этой зоны (https://technet.microsoft.com/ru-ru/library/cc706993.aspx) . Благодаря этому конечные пользователи, щелкая ссылки на страницах, будут попадать на правильные URL-адреса.

Таким же образом действуют и средства балансировки нагрузки, особенно, если они записывают вместо исходного URL-адреса пользователя URL-адрес отдельного веб-сервера, на котором осуществляется балансировка нагрузки запроса. Чтобы учесть такие перезаписанные URL-адреса, просто добавьте альтернативные сопоставления доступа для URL-адреса каждого отдельного веб-сервера в качестве внутренних URL-адресов, а затем свяжите их с той же зоной, что и общедоступный URL-адрес пользователя. Если они сохраняют исходные URL-адреса, то просто укажите, что эти адреса являются общедоступными адресами.

Интеграция альтернативного сопоставления доступа со службами проверки подлинности

Альтернативные сопоставления доступа позволяют предоставить веб-приложение во всех пяти зонах, при этом для каждой зоны используется свой веб-сайт IIS.

Эта зоны позволяют не только использовать несколько URL-адресов для доступа к одному и тому же веб-приложению. Они также позволяют использовать для этого несколько служб проверки подлинности.

При расширении веб-приложения в зону необходимо использовать проверку подлинности Windows, предоставленную IIS. После завершения расширения веб-приложения зону можно изменить и использовать другой тип проверки подлинности.

Для изменения конфигурации проверки подлинности в зоне выполните следующую процедуру.

Изменение конфигурации проверки подлинности в зоне

1. В меню Администрирование откройте центр администрирования.

2. На странице центра администрирования нажмите Управление приложениями.

3. На странице "Управление приложениями" в разделе Безопасность приложений щелкните Поставщики проверки подлинности .

4. На странице "Поставщики проверки подлинности" выберите веб-приложение из списка Веб-приложение.

5. Щелкните имя зоны, конфигурацию проверки подлинности которой необходимо изменить.

   Примечание

   Выбрать можно только зону, поддерживаемую веб-сайтом IIS. Такие зоны были назначены веб-сайту IIS в рамках процедуры "Расширение существующего веб-приложения".

6. На странице "Изменение параметров проверки подлинности" в разделе Тип проверки подлинности выберите один из следующих типов проверки подлинности для этой зоны:

   • Windows

   • Формы

   • Единый вход

7. При необходимости измените другие параметры конфигурации проверки подлинности и щелкните Сохранить.

На этом этапе также можно изменить параметры конфигурации проверки подлинности для любой другой зоны. Можно настроить абсолютно независимые параметры проверки подлинности для различных зон, использующих одинаковый контент. Например, можно настроить анонимный вход для какой-то части контента, а для остального контента использовать учетные данные. Можно в одной из зон включить анонимный доступ и отключить все другие виды проверки подлинности, что позволяет получать доступ только к анонимному контенту. В то же самое время в другой зоне можно отключить анонимный доступ и включить проверку подлинности NTLM, что обеспечивает только доступ с проверкой подлинности. Кроме того, можно настроить доступ различных видов учетных записей к одному и тому же контенту: одна зона может использовать учетные записи Windows Active Directory, а другая — учетные записи, отличные от учетных записей Active Directory с проверкой подлинности на основе форм ASP.NET.

Интеграция альтернативного сопоставления доступа с политиками веб-приложений

Политики веб-приложений позволяют администраторам предоставлять или запрещать доступ к учетным записям и группам безопасности для всех веб-сайтов, используемых через зону. Это может оказаться полезным в ряде ситуаций.

Например, обходчик поиска Windows SharePoint Services 3.0 должен пройти через ту же инфраструктуру проверки подлинности, что и остальные средства; он может выполнять обход только того контента, к которому он получает доступ. Однако пользователи хотят, чтобы операция поиска выполняла обход контента с ограниченным доступом, чтобы авторизованные пользователи могли получить доступ к такому контенту в результатах поиска. Служба поиска применяет к веб-приложениям политику "Полное чтение", чтобы обходчик мог считывать весь контент этих приложений. Таким образом, обходчик может выполнять обход и индексирование всего существующего и будущего контента, включая контент, явное разрешение на доступ к которому не было получено у администратора веб-сайта.

В следующем примере рассматривается персонал службы поддержки, которым необходим административный доступ к веб-сайтам Windows SharePoint Services 3.0 для оказания помощи пользователям. Для этого можно создать политику веб-приложения, предоставляющую учетным записям сотрудников службы поддержки разрешение "Полный доступ" с тем, чтобы они обладали полным административным доступам ко всем имеющимся и будущим веб-сайтам веб-приложений.

Поскольку политики привязаны к веб-приложениям и их зонам, то можно гарантировать, что политика, применяемая к одной зоне, не влияет на другую зону. Это может оказаться полезным, если контент публикуется как в корпоративной сети, так и в Интернете. Например, предположим, что персоналу службы поддержки присвоено разрешение "Полный доступ" для зоны веб-приложения, назначенного корпоративной сети. При попытке использовать эту учетную запись для получения доступа к веб-сайту через Интернет, политика "Полный доступ" применяться не будет, поскольку этот URL-адрес находится в другой зоне. Поэтому учетная запись не сможет автоматически получить административный доступ к веб-сайту.

Сопоставление альтернативного доступа и сопоставление с внешним ресурсом

Windows SharePoint Services 3.0 позволяет применить возможности альтернативного сопоставления доступа к контенту, не размещенному на ферме серверов Windows SharePoint Services 3.0. Чтобы настроить эти возможности, перейдите на страницу "Сопоставления для альтернативного доступа" и щелкните Сопоставить с внешним ресурсом. После этого предлагается создать запись для внешнего ресурса, который можно рассматривать как другое веб-приложение. После создания внешнего ресурса ему можно назначить другие URL-адреса и зоны точно так же, как и для веб-приложений. Эта функция не реализована в Windows SharePoint Services 3.0, однако ее можно использовать в продуктах сторонних производителей, созданных на основе Windows SharePoint Services 3.0.

Например, технология поиска в Office SharePoint Server 2007 может выполнять обход контента, являющегося внешним для данной фермы, включая общие папки и веб-сайты. Если этот контент доступен по другим URL-адресам в других сетях, можно ограничить результаты поиска соответствующими URL-адресами текущей сети пользователя. При использовании технологии сопоставления с внешним ресурсом для альтернативного сопоставления доступа операция поиска может повторно сопоставить внешние URL-адреса в результатах поиска, чтобы установить соответствие с зоной пользователя.

Устранение неполадок в альтернативных сопоставлениях доступа

Чтобы избежать шести наиболее распространенных ошибок, которые совершают администраторы при использовании альтернативного сопоставления доступа, используйте следующие рекомендации

Ошибка 1. Настройка альтернативных сопоставлений доступа нужна только при нестандартном развертывании SharePoint

Причиной наиболее распространенной проблемы, связанной с альтернативными сопоставлениями доступа, является тот факт, что администраторы не осознают всей важности первоочередной настройки этих функций. Конечно, эта позиция администраторов вполне объяснима: ведь альтернативные сопоставления доступа — это новое требование в Windows SharePoint Services 3.0. При выполнении даже самых простых развертываний администраторы Windows SharePoint Services 3.0 должны убедиться в правильности настройки альтернативных сопоставлений доступа.

Возникновение любой из следующих проблем означает, что, возможно, настройка альтернативных сопоставлений доступа была выполнена неверно.

• сайт отображает искаженные изображения.

• Сообщения об ошибках служб DNS или сообщения об ошибках, указывающие на невозможность обнаружения сервера при попытке входа на веб-сайт без указания имени файла (например, http://имя_компьютера/имя_сайта), при этом доступ к веб-сайту возможен при переходе непосредственно на указанный файл в рамках веб-сайта (например, http://имя_компьютера/имя_сайта/default.aspx), могут быть следствием неверно настроенных альтернативных сопоставлений доступа.

• При попытке входа на личный веб-сайт выполняется перенаправление на веб-сайт http://имя_компьютера. Если Windows SharePoint Services 3.0 получают запрос с нераспознанного URL-адреса (или URL-адреса, который не был настроен для альтернативных сопоставлений доступа) и установлены Обновление инфраструктуры для Windows SharePoint Services 3.0, то Windows SharePoint Services 3.0 попытаются определить правильное веб-приложение, а затем ответят на запрос, используя базовый URL-адрес ссылок на странице, которую он возвращает. Если запрос поступает с URL-адреса, который не был указан для альтернативных сопоставлений доступа и установлены Обновление инфраструктуры для Windows SharePoint Services 3.0, то Windows SharePoint Services 3.0 также создадут критическую ошибку в журнале событий Windows и журналах URL-адресов Службы Windows SharePoint Services для уведомления администратора Службы Windows SharePoint Services о необходимости настройки альтернативных сопоставлений доступа для нераспознанного URL-адреса.

Чтобы Windows SharePoint Services 3.0 обеспечил надежные и стабильные интерфейсы API, способные работать на нескольких компьютерах, включая те из них, на которых не запущена служба веб-приложения, разрешения URL-адресов на веб-сайты не могут использовать только файлы узлов, службы DNS или привязки IIS. Вместо этого, получив запрос, Windows SharePoint Services 3.0 использует для разрешения URL-адреса только альтернативные сопоставления доступа. Хотя это необходимо, чтобы убедиться, что файлы узлов, службы DNS и привязки IIS настроены верно и веб-запросы достигают сервер Windows SharePoint Services 3.0, также необходимо настроить URL-адреса для поддержки альтернативных сопоставлений доступа, как показано в следующих примерах.

Полное доменное имя (FQDN)

Если для достижения веб-приложения используется URL-адрес FQDN, необходимо в DNS настроить это доменное имя. Также следует настроить соответствующий ему URL-адрес для альтернативных сопоставлений доступа. Если пользователи используют именно этот URL-адрес для входа на веб-сайт, сделайте его общедоступным. Если же это URL-адрес, применяемый обратным прокси-сервером для пересылки запросов на веб-сайт, сделайте адрес внутренним.

Localhost

Localhost — это специальное имя узла, позволяющее ввести в браузере https://localhost/ и получить доступ к веб-сайту, размещенному на локальном компьютере. Однако в связи с тем, что localhost становится доступным только при получении доступа к файлу веб-сайтов компьютера, Windows SharePoint Services 3.0 не может автоматически воспользоваться этой возможностью. Чтобы адрес https://localhost/ стал допустимым URL-адресом Windows SharePoint Services 3.0, необходимо указать https://localhost/ в качестве альтернативного сопоставления доступа.

IP-адреса

При работе в среде, где отсутствует служба DNS или разрешение имен узлов, а используются только URL-адреса с IP-адресами, все равно необходимо ввести эти URL-адреса в качестве альтернативных сопоставлений доступа.

Ошибка 2: Можно использовать функцию преобразования ссылок обратного прокси-сервера вместо альтернативного сопоставления доступа

Сопоставление альтернативного доступа и преобразование ссылок обратного прокси-сервера выполняют одинаковые функции по исправлению ссылок на страницах и перемещению пользователей на правильные общедоступные URL-адреса. Поэтому некоторые администраторы могут прийти к выводу, что функция альтернативного сопоставления доступа не нужна. Но это мнение является ошибочным по нескольким причинам.

• В время тестирования на совместимость функция преобразования ссылок любого обратного прокси-сервера, включая ISA Server 2006, недостаточна для исправления всех ссылок Windows SharePoint Services 3.0 для использования общедоступных URL-адресов. Windows SharePoint Services 3.0 вставляет свои URL-адреса во множество мест и в различных кодировках, а обратные прокси-серверы пока не способны найти и исправить все подобные адреса.

• Некоторые функции Windows SharePoint Services 3.0 не проходят через правила публикации обратных прокси-серверов, как, например, оповещения по электронной почте. Только альтернативные сопоставления доступа позволят гарантировать, что во всех ссылках оповещений по электронной почте используются верные URL-адреса для пользователей.

  Важно!

  Если центр администрирования предоставляется с помощью правила публикации, убедитесь, что функция преобразования ссылок отключена для этого правила. В противном случае эта функция может помешать настройке альтернативного сопоставления доступа.

Ошибка 3: Попытка повторного использования одного и того же URL-адреса в альтернативном сопоставлении доступа или отсутствие выравнивания URL-адресов в одной зоне

Эту ошибку часто совершают при настройке Windows SharePoint Services 3.0 для размещения веб-приложения как во внутренней сети, так и в Интернете. Например, если веб-приложение в корпоративной сети было настроено с использованием адреса "https://sharepoint" как URL-адреса зоны по умолчанию, то для размещения этого приложения в Интернете по адресу http://www.contoso.com,/ можно попытаться настроить обратный прокси-сервер для пересылки запросов на http://sharepoint,/ а затем добавить https://www.contoso.com в качестве общедоступного URL-адреса к зоне Интернета. Это будет ошибочным решением. Хотя доступ к этому веб-сайту из корпоративной сети предоставляется по-прежнему, доступ из Интернета связан с некоторыми проблемами, а некоторые ссылки указывают на адрес https://sharepoint. Это связано с тем, что два URL-адреса были указаны в различных зонах альтернативного сопоставления доступа и, следовательно, они не связаны друг с другом.

URL-адрес может использоваться в альтернативных сопоставлениях доступа только единожды, а в представленном выше примере URL-адрес https://sharepoint уже использовался в корпоративной сети. Чтобы переадресовать Интернет-запросы на то же самое веб-приложение, используйте другой внутренний URL-адрес для правила публикации обратного сервера, например, http://sharepoint.perimeter.contoso.com/. Можно оставить адрес https://sharepoint в альтернативных сопоставлениях доступа и добавить https://www.contoso.com в качестве общедоступного URL-адреса в зоне Интернета. Необходимо добавить http://sharepoint.perimeter.contoso.com/ в качестве дополнительного внутреннего URL-адреса в ту же самую зону, что и общедоступный URL-адрес https://www.contoso.com (зона Интернета). В результате использования двух адресов в одной и той же зоне Windows SharePoint Services 3.0 сможет создать верные ссылки на основании общедоступного URL-адреса для этой зоны.

Ошибка 4: Обновления альтернативных сопоставлений доступа автоматически приводят к обновлению привязок IIS

После расширения веб-приложения для зоны Windows SharePoint Services 3.0 не пытается изменять привязки IIS. Если эти привязки в IIS меняются за счет добавления привязки заголовка узла, изменения номера порта или добавления SSL-порта, Windows SharePoint Services 3.0 не получает сведения об этих изменениях и не выполняет обновление URL-адресов альтернативных сопоставлений доступа. Точно так же добавление URL-адреса SSL к URL-адресам альтернативных сопоставлений доступа не приводит к автоматическому обновлению привязок IIS.

Чтобы внести изменения в привязки IIS, удалите веб-приложение из зоны с помощью ссылки Удаление SharePoint с веб-сайта IIS на странице "Управление приложениями".

После этого можно повторно расширить веб-приложение для этой же зоны, используя обновленные привязки. Также эту процедуру можно использовать для добавления SSL-порта. Рекомендуется не использовать повторно один и тот же веб-сайт IIS для HTTP и размещения SSL. Вместо этого выполните расширение выделенного HTTP и веб-сайта выделенного SSL, назначив каждый из них собственной зоне альтернативного сопоставления доступа и URL-адресам.

Ошибка 5: Отсутствие настройки среды для разрешения функции поиска выполнять обход веб-сайтов

Если настройки альтернативных сопоставлений доступа и сети позволяют пользователям получать доступ к веб-сайтам, необходимо также настроить их для поддержки поиска Windows SharePoint Services 3.0. Служба поиска Windows SharePoint Services 3.0 выполняет обзор веб-приложений и выполняет обход их контента; поэтому эта служба должна также обладать доступом к общедоступным URL-адресам. Убедитесь, что компьютер, выполняющий службу индексирования поиска, имеет доступ к этим общедоступным URL-адресам. Это особенно важно для компьютеров, на которых используется проверка подлинности NTLM. В случае необходимости настройте параметры прокси-сервера для учетной записи службы поиска Windows SharePoint Services 3.0 и разрешите использование прокси-серверов. Для этого войдите в компьютер, используя эту учетную запись, и поменяйте параметры подключения по локальной сети в Internet Explorer.

Для изменения параметров подключения по локальной сети в Internet Explorer используйте следующую процедуру.

Изменений параметров подключения по локальной сети в Internet Explorer

1. На Панели управления откройте меню Свойства браузера.

2. На вкладке Подключения на странице свойств Свойства браузера щелкните Параметры локальной сети.

3. Измените параметры подключения по локальной сети в диалоговом окне "Настройка параметров локальной сети (LAN)" и нажмите ОК.

Ошибка 6: Ошибки ввода

Убедитесь, что URL-адреса в альтернативных сопоставлениях доступа указаны верно. При использовании обратного прокси-сервера убедитесь, что URL-адреса альтернативных сопоставлений доступа соответствуют URL-адресам в правиле публикации.

Загрузить эту книгу

Для упрощения чтения и печати этот раздел включен в следующую загружаемую книгу:

• Планирование и архитектура для Windows SharePoint Services 3.0, часть 2 (на английском языке)

Полный список доступных книг см. в разделе Загружаемые книги для служб Windows SharePoint Services.

См. также

Понятия

Настройка альтернативного сопоставления доступа (Windows SharePoint Services)