"SharePoint 2010" にカテゴリー登録されている85 投稿

カスタム タイマージョブ展開時の注意事項

カスタム タイマージョブ開発を行う場合の、SharePoint 2010 および 2013 共通の注意事項について記載しておきます。

カスタム タイマージョブの登録は、サイト コレクションなどのフィーチャーの Activated イベントなどを使って行いますが、当該フィーチャーを非アクティブ化した後で再びアクティブ化しようすとるとエラーが発生してアクティブ化できなくなることがあります。

ULSログを確認すると、次のような「アクセスが拒否されました」というエラー情報のエントリーが確認できます。

2014-06-26 17-38-56

この事象については、マイクロソフト社の KB に情報が公開されていますので詳細は下記を確認してください。

SharePoint 2010 から導入された新しいセキュリティ機能の影響で、Microsoft.SharePoint.Administration 名前空間内の SPPersistedObject から派生したオブジェクトへのあらゆる変更はブロックされ、コンテンツを保持するWebアプリケーション側から構成データベースを更新することは許可されないようになっています。この新しい機能は、SPWebServie.RemoteAdministratorAccessDenied プロパティで制御されています。

そのため、こうしたエラーが発生した場合は、必要に応じてWindows PowerShell などを使って、このプロパティ値を false に変更し、IISReset を行います。

[SharePoint管理シェルの例]


#RemoteAdministratorAccessDenied プロパティを確認する
>$contentService=[Microsoft.SharePoint.Administration.SPWebService]::ContentService
>$contentService.RemoteAdministratorAccessDenied
#この機能をオフにする
>$contentService.RemoteAdministratorAccessDenied=$false
>$contentService.Update()
>IISRESET


SharePoint Web Services 証明書変更による不具合

SharePoint Server 2010 および SharePoint Server 2013 の Web フロントエンドの IIS サーバー上には SharePoint Web Services という名前のサイトが作成されています。

2014-04-03 11-16-17

このサイトはサービス アプリケーションが使用します。HTTP (TCP 32843)  および HTTPS (TCP 32844) を使用できるようになっていますが、HTTPS のバインドでは証明書が未選択になっています。

2014-04-03 11-16-29[バインド設定]

そこで手動で任意の証明書に変更すると、Secure Store Services が利用できないなど不具合が発生します。

たとえば Secure Store Services の管理ページにアクセスするとアクセス権限がないというメッセージが表示されてしまうようになります。

2014-04-03 11-17-38 [Secure Store Services にアクセスしたところ]

イベントログにも下記のようなエラーが記録されます。

2014-04-03 11-20-06

また、SharePoint Server 2013 の Access Services 2013 などにも影響がでてしまい、アプリケーションの利用、新規作成、削除などができなくなります。

対処方法

対処方法は netsh コマンドを使って、SharePoint 内部で使用している証明書に戻すことです。IIS管理マネージャーのGUIからは設定できません。

SharePoint サーバー上のローカル コンピュータの証明書管理コンソールを起動すると、[SharePoint]ノード内に 3つの証明書が既定で追加されていることがわかりますが、このうちの SharePoint Services の証明書を SharePoint Web Services サイトに設定しなおす必要があります。

2014-04-03 13-43-59

まず、SharePoint Web Services サイトに割り当てた証明書を削除するため次のコマンドを実行します。ちなみに、証明書の直接削除は GUI からは行えません。

netsh http delete sslcert ipport=0.0.0.0:32844

続いて SharePoint Serviceの証明書を追加するのですが、拇印とアプリケーションIDの指定が必要です。拇印については、証明書管理コンソールから証明書のプロパティを表示すれば確認できます。

2014-04-03 13-48-58

アプリケーションIDについては、SharePointでは基本共通となるため次のコマンドを実行し、取得します。


netsh http show sslcert

2014-04-03 13-52-18

以上を踏まえ、SharePoint Services の証明書の追加は次のようなコマンドを実行することになります。


netsh http add sslcert ipport=0.0.0.0:32844 certhash="c4ac6c96e4f24e1822dfb474ef2dcb7378038bc5" appid="{4dc3e181-e14b-4a21-b022-59fc669b0914}" certstorename=SharePoint

コマンド実行後に SharePoint Web Services サイトのバインドを確認すると、証明書は再び未選択のままとなりますが実際には設定されています。この後は、Secure Store Services 管理ページなどは問題なくアクセスできるようになるはずです。

参考資料

[SharePoint 2010] Sandbox ソリューションのエラー対応

SharePoint 2010 でサンドボックス ソリューションとして Web パーツ開発などする場合、いざWebパーツをページに追加しようとすると、次のようなメッセージが表示されてしまうことがあります。

「Sandboxed Code host Services が ビジー状態で要求を処理できなかったので、セキュリティで保護されたコード実行要求が拒否されました」

この手のエラーが表示されることは意外と多くあります。対処方法が次のマイクロソフト社のサイトに記載されていますので、問題に遭遇したらこのURLを参考にするとよいです。

Error: "The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request" (Ricky Kirkham)

ちなみに、私の環境でも同様のエラーが出ていたのですが、上記情報のうち "レジストリーを修正する" 手順で治りました。よく見ないと間違いがわからないので気を付けてください。レジストリの値が "0x00023c00" ではなく、"0x00023e00 " になっている必要があります。

簡単に手順を書くと次の通りです。

1. Windows サービスの管理コンソールを開き、SharePoint 2010 User Code Host サービスのログオン ユーザー アカウントを確認する。

2.SharePoint 管理シェルを起動し、次のコマンドを実行して1のサービスで使用しているユーザーアカウントの SID を調べる。
> (Get-SPManagedAccount -Identity "ドメイン名\ユーザー名").Sid.Value

3.レジストリ エディタを起動し 次のレジストリキーを確認する。

>HKEY_USers\<2で取得したSID>\SOFTWARE\Microsoft\Windows\CurrentVersion\MinTrus\Trust Providers\SoftwarePublishing

4.State キーの値が "0x00023e00" となっていることを確認する。異なっている場合は修正する。

5. 全サーバーのSharePoint 2010 User Code Host サービスを再起動する。

 

この手のトラブルに見舞われず、開発作業に専念したいものです。


[TIPS] クライアント オブジェクト モデルをページロード時に呼び出す

SharePoint 上のページに JavaScript Object Model を使ったコードを実装する場合、ページ ロード時に関数を呼び出したいことがあります。

この場合は _spBodyOnLoadFunctionNames.push() メソッドを使うのが一般的です。通常のWebサイトであれば、Body要素の Load イベントを利用するところですが、SharePoint のコンテンツ ページ上からは Body 要素の Load イベントに直接追加できません。

そのために用意されているのが _spBodyOnLoadFunctionNames 配列であり、push メソッドに呼び出したい関数名を指定します。

しかし、クライアント オブジェクト モデルを使う場合にこれを用いてしまうと、呼び出しに必要な SP.JS ファイルがロードされる前に関数が呼び出されてしまうのでうまくいきません。

このようなケースでは ExecuteOrDelayUntilScriptLoaded 関数を利用すると便利です。


SharePoint Web アプリケーションの認証モードの確認

SharePoint 2010 からSharePoint Web アプリケーションに認証モードが導入されました。

SharePoint Web アプリケーション作成時には、クラシック認証モードとクレームベース認証モードのいずれかを指定する必要があります。

SharePoint 2010 ではマイクロソフトの推奨はクレームベース認証モードではありますが、GUI (サーバー全体管理サイト)から作成する場合は既定値が クラッシック認証だったことや他のカスタム ソリューションとの関係もあり、実際にはクラシック認証モードにしているケースも多いようです。

SharePoint 2013では認証モードはクレームベース認証モードが主体であり、クラシック認証モードは基本的に使用しません。そうでないと Office Web Apps など、様々な機能が利用できません。 たとえば、SharePoint 2013 では OAuth 2.0 がサポートされていますが、このプロトコルを使うにはクレームベース認証モードになっていなければなりません。したがって、SharePoint 2013 で SharePoint Web アプリケーションをGUI から作成する場合、認証モードの選択画面がそもそもありません。最初からクレームベース認証モードです。

SharePoint 2013 の新規導入は別として、こうした観点から、今後既存環境をアップグレードをすることを視野に入れておく場合は、できるだけクレームベース認証にしておいた方がよいと言えます。特にカスタム ソリューションを構築しているのであればクレームベース認証モードで動作するよう十分に動作検証をし、アップグレードに備える必要があります。※ここで述べているのはあくまでも認証モードのことであり、認証方法ではありません。クレームベース認証モードでは、Windows 認証、フォームベース認証、SAMLトークンベース認証のいずれかを使用できます。

認証モードの確認

現在利用している SharePoint Web アプリケーションの認証モードを確認するには[サーバー全体管理]サイトから確認できます。ただし、切り替えは Windows PowerShell からしか行えません。そのため Windows PowerShellからの確認方法と認証モードの切り替え方法を整理しておくことは大切です。

設定を確認する

現在のSharePoint Web アプリケーションがクレームベース認証モードになっているかどうかは、次のコマンドを実行します。True になっていれば、クレームベース認証モードです。False の場合はクラシック認証モードです。

$webApp= Get-SPWebApplication http://sp2013 $webApp.UseClaimsAuthentication

SPWebApp-AuthMode

[SharePoint 2010 の場合] クレームベース認証モードに変更する (※クラシック認証にするには$false を設定する)

SharePoint 2013 に移行する前に先にSharePoint 2010上で認証モードを変更しておくには次のコマンドを実行します。

$webApp= Get-SPWebApplication http://sp2013 $webApp.UseClaimsAuthentication=$true; $webApp.Update()

[SharePoint 2013 の場合] クレームベース認証モードに変更する

SharePoint 2010 からの移行では、データベース アタッチを行います。先に SharePoint 2013 上でSharePoint Web アプリケーションを既定のクレームベース認証で作成したあと、SharePoint 2010 で利用していたコンテンツDBをアタッチします。その後、アタッチしたコンテンツDBがクラッシック認証モードとなっていた場合は、次のコマンドを実行します。

Convert-SPWebApplication -Identity "http://sp2013" -To Claims -Retain Permissions

詳細については下記の記事を参照してください。