Комплект продуктов и технологий, реализованный в Microsoft SharePoint 2007, — а в него входят Windows SharePoint Services (WSS) 3.0 и Microsoft Office SharePoint Server (MOSS) 2007, — содержит добротные функции управления документами, средства для совместной работы и функции управления веб-содержимым, готовые к использованию без предварительной настройки. Однако организации, имеющие опыт эксплуатации SharePoint 2007 в течение нескольких лет, высказывают определенные претензии к этому продукту. Речь не идет о неких непреодолимых препятствиях, но все же надо сказать, что отмечаемые недостатки могут поставить в тупик администраторов, ответственных за обслуживание и оптимизацию среды SharePoint. По всей вероятности, у каждого администратора SharePoint имеется свой список претензий к рассматриваемому продукту, но я хочу рассказать о наиболее распространенных замечаниях.

Остроту почти всех упоминаемых в статье проблем могут снять сами администраторы с помощью различных обходных приемов. Для решения прочих требуются специальные продукты от независимых поставщиков.

Глобальная структура навигации

По умолчанию встроенные ссылки и средства навигации по сайтам SharePoint ограничены уровнем коллекции сайта. Иначе говоря, каждая коллекция сайта выступает в роли навигационного острова и отображает ссылки только на сайты, расположенные внутри данной коллекции. Нажав кнопку Home в коллекции сайта, пользователь перемещается в корень коллекции (но не в корень веб-приложения). Эта особенность может сбить с толку конечных пользователей, особенно если речь идет о средах, где имеется множество коллекций сайта. С точки зрения масштабирования оптимальный метод состоит в том, чтобы создавать несколько коллекций сайта — распределять их по различным базам данных контента и обеспечивать более высокий уровень управляемости. В результате многие администраторы SharePoint оказываются в ситуации, когда у них нет очевидного способа обеспечить своих пользователей средой для «гладкой» навигации по различным сайтам; для всех коллекций сайта внутри веб-приложения имеется одно решение — глобальная структура навигации Global Navigation. Microsoft обеспечивает возможность модификации этой структуры. Для этого можно воспользоваться классом SiteMapProvider, а именно Microsoft.SharePoint.Navigation.SPXmlContentMapProvider, а затем модифицировать эталонную страницу таким образом, чтобы она ссылалась на созданный пользователем класс SiteMapProvider. Однако пользователи не могут модифицировать данное решение с помощью применяемого по умолчанию графического интерфейса. Дополнительные сведения о классе SiteMapProvider можно найти в подготовленной специалистами Microsoft статье «SPXmlContentMapProviderClass (Microsoft.SharePoint.Navigation)», опубликованной по адресу msdn.microsoft.com/en-us/library/microsoft.sharepoint.navigation.spxmlcontentmapprovider.aspx.

Управление базой данных контента

Все содержимое SharePoint хранится в ряде баз данных контента, которые размещаются в базе данных Microsoft SQL Server. В этих базах данных содержатся все документы, данные списков, веб-элементы и другие средства настройки, и потому они являются жизненно важным компонентом среды SharePoint. Но, к сожалению, продукт Microsoft по умолчанию развертывает лишь по одной базе данных контента в каждом веб-приложении, и во многих организациях эта единственная база данных разрастается до размеров свыше 100 Гбайт, превосходя максимальное рекомендуемое значение для баз данных контента. Для преодоления этой проблемы специалисты Microsoft рекомендуют создавать несколько баз данных и распределять содержимое по нескольким коллекциям сайта. Недостаток описанного способа состоит в том, что пользователь не имеет возможности определить, в какую базу данных попадет новая коллекция сайта. Попытка организовать контент по базам данных (скажем, выделить для каждого отдела организации собственную базу данных контента) может обернуться новыми проблемами.

Рассматриваемая задача решается двумя способами. Первое решение — самое простое, но оно применимо лишь в тех случаях, когда пользователь создает коллекцию сайта в новой базе данных контента. В таких случаях нужно просто сформировать коллекцию сайта, используя утилиту командной строки Stsadm с переключателем -createsiteinnewdb. Для существующих баз данных контента следует просто увеличить максимальное число узлов, которые могут быть созданы в этой базе данных с переходом по ссылке Content Databases в инструментальном средстве SharePoint Central Admin. Установите этот показатель намного выше, чем у любой другой базы данных, и SharePoint автоматически разместит коллекцию сайта в выделенной вами базе данных.

Поиск по членству в группах AD

Хотя при выполнении авторизации SharePoint может использовать учетные записи Active Directory (AD) для безопасного доступа, в случаях, когда группы AD применяются для предоставления прав безопасности, имеются некоторые ограничения. Если, например, администратор хочет предоставить всем членам определенной группы AD права доступа к коллекции узлов, он может добавить их из программы SharePoint, однако возможность определения, кто является членом той или иной группы, не предусмотрена. Поэтому администратору приходится выходить из SharePoint и решать вопрос членства в группе с помощью другого инструмента, такого как оснастка Active Directory Users and Computers консоли Microsoft Management Console (MMC). Простого способа напрямую обойти это ограничение внутри SharePoint не существует. Но вы можете решить эту проблему, воспользовавшись административными решениями для SharePoint от независимых поставщиков и специализированными утилитами, просматривающими AD с использованием протокола LDAP. Такими функциональными возможностями обладает, в частности, веб-часть RSSBus (www.rssbus.com/products/sharepoint/templates/template.aspx? webpart=ldap.ListGroups).

Неоднократные приглашения к аутентификации

Возможно, пользователям придется на протяжении одного рабочего сеанса проходить процедуру проверки полномочий несколько раз (этот порядок определяется в зависимости от метода доступа пользователей к SharePoint, а также от настроек безопасности браузера). Такая ситуация особенно часто возникает при использовании клиента Microsoft Office, такого как Word или Excel.

К счастью, проблема неплохо документирована, и ее, как правило, можно снять, изменив настройки безопасности браузера на automatically use the user’ s credentials или reuse the credentials initially used. Применительно к большинству организаций это означает, что в локальную зону безопасности intranet браузера Internet Explorer (IE) нужно добавить указатель URL сервера SharePoint. После этого повторные приглашения к выполнению процедуры аутентификации, по идее, выводиться не должны.

Поставщик общих служб и масштабируемость ферм

Реализованная в SharePoint 2007 концепция поставщика общих служб Shared Services Provider (SSP) вызвала к жизни множество неприятных проблем, связанных с масштабируемостью. Так, на каждый поставщик SSP должно приходиться не более одного сервера индекса. В результате компонент индексирования становится неизбыточным и возникает необходимость в составлении сценариев с использованием серверов индекса из различных ферм, которые индексировали бы содержимое других сайтов. Иные архитектурные особенности ограничивают масштабируемость SharePoint в моделях ASP — речь идет главным образом о требовании, согласно которому каждый сервер с ролью Web должен содержать каждое веб-приложение в данной ферме, что существенно увеличивает непроизводительные затраты и снижает число веб-приложений, которые могли бы быть развернуты.

В версии SharePoint 2010 концепция SSP, к счастью, не реализована. В новой версии поставщики общих служб заменены моделью Services, в которой каждая общая служба имеет соответствующую базу данных SQL Server, используемую членами фермы. Кроме того, снято ограничение, обязывающее размещать все веб-приложения на каждом сервере с ролью Web.

Тем не менее упомянутые проблемы трудно решать в продукте SharePoint 2007. Однако администраторы добились определенных успехов в работе с продуктами от независимых поставщиков: порой им удается делать компоненты индексирования избыточными и масштабировать SharePoint за счет создания нескольких ферм. Но при достижении определенного масштаба управлять средами этих типов может быть неудобно — вот почему модуль SSP не представлен в версии SharePoint 2010.

Преодолеть ограничения

Всякая технология имеет свои недостатки, заставляющие пользователей спрашивать с досадой: «И о чем это думали разработчики?». Я совсем не претендую на то, что в настоящей статье представлен исчерпывающий список особенностей SharePoint, из-за которых администраторам приходится рвать на себе волосы; она всего лишь дает представление о некоторых типичных проблемах. Как следует разобравшись в ограничениях SharePoint и познакомившись с эффективными обходными путями, вы сможете устранить досадные проблемы. И будем с нетерпением ожидать усовершенствований, которые обязательно появятся в версии SharePoint 2010. 

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF