Como resolver erros de acesso negado com stsadm -o retractsolution

Temos um farm de 2 servidores executando o MOSS 2007 SP1. Eu sou um membro do grupo Administradores nos dois servidores.

Também sou membro do grupo Administradores de Farm.

Eu precisava atualizar algumas soluções, então naturalmente comecei com o comando stsadm retractsolution nas soluções antigas. Não importa qual solução tente executar o comando, recebo 'Acesso negado'.

Felizmente, o arquivo ULS Log me fornece um pouco mais de informação:

System.Data.SqlClient.SqlException: Não é possível abrir o banco de dados "SharePoint_AdminContent" solicitado pelo logon. O login falhou. Falha no login para o usuário '*** Login no meu domínio ***'.

O que parece estranho aqui é o fato de o SharePoint estar tentando se conectar à MINHA conta usando a Autenticação Integrada do Windows em vez de se conectar à conta de serviço do Farm configurada. É claro que minha conta não tem acesso ao banco de dados de Conteúdo do administrador.

Portanto, a pergunta é: Minha conta precisa de permissões para o banco de dados de Conteúdo do administrador para executar tarefas de administração? Eu certamente espero que não, então algo mais está terrivelmente errado?

A resposta curta é "sim" para a maioria das atividades que você realizará via STSADM nos bancos de dados SQL.

Para a grande maioria dos comandos STSADM executados diretamente na API do SharePoint (em vez de agendar tarefas para executar uma ação), o contexto de segurança no qual os comandos são executados é seu - o usuário conectado. Como você viu no exemplo que você citou, o contexto da sua conta de usuário é o que será usado para a retirada. Se você não tiver os direitos apropriados no SQL para executar a operação, ela falhará (como você viu).

Isso contrasta com a maioria das atividades que você realiza por meio da interface do usuário (ou seja, Central Admin). No exemplo que você citou, a retirada da solução via Administrador Central resultaria na execução do comando no contexto da conta de serviço do farm, pois essa conta é a identidade do pool de aplicativos do site do Administrador Central. Resultado: a retração seria bem-sucedida, mesmo que você (pessoalmente) não tenha permissões para o banco de dados associado.

Se o seu ambiente estiver configurado de forma que sua conta não tenha acesso em nível de administrador aos bancos de dados no farm do SharePoint, eu recomendaria a realização de tantas atividades quanto possível por meio da interface do usuário para evitar o tipo de problemas de contexto de segurança que você encontra . Você descobrirá que pode fazer a maior parte do que precisa fazer dessa maneira. Uma exceção notável que vem à mente, no entanto, é adicionar uma solução (STSADM -o addolution) ao armazenamento de soluções do farm - não existe contrapartida da interface do usuário ao comando STSADM.

Como alternativa, você poderia fazer algo semelhante ao sugerido pelo MadlyAlive (por exemplo, fazer login com a conta de serviço do farm) ... embora o acesso do administrador local à conta do serviço do farm não seja exigido nem recomendado pela Microsoft. Você também pode ter sua conta com o conjunto mínimo de permissões necessárias dentro do SQL Server para executar suas operações.

Para mais discussão, consulte o artigo da KB da Microsoft em http://support.microsoft.com/kb/896148 .

Recapitulação da regra geral: o STSADM usa o contexto da sua conta, o Central Admin usa o contexto da conta do serviço de farm.

Eu espero que isso ajude!

Isso pode estar evitando o problema principal, mas ao tentar executar um comando stsadm semelhante

stsadm -o preupgradecheck

Eu estava recebendo acesso negado também. Mas executar o prompt de comando como administrador me permitiu executá-lo.