ADG Оставить заявку
Блог Интеграции 4 мин чтения

Корпоративный портал на WSS 2.0: документы загружены, поиск сломан, клиент доволен наполовину

Разворачиваем Windows SharePoint Services 2.0 для внутреннего портала. День установки проходит гладко, а потом начинается настоящая работа - поиск и права.

Контекст момента

SharePoint Portal Server 2003 и WSS 2.0 активно внедряются в компаниях; Microsoft объявил о следующей версии SharePoint, выход которой ожидается в 2007 году

Клиент сформулировал задачу просто: «хотим внутренний портал, чтобы сотрудники хранили документы и читали новости компании». Никаких специфических требований к платформе, никаких интеграций с 1С или SAP - просто документы и новости. Мы предложили Windows SharePoint Services 2.0: у клиента уже стоял Windows Server 2003, лицензий на WSS не требуется, и задача укладывалась в стандартный сценарий применения.

День первый: всё идёт по плану

Установка WSS 2.0 на Windows Server 2003 - это примерно половина рабочего дня плюс хвост на конфигурацию. Последовательность знакомая: сервисный аккаунт для пула приложений, установка SQL Server 2000 (или MSDE, если бюджет совсем не располагает), настройка IIS, запуск мастера установки WSS.

Ключевые моменты, на которых можно потерять время:

  • Сервисный аккаунт. Должен быть доменным, с правами локального администратора на сервере. Без этого SharePoint-таймер отказывается стартовать, и ошибка в Event Log не очень помогает понять почему.
  • База конфигурации. WSS создаёт отдельную базу для своей конфигурации и отдельные базы для каждого сайта. На SQL Server 2000 нужно заранее проверить уровень совместимости и убедиться, что аккаунт сервиса имеет права dbcreator.
  • IIS и заголовок хоста. Если на том же IIS уже крутится что-то ещё, нужно аккуратно разделить сайты по портам или заголовкам - WSS по умолчанию хочет занять порт 80 и не спрашивает.

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

День второй: «а где поиск?»

Вот тут начинается интересное.

WSS 2.0 поставляется с базовым поиском - по метаданным и содержимому документов. Но чтобы он работал, нужно вручную запустить индексирование: в Central Administration включить сервис Windows SharePoint Services Search, задать расписание обхода, дать ему отдельный аккаунт (снова сервисный аккаунт, и снова с нужными правами).

Пользователи к этому моменту уже загрузили в библиотеки несколько десятков документов - Word, Excel, PDF - и немедленно попробовали найти что-нибудь по содержимому. Поиск вернул пустой результат. Не ошибку - просто ничто ничего не нашло. Это классическая ловушка: интерфейс поиска есть, а индекс ещё не построен и никакой индикации об этом нет.

Мы запустили полный обход вручную, убедились, что сервис индексирования запущен, проверили, что iFilter для PDF установлен - WSS умеет индексировать PDF, но только при наличии Adobe iFilter, который надо ставить отдельно. После этого поиск заработал, но клиент уже успел усомниться.

Права доступа: где SharePoint опережает ожидания

Модель разрешений в WSS 2.0 оказалась неплохой. Можно управлять доступом на уровне семейства сайтов, отдельного сайта, библиотеки и даже конкретного документа. Группы - «Читатели», «Участники», «Администраторы» - отображаются в Active Directory и синхронизируются с доменными группами.

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

Единственное, что раздражает - нет нормального отчёта «кто к чему имеет доступ» в стандартном интерфейсе. Если нужен аудит прав, приходится либо смотреть вручную по каждой библиотеке, либо писать запрос к базе напрямую. Для небольшого портала терпимо, для крупного - было бы проблемой.

Что получилось в итоге

Рабочий портал с несколькими сайтами, библиотеками документов, лентой новостей и настроенным поиском. Интеграция с Active Directory работает из коробки - пользователи входят с доменными учётными данными, дополнительной аутентификации нет.

Производительность на текущих объёмах вопросов не вызывает. SQL Server 2000 справляется, IIS не перегружен. Мы порекомендовали вынести базы данных на отдельный диск и настроить регулярный бэкап через stsadm - штатный инструмент командной строки WSS, который умеет делать резервную копию всего сайта со структурой.

SharePoint Portal Server 2003 - коммерческая версия с расширенным поиском, аудиторией и профилями пользователей - у этого клиента не нужен: WSS 2.0 закрывает задачу. Разница становится ощутимой, когда нужен поиск по нескольким серверам или сложный интранет с профилями. Пока масштаб не тот.

Главное наблюдение по итогу первой недели: пользователи быстро привыкают загружать документы в SharePoint, но так же быстро начинают требовать всё больше - версионирование, уведомления об изменениях, согласование документов. Всё это в WSS есть, но требует отдельной настройки под каждый сценарий. Так что «развернули и забыли» не получается - портал начинает жить и просить внимания.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.