Управление корпоративными проектами с помощью SharePoint - Полномочия базы данных сеанса
ОГЛАВЛЕНИЕ
Полномочия базы данных сеанса
Если решено расширить веб-узел по умолчанию, убедитесь, что для пула приложений используется учетная запись домена — см "Plan for Administrative and Service Accounts (Office SharePoint Server)" («Планирование для административных и служебных учетных записей (Office SharePoint Server)») — в противном случае придется столкнуться с касающимися решений проблемами после предоставления веб-узлов PWA, которые, как правило, проявляют себя в обычно неинформативном сообщении об ошибках SharePoint, подобном изображенному на рис. 4.
Рис. 4. Ошибка при доступе к базе данных SSP
Чтобы найти более осмысленную информацию, следует проверить журналы трассировки, расположенные в каталоге %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\LOGS. Это может быть долгой и нудной задачей, если в ферме есть несколько серверов интерфейса пользователя со сбалансированной нагрузкой.
В целях поиска и устранения неполадок лучше изменить запись DNS для имени узла PWA так, чтобы она временно указывала на единственный сервер интерфейса пользователей. Этим способом можно узнать, какой сервер обрабатывает клиентские запросы, так что необходимо будет лишь проверить файлы журнала трассировки этого одного сервера.
Откройте последний файл журнала в блокноте и найдите запись "Cannot open database." Если она там есть, то ясно, что существует проблема с полномочиями для базы данных. Например, в журнале трассировки на рис. 4 показано, что у учетной записи LITWARE\WSS02$ нет доступа к базе данных SharedServices1_DB. Это ясно говорит, что веб-узел PWA работает с удостоверением сетевой службы.
LITWARE\WSS02$ — учетная запись компьютера веб-сервера интерфейса пользователей, а SharedServices1_DB — база данных поставщика общих служб. Среди прочего, серверы веб-интерфейса используют данные состояния сеанса ASP.NET в таблице ASPStateTempSessions, но у LITWARE\WSS02$ нет доступа к этой базе данных.
Важно отметить необходимость включить базу данных поставщика общих служб в еженедельные действия по обслуживанию баз данных, чтобы гарантировать стабильную работу системы. Например, следует удалить просроченные данные о состоянии сеанса из ASPStateTempSessions путем использования команды SQL TRUNCATE TABLE ASPStateTempSessions, как задокументировано в "Deploy Project Server 2007 to a Server Farm Environment" («Развертывание Project Server 2007 в среде фермы серверов»).
Проблемы настройки, связанные с Network Service (сетевой службой), могут быть запутанными, так что я рассмотрю их подробнее. Учетные записи доменов (такие как LITWARE\SspConfigAdmin) работают для пулов приложений в фермах серверов, поскольку они идентичны на всех компьютерах. Напротив, учетная запись сетевой службы (NT AUTHORITY\NETWORK SERVICE) различается на всех компьютерах. На сервере интерфейса пользователей, именуемом wss02.litware.com, учетная запись NT AUTHORITY\NETWORK SERVICE преобразуется в LITWARE\WSS02$. Но на сервере sql01.litware.com учетная запись NT AUTHORITY\NETWORK SERVICE преобразуется в LITWARE\SQL01$. В этом и заключается проблема.
Если изучить полномочия SQL Server для SharedServices1_DB в SQL Server Management Studio, можно увидеть, что учетная запись NT AUTHORITY\NETWORK SERVICE имеет полномочия db_owner в попытке дать пулам приложений, использующим учетную запись сетевой службы, доступ к базе данных поставщика общих служб. Но помните, что это работает только в установке с одним сервером.
Все назначения полномочий можно исправить, прямо дав LITWARE\WSS02$ и всем другим учетным записям серверов WSS (возможно LITWARE\WSS01$ и так далее) полномочия db_owner для SharedServices1_DB, но лучше вместо этого использовать учетные записи доменов для пулов приложений, чтобы все серверы интерфейса пользователей использовали то же удостоверение, которому SharePoint дала требуемые полномочия для базы данных.