У нас есть ферма из 2 серверов под управлением MOSS 2007 SP1. Я являюсь членом группы администраторов на обоих серверах.
Я также являюсь членом группы администраторов фермы.
Мне нужно было обновить несколько решений, поэтому, естественно, я начал с команды stsadm retractsolution для старых решений. Независимо от того, какое решение я пытаюсь запустить, я получаю ответ «Доступ запрещен».
К счастью, файл журнала ULS дает мне немного больше информации:
System.Data.SqlClient.SqlException: Cannot open database "SharePoint_AdminContent" requested by the login. The login failed. Login failed for user '***My Domain Login***'.
Что здесь кажется странным, так это то, что SharePoint пытается подключиться к МОЙ учетная запись с использованием встроенной проверки подлинности Windows вместо подключения к настроенной учетной записи службы фермы. Конечно, у моей учетной записи нет доступа к базе данных Admin Content.
Итак, вопрос: нужно ли моей учетной записи предоставлять разрешения на базу данных Admin Content для выполнения задач администрирования? Я очень надеюсь, что нет, значит, что-то еще ужасно не так?
Короткий ответ - «да» для большинства действий, которые вы будете выполнять с помощью STSADM в отношении баз данных SQL.
Для подавляющего большинства команд STSADM, которые выполняются непосредственно для SharePoint API (а не для планирования задач для выполнения действия), контекст безопасности, в котором выполняются команды, принадлежит вам - пользователю, выполнившему вход. Как вы видели в приведенном вами примере, ваш контекст учетной записи пользователя - тот, который будет использоваться для отзыва. Если у вас нет соответствующих прав в SQL для выполнения операции, она завершится ошибкой (как вы видели).
Это контрастирует с большинством действий, которые вы будете выполнять через пользовательский интерфейс (то есть через Central Admin). В приведенном вами примере отзыв решения через Central Admin приведет к тому, что команда будет выполняться в контексте учетной записи службы фермы, поскольку эта учетная запись является идентификатором пула приложений для сайта Central Admin. Результат: отзыв будет успешным, даже если у вас (лично) нет прав доступа к связанной базе данных.
Если ваша среда настроена так, что ваша учетная запись не имеет доступа на уровне администратора к базам данных в ферме SharePoint, я бы рекомендовал выполнять как можно больше действий через пользовательский интерфейс, чтобы избежать проблем контекста безопасности, с которыми вы сталкиваетесь. . Вы обнаружите, что таким образом можете делать большую часть того, что вам нужно. Однако на ум приходит одно примечательное исключение: добавление решения (STSADM -o addolution) в хранилище решений фермы - не существует аналога UI для команды STSADM.
В качестве альтернативы вы можете сделать что-то похожее на то, что предлагает MadlyAlive (т. Е. Войти в систему с учетной записью службы фермы) ... хотя доступ локального администратора для учетной записи службы фермы не требуется и не рекомендуется Microsoft. Вы также могли бы предоставить вашей учетной записи минимальный набор разрешений внутри SQL Server, необходимых для выполнения ваших операций.
Дополнительные сведения см. В статье базы знаний Microsoft по адресу http://support.microsoft.com/kb/896148.
Резюме эмпирического правила: STSADM использует контекст вашей учетной записи, Central Admin использует контекст учетной записи службы фермы.
Надеюсь, это поможет!
Это позволяет избежать основной проблемы, но при попытке запустить аналогичную команду stsadm
stsadm -o preupgradecheck
Я также получал отказано в доступе. Но запуск командной строки от имени администратора позволил мне запустить ее.