MOSS 2007 SP1を実行している2サーバーファームがあります。私は両方のサーバーのAdministratorsグループのメンバーです。
また、Farm Administratorsグループのメンバーでもあります。
いくつかのソリューションをアップグレードする必要があったので、当然、古いソリューションでstsadmtractsolutionコマンドを使い始めました。コマンドを実行しようとするソリューションに関係なく、「アクセス拒否」が返されます。
幸い、ULSログファイルには、もう少し情報が含まれています。
System.Data.SqlClient.SqlException:ログインによって要求されたデータベース「SharePoint_AdminContent」を開けません。ログインに失敗しました。ユーザー「*** My Domain Login ***」のログインに失敗しました。
ここで奇妙に思われるのは、SharePointが構成済みのファームサービスアカウントではなく、Windows統合認証を使用して[〜#〜] my [〜#〜]アカウントで接続しようとしているという事実です。もちろん、私のアカウントには管理コンテンツデータベースへのアクセス権がありません。
したがって、問題は、管理タスクを実行するために、アカウントに管理コンテンツデータベースへのアクセス許可を付与する必要があるかどうかです。私は間違いなく願っていますが、他にひどく間違っているものはありますか?
短い答えは、SQLデータベースに対してSTSADMを介して実行するほとんどのアクティビティについては「はい」です。
(アクションを実行するタスクをスケジュールするのではなく)SharePoint APIに対して直接実行される圧倒的多数のSTSADMコマンドの場合、コマンドが実行されるセキュリティコンテキストは、サインインユーザーです。引用した例で見たように、yourユーザーアカウントコンテキストが撤回に使用されるものです。 SQLで操作を実行するための適切な権限がない場合、(ご覧のとおり)失敗します。
これは、UIを介して実行するほとんどのアクティビティ(つまり、中央管理)とは対照的です。引用した例では、中央管理を介してソリューションを撤回すると、ファーム管理アカウントのコンテキスト内でコマンドが実行されます。これは、そのアカウントが中央管理サイトのアプリケーションプールIDであるためです。結果:関連付けられたデータベースへの権限が(個人的に)ない場合でも、撤回は成功します。
アカウントがSharePointファーム内のデータベースへの管理者レベルのアクセス権を持たないように環境が設定されている場合は、UIを通じてできるだけ多くのアクティビティを実行して、発生しているセキュリティコンテキストの問題の種類を回避することをお勧めします。その方法で必要なほとんどのことを実行できることがわかります。ただし、頭に浮かぶ1つの注目すべき例外は、ソリューション(STSADM -o addsolution)をファームソリューションストアに追加することです。STSADMコマンドに対応するUIはありません。
または、MadlyAliveが提案したもの(つまり、ファームサービスアカウントでのログイン)と同様のことを行うこともできますが、ファームサービスアカウントのローカル管理者アクセスは、Microsoftによって要求も推奨もされていません。操作を実行するために必要なSQL Server内の最小限の権限セットをアカウントに付与することもできます。
詳細については、MicrosoftのKB記事 http://support.Microsoft.com/kb/896148 を参照してください。
要約すると、STSADMはアカウントコンテキストを使用し、サーバーの全体管理はファームサービスアカウントコンテキストを使用します。
これが役に立てば幸いです!
これはコアの問題を回避している可能性がありますが、同様のstsadmコマンドを実行しようとすると
stsadm -o preupgradecheck
Access Deniedも受け取っていました。しかし、管理者としてコマンドプロンプトを実行すると、コマンドプロンプトを実行できました。