Come risolvere gli errori di accesso negato con stsadm -o retractsolution

Abbiamo una server farm 2 che esegue MOSS 2007 SP1. Sono un membro del gruppo Administrators su entrambi i server.

Sono anche membro del gruppo Amministratori agricoli.

Avevo bisogno di aggiornare alcune soluzioni, quindi naturalmente ho iniziato con il comando stsadm retractsolution sulle vecchie soluzioni. Indipendentemente dalla soluzione che tento di eseguire il comando, torno "Accesso negato".

Il file di registro ULS fortunatamente mi dà qualche informazione in più:

System.Data.SqlClient.SqlException: Impossibile aprire il database "SharePoint_AdminContent" richiesto dall'account di accesso. Accesso fallito. Accesso non riuscito per l'utente "*** Accesso al mio dominio ***".

Ciò che sembra strano qui è il fatto che SharePoint sta tentando di connettersi con l' account MY utilizzando l'autenticazione integrata di Windows invece di connettersi con l'account del servizio farm configurato. Ovviamente il mio account non ha accesso al database dei contenuti di amministrazione.

Quindi la domanda è: al mio account devono essere concesse le autorizzazioni per il database dei contenuti di amministrazione per eseguire le attività di amministrazione? Spero proprio di no, quindi qualcos'altro è terribilmente sbagliato?

La risposta breve è "sì" per la maggior parte delle attività che eseguirai tramite STSADM su database SQL.

Per la stragrande maggioranza dei comandi STSADM che vengono eseguiti direttamente contro l'API di SharePoint (piuttosto che pianificare le attività per eseguire un'azione), il contesto di sicurezza all'interno del quale vengono eseguiti i comandi è tuo: l'utente che ha effettuato l'accesso. Come hai visto nell'esempio che hai citato, il contesto del tuo account utente è quello che verrà utilizzato per la retrazione. Se non disponi dei diritti appropriati in SQL per eseguire l'operazione, l'operazione fallirà (come hai visto).

Ciò è in contrasto con la maggior parte delle attività che eseguirai attraverso l'interfaccia utente (ovvero, amministratore centrale). Nell'esempio citato, ritirare la soluzione tramite Amministrazione centrale comporterebbe l'esecuzione del comando nel contesto dell'account del servizio farm, poiché tale account è l'identità del pool di applicazioni per il sito di amministrazione centrale. Risultato: la ritrattazione avrà esito positivo anche se (personalmente) non si dispone delle autorizzazioni per il database associato.

Se il tuo ambiente è configurato in modo tale che il tuo account non abbia accesso a livello di amministratore ai database all'interno della farm di SharePoint, ti consiglio di svolgere quante più attività possibili attraverso l'interfaccia utente per evitare il tipo di problemi del contesto di sicurezza che stai riscontrando . Scoprirai che puoi fare la maggior parte di ciò che devi fare in quel modo. Un'eccezione notevole che viene in mente, tuttavia, è l'aggiunta di una soluzione (STSADM -o addizione) all'archivio della soluzione della farm: non esiste alcuna controparte dell'interfaccia utente per il comando STSADM.

In alternativa, potresti fare qualcosa di simile a quanto suggerito da MadlyAlive (ovvero, accedere con l'account del servizio farm) ... sebbene l'accesso di amministratore locale per l'account del servizio farm non sia richiesto né raccomandato da Microsoft. Potresti anche avere il tuo account concesso il set minimo di autorizzazioni all'interno di SQL Server necessarie per eseguire le tue operazioni.

Per ulteriori discussioni, consultare l'articolo KB di Microsoft all'indirizzo http://support.microsoft.com/kb/896148 .

Riepilogo della regola empirica: STSADM utilizza il contesto dell'account, Central Admin utilizza il contesto dell'account del servizio farm.

Spero che questo possa essere d'aiuto!

Questo potrebbe evitare il problema principale, ma quando si tenta di eseguire un comando stsadm simile

stsadm -o preupgradecheck

Stavo ricevendo anche Accesso negato. Ma l'esecuzione del prompt dei comandi come amministratore mi ha permesso di eseguirlo.