Как устранить ошибки Access Denied с помощью stsadm -o retractsolution

У нас есть 2 серверная ферма с MOSS 2007 SP1. Я являюсь членом группы администраторов на обоих серверах.

Я также являюсь членом группы администраторов фермы.

Мне нужно было обновить несколько решений, поэтому, естественно, я начал с команды stsadm retractsolution для старых решений. Независимо от того, какое решение я пытаюсь выполнить, я получаю ответ «Отказано в доступе».

Файл журнала ULS, к счастью, дает мне немного больше информации:

System.Data.SqlClient.SqlException: Невозможно открыть базу данных «SharePoint_AdminContent», запрошенную при входе в систему. Ошибка входа. Не удалось войти в систему для пользователя «*** Мой домен Логин ***».

Здесь кажется странным тот факт, что SharePoint пытается подключиться к моей учетной записи с помощью встроенной проверки подлинности Windows вместо подключения с настроенной учетной записью службы фермы. Конечно, моя учетная запись не имеет доступа к базе данных Admin Content.

Поэтому возникает вопрос: нужно ли моей учетной записи предоставлять разрешения для базы данных Admin Content для выполнения задач администрирования? Я надеюсь, что нет, так что-то еще не так?

Краткий ответ «да» для большинства действий, которые вы будете выполнять через STSADM с базами данных SQL.

Для подавляющего большинства команд STSADM, которые выполняются непосредственно с API-интерфейсом SharePoint (вместо планирования задач для выполнения действия), контекст безопасности, в котором выполняются команды, принадлежит вам - зарегистрированному пользователю. Как вы видели в приведенном вами примере, контекст вашей учетной записи пользователя будет использоваться для отвода. Если у вас нет соответствующих прав в SQL для выполнения этой операции, она потерпит неудачу (как вы видели).

Это контрастирует с большинством действий, которые вы будете выполнять через пользовательский интерфейс (то есть Central Admin). В приведенном вами примере откат решения через Central Admin приведет к выполнению команды в контексте учетной записи службы фермы, поскольку эта учетная запись является удостоверением пула приложений для сайта Central Admin. Результат: откат пройдет успешно, даже если у вас (лично) нет прав доступа к связанной базе данных.

Если ваша среда настроена так, что ваша учетная запись не имеет доступа на уровне администратора к базам данных в ферме SharePoint, я бы рекомендовал выполнять как можно больше действий с помощью пользовательского интерфейса, чтобы избежать проблем с контекстом безопасности, с которыми вы сталкиваетесь. , Вы обнаружите, что можете сделать большую часть того, что вам нужно сделать таким образом. Однако в голову приходит одно заметное исключение - добавление решения (STSADM -o addolution) в хранилище решений фермы - аналога пользовательского интерфейса для команды STSADM не существует.

В качестве альтернативы вы можете сделать что-то похожее на то, что предлагает MadlyAlive (то есть войти в систему с учетной записью службы фермы) ... хотя доступ локального администратора для учетной записи службы фермы не требуется и не рекомендуется корпорацией Microsoft. Вы также можете предоставить своей учетной записи минимальный набор разрешений внутри SQL Server, необходимый для выполнения ваших операций.

Дополнительную информацию см. В статье Microsoft KB по адресу http://support.microsoft.com/kb/896148 .

Напомним, практическое правило: STSADM использует контекст вашей учетной записи, Central Admin - контекст учетной записи службы фермы.

Надеюсь, это поможет!

Это может избежать основной проблемы, но при попытке запустить аналогичную команду stsadm

stsadm -o preupgradecheck

Я также получал отказано в доступе. Но запуск командной строки от имени администратора позволил мне запустить ее.