Управление корпоративными проектами с помощью SharePoint - Службы MOPS и учетные записи служб

Службы MOPS и учетные записи служб

После решения вопроса о связи между серверами интерфейса пользователей и баз данных должна появиться возможность доступа к Project Web Access. Ура! Теперь можно уделить внимание более сложной проблеме, касающейся MOPS. Сделайте глубокий вдох и откройте журнал событий приложений на своем сервере приложений MOPS — не удивляйтесь, если увидите тысячи и тысячи сообщений об ошибках, заявляющих "Queue system could not start" («Система очередей не смогла запуститься, как показано на рис. 7. Можно также заметить, что службы MOPS задействуют почти 100% ресурсов ЦП.

Рис. 7. The Queue system could not start

Система очередей является основой инфраструктуры приложений MOPS для вставки баз данных MOPS и обработки запросов на обновление, выполняя задачи очистки и обслуживания, а также обновляя базу данных отчетов для использования в задачах анализа данных. Это подробно описано в статье "Microsoft Office Project Server 2007 Queuing System" («Система очередей Microsoft Office Project Server 2007»). Согласно этой статье, система очередей полагается на службу Windows, реализованную в сборке Microsoft.Office.Project.Server.Queuing.exe и работающую под удостоверением администратора настройки SharePoint и учетной записи службы таймеров для доступа к базе данных настройки фермы.

При запуске служба Windows извлекает список всех SSP из базы данных настройки, включая соответствующие учетные записи администратора SSP и их зашифрованные пароли, а затем запускает дополнительный процесс Microsoft.Office.Project.Server.Queuing.exe для каждого из SSP, связанных с веб-узлами PWA, в контексте соответствующей учетной записи администратора SSP. Другими словами, Microsoft.Office.Project.Server.Queuing.exe запускает несколько экземпляров самого себя под различными учетными записями, так что общее число процессов Microsoft.Office.Project.Server.Queuing.exe, работающих на сервере приложений MOPS, равно числу SSP плюс один.

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

На сервере приложений MOPS в ферме с одним SSP, связанным с веб-узлами PWA, можно увидеть два процесса Microsoft.Office.Project.Server.Queuing.exe – один работающий от имени учетной записи администрирования настойки, а другой от имени учетной записи администратора SSP. В моей тестовой среде этими учетными записями являются WssConfigAdmin и SspConfigAdmin, как показано на рис. 8.

Рис. 8. Сбой связи между процессами из-за отказа в доступе

Так почему же система очередей не запускается? Запись об ошибке в событии приложения не предоставляет достаточной информации, но дополнительные сведения о ней можно получить, если установить уровень сообщений о наименее важных ошибках в журнале трассировки на «подробный» на вкладке операций области ведения журнала диагностики в центре администрирования SharePoint 3.0.

На рис. 8 показан получившийся журнал трассировки, а если взглянуть на него ближе, то можно увидеть, что ProjectQueueService (общая служба Window) запускает QueueExecService (рабочий процесс очереди), но процесс QueueExecService терпит сбой из-за отказа в доступе. Когда это происходит с QueueExecService, ProjectQueueService пытается перезапустить его, но опять же терпит сбой по той же самой причине, в результате чего время процессора продолжают расходоваться, а журналы событий и трассировки заполняются тысячами ошибок. Это бесконечный цикл.

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

Если изменить учетную запись администратора SSP в центре администрирования SharePoint 3.0 и указать учетную запись администрирования настройки (WssConfigAdmin), то система очередей запустится. Это также работает в обратную сторону, можно просто оставить учетную запись администратора SSP неизменной (SspConfigAdmin) и использовать ее как учетную запись службы для службы Windows, система очередей также запустится.

Тогда оказывается логичным, что и учетная запись администрирования настройки, и учетная запись администратора SSP требуют полномочий; просто система очереди не запускается, если ProjectQueueService и QueueExecService используют различные учетные записи.

Это ясное указание на проблему с полномочиями между различными процессами, желающими взаимодействовать друг с другом на локальном компьютере. В конце концов, ProjectQueueService и QueueExecService должны наблюдать друг за другом, чтобы гарантировать единообразное поведение службы (отметьте записи ProcessWatcher в журнале трассировки на рис. 8). Например, при отключении службы Windows ProjectQueueService должны отключиться и рабочие процессы QueueExecService.

К ошибке ведет попытка получить доступ к процессу, работающему в ином контексте безопасности. Доступ к процессу в ином контексте безопасности требует повышенных полномочий. Хотя учетная запись службы и может иметь эти полномочия, Windows Server 2008 все так же отказывает в доступе, поскольку контроль учетных записей пользователей (User Account Control – UAC) по умолчанию включен, что заставляет процессы работать со стандартным уровнем полномочий.

Как только UAC отключен, ProjectQueueService и QueueExecService получают возможность работать с повышенными полномочиями, и система очередей запускается. Пользователь может выбрать, использовать ли учетную запись администрирования настройки как учетную запись администратора для всех SSP, выполняя тем самым все процессы с помощью одной и той же учетной записи, либо ослаблять безопасность на серверах приложений MOPS путем отключения UAC.