こんにちは、SharePoint サポートの森 健吾 (kenmori) です。今回の投降では、以下に記載している COMException (0x800703FA) について、他サイトに記載されているよりも少しだけ深くお話しますので、問題解決にお役立ていただければと思います。
出力されるエラー
System.Runtime.InteropServices.COMException (0x800703FA): CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} を含むコンポーネントの COM クラス ファクトリを取得中に、次のエラーが発生しました: 800703fa。
1. 発生シナリオと対処策について
影響箇所としては COM の仕組みを使用するサービス アプリケーション全体であり、この現象が発生するとバックエンド サービスの機能が全く使用できなくなります。
実際にお問い合わせを経験しているのはSearch Service Application, Excel Service, PowerPoint Service などがあり、これらのサービスが影響を受けてしまった場合、結果的にクロールや検索、Office Web Apps、Excel Service を使用したブラウザによるファイルを表示することができなくなるため、システムの稼働に影響する状況を招きます。
また、カスタム コードがサービス アプリケーションやそれに依存するインスタンス (例. コンテンツ ソース etc.) を生成する際にも現象発生する場合があります。急に発生すると慌てることになりますが、対処策はありますので速やかに対処しましょう。
対処策
1) gpedit.msc を実行します。2) 画面左のツリーより "コンピュータの構成" - "管理用テンプレート" - "システム" と展開し、[ユーザー プロファイル] を選択します。3) "ユーザーのログオフ時に強制的にユーザー レジストリをアンロードしない" を "有効" に設定し、[OK] をクリックします。4) サーバーを再起動します。
- 補足 グループ ポリシーにてポリシーを管理している場合は、ドメイン コントローラ上でグループ ポリシー エディターを開き、上述の設定を変更ください。
おそらく、多くのブログ等で上記までの情報を記載している状況です。それでも回避はできますので問題ないかと思いますが、運用環境においては原因や対処策が実際に発生している現象と合致しているかなどの認識を合わせる必要があることを想定しております。
以下に本現象の原因について、開発者ではない管理者の方々が疑問を払しょくできるレベルを目指し少しだけ詳細に記載します。
2. COMException (0x800703FA) の発生原因を理解する
アプリケーションがあらかじめ前処理にて取得し正常に操作を完了できたレジストリ ハンドルを使って、再度同じハンドルを使ってレジストリ キーにアクセスする際に対象のキーそのものが削除されてしまっていることを認識した際に 0x800703FA (ERROR_KEY_DELETED) は一般的に発生するエラーです。
Windows API の観点から補足すると、Windows API を使用してプログラミングを実装する際の一般的な流れは、以下のような流れになります。
1) Windows が保持するリソースをアクセスするためのハンドルを取得する。2) ハンドルを使用して Windows リソースを操作する。
ハンドルという用語を理解するために、文字通り車と車のハンドルを想像してください。Windows プログラミングではハンドルを取得した上であらためて Windows リソースをコントロールするようなコードになります。
この現象は 1) で過去に取得していたレジストリ キーを、2) で操作しようとした際に対象のキーが消えてしまっているという現象です。つまり、ハンドルだけ残されて車が盗まれたような状況です。なぜ消えてしまったと認識しているのでしょうか。これを理解するためには、Windows のユーザー プロファイルを少し理解する必要があります。
3. Windows のユーザー プロファイルについて
Windows ユーザー プロファイルには、一般的にユーザーが端末に最初にログインした際に生成されるユーザーごとのリソースが含まれます。代表的な例として、%systemdrive%\users フォルダ配下に存在する各ユーザーのフォルダ (MyDocuments や Desktopを含む) や、レジストリ (HKEY_CURRENT_USER) があります。
これらのリソースは、ユーザーの対話的なログオンや該当ユーザーのプロセスがプロファイル ロードを要求した際にワークステーションのメモリ上にマッピングされ、使用できる状態になります。上記の前提をもとに特筆すべきこととして、Windows Server 2008 から、ユーザー プロ���ァイルのロードが抑制され、さらに強制的にアンロードするような動作も追加されました。これは、かねてから以下のような状況が報告されていたことに起因します。
(1) バックグラウンド サービスを含むプロセス内にてユーザー プロファイルのロードがシステム リソースの使用率を高めること(2) アカウントのログオフ時に競合が発生することがある (前回のセッションがプロファイルのアンロード先のディスクをロックし、次回のログオンがその情報をディスクから読み込めず、キャッシュから制限付きでロードされてしまうなど)
(1) についてはあらかじめバックエンドのシステムがプロファイルをロードしないようにすることで対処できます。プロファイルをロードしないような設定は IIS のアプリケーション プールの設定等にも追加されています。また、運用的にもバックグラウンド サービスが LOCALSERVICE や NETWORKSERVICE などのようなアカウントを使用すれば、これらのアカウントはプロファイルを持たない特殊なユーザーであるため問題を回避できます。ただし、SharePoint のような AD にアクセスするなどの特別な要件がある場合は、ドメイン ユーザーの権限でサービスを動作させる必要があるため、プロファイルを持たないこれらのアカウントをサービスの実行アカウントに指定することが現実的ではありません。そのため、SharePoint は本現象の影響を受けることがやむを得ない条件に該当します。
(2) については今回の投稿にて記載した通りユーザー プロファイルを適時アンロードすることで対処できます。このアンロードについては、以下のようなイベントログが出力されたタイミングで実行されます。プロセス内でプロファイルに対する参照がなくなったタイミングで実行されます。ただし、そのタイミングで他プロセスがユーザープロファイル リソース内のハンドル (レジストリ ハンドル等) を保持している場合は、その後のアプリケーションの動作に影響を与えてしまう動作となります。
イベント ID : 1530レベル: 警告,ソース : Microsoft-Windows-User Profiles Service,イベント ID : 1530,タスク カテゴリ : なし,"レジストリ ファイルは他のアプリケーションまたはサービスで使用されています。ファイルはすぐにアンロードされます。レジストリ ファイルを保持しているアプリケーションまたはサービスはこれ以降正しく機能しない可能性があります 詳細 - 4 user registry handles leaked from\Registry\User\S-1-5-21-574761793-3042057060-3609535109-1106_Classes:Process2884 (\Device\HarddiskVolume1\Windows\System32\inetsrv\w3wp.exe) has opened key\REGISTRY\USER\S-1-5-21-574761793-3042057060-3609535109-1106_CLASSESProcess2884 (\Device\HarddiskVolume1\Windows\System32\inetsrv\w3wp.exe) has opened key\REGISTRY\USER\S-1-5-21-574761793-3042057060-3609535109-1106_CLASSESProcess5828 (\Device\HarddiskVolume1\Windows\System32\inetsrv\w3wp.exe) has opened key\REGISTRY\USER\S-1-5-21-574761793-3042057060-3609535109-1106_CLASSESProcess5828 (\Device\HarddiskVolume1\Windows\System32\inetsrv\w3wp.exe) has opened key\REGISTRY\USER\S-1-5-21-574761793-3042057060-3609535109-1106_CLASSES"
上述の回避策 "ユーザーのログオフ時に強制的にユーザー レジストリをアンロードしない" を “有効” にした場合は、強制的にアンロードしない代わりに以下のようなイベントログが出力されるよう変更になります。
イベント ID : 1517レベル : 情報,ソース : Microsoft-Windows-User Profiles Service,イベント ID : 1517,タスク カテゴリ : なし,"ログオフ時にアプリケーションまたはサービスがレジストリをまだ使用している間に、Windows はユーザー S-1-5-21-574761793-3042057060-3609535109-1106 のレジストリを保存しました。ユーザーのレジストリによって使用されたメモリは解放されていません。レジストリは使用されなくなったときにアンロードされます。ユーザー アカウントとしてサービスを実行していることが原因と考えられます。 LocalService または NetworkService アカウントでサービスを構成してみてください。
イベント ID : 1512レベル : 情報,ソース : Microsoft-Windows-User Profiles Service,タスク カテゴリ : なし,"レジストリ ファイルをアンロードできません。レジストリに使用されたメモリが解放されていません。ユーザー アカウントとしてサービスが実行されていることが原因と考えられます。LocalService または NetworkService アカウントでサービスを実行してみてください。詳細 - このメディアは書き込み禁止になっています。
この設定を、SharePoint サーバー端末に対して実施することによるリスクは極めて低く、これまでに問題は報告されておりません。ただし、万が一繰り返しログオン時にキャッシュから制限付きでプロファイルがロードされてしまうような事象が SharePoint サーバー端末で頻発する場合には、システムでプロファイルをロックしてしまう処理が存在する等異なる問題が発生している可能性がありますので別途対処が必要となります。
タイトル : イベント ID: 1530 Windows Vista または新しいコンピューター上のアプリケーション ログに記録されることがあります。アドレス : http://support.microsoft.com/kb/947238
4. COM＋ コンストラクタについて
最後にレジストリとサービスの関係について少しだけ説明します。SharePoint の一部のサービス アプリケーションは COM を使用したインスタンスの生成を使用しているようです。COM クラス ファクトリを使用する場合、レジストリの HKEY_CLASSES_ROOT (HKCR) 配下のエントリを読み込んで該当のCOM サーバー (例. mssearch.exe など) に接続する動作となります。
HKEY_CLASSES_ROOT について
このキー配下の情報は、実は HKEY_CURRENT_USER (HKCU) と HKEY_LOCAL_MACHINE (HKLM) 配下の情報がマージされる形で表示されています。この HKEY_CLASSES_ROOT 配下のキーにアクセスすると、プロファイルがロードされている場合は優先的に HKEY_CURRENT_USER\Software\Classes 配下のキーにアクセスし、プロファイルがアンロードされているときには HKEY_LOCAL_MACHINE\Software\Classes 配下のキーにアクセスする動作となります。
タイトル : HKEY_CLASSES_ROOT Keyアドレス : http://msdn.microsoft.com/en-us/library/ms724475(VS.85).aspx
例えば、プロファイルがロードされていた状態でw3wp.exe 内で HKCU キー配下のレジストリ キーのハンドルを保持していた場合、OWSTIMER.EXE の再起動のタイミングなどで該当ユーザーのプロファイルの実態がアンロードされ、該当ユーザーのレジストリ HKCU キー配下の情報などがディスクに保存されてメモリ マッピングから削除される状態を想定します。
この場合、w3wp.exe 内で保持しているハンドルを持って再度サービス アプリケーションを起動するための処理を行った場合、HKLM 配下にキーが存在したとしても HKCU 配下のキーが削除されていると判断されエラーが発生する動作となります。
これは、HKCR レジストリ キーを指定して取得する際に、その時はプロファイルが正常にロードされていたことから、HKCU キーにアクセスしてレジストリ情報を取得するようにハンドルが作られているからです。
5. まとめ
イベント ID 1530 が発生している場合、実影響が出ていないとしてもポリシーを変更して、現象発生を防ぐ措置を実施しておくことが得策と考えます。是非とも上述の情報を運用においてお役立ていただけますと幸いです。
こんにちは SharePoint サポートの森 健吾 (kenmori) です。
今回の投稿では、SharePoint Server におけるページについて理解した上で、SharePoint Designer (以下 SPD) を使用して標準のマスタ ページや、ASPX ページをカスタマイズした際の動きを説明します。
SPD は、FrontPage から派生した SharePoint 専用のページ編集ツールとして活躍してきた背景があります。その他にも、ワークフロー、外部コンテンツ タイプなど様々なカスタマイズが実施できるツールとして規模拡張してきました。ただし、SPD 2013 ではデザイン ビューが削除され、ページ編集ツールとしては規模縮小してきている感覚もうかがえます。
今回の投稿では、このツールが実施していることを理解し、注意点等をあらかじめ確認できるようにしていきたいと考えています。
参考情報 : ダウンロード サイト
SPD は以下のダウンロード サイトから無料でダウンロードできます。製品バージョンと同じ SPD を入手して使用ください。また、最新の修正プログラムについても確認し、合わせて適用ください。
タイトル : SharePoint Designer 2013アドレス : http://www.microsoft.com/ja-jp/download/details.aspx?id=35491
タイトル : Microsoft SharePoint Designer 2010 (32 ビット版)アドレス : http://www.microsoft.com/ja-jp/download/details.aspx?id=16573
タイトル : Microsoft SharePoint Designer 2010 (64 ビット版)アドレス : http://www.microsoft.com/ja-jp/download/details.aspx?id=24309
SPD は、Office ファミリーの製品となりますため、SharePoint Foundation サポートや Office 共通コンポーネントなどのモジュールがインストールされます。
クライアント PC にインストールする際に、異なるバージョンの Office と同一環境にインストールする際 (例. Office 2010 + SharePoint Designer 2013) には、コンポーネント間におけるバージョン差異により、細かな機能の動作に影響を及ぼす可能性も想定されます。この点につきましてもあらかじめご確認ください。
1. SharePoint における標準のページについて
SharePoint 標準のページには、Web パーツ ページ、Wiki ページ、発行ページなどがあります。
ユーザーは[サイトの操作] – [ページの編集] (または [*] – [ページの編集] ) をクリックしてページを編集することができます。SharePoint におけるページはページ上に配置された表示コントロールが動的に別途格納されたデータを参照して、表示を構成する動作となります。つまり、ページをカスタマイズしても標準ではテキストファイルで保存されている ASPX ページの定義を直接書き変えない構造となります。
・Web パーツ ページは、コンテンツ DB 内 WebParts テーブル内に Web パーツの各種プロパティ情報をもとにページを構成します。・Wiki ページは、ページ リスト アイテムの "WikiField" 列にリッチテキストで編集した情報をもとにページを構成します。・発行ページは、アイテムが所属するコンテンツ タイプをもとに別途保存されたページ レイアウトにリダイレクトし、マスタ ページ (*.master) + ページレイアウト (*.aspx) でページを構成した後、アイテムが保持する列情報の値をページ上に動的に配置して表示を構成します。それに加えて Web パーツページと同様の動作も行います
このように SharePoint は、ASPX ページ定義を編集することなく、動的にユーザー操作によるページ設定の情報を保持するような仕組みを実装しています。
タイトル : Web ページを計画するアドレス : http://technet.microsoft.com/ja-jp/library/cc263106(v=office.14).aspx
2. SPD でページをカスタマイズする
SPD でページを標準モードでカスタマイズすると、ページの編集画面でカスタマイズするよりも少しだけ拡張したカスタマイズができます。主な SPD 標準モードのページ カスタマイズ用途は、以下となります。
・リッチ テキスト上で、HTML コントロールを視覚的に挿入してデザインする。・Web パーツのプロパティ等の設定を変更する・リスト ビュー Web パーツのカスタマイズ・ユーザー設定のリスト フォームのカスタマイズ
ページを開いた際に黄色く表示される箇所 (下図) は編集不可能ですので、カスタマイズする必要がある場合は詳細モードに切り替える必要があります。
ページを詳細モードで開くと一言でいえば、上記のブロックを解除し ASPX ページのコードを直接書き換えるカスタマイズが可能です。つまり、上述した SharePoint 標準モードでは Wiki 編集コントロールや Web パーツなどの各種コントロールが変更内容を ASPX に保存することなく制御していましたが、ASPX を書き換えるようにすることでこの制限を超えたカスタマイズが可能となります。
ただし、この操作を実施して ASPX ページのコードを直接書き換えると、運用上のデメリットが生じます。この内容については、本投稿 4. にて詳細にご説明します。
3. リスト ビュー Web パーツをカスタマイズする
サーバー レンダリング時におけるリスト ビュー (XsltListViewWebPart) のXSL カスタマイズは標準モード (詳細モードなし) での編集で実現可能です。
XsltListViewWebPart の XSL はこれまで記載した通り WebParts テーブルに保存することが可能です。SPD 上で記述したコードは ASPX ページ上にコードとして保存されるのではなく、構文チェックされた上で WebParts テーブル側に格納される動作となります。SPD で再度ページを開くと ASPX 上にコードの実体があるように見えますが、これは SharePoint がページを取り出す際に様々な処理が動いています。改めてページを開いた際に、保存した通りに表示されてこない場合があるのは、このためだったりします。
(参考情報)ASPX ページ上に実際に保存されている定義情報が何かを確認したい場合、Web フォルダ (\\MachineName\DavWWWRoot\) を開いて該当ページを開き ASPX などの定義を確認すれば一目瞭然です。
SPD で XSL を編集した場合、アプリケーション プール リサイクルをしなくても、動的に変更を適用することが可能です。カスタマイズが施されたページ表示処理では XSL の更新日時等を表示の度に毎回チェックし、必要に応じてキャッシュの更新タイミングをうかがうような処理となります。
しかし、これまでの情報を見る限り、詳細モードでカスタマイズしてないため問題ないように見えますが、柔軟に動作設計を変更できる反面、XSL 変更によりコンパイルとキャッシュの動作は標準処理から変更されるため、パフォーマンスは劣化します。
SPD で XSL をカスタマイズした際によくある事象としては、以前多田さんのブログ投稿に記載したような現象が報告されていますので、運用上注意が必要となります。
タイトル : Web パーツのエラーでページが表示できない場合のトラブルシューティングアドレス : http://blogs.technet.com/b/sharepoint_support/archive/2013/10/10/a.aspx
4. サイト定義ファイル (ゴースト ファイル) をカスタマイズする
上記の通り SPD を使用して、標準モードが提供しているカスタマイズ範囲を超える大きな変更を加える場合、詳細モードでページをカスタマイズする必要があります。しかしその場合、ASPX ページのサイト定義変更されたページが元となる定義ファイルから分離され、複製されたバイナリがコンテンツ DB に保存されて別途管理されます。
(補足)上記のような動作を、弊社サイトでは、「ページのカスタマイズ」、「サイト定義の適用解除」、「実体化」、「ゴースト解除」といった様々な言葉で呼びます。この投稿では、他の意味に捉えられる危険性のない「ゴースト解除」という用語を選択します。
この種のカスタマイズを実施した際には以下のデメリットについて最初に考慮する必要があります。
ゴースト解除のデメリット
・修正プログラム等でサイト定義ファイルに変更を加えても、コンテンツ DB 内に分離してバイナリが保管されているため反映されない。・コンテンツ アクセス毎に、データベースからバイナリ データを取り出す必要が生じるためパフォーマンスが劣化する。
つまり、ゴースト解除にならないように可能な限り調整した方が賢明です。
4-1. サイト定義ファイル (ゴースト ファイル) とは
サイト定義ファイルと呼ばれるページはゴースト ファイルとも呼ばれ、SharePoint ファイルは物理ファイルとして SharePoint Server 端末上に配置されたものを参照しており、要求された際にはワーカープロセス内でページ コンテンツをキャッシュして、以後高速にページを描画することができます。
(説明 : C:\Program Files\Common Files\Microsoft Shared\web server extensions\<ver>\TEMPLATE フォルダからの相対パスが AllDocs テーブル内に格納されています。)
サイト定義ファイルは、例えば以下のようなファイルを含みます。
・SharePoint 標準のマスタ ページ (例. default.master)・フォーム (例. ListForm.aspx) などの ASPX ページ・ページ レイアウト・スタイル ライブラリにある CSS, XSL および JavaScript 表示テンプレート・ソリューション パッケージで展開されたカスタム サイト定義ファイル
これらのサイト定義ファイル (ゴースト ファイル) をテキスト エディター等で編集して、メモリ キャッシュをフラッシュするためにアプリケーション プールをリサイクルすると、このページを参照しているすべてのサイト コレクション上に配置された同一ファイル (ページやマスタ ページ等) に修正が反映されます。
一般的に製品の修正プログラムがサイト コンテンツを修正する場合は、この仕組みを利用して広範囲に修正を適用する動作となります。
タイトル : サイト定義と構成アドレス : http://msdn.microsoft.com/ja-jp/library/aa978512(office.14).aspx?lc=ja-JP
(注意)サイト定義ファイルのカスタマイズを行う際には、事前にバックアップを取り、問題があったら元のファイルと差し替えることを忘れないようしてください。カスタマイズされた後の状態では、弊社およびサードパーティ製製品開発元のサポートが受けられない可能性があります。また、アーキテクチャの説明のため、データベースやテーブルに対する言及を行っておりますが、これらの設計は公開されておりません。そのため、今後同一の設計を維持するお約束はできず、予期せず変更される可能性があります。特に直接 SQL を実行して更新系の処理を実行するようなシステムを作成した場合、該当コンテンツ データベース自体が弊社サポート対象外となりますため絶対にやめてください。
4-2. サイト定義ファイルのカスタマイズ (ゴースト解除) とは
SPD によるゴースト解除は、通常以下のダイアログで [はい] を押した際に実施されます。SPD 2007 まではページ編集によって無条件でゴースト解除されていましたが、SPD 2010 以降ではページを詳細モードで開いて保存した場合に、以下のダイアログが表示されゴースト解除されます。
SPD を使用する以外でも、該当コンテンツをローカルに [エクスポート]、[コピーのダウンロード] し、そのファイルを編集してアップロードして上書きしてもゴースト解除となります。または、バージョン管理画面から、旧バージョンのファイルに戻しても別途ストアされたファイルが新しいバージョンのファイルとして上書きされるので同じ状況になります。
ゴースト解除された状態では、コンテンツのバイナリ コピーがコンテンツ データベース(AllDocStream, DocStream) に格納されます。サイト定義ファイルに元に戻すことは可能ですが、基本的にサイト定義ファイルとはファイルの内容が分離され別のファイルとして管理されるという点と、個別にカスタマイズされた内容をメモリ内にキャッシュできる余裕はありませんので毎回読み込まれる動作となり、上述に記載したデメリットにつながる結果となります。
技術的な詳細はさておき、結果的に上記の通り、運用面において以下のような影響を生じさせることを把握しておく必要があり、重要ですので再度記載します。
なお、このような相違があることを考慮し、必要性もなくとりあえず [詳細モード] で開くなど、むやみにゴースト解除するような操作は避けた方が良いでしょう。
4-3. カスタマイズ状態 (ゴースト解除) を確認する方法
以下は、指定されたページがカスタマイズされているかどうかを確認するための PowerShell コマンド例です。
$web = Get-SPWeb http://sharepoint/sites/site/$file = $web.GetFile("http://sharepoint/sites/site/_catalogs/masterpage/v4.master")$file.CustomizedPageStatus
(結果) Uncustomized ・・・ ゴースト ファイルのまま Customized ・・・ ゴースト解除されたファイル None ・・・ 単なるコンテンツ ファイル (例. ユーザーが任意にアップロードしたファイル等)
なお、サイト定義ファイルに戻すには以下の 4 つの方法があります。
方法 1) PowerShell を続けて実行します。
$file.RevertContentStream()
方法 2) SPD で [サイト定義にリセット] をクリックします。
上記のコマンドはSPD でファイルを選択し、[サイト定義にリセット] をクリックすることと同等です。
(補足 : ファイル名の左に情報アイコンがついているものは、ゴースト解除されたファイルです。)
方法 3) サイトの操作からサイト定義にリセット操作を行います。
ブラウザー操作からは、ゴースト解除されている状況は確認できませんが、リセットは可能です。
以下の画面で対象のファイルを指定し、サイト定義にリセットします。
5. 意図せぬサイト定義ファイルのカスタマイズ (ゴースト解除)を防ぐ
非常によくあるお問い合わせとして Wiki ページのサイト定義ファイルをカスタマイズ (ゴースト解除) すると以下の画面 (現在のページは、元のテンプレートからカスタマイズされています。[テンプレートの状態に戻します。]) が表示されます。Wiki ページは、ゴースト解除しなくてもかなりの幅のソリューションを提供可能です。
この現象でお問い合わせいただくほとんどの場合が、SPD で意図せず詳細モードでページを開いて保存した場合や、バージョン履歴の画面から旧バージョンの Wiki ページに戻した結果、旧 ASPX ページが現在の ASPX ページを上書きしゴースト解除された場合となります。
ゴースト解除を意図していない場合は、画面上のリンクをクリックするなどして元のテンプレートの状態に戻しておくことをお勧めします。
もしも、SPD で Web パーツや Wiki エリアを超える範囲にカスタマイズを加える等、意図してゴースト解除されている場合で、これを非表示にしたい場合は標準機能では実現できません。メッセージバーコンテンツがページ ロード時のスクリプトで遅延ロードされることを考慮し、その処理の後でメッセージ バーに後付でスタイル (display: none) を指定して非表示にするくらいしか現実的な方法としてはないでしょう。
また、"SharePoint の全体管理サイト" の [SharePoint Designer 設定] 画面では、SPD の詳細モードなど、カスタマイズ範囲を制限する設定などもあります。ご参考にしていただけますと幸いです。
タイトル : Sharepoint Designer 2010 を管理するアドレス : http://office.microsoft.com/ja-jp/sharepoint-designer-help/HA101838275.aspx
まとめ
SPD によるページ編集は、局所的に、直感的に、スピーディにかつ柔軟にページ デザインを変更することに向いています。ただし、規模を拡大して使用すれば、サイト定義ファイルから分離され、アップグレード面やパフォーマンス面のデメリットが生じます。
カスタマイズの対象は、特定のサイトやページといった局所的なシナリオに限定されます。SPD では、カスタマイズ操作の自動化や、多数のサイトに横展開する方法がない点等の制約事項があります。
このように、大規模なシステムで大量サイトに渡るコンテンツをカスタマイズするといった要件には現実的にそぐわない側面もあり、その際は開発工数が発生しますが Visual Studio を使用したソリューション等 (Web パーツやカスタム サイト、リスト定義等) を代替として検討した方が現実的ということになります。
これからも、SPD を使用した際の問題やトラブルシューティングに関する情報をご紹介していく予定ですが、本投稿についてはそれらのベースとなる情報となりますため、参考情報としていただけますと幸いです。
皆さんこんにちは。SharePoint サポート チームの荒川です。
User Profile Service アプリケーションとサイト コレクションの同期についてはこれまでに何度か記事で取り上げてきましたが、今回は様々な技術情報サイト (マイクロソフト公式サポート技術情報や TechNet、MSDN ブログの過去の記事など) に分散されている情報を集約した形でまとめ記事を作成してみました。情報量が大変多いため、一度に全部読むことは難しいかもしれませんが、目次のリンクを活用いただくことでページ内を簡単にジャンプできるようにしていますので、包括的な情報源としてご活用ください。
目的この資料では、User Profile Service アプリケーションとサイト コレクションの間でユーザー プロファイルが同期される仕組みと、それに関連するトラブルシューティングの方法について解説します。
免責事項本投稿内容については SharePoint 製品サポート チームにおいてレビュー済みの内容となりますが、マイクロソフトの公式文書ではありませんのでご了承ください。本投稿内容は今後定期的に最新の情報を反映するようにメンテナンスしていく予定です。そのため、新たな情報が得られた際には適宜更新される可能性があります。
対象製品本資料は、SharePoint Server 2013 を対象にしていますが、SharePoint Server 2010 および Office SharePoint Server 2007 についても一部同様にご参照いただけます。
目次
動作の解説このセクションでは User Profile Service アプリケーションとサイト コレクションの間でユーザー プロファイルが同期される仕組みについて解説します。
サイト コレクションのユーザー情報についてサイト コレクションのユーザー情報とは、主に SharePoint サイト上におけるユーザーの表示名などのユーザー情報に利用される情報を指します。サイト コレクションのユーザー情報が利用��れる個所は主に以下となります。
<目次に戻る>
サイト コレクションのユーザー情報とユーザー プロファイルの関係サイト コレクションのユーザー情報は、ユーザー プロファイルのユーザー情報とは独立した形でサイト コレクション内に保存されます。したがって、ユーザー プロファイルのユーザー情報とサイト コレクションのユーザー情報はそれぞれ異なるものとして扱われます。
〔ユーザー プロファイルのユーザー情報〕≠〔サイト コレクションのユーザー情報〕
詳細については後述の「ユーザープロファイルの情報がサイト コレクションのユーザー情報に自動的に反映される仕組み」セクションで詳しく解説しますが、AD 上でユーザー情報を更新した後、User Profile Service アプリケーションで同期を行いユーザー プロファイルのユーザー情報を更新したとしても、直ぐにサイト コレクションのユーザー情報に反映されるわけではありません。
サイト コレクションのユーザー情報の確認方法と編集方法サイト コレクションのユーザー情報の確認方法と編集方法は、サイト コレクションが User Profile Service アプリケーションと関連付けられているかどうかによって変わります。サイト コレクションが含まれる Web アプリケーションが User Profile Service アプリケーションと関連付けられていない環境または、SharePoint Foundation では、サイト コレクションのユーザー情報はユーザーが自分で編集して管理します。ユーザーは自身の個人用設定から、サイト コレクションのユーザー情報ページ (<サイト コレクション>/_layouts/15/userdisp.aspx) にアクセスしてユーザー情報の確認と編集ができます。
SharePoint Server で User Profile Service アプリケーションが構成されていた場合は、サイト コレクションのユーザー情報がユーザー プロファイルの情報から管理タイマージョブにより自動同期されるため、ユーザーが自分でサイト コレクションのユーザー情報を管理することはできません。ユーザーは自身のユーザー プロファイルページ (<個人用サイトのホスト>/Person.aspx) にアクセスしてユーザー プロファイル情報の確認と、管理者によって許可されているプロパティの編集ができます。ユーザー プロファイルの情報は定期的に実行される管理タイマー ジョブによってサイト コレクションのユーザー情報に反映されます。
なお、過去に一度でも User Profile Service アプリケーションに関連付けてプロファイルの同期対象となったサイト コレクションでは、後から User Profile Service アプリケーションの関連付けを解除した場合であってもサイトのユーザー情報をユーザー インターフェイス上から変更することができなくなります。この場合、サイト コレクションのユーザー情報ページ (<サイト コレクション>/_layouts/15/userdisp.aspx) にアクセスできるようにはなりますが、アイテムの編集をクリックしてもプロパティを編集できません。
サイト コレクションの管理者は「<サイト コレクションの URL>/_catalogs/users」または「<サイト コレクションの URL>/_layouts/15/people.aspx?MembershipGroupId=0」に直接アクセスすることで、サイト コレクションに含まれるユーザーの一覧 (ユーザー情報リスト) を確認し、必要に応じてサイト コレクションのユーザー情報を管理できます。
SharePoint Foundation ではユーザー情報リストの一覧から任意のユーザー名をクリックすることで、各ユーザーのサイト コレクションのユーザー情報の編集ページ (<サイト コレクション>/_layouts/15/userdisp.aspx) にジャンプして、ユーザー情報を編集できます。
SharePoint Server では、ユーザー情報リストの一覧からユーザー名をクリックした際の動作がユーザー プロファイルの有無により異なります。対象のユーザーのユーザー プロファイルが存在する場合には、ユーザー名をクリックした際にユーザーのプロファイル ページ (<個人用サイトのホスト>/Person.aspx) にジャンプします。対象のユーザーのユーザー プロファイルが存在しない場合 (サイトに権限を登録した直後や User Profile Service アプリケーションが存在しない場合など) には、ユーザー名をクリックした際に SharePoint Foundation と同様にサイト コレクションのユーザー情報の編集ページ (<サイト コレクション>/_layouts/15/userdisp.aspx) にジャンプしますが、Web アプリケーションが User Profile Service アプリケーションに関連付けられており、過去にサイト コレクションでプロファイルの同期が実行されたことがある場合にはアイテムの編集はできません。
サイト コレクションの管理者は以下のPowerShell スクリプトを使用することで、User Profile Service アプリケーションの関連付けの有無にかかわらず、サイト コレクションのユーザー情報を直接参照および編集できます。
(サンプル コード)
User Profile Service アプリケーションにインポートされたユーザー プロファイルの情報の確認方法と編集方法User Profile Service アプリケーションにインポートされたユーザー プロファイルの情報は以下の方法で確認および編集できます。
(手順) ユーザーが User Profile Service アプリケーションにインポートされたユーザー プロファイルの情報を確認および編集する方法
(手順) 管理者が User Profile Service アプリケーションにインポートされたユーザー プロファイルの情報を確認および編集する方法
また、以下の PowerShell スクリプトではユーザー プロファイルにインポートされたユーザー情報をテキスト ファイルに出力して確認できます。
(サンプル コード) GetUserProfileData.ps1
サイト コレクションのユーザー情報が登録されるタイミングサイト コレクションのユーザー情報が登録されるタイミングは次のとおりです。
この時、その時点でのユーザーの表示名や電子メールアドレス、役職や部署などの情報が LDAP クエリを介して取得され、自動的にサイト コレクションのユーザー情報に登録されます。
ユーザー プロファイルの情報が登録されるタイミングユーザー プロファイルのユーザー情報が登録されるタイミングは次のとおりです。
ユーザー プロファイルの情報がサイト コレクションのユーザー情報に自動的に反映される仕組みSharePoint Server では、サイト コレクションのユーザー情報が定期的にユーザー プロファイルの情報と同期されます。Active Directory (AD) で更新されたユーザーの属性情報は、User Profile Service アプリケーションによって SharePoint のユーザー プロファイル情報と同期され、SharePoint のユーザー プロファイル情報はタイマー サービスによって各サイト コレクションのユーザー情報と同期されます。
〔Active Directory〕<=>〔User Profile Service Application〕<=>〔Site Collection〕
したがって、AD の情報をサイト コレクションのユーザー情報に反映させるには、予め User Profile Service アプリケーションに AD の情報を同期しておく必要があります。
プロファイル同期に関連するタイマー ジョブプロファイル同期に関する主なタイマー ジョブは以下の３つです。
パフォーマンスの観点から、クイック同期は SharePoint サイト コレクションに追加した直後のユーザーに対して最初の 1 回のみ実行されます。各タイマー ジョブの設定内容はサーバーの全体管理サイトで [監視] セクションの [ジョブ定義の確認] から変更できます。
ユーザー プロファイルから SharePoint への同期対象になるユーザーと同期対象にならないユーザー既定では、サイト コレクションにおいて「アクティブ ユーザー」と認識されているユーザーのみがユーザー プロファイルから SharePoint への同期対象となります。個人用サイトにおいては、ユーザー自身がサイト コレクションの所有者となるため、ユーザーは必ずアクティブ ユーザーになります。それ以外のサイトにおいて、ユーザーがサイト コレクションの「アクティブ ユーザー」と認識されるためには、以下のいずれかの条件を満たす必要があります。
パフォーマンスの観点より、既定では Active Directory グループを介してサイトに権限を登録されるユーザーのうち、サイトに投稿を行わないユーザー (非アクティブ ユーザー) に対してはユーザー プロファイルの情報が同期されません。つまり、Active Directory グループを介してサイトに権限を登録するユーザーをプロファイルの同期対象にするには、最低限投稿権限以上の権限が必要となります。
また、毎回すべてのユーザー プロファイルが同期の対象となるわけではなく、過去に同期が実行された後、変更が発生したユーザー プロファイルのみが同期の対象となります。User Profile Service アプリケーションのプロファイル データベースでは、ユーザー プロファイルの変更履歴を管理しており、過去に変更された内容が変更ログ (UserProfileEventLog テーブル) として記録されています。ユーザー プロファイルから SharePoint への同期タイマー ジョブが実行される際には、ユーザー プロファイルの変更ログの最終変更日時と、コンテンツ データベース単位で管理している同期情報テーブル (SiteSynch テーブル) の最終更新日時を比較して、前回同期実行日時以降に変更が加えられたユーザー プロファイル情報のみをサイトに同期します。たとえば、User Profile Service アプリケーションにおいて AD から完全同期を実行した後に一度ユーザー プロファイルから SharePoint への同期タイマー ジョブが実行された後、続けて AD から完全同期を実行したとしても、AD 上で特に変更が無ければプロファイルの変更ログにはエントリが記録されませんので、次回の同期タイマー ジョブの実行時にはサイト コレクションに対する同期は発生しません。
非アクティブ ユーザーを同期対象にする方法Active Directory グループを介してサイトに権限を登録されるユーザーのうち、サイトに投稿を行わないユーザー (非アクティブ ユーザー) をプロファイルの同期対象とすることも可能です。非アクティブ ユーザーをプロファイルの同期対象とするには、以下の操作を実施する必要があります。
(手順) 非アクティブ ユーザーをプロファイルの同期対象とする方法
本操作を行うと、ユーザー プロファイルが存在し、サイト コレクションのユーザー情報に登録されたすべてのユーザーがプロファイルの同期対象になります。ユーザー数が多い (数千から数万単位の) 環境ではパフォーマンスの問題を引き起こす可能性がありますので、初回の同期はオフピークの時間帯に行うことをお勧めします。
(補足)
サイト コレクションのユーザー情報にユーザー プロファイルの情報が同期されない場合のトラブルシューティング以下に、サイト コレクションのユーザー情報にユーザー プロファイルの情報が同期されない場合のトラブルシューティングについて記載します。
最初に確認することSharePoint Server においてサイト コレクションのユーザー情報にユーザー プロファイルの情報が同期されない場合は、最初に以下の内容を確認します。
User Profile Service アプリケーションに正しくプロファイル情報がインポートされているかについては、先述の「User Profile Service アプリケーションにインポートされたユーザー プロファイルの情報の確認方法と編集方法」をご参照ください。
対象のユーザーがアクティブ ユーザーかどうか調べるには、コンテンツ データベースの UserInfo テーブルを参照する必要があります。コンテンツ データベースの UserInfo テーブルに対するクエリ結果をテキスト ファイルに出力する PowerShell のサンプル コードを以下に記載します。SQL Server の管理権限がある場合は、SQL Server Management Studio から直接データベースに対してクエリを実行しても構いません。
(サンプル コード) コンテンツ データベースの UserInfo テーブルに対するクエリ結果をテキスト ファイルに出力する PowerShell のサンプル コード
tp_IsActive の値が 1 になっているユーザーはアクティブ ユーザーです。tp_IsActive の値が 0 になっているユーザーは非アクティブ ユーザーです。tp_SiteID の値がサイト コレクションの ID を示します。tp_SiteID の値からサイト コレクションの URL を調べるには以下の PowerShell コマンドを実行します。
Web アプリケーションが User Profile Service アプリケーションに関連付けられているかチェックするWeb アプリケーションが User Profile Service アプリケーションに関連付けられていない場合、プロファイルの同期対象となりません。以下の手順で Web アプリケーションが User Profile Service アプリケーションに関連付けられているか確認します。
(手順) Web アプリケーションの関連付けを確認する
データベースの同期情報をリセットするUser Profile Service アプリケーションのプロファイル データベースでは、コンテンツ データベースとユーザー プロファイルの同期情報が管理されています。この情報には、同期対象となるコンテンツ データベースの ID や、最終同期日時に関する情報が記録されています。何らかの理由でこれらの同期情報の整合性が失われると、同期処理が正常に動作しない場合があります。このような場合には以下のコマンドを実行することで同期情報をリセットし状況を改善できる可能性があります。
注意事項：データベースの同期情報をリセットすると、次回のユーザー プロファイルから SharePoint への完全同期のタイミングで、ユーザー プロファイルが存在し、サイト コレクションのユーザー情報に登録されたすべてのユーザーがプロファイルの同期対象になります。ユーザー数が多い (数千から数万単位の) 環境ではパフォーマンスの問題を引き起こす可能性がありますので、初回の同期はオフピークの時間帯に行うことをお勧めします。
(手順) データベースの同期情報をリセットする
サイト コレクションのクォータ制限に達していないかチェックするサイト コレクションのユーザー情報リストは内部的に特殊なリストとして扱われており、各ユーザー情報は特殊なアイテムとして扱われるため、サイト コレクションがクォータ制限に達しているとユーザー情報を更新できません。以下の手順でサイト コレクションのクォータ制限に達していないか確認します。
(手順) サイト コレクションのクォータ設定を確認する
サイト コレクションがロックされていないか確認するサイト コレクションのユーザー情報リストは内部的に特殊なリストとして扱われており、各ユーザー情報は特殊なアイテムとして扱われるため、サイト コレクションが読み取り専用にロックされているとユーザー情報を更新できません。以下の手順でサイト コレクションがロックされていないか確認します。
(手順) サイト コレクションのロック状況を確認する
コンテンツ データベースが読み取り専用となっていないか確認するコンテンツ データベースが SQL Server において読み取り専用となっていた場合は、データの書き込みに失敗するためプロファイルの同期が行われません。以下の手順でコンテンツ データベースのステータスを確認できます。
(手順) データベースの状態を確認する方法
Web アプリケーションが除外対象に設定されていないか確認するユーザー プロファイルから SharePoint への同期機能では、特定の Web アプリケーションを同期対象から除外するための機能が備わっています。以下のコマンドを入力することで、ひとつまたは複数の Web アプリケーションをプロファイル同期の対象外とできます。
過去に上記コマンドを実行された経緯がある場合、Web アプリケーション単位でサイト コレクションへのプロファイル同期が行われなくなります。設定を元に戻す際には以下のコマンドを入力して設定を初期化します。
過去に設定された経緯が不明な場合は、取り急ぎ上記コマンドを実施することで切り分けが可能です。
なお、設定内容は SharePoint 構成データ オブジェクトとして保存されるため、通常は外部から参照できませんが、構成データベースに対して直接クエリをかけることで値を参照できます。以下のクエリの実行結果より得られた値から m_WebApplicationSyncExcludeList フィールドの値を確認し、Web Application ID の値が入っていれば設定は有効です。
(サンプル コード) PowerShell で構成データベースに対してクエリを実行した結果をテキスト ファイルに出力するサンプル コード
User Profile Service アプリケーションでユーザー プロファイルの同期処理が進行中でないか確認する更新の競合を避けるため、User Profile Service アプリケーションで Active Directory などの外部データソースからプロファイルをインポート (同期) している処理の最中は、サイト コレクションへのプロファイル同期ジョブがスキップされます。前回の同期ジョブの実行時に User Profile Service アプリケーションでユーザー プロファイルの同期処理が進行中であった可能性が考えられる場合には、User Profile Service アプリケーションで同期処理が完了したことを確認してから、サイト コレクションへのプロファイル同期ジョブを実行します。
User Profile Service アプリケーションでユーザー プロファイルの同期処理が進行中かどうかは、以下の方法で確認できます。
(手順) User Profile Service アプリケーションでユーザー プロファイルの同期処理が進行中でないか確認する
データベースがオフラインでないか確認する (MOSS2007 のみ)MOSS2007 の 2009 年 10 月の累積的な更新プログラム (CU ビルド 12.0.6518.5000) 適用前の環境では、コンテンツ データベースがオフライン状態の時にユーザー プロファイルが同期できない問題がありました。現在この問題は改善していますが、MOSS2007 において 2009 年 10 月の CU を適用されていない環境ではご注意ください。
(手順) コンテンツ データベースがオフラインになっていないか確認する方法
コンテンツ データベースまたはサイト コレクションが Moving の状態になっていないか確認する (MOSS2007 のみ)MOSS2007 では、コンテンツ データベースまたはサイト コレクションを移動する前に共有サービス プロバイダとの接続を切るために、「Stsadm -o preparetomove」コマンドを実施する必要がありました。このコマンドを実行すると、対象のコンテンツ データベース ID またはサイト コレクション ID が共有サービス プロバイダ データベースの同期情報管理テーブル (SiteSynch テーブル) に「Moving」状態として登録され、以降のプロファイル同期の対象になりません。データベースやサイト コレクションを別の環境に移動するケースにおいて、移動元の環境でデータが再利用されなければ問題ありませんが、再利用される場合は「Stsadm -o preparetomove」コマンドで「Undo」操作を行わなければならないことに注意してください。
MOSS2007 SP1 の移行シナリオでは、コンテンツ データベースをファームから切り離してアップグレードするシナリオにおいて「Stsadm -o preparetomove」コマンドの実施を行う必要がありました。これは、コンテンツ データベースをファームから切り離して再接続した場合、同じ環境であってもデータベース ID が変わるため、古い情報を共有サービス プロバイダから切り離す必要があったためです。しかしながら、MOSS2007 インフラストラクチャ更新プログラム以降の環境では、同じ環境でコンテンツ データベースを切り離して再接続しても、データベース ID が変わらないように動作が変更されました。このため、MOSS2007 インフラストラクチャ更新プログラム以降の環境において、同じ環境で使用するコンテンツ データベースに対して「Stsadm -o preparetomove」コマンドを実行してしまうと、データベースの再接続後に引き続き「Moving」フラグが付いたままとなり、プロファイル同期が行われなくなります。
(手順) Preparetomove 操作を行ったコンテンツ データベースまたはサイト コレクションを再び同期対象に戻す方法
(参考資料)Preparetomove: Stsadm operation (Office SharePoint Server)http://technet.microsoft.com/en-us/library/cc262122(v=office.12).aspx
Office Server Web Services で使用される自己発行証明書が破損していないか確認する (MOSS 2007 のみ)MOSS 2007 サーバーに Microsoft .NET Framework 3.5 Service Pack 1 が適用された環境では、共有サービス プロバイダによって使用される Office Server Web Services で使用される SSL 自己発行証明書が破損する問題が報告されています。この問題が発生すると、プロファイル同期が正しく動作しなくなり、ユーザープロファイルの情報がサイト コレクションに同期されなくなることが報告されています。現象の詳細および回避策については以下の資料を参照してください。
(参考資料)SSL でセキュリティ保護された Office SharePoint Server 2007 サイトまたは共有サービス プロバイダの [検索の設定] ページを参照できないhttp://support.microsoft.com/kb/962928
その他のトラブルシューティングこのセクションではユーザー プロファイルの同期に関連するその他のトラブルシューティングについて記載します。
Active Directory セキュリティ グループの表示名が更新されないサイト コレクションに登録した Active Directory セキュリティ グループの情報 (表示名、電子メールアドレス) は、プロファイルの同期対象になりません。サイト コレクションに登録した Active Directory セキュリティ グループの表示名を変更するには、以下の手順を実施します。
(手順) サイト コレクションに登録した Active Directory セキュリティ グループの表示名を変更する
通知が設定できずユーザーが有効な電子メールアドレスを持たない旨のメッセージが表示されるサイト コレクションのユーザー情報に電子メール アドレスが登録されていない場合にこの問題が発生します。ユーザー プロファイルが正しく同期されているか確認するとともに、ユーザー プロファイルに電子メールアドレスが登録されているか確認します。必要に応じてサイト コレクションのユーザー情報を手動で編集して電子メールアドレスを登録します。
(関連情報)サイト コレクションのユーザー情報の確認方法と編集方法User Profile Service アプリケーションにインポートされたユーザー プロファイルの情報の確認方法と編集方法サイト コレクションのユーザー情報にユーザー プロファイルの情報が同期されない場合のトラブルシューティング
こんにちは、SharePoint サポートの佐伯です。本投稿では、SharePoint サイトのお知らせアイテムを新着順に表示する Web パーツを作成する方法をご紹介します。今回はコンテンツ検索 Web パーツを使用しますが、コンテンツ検索は検索インデックスに配置されているものを表示できるので、複数のサイト コレクションにまたがるコンテンツや SharePoint の外部コンテンツもクロールされて検索インデックスに配置されていれば表示することができます。複数のサイト コレクションのお知らせアイテムを表示させたい場合はコンテンツ検索 Web パーツが便利です。それでは以下のような表示を目指して作成していきましょう！ページにコンテンツ検索 Web パーツを配置後、以下の手順を実施していきます。1) コンテンツ検索 Web パーツのタイトルを設定する2) 表示するアイテム数を設定する3) クエリを設定する4) アイテム表示テンプレートを設定する5) 管理プロパティのマッピングを設定する1) コンテンツ検索 Web パーツのタイトルを設定する1. [歯車] – [ページの編集] をクリックし、ページを編集モードにします。2. コンテンツ検索 Web パーツの [Web パーツの編集] をクリックします。3. “外観” を展開し、タイトルを設定します。今回は 新着情報 を設定します。4. 枠の種類を タイトルのみ に設定します。2) 表示するアイテム数を設定する1. 表示するアイテム数を設定します。今回は 5 を設定します。3) クエリを設定する1. [クエリの変更] をクリックします。2. [クエリの作成] ダイアログで、[詳細モードへの切り替え] をクリックします。3. クエリ テキストにアイテムを取得する条件を設定します。今回はコンテンツ タイプがお知らせのアイテムを取得するよう、ContentTypeId:"0x0104*" を設定します。※設定後は対象のアイテムが取得できるかを、[テスト クエリ] をクリックして検索結果のプレビューをご確認ください。(補足) コンテンツ タイプ ID の詳細については以下のサイトをご参照ください。タイトル : コンテンツ タイプ IDアドレス : http://msdn.microsoft.com/ja-jp/library/aa543822(v=office.14).aspx4. [並べ替え] タブをクリックし、並べ替えの設定を行います。最終更新日順で取得するよう LastModifiedTime の 降順を設定します。5. [OK] をクリックして [クエリの作成] ダイアログを閉じます。6. ここで一旦 [OK] をクリックして Web パーツを保存し、ページを保存します。4) アイテム表示テンプレートを設定するアイテム表示テンプレートには、コンテンツ検索 Web パーツで表示するアイテムのデザインやレイアウト、表示する情報が定義されています。コンテンツ検索 Web パーツに使用するアイテム表示テンプレートを作成していきましょう。なお、今回の投稿では表示テンプレートの説明は省略させていただきますが、詳細については以下の投稿をご参照ください。SharePoint 2013 検索結果の表示を制御する表示テンプレートSharePoint に既定で用意されているアイテム表示テンプレートをコピーして、新しくアイテム表示テンプレートを作成します。1. [サイトの設定] – [Web デザイナー ギャラリー] - [マスター ページ] にアクセスします。2. [Display Templates]、[Content Web Parts] の順にフォルダを展開し、Item_TwoLines.html ファイルをダウンロードします。3. ダウンロードした Item_TwoLines.html ファイルのファイル名を変更します。ここでは、Item_NewItems.html に変更します。4. Item_NewItems.html ファイルを開き、<div id="TwoLines"> の Id をこの *.html ファイルのファイル名に変更します。 <div id="Item_NewItems">5. <title> には表示テンプレートのタイトルを入力します。<title>新着情報</title>6. <mso:ManagedPropertyMapping> には、結果アイテムで表示する管理プロパティのマッピングを設定します。以下のように変更します。<mso:ManagedPropertyMapping msdt:dt="string">'Link URL'{リンクの URL}:'Path','Line 1'{行 1}:'Title','Line 2l'{行 2 (左)}:'','Line 2r'{行 2 (右)}:'','Line 3'{行 3}:''</mso:ManagedPropertyMapping>(補足) 管理プロパティのマッピングを追加する際は、'Link URL'{リンクの URL}:'Path' のような形式で記述します。Path は取得する管理プロパティです。この管理プロパティは表示テンプレートに記述していなくても問題ありません。[Web パーツの編集] でも設定が可能です。Link URL は結果アイテムの管理プロパティ (ここでは Path) を取得する際に指定するプロパティ名です。Javascript で $getItemValue(ctx, "Link URL") と記述することで管理プロパティ Path を取得することができます。リンクの URL は [Web パーツの編集] で表示されるプロパティ名です。(参考)7. <body> 内に結果アイテムを表示するコードを記述し、保存します。(サンプル コード)<body> <!-- Warning: Do not try to add HTML to this section. Only the contents of the first <div> inside the <body> tag will be used while executing Display Template code. Any HTML that you add to this section will NOT become part of your Display Template. --> <script> $includeLanguageScript(this.url, "~sitecollection/_catalogs/masterpage/Display Templates/Language Files/{Locale}/CustomStrings.js"); </script> <!-- Use the div below to author your Display Template. Here are some things to keep in mind: * Surround any JavaScript logic as shown below using a "pound underscore" (#_ ... _#) token inside a comment.
* Use the values assigned to your variables using an "underscore pound equals" (_#= ... =#_) token. --> <div id="Item_NewItems"><!--#_var encodedId = $htmlEncode(ctx.ClientControl.get_nextUniqueId() + "_2lines_");var linkURL = $getItemValue(ctx, "Link URL");linkURL.overrideValueRenderer($urlHtmlEncode);var iconURL = Srch.ContentBySearch.getIconSourceFromItem(ctx.CurrentItem);var line1 = $getItemValue(ctx, "Line 1");var line2l = $getItemValue(ctx, "Line 2l");var line2r = $getItemValue(ctx, "Line 2r");var line3 = $getItemValue(ctx, "Line 3");line1.overrideValueRenderer($contentLineText);line2l.overrideValueRenderer($contentLineText);line2r.overrideValueRenderer($contentLineText);line3.overrideValueRenderer($contentLineText);var containerId = encodedId + "container";var pictureLinkId = encodedId + "pictureLink";var pictureId = encodedId + "picture";var dataContainerId = encodedId + "dataContainer";var line1LinkId = encodedId + "line1Link";var line1Id = encodedId + "line1";var line2lId = encodedId + "line2l";var line2rId = encodedId + "line2r";var line3Id = encodedId + "line3";_#--> <div id="_#= containerId =#_" data-displaytemplate="ItemNewItems" style='padding-bottom:5px;'> <div class="cbs-Detail" id="_#= dataContainerId =#_"> <a class="ms-noWrap ms-displayBlock ms-rteFontSize-2" href="_#= linkURL =#_" title="_#= $htmlEncode(line1.defaultValueRenderer(line1)) =#_" id="_#= line1LinkId =#_"> _#= line1 =#_ </a><!--#_if(!line2l.isEmpty){_#--> <span class="ms-metadata ms-noWrap" title="_#= $htmlEncode(line2l.defaultValueRenderer(line2l)) =#_" id="_#= line2lId =#_">_#= line2l =#_</span><!--#_}_#--><!--#_if(!line2r.isEmpty){_#--> <span class="ms-metadata ms-noWrap" title="_#= $htmlEncode(line2r.defaultValueRenderer(line2r)) =#_" id="_#= line2rId =#_">_#= line2r =#_</span><!--#_}_#--><!--#_if(!line3.isEmpty){_#--> <div class="ms-srch-item-path ms-noWrap" title="_#= $htmlEncode(line3.defaultValueRenderer(line3)) =#_" id="_#= line3Id =#_">_#= line3 =#_</div><!--#_}_#--> </div> </div> </div></body>これでアイテム表示テンプレートの作成は完了です。8. 編集した Item_NewItems.html をマスター ページ ギャラリーの [Display Templates] - [Content Web Parts] フォルダにアップロードします。9. Web パーツの編集に戻りましょう。ページを編集モードにして、コンテンツ検索 Web パーツの [Web パーツの編集] をクリックします。10. 上記で作成したアイテム表示テンプレートを設定します。5) 管理プロパティのマッピングを設定する上記のアイテム表示テンプレートで定義したフィールドに表示する管理プロパティをマッピングしていきましょう。1. “プロパティのマッピング” を展開し、アイテム表示テンプレートのフィールドに対し、管理プロパティのマッピングを変更します。 にチェックを入れます。2. 以下のように、それぞれの項目に管理プロパティ (Path, Title, LastModifiedTime, EditorOWSUSER, Path) を設定します。3. Web パーツを保存し、ページを保存します。以上でカスタマイズは完了です。
上記の手順は参考例ですので必要に合わせて変更してください。ご参考になれば幸いです。
こんにちは、SharePoint サポートの タノグチです。 前回 ブログをアップさせていただいてから、早くも 数か月たってしまいました。時間が過ぎるのは、本当に早いですね。。。
今回、私がご紹介するのは、Windows 7 の既知問題についてです。 クライアント端末としてWindows 7 を使用し、SharePoint Server のドキュメント ライブラリーに保存されている Office ファイル (Excel や Word など) を 参照しようとすると、参照時間がものすごくかかる！ という問題です。
実はこの現象、クライアント端末が Windows 7 の場合に Internet Explorer オプションの [LAN の設定] にて、"設定を自動的に検出する" にチェックが入っていると発生します。
〇 詳細 〇
⇒ Office ファイルを参照した場合やエクスプローラビューを使用する場合、 WebClient を使用した WebDAV の通信が発生します。
⇒ "設定を自動的に検出する" にチェックが入っている Windows 7 端末で、 WebClient を使用した WebDAV の通信が発生した場合、WPAD (Web プロキシ設定の自動検出) を実施します。
⇒ 自動的に検出するオプションが有効になっているが、自動検出に応えられる構成を整備していない環境では、WPAD による自動構成ファイルをネットワーク環境から検出するための処理 (補足 *1) に大量の時間がかかるため、タイムアウトが発生するまで待つことになります。
⇒ Windows 7 端末で Office 文書の参照を行うと、この “待ち時間” が加算されるため、参照時間が長くなります。
⇒ Windows 7 端末において、WebClient を使用した WebDAV の通信が発生した際に、毎回 Proxy の自動検出を実行し、動作が遅延する点は WebClient モジュールの動作不具合として認識されています。
この遅延は、Web プロキシ設定の自動検出を行える環境であれば発生しませんし、自動検出用の構成ファイルを配置していないネットワーク環境の場合はチェックを外すこと (*下記参照) で回避できます。チェックを外すことで、 Proxy の自動検出はしなくなりますが、もともと上記設定により構成情報を自動検出できない環境のため、問題はありません。
( 補足 *1) 一般的に DHCP サーバー, DNS サーバーに配置された自動構成ファイルを読み込みにいきます。これが存在しない場合は、NetBIOS にて検索しますが、ネットワーク上に存在しない自動構成ファイルを検索するための処理に時間がかかります。詳細につきましては、以下をご確認ください。
タイトル : ブラウザー設定の自動検出と自動構成を有効にする
アドレス : http://technet.microsoft.com/ja-jp/library/cc817419.aspx
〇 解決方法はこちら 〇
1) クライアント マシンにおいて、Internet Explorer を起動します。
2) [ツール] メニューをクリックし、[インターネット オプション] をクリックします。
3) [接続] のタブより、[LAN の設定] をクリックします。
4) [自動構成] の [設定を自動的に検出する] のチェックをはずし、[OK] をクリックします。
5) ドキュメント ライブラリ上の Office 文書を参照し、現象が回避されているか確認します。
この問題は、次期 OS で修正予定 です。残念ですが、現在の OS では 修正予定はありません。。。
2度目のブログ書き込みでも、不具合についてでした…
近々、この件に関して、詳細情報が公開されますので、その際は更新します！
もし、ご意見やご感想等がございましたら本ブログのメニューバーの "EMAIL" フォームにてご連絡をお待ちしております。
今後とも SharePoint 製品をよろしくお願いします。
Tschüs, タノグチ
SharePoint Server 2010 および SharePoint Server 2013 の CU 早見表です。
使い方
1. サーバーの全体管理サイトにアクセスします。2. [システム設定] セクションの [このファームのサーバーの管理] をクリックします。3. 表示された [ファーム サーバー] ページで確認できるファーム バージョンをリストに照らし合わせます。
SharePoint Server 2013
SharePoint Server 2010
今回の投稿では、SharePoint サーバーから Office ファイルをクライアント アプリケーションを使用して開く際の動作について、その仕組みを簡単にご説明します。SharePoint からファイルを開く際の問題に直面した際には、是非トラブルシュートのヒントとしてご使用いただけますと幸いです。
近年 Office は、SharePoint ないしは Web サーバー上にあるファイルと積極的に連携するために、仕組みを増やしてきた経緯があります。ただし、ActiveX、Browser Helper Object をベースに実装しており、また Office という名前が連想しにくい名前であったりするため、特にセキュリティ ソフトなどが検出した際に、無意識に無効にする方も多いと思います。
無効化すると使用できなくなるだけで、それ以外の影響はありません。ただし、業務上必要なコンポーネントを無効化してしまい、ファイルが開けないといった問題を生じさせてしまうことは不本意ですので、簡単な情報公開をさせていただければと思います。
下記にて、SharePoint からファイルを開くにあたりブラウザーから呼び出される優先順位順を含めて、モジュール一覧をご紹介します。
本投稿の構成について
1. ProtocolHandler.exe
2. SharePoint OpenDocuments Class (OWSSUPP.DLL)
3. Office Document Cache Handler (URLREDIR.DLL)
これより、それぞれのコンポーネントの 1) 動作条件 2) 動作説明 3) 動作変更方法 4) よくあるお問い合わせ 5) 開発者向けの情報としてまとめ記載します。
SharePoint のライブラリなどのハイパーリンクから、Office ファイルを直接開く動作を実装しています。プロトコル (例. ms-word: ms-excel: 等) に対応し、ブラウザー プロセス外で Office ファイルを直接開くようにしたプログラムです。
1) 動作条件 (下記を双方満たす)
・Office 2010 SP2、Office 2013 以降
・SharePoint Server 2013 以降、SharePoint Online
2) 動作説明
SharePoint で表示されるドキュメントへのハイパーリンクのクリック イベントで、ファイル拡張子が対応しているプロトコルに合わせて URL (例. ms-word:ofv|u|http://sharepoint/Shared%20Documents/Document.docx) 先にナビゲートした場合に作動します。
レジストリに指定されたプロトコル ハンドラー定義を見てみましょう。ブラウザーは ms-word プロトコルに登録されたハンドラー (PROTOC~1.EXE) を実行するという動作です。
この仕組みでは、ProtocolHandler.exe という外部プログラムによって Office 連携を実装しております。ブラウザー内部でロードされませんので、セキュリティの観点においても優れた方法です。
3) 動作変更方法
SharePoint On-Premise のみ変更可能となりますが、拡張子に対するプロトコル ハンドラーの登録は、サーバー上の下記の XML ファイルで実施しています。
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\XML\DocIcon.xml
この XML ファイルの設定値を (空欄などに) 書き換えて、IISRESET を実施するとクライアント側の動作を変更することができます。
4) よくある問い合わせ
同一端末に旧バージョンの Office 2007 (または Office 2010 RTM, SP1) とOffice 2013 ファミリー製品 (例. Visio, Project, SharePoint Designer 2013) を混在インストールした場合、ProtocolHandler.exe が Office 2007 と連携できないためエラーを出力する場合が想定されます。
この動作は、複数バージョンの Office を混在インストールした際の制限事項となります。
タイトル : Office 2007 または Office 2010 クライアント環境に、Office 2013 アプリケーションを単体でインストールした場合、 SharePoint Server 2013 上の Office ファイルが開けなくなる。
アドレス : http://support.microsoft.com/kb/2874782/ja
5) 開発者向け
プロトコルを接頭辞にした URL を参照先に指定するだけでクライアント アプリケーションとの連携が可能であるため、クライアントとの連携を実装しやすくなりました。
HTML
<a href="ms-word:ofv|u|http://sharepoint/Shared%20Documents/Document.docx">TITLE</a>
JavaScript
location.href = "ms-word:ofv|u|http://sharepoint/Shared%20Documents/Document.docx ";
SharePoint のライブラリなどのハイパーリンクから、Office ファイルを直接開く動作を実装しています。最も古くから存在する方法です。
1) 動作条件(下記を双方満たす)
・サポートされるすべてのバージョンの Microsoft Office
・サポートされるすべてのバージョンの SharePoint Server
SharePoint で表示されるドキュメントへのハイパーリンクのクリック イベントで、onclick イベントの引数に渡されたファイルの拡張子や ProgId などを見て起動します。
Microsoft Office が提供しているものは SharePoint.OpenDocuments というクラス ID であり、JavaScript によって Active X がロードされ、ブラウザープロセス内部で Office ファイルをサーバーから直接開く処理が実行されます。
3-1) 動作変更方法 (クライアント)
Internet Explorer より [ツール] – [アドインの管理] をクリックすると、下記のように表示されます。
ここで、Active X を無効にすると、コントロール クラスがロードできなくなるため、この仕組みが動かなくなります。
3-2) 動作変更方法 (SharePoint Server)
SharePoint On-Premise のみ変更可能となりますが、SharePoint で表示されるドキュメントへのハイパーリンクのクリック イベントでは、1. ProtocolHandler.exe と同様、DocIcon.xml に記載されたファイル拡張子が対応している OpenControl を ActiveX としてロードします。
タイトル : DocIcon.xml ファイルについて
アドレス : http://msdn.microsoft.com/ja-jp/library/ms463701(v=office.14).aspx
4) よくあるお問い合わせ
Microsoft SharePoint Foundation サポートがインストールされている必要があります。
仕組み 1. protocolhandler.exe と 2 SharePoint OpenDocuments コントロールは、このコンポーネントをインストールしていない環境では動作しません。
カスタム Web サイトなどから、JavaScript を使用して、このモジュールを呼び出したい場合は、下記のようなコードになります。
var stsopen = new ActiveXObject("SharePoint.OpenDocuments");
// 閲覧モードの場合
stsOpen.ViewDocument("http://sharepoint/Shared%20Documents/Document.docx", null);
// 編集モードの場合
stsOpen.EditDocument("http://sharepoint/Shared%20Documents/Document.docx", null);
通常のハイパーリンク クリック時に、ナビゲーション先のファイルをサーバーから直接開くよう動作します。
・Microsoft Office 2010 以降
・サポートされるすべてのバージョンの SharePoint Server、およびDAV, MS-FSSHTTP に対応したサーバー
SharePoint サーバー上のファイルへのリンクをクリックした場合、おそらく上記 1. 2. までの処理で、サーバーから直接開く処理が実行されていると思います。ただし、下記のようにいくつかの例外があり、下記のリンクには JavaScript の onclick イベントが付与されていません。
・ユーザーがリッチテキスト エディターなどに張り付けたハイパーリンク (例. <A HREF="http://sharepoint/Shared%20Documents/Document.docx">TITLE</A>) をクリックした場合
・Outlook などから、メールに記載されたハイパー リンクをクリックした場合
・ドキュメントへのリンクを右クリックし、[新しいタブで開く]や [新しいウインドウで開く] をクリックした場合
・ブラウザーのアドレスバーにドキュメントへの URL を直接入力した場合
上記操作の場合、スクリプトが実行されないため 通常は SharePoint 側が意図してファイルの開き方を指定することはできません。ここで紹介する中で、唯一 SharePoint Server の設定に関係なく動作する Office 側のモジュールです。
このモジュールは、IE の Browser Helper Object (BHO) として実装されています。IE 内部でトリガーされるナビゲーションイベント (BeforeNavigate イベント) をフックして、DAV または MS-FSSHTTP に対応したサーバー (※) であると判断した場合はファイルを直接開きます。
注意
動作対象の拡張子 (docx, doc, odt, pptx, ppt, ppsx, odp, xlsx, xls, ods) がハードコードされています。
よくあるお問い合わせとして、xlsm は動作対象から除外されており、直接サーバーから開かれませんので、ご注意ください。
このモジュールの役割は、主にサーバーから直接開くことです。Office Document Cache Handler と名前がついていますが、モジュール名である URLREDIR.DLL という名前のほうが実装内容に合致しています。実際にドキュメント キャッシュを扱って、サーバーとの通信量を削減する処理を実施しているのは Office クライアント アプリケーション本体です。ただし、ファイルを直接開くことがドキュメント キャッシュを使用することの条件であり、このモジュールはその動作を実現するためのハンドラーということになります。
初回と次回以降の細かな動作の違い
サーバー側の WebDAV、MS-FSHTTP への対応状況が判断できない場合、最初はダウンロードして開きます。Web フォルダ (ドキュメント ライブラリやアイテムごとの添付ファイル等) 単位で WebDAV、MS-FSHTTP への対応が確認できた時点で下図のようにレジストリ キー (HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Common\Internet) に値 EnableBHO = 1 が登録されます。このキーが存在する Web フォルダ内のファイルのみ、ハイパーリンクをクリックした際にはサーバーから直接ファイルを開くように動作します。そのため、Web フォルダごとに最初はダウンロード、次からは直接開くといった動作となりますため、全体的に見てこの仕組みが動いたり動かなかったりという印象を持つ方も多いと思います。
なお、下記のレジストリ キーを変更した際には、上記の様に一度実績がある Web フォルダのみ開くという動作をやめ、最初からサーバーより直接開いてみる動作となります。
キー : HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Common\Internet\
値の名前 : OptimisticBHO
値の種類 : REG_DWORD
値のデータ : 1
3) 動作変更方法 (クライアント)
IE のアドオンの管理でも、有効、無効を制御できます。
IE のバージョンにより、既定で無効にされており、サーバーから開けない場合があります。詳しくは下記をご参考にしてください。
タイトル : Office 2010 - Performance and Caching Add-on Disabled by Default in Internet Explorer 9
アドレス : http://support.microsoft.com/kb/2463597
なお、すでに上記しましたが、xlsm は対応していません。
特に開発者向けの情報はありません。
(補足※)
このコントロールは、SharePoint Server以外にも対応しています。例えば IIS の WebDAV 発行機能などにも対応しています。
また、記載した MS-FSSHTTP プロトコルは、SharePoint 2010 以降で追加された既定で有効化された通信手法であり、cellstorage.svc として実装されております。
ドキュメント キャッシュを使用してサーバーとの通信量を減らすためのプロトコルです。
下記の設定で有効化状況を制御できます。
タイトル : SPWebApplication.CellStorageWebServiceEnabled property
アドレス : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.cellstoragewebserviceenabled(v=office.15).aspx
タイトル : [MS-FSSHTTP]: File Synchronization via SOAP over HTTP Protocol
アドレス : http://msdn.microsoft.com/en-us/library/dd943623(v=office.12).aspx
いかがでしたでしょうか。今回の投稿は以上となります。
こんにちは、SharePoint サポートの佐伯です。前回の投稿に引き続き、今回もコンテンツ検索 Web パーツについて取り上げていきます。SharePoint サイトの運用上、カスタムの管理プロパティを作成し、この情報をコンテンツ検索 Web パーツで表示させたいというお問い合わせを多くいただきます。本投稿では、こちらの方法についてご紹介したいと思います。
まずは、以下のケースを考えてみましょう。そこで、ドキュメントの分類用の列を用意して複数のドキュメント ライブラリに追加し、その列の情報をマッピングした管理プロパティを表示する Web パーツを作成しましょう。Web パーツはコンテンツ検索 Web パーツを使用します。
それでは作成していきましょう。1. サイト列の作成まずは、列の作成から始めましょう。複数のドキュメント ライブラリで使用するため、サイト列の作成をおすすめします。1. [歯車] – [サイトの設定] をクリックします。2. [Web デザイナー ギャラリー] – [サイト列] をクリックします。3. [作成] をクリックします。4. 列名に “文書のカテゴリ" と入力し、この列の情報の種類には “選択肢 (メニューから選択)“ にチェックを入れます。5. 列の選択肢を入力し、保存します。2. ドキュメント ライブラリの作成上記で作成したサイト列をドキュメント ライブラリに追加しましょう。1. ドキュメント ライブラリにアクセスし、リボンの [ライブラリの設定] をクリックします。2. 列セクションにある [サイト内の既存の列から追加] をクリックします。3. [利用可能なサイト列] で 文書のカテゴリ を選択して追加します。4. [OK] をクリックします。文書のカテゴリ 列を追加したいドキュメント ライブラリに上記の手順 1 ～ 4 を実施していきます。クロールをする前に、サイト列に何らかのコンテンツを含めましょう。テスト用のドキュメントをアップロードし、追加した文書のカテゴリ列に値をセットします。- フル クロールの実行次にフル クロールを実行します。フル クロールを実行すると、上記で作成したサイト列がクロールされたプロパティとして反映されます。1. サーバーの全体管理サイトにアクセスします。2. [アプリケーション構成の管理] – [サービス アプリケーションの管理] をクリックします。3. [サービス アプリケーションの管理] ページで該当の [Search Service Application] をクリックします。4. [検索管理] メニューの [クロール] - [コンテンツ ソース] をクリックします。5. 必要なコンテンツ ソースの名前をポイントし、表示された矢印をクリックして [フル クロールの開始] をクリックします。フル クロールが完了後、[クエリと結果] – [検索スキーマ] をクリックし、[クロールされたプロパティ] をクリックします。文書のカテゴリがクロールされたプロパティとして反映されました。(補足) 列の種類が選択肢のサイト列は、ows_q_CHCS_サイト列名となります。1 行テキスト列であれば ows_q_TEXT_サイト列名、日付と時刻列であれば ows_q_DATE_サイト列名 になります。3. 管理プロパティの作成1. サーバーの全体管理サイトにアクセスし、[アプリケーション構成の管理] – [サービス アプリケーションの管理] より、該当の [Search Service Application] をクリックします。2. [検索管理] メニューの [クエリと結果] – [検索スキーマ] をクリックします。3. [新しい管理プロパティ] をクリックします。4. 以下の項目を設定します。プロパティ名 : DocumentCategory種類 : テキスト5. DocumentCategory の値を検索結果に表示するために [取得可能] にチェックを入れます。6. クロールされたプロパティへのマッピングで [マッピングの追加] をクリックします。7. クロールされたプロパティの選択でプロパティを選択し、[OK] をクリックしダイアログを閉じます。8. [OK] をクリックします。- フル クロールの実行マッピングされた情報を反映するため、再度フルクロールを実行します。手順は上述のフル クロールの実行と同様です。4. 管理プロパティのマッピング上記で作成した管理プロパティをコンテンツ検索 Web パーツで表示するようマッピングします。1. ページにコンテンツ検索 Web パーツを配置し、[Web パーツの編集] をクリックします。2. 今回は既定で用意されている表示テンプレートを使いましょう。"表示テンプレート" を展開し、アイテムで 2 行 を選択します。この表示テンプレートでは、2 つの管理プロパティを表示することができます。※表示する管理プロパティの数を変更したい場合や、デザインおよびレイアウトを変更したい場合は表示テンプレートをカスタマイズします。表示テンプレートのカスタマイズについては、こちらの投稿でご紹介しています。3. "プロパティのマッピング" を展開し、アイテム表示テンプレートのフィールドに対し、管理プロパティのマッピングを変更します。 にチェックを入れます。4. 行 1 には Title、行 2 には DocumentCategory を設定します。さらに、検索結果で取得するアイテムの条件を指定していきましょう。- クエリの編集今回は、結果を取得するリストを指定し、最新のドキュメントを取��するクエリの編集方法をご紹介します。まずは、結果を取得するリストを指定しましょう。1. [Web パーツの編集] の [クエリの編集] をクリックします。2. [詳細モードへの切り替え] をクリックします。以下のように切り替わります。3. クエリ テキストに検索結果を取得する条件を設定します。まずは対象のリストの GUID を調べましょう。<リストの GUID の調べ方>以下のスクリプトを SharePoint 2013 管理シェルで実行し、対象のリストの GUID を取得します。管理者権限で実行する必要があります。$web = Get-SPWeb <Web サイトの URL>$list = $web.Lists["<リスト名>"]$list.IDここで取得した GUID をメモしておきます。条件に指定したい他のリストの GUID も調べます。4. 上記で取得したリストの GUID で以下のようなクエリを作成します。なお、リストの GUID を指定するだけではそのリストも検索結果で取得されるので、IsDocument:"True" も追加します。IsDocument:"True" ListID:8bb03432-fdd6-4872-9252-6f7f6f08c9d4なお、複数のリストを指定する場合は OR を使って以下のようにクエリを作成します。IsDocument:"True" (ListID:8bb03432-fdd6-4872-9252-6f7f6f08c9d4 OR ListID:8d4a2be1-886c-4652-8d87-eb3d7a307b85 OR ListID:81091af5-ef87-447e-b351-a81ccbca097f)
次に、最新のドキュメントを取得する設定を行います。5. [並べ替え] タブを選択し、並べ替え項目に LastModifiedTime の 降順 を設定します。これで最終更新日の降順でドキュメントが取得されます。6. Web パーツを保存し、ページを保存します。以上で完了です。いかがでしたか。上記で紹介している手順は必要に合わせて変更してください。参考にしていただければ幸いです。
MOSS 2007 や SharePoint 2010 では、サイトのユーザー情報におけるユーザーの表示名やメールアドレスなどの情報は、プロファイルをインポートすることにより AD と同期させることが可能です。
WSS 3.0 や SharePoint Foundation 2010 では基本的にはユーザーが手動でサイトのユーザー情報を更新して情報を同期する必要があります。
MOSS 2007 や SharePoint 2010 におけるプロファイルの同期の仕組みは次のとおりです。
1. プロファイルのインポート (同期) により AD から SharePoint のユーザープロファイルに情報が取り込まれる。
2. 既定では 1 時間に 1 回実行されているプロファイルの同期タイマージョブによりサイトのユーザー情報に同期される。
この 2 段階のプロセスを経て、最終的にサイトのユーザー情報に情報が反映されます。
なお、上記 2 のプロファイルの同期ジョブでは、既定では「アクティブユーザー」に対してのみ同期処理が実行されます。
SharePoint ではユーザーが「アクティブ ユーザー」かどうか、コンテンツ データベースの UserInfo テーブルで管理しており、「アクティブユーザー」に対しては tp_IsActive フラグが 1 に設定されます。
ユーザーは以下のいずれかの条件を満たすことで、アクティブとみなされます。
・サイトの権限に直接ユーザー登録されている
・過去に何らかのアイテムの更新処理を行ったことがある
したがって、サイトに AD グループ経由で権限登録されており、かつ、「閲覧のみ」の権限しか持たずアイテムを更新したことが無いユーザーについては非アクティブと認識され、結果として AD の情報が更新されてもサイトのユーザー情報が更新されないという状況が発生します。
既定でアクティブユーザーに対してのみプロファイルの同期処理が実行される動作は、製品の想定された動作ですが、「stsadm –o sync –ignoreisactive 1」コマンドを実行することでこの動作を変更でき、非アクティブユーザーに対してもプロファイル同期が行われるよう、動作を変更することが可能です。このあたりの詳しい解説については以下の資料をご参照ください。
How to Update Inactive User Profile Information in SharePoint
http://blogs.msdn.com/b/rcormier/archive/2012/09/08/how-to-update-inactive-user-profile-information-in-sharepoint.aspx
ここまでの話は、比較的 MOSS の頃からメジャーな話なので、既にご存知の方もおられるかと思います。
有志の方々が PowerShell スクリプトなどで強制的に SPUser オブジェクトのプロパティを書き換える方法など紹介されておりますので、既にこのようなソリューションで対応されている方もおられるかと思います。
Update Inactive User Information Using PowerShell
http://gallery.technet.microsoft.com/scriptcenter/Update-Inactive-User-736dec27
MOSS running stsadm –o migrategroup command keeps the old group name and does not replace with the new name
http://blogs.msdn.com/b/joerg_sinemus/archive/2010/09/28/moss-running-stsadm-o-migrategroup-command-keeps-the-old-group-name-and-does-not-replace-with-the-new-name.aspx
SPS2010 running stsadm –o migrategroup command keeps the old group name and does not replace with the new name
http://blogs.msdn.com/b/joerg_sinemus/archive/2010/12/16/sps2010-running-stsadm-o-migrategroup-command-keeps-the-old-group-name-and-does-not-replace-with-the-new-name.aspx
で、ここからが本題です。
SharePoint 2010 および SharePoint Foundation 2010 以降に限られますが、実は、以下の PowerShell コマンドにより強制的にサイトのユーザー情報を AD の情報と同期させることが可能です。
Get-SPUser -Web <サイトの URL> -Identity <ユーザーログオン名> | Set-SPUser -SyncFromAD
例) Get-SPUser -Web http://sp2010 -Identity contoso\user1 | Set-SPUser -SyncFromAD
注意点として、このコマンドはプロファイルを更新するものでは無く、あくまでサイトのユーザー情報を更新するものなので、ユーザープロファイルは更新されません。また、サイト コレクション単位で実行する必要があります。
この方法を応用すれば、SharePoint Foundation においてもユーザー情報の同期が実装できるかもしれません、、、が、ユーザー数が多い環境では AD に対して負担をかけるかもしれませんので、実施にあたっては十分に検証していただくことをお勧めします。
Get-SPUser
http://technet.microsoft.com/ja-jp/library/ff607580.aspx
Set-SPUser
http://technet.microsoft.com/ja-jp/library/ff607827.aspx
SharePoint Server 2013 のセットアップ時には、製品準備ツールを使用して各種必須コンポーネントをインストールする必要があります。製品準備ツールの実行にはインターネットへの接続が必要になりますが、場合によってはインターネットに接続されていない環境に製品をセットアップする必要が生じることもあるかと思います。今回は、インターネットに接続されていない Windows Server 2012 環境に SharePoint Server 2013 をインストールする方法を紹介します。
インストール ソースの作成手順
インストール メディアの内容をすべてローカルに保存した後、prerequisiteinstallerfiles フォルダの中に以下のファイルをそれぞれダウンロードしてコピーしておきます。
Windows Identity Foundation 1.0 for Windows Server 2008 R2http://go.microsoft.com/fwlink/?LinkID=226830ファイル名：windows6.1-kb974405-x64.msu
Microsoft Sync Framework Runtime v1.0 SP1 (x64) http://go.microsoft.com/fwlink/?LinkID=224449ファイル名：synchronization.msi
Microsoft SQL Server 2012 Native Client 64 ビット版http://go.microsoft.com/fwlink/?LinkId=228086ファイル名：sqlncli.msi
Windows Server AppFabrichttp://go.microsoft.com/fwlink/?LinkId=235496ファイル名：WindowsServerAppFabricSetup_x64.exe
Windows Identity Extensions for Windows Server 2008 R2http://go.microsoft.com/fwlink/?LinkID=252368ファイル名：MicrosoftIdentityExtensions-64.msi
WCF Data Services 5.0 for ODatahttp://go.microsoft.com/fwlink/?LinkId=247921ファイル名：WcfDataServices.exe
Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB2671763)http://go.microsoft.com/fwlink/?LinkId=251471ファイル名：AppFabric1.1-RTM-KB2671763-x64-ENU.exe
Microsoft Information Protection and Control Client (MSIPC)http://go.microsoft.com/fwlink/?LinkID=219568ファイル名：setup_msipc_x64.msi
補足：Windows Server 2012 では既定で .NET 4.5 と Windows Management Framework 3.0 が含まれるため上記のリストでは割愛しています。Windows Server 2012 より前の OS では必要に応じて以下のプログラムを事前にインストールしておきます。
Microsoft .NET Framework バージョン 4.5http://go.microsoft.com/fwlink/?LinkID=250950ファイル名：dotNetFx45_Full_setup.exe
Windows Management Framework 3.0 (Windows PowerShell 3.0 を含む)http://go.microsoft.com/fwlink/?LinkID=233187ファイル名：Windows6.1-KB2506143-x64.msu
インストール ソースのルート (prerequisiteinstaller.exe と同じパス) に PrerequisiteInstaller.Arguments.txt を作成して以下の内容をコピー＆ペーストします。(すべて1行で記述します。)
/IDFX:"C:\prerequisiteinstallerfiles\windows6.1-kb974405-x64.msu" /Sync:"C:\prerequisiteinstallerfiles\synchronization.msi" /sqlncli:"C:\prerequisiteinstallerfiles\sqlncli.msi" /AppFabric:"C:\prerequisiteinstallerfiles\WindowsServerAppFabricSetup_x64.exe" /IDFX11:"C:\prerequisiteinstallerfiles\MicrosoftIdentityExtensions-64.msi" /WCFDataServices:"C:\prerequisiteinstallerfiles\WcfDataServices.exe" /KB2671763:"C:\prerequisiteinstallerfiles\AppFabric1.1-RTM-KB2671763-x64-ENU.exe" /MSIPCClient:"C:\prerequisiteinstallerfiles\setup_msipc_x64.msi"
※上記の例では汎用的に利用できるように、ファイルを一旦ローカル ドライブにコピーして利用することを想定しているため、参照先を C:\prerequisiteinstallerfiles に指定しています。インストール メディアの挿入先ドライブのパスを直接指定したり、ファイル共有のパスを指定することも可能です。
作成したインストール ソースを任意のファイル共有にコピーして利用します。インストール ソースをもとにインストール用のメディアを作成したり ISO ファイルを作成して利用することもできます。
利用方法
インストール ソースの prerequisiteinstallerfiles フォルダを C:\ にコピーします。
製品準備ツール (prerequisiteinstaller.exe) を起動してウィザードに従って各種必須コンポーネントをインストールします。
インストール時の注意点
上記のインストール ソースを使用してインターネットに接続されていない環境で製品準備ツールを実行する際には、いくつかの注意点があります。
.NET Framework 3.5 の機能の有効化に失敗する
製品準備ツールの実行中に、Web サーバー (IIS) およびアプリケーション サーバーの役割といくつかの Windows 機能が有効化されます。このとき、.NET Framework 3.5 が有効にされますが、Windows Server 2012 では .NET Framework 3.5 の機能をインストールする際に既定で Windows Update を参照するため、インターネットに接続されていない環境では、Windows 機能の有効化に失敗します。
この問題の対策として、製品準備ツールを実行する前に以下の手順で .NET Framework 3.5 の機能を有効にしておきます。
Windows Server 2012 のインストール メディアを挿入します。
PowerShell で以下のコマンドを実行します。
Import-Module ServerManagerAdd-WindowsFeature Net-Framework-Features -Source D:\sources\sxs
※D:\sources\sxs の部分にはインストール メディアのドライブを指定します。)
再起動後に製品準備ツールが再開されるとインターネットからコンポーネントをダウンロードしようとする
製品準備ツールの実行中に、途中で何度かシステムの再起動が必要になります。この時、[完了] をクリックしてシステムを再起動する前に、%systemdir%\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup の下にある SharePointServerPreparationToolStartup_0FF1CE14-0000-0000-0000-000000000000.cmd ファイルを削除してください。
既定では、製品準備ツールの処理中に再起動が必要になった場合、スタートアップ フォルダに再開用のコマンド ファイルが作成されて、再起動後に自動的に製品準備ツールが再開されますが、この方法で再開された場合、PrerequisiteInstaller.Arguments.txt が参照されません。このため、再起動前に手動でスタート アップフォルダのコマンド ファイルを削除して、再起動後に手動で製品準備ツールを実行します。既にインストールされたコンポーネントのセットアップはスキップされるため、この方法で再起動と製品準備ツールの手動実行を 2、3 回繰り返せば最終的にセットアップが最後まで完了するようになります。
関連資料
ネットワーク共有から SharePoint 2013 の必須コンポーネントをインストールする http://technet.microsoft.com/ja-jp/library/ff686793.aspx
SharePoint 2013: Install Prerequisites Offline or Manually on Windows Server 2012 - A Comprehensive Guide http://social.technet.microsoft.com/wiki/contents/articles/14582.sharepoint-2013-install-prerequisites-offline-or-manually-on-windows-server-2012-a-comprehensive-guide.aspx
.NET Framework 3.5 installation error: 0x800F0906, 0x800F081F, 0x800F0907 http://support.microsoft.com/kb/2734782
現在マイクロソフトでは、私達と一緒に SharePoint のサポートに携わるサポートエンジニアを募集しています。SharePoint に興味がある方はもちろん、SharePoint を通じでお客様のビジネス成功に携わりたい方、そしてマイクロソフトの製品をより良くしていきたいと考えている方、私達と一緒にマイクロソフトのサポートエンジニアとして働いてみませんか。
興味がある方は、是非一度、こちら（マイクロソフト採用情報）をクリックしてみてください。皆さまからのご応募を、心よりお待ちしております。
こんにちは、SharePoint サポートの 森 健吾 (kenmori) です。今回の投稿では、Office 開発サポートを担当していた時期に記載した下記投稿 Office サーバーサイド オートメーションの危険性の続編として、その代替案を記載いたします。タイトル : Office サーバー サイド オートメーションの危険性についてアドレス: http://blogs.msdn.com/b/office_client_development_support_blog/archive/2012/04/12/1-office.aspx上記投稿のおさらいとなりますが、例えば以下のような機能を Web サーバー上で Office API を使用したオートメーションで実装することはサポートされていません。
・夜間にデータを集計しOffice ファイルを作成 ・Web ページ上でファイルを選択して PDF などに変換 本投稿では、この対処方法として以下の 2 つの方法をご紹介します。
1. OpenXML SDK を使用した開発を実施する。2. SharePoint Server 2013 を使用し、Word / PowerPoint Automation Service を使用したドキュメント変換を実施する。
1. OpenXML SDK を使用した開発を実施する。
Office サーバーサイド オートメーションの代替案として、まず筆頭に挙がるのが Open XML SDK を使用した開発となります。本ソリューションを実装するにあたり、SharePoint は必要ありません。以前の 97-2003 形式 (OLE 複合ドキュメント) 形式 (例. doc, xls, ppt) とは異なり、Open XML 形式の Office ファイル (例. docx, xlsx, pptx 等) は、公開された規格にそった XML によって成り立っています。Open XML 形式の Office ファイルは、拡張子を *.zip に変更して開くと定義を確認できます。
そのため、Office アプリケーションがインストールされていなくても、ファイルを編集できるようになっています。
タイトル : Open XML SDK ドキュメント アドレス : http://msdn.microsoft.com/ja-jp/library/bb226703.aspx
タイトル : Open XML SDK 2.0 for Microsoft Officeアドレス : http://www.microsoft.com/ja-jp/download/details.aspx?id=5124
ただし、多くの開発者が VBA などを通じて感覚的に養ってきたこれまでの開発手法と比較すると全く異なる内容である点や、膨大な SDK をはじめから覚えないといけないということで、移行のコスト等を敬遠していることをよく聞きます。しかし、Open XML SDK 2.0 には Open XML 2.0 Productivity Tools for Microsoft Office という非常に強力な支援ツールがあります。OpenXML Productivity Tools for Microsoft Office は上記 Open XML SDK 2.0 のサイトからダウンロードが可能です。インストール後、スタートメニューから起動し、さっそく動作を見てみましょう。
使用手順1. 画面左上 [ファイルを開く] をクリックし、Office ファイルを選択して開きます。2. [コードの反映] をクリックします。
参考) 読み込まれたファイル
これだけで、今読み込んだファイルを作成するのに必要なサンプル コード (ベストなコードではない) が右ペインに自動生成されます。やはり、新規のファイルから起こすと生成されるコード量は多いですが、多くの場合は編集を実施するだけですので、必要な個所をコピーペーストしながら新規コードに移植して実装すると想像よりも簡単に実装できると思います。
移行を考える場合は、このツールを駆使してコードの実装方法を確認し、必要な処理を組み込んでテストを実施するという流れになると思います。
ということで、さっそく私も自動生成されたコードをもとに、さっそくパラグラフを 1 つ追加してみました。WindowsBase.dll (System.IO.Packagin 名前空間) とDocumentFormat.OpenXml.dll を参照に加え、下記のコードを実装することで Hello World という文字を含むパラグラフが以下のコードで追加されました。
using DocumentFormat.OpenXml;using DocumentFormat.OpenXml.Packaging;using DocumentFormat.OpenXml.Wordprocessing;
using (WordprocessingDocument package = WordprocessingDocument.Open(filePath, true)){ // Productivity Tool が生成したコードの貼り付け Paragraph paragraph1 = new Paragraph() { RsidParagraphAddition = "00496DA6", RsidRunAdditionDefault = "00104CC6" }; Run run1 = new Run(); RunProperties runProperties1 = new RunProperties(); RunFonts runFonts1 = new RunFonts() { Hint = FontTypeHintValues.EastAsia }; runProperties1.Append(runFonts1); Text text1 = new Text(); text1.Text = "Hello World"; run1.Append(runProperties1); run1.Append(text1); paragraph1.Append(run1); // ここまで package.MainDocumentPart.Document.Body.Append(paragraph1);}
上記画面キャプチャを見ても一目瞭然の通り、コードはほとんど Productivity Tool が自動生成したものです。
補足最新バージョンとして公開されている、Open XML SDK 2.5 for Microsoft Office は、英語のみのご提供となりますが、以下のサイトよりダウンロードすることが可能となります。Productivity Tool には Office 2013 フォーマットでの検証機能が追加されており、SDK のアセンブリは .NET Framework 4.0 ベースのアセンブリとして作成されております。必要に応じてご活用ください。
タイトル : Open XML SDK 2.5 for Microsoft Officeアドレス :http://www.microsoft.com/en-us/download/details.aspx?id=30425
2. SharePoint Server 2013 を使用し、Word / PowerPoint Automation Service を使用したドキュメント変換を実施する。Open XML SDK を使用することで、ファイルの自動編集は可能になりますが、私が Office 開発サポートを実施していた際の経験からも、サーバー サイド オートメーションにおける最もよくあるお問い合わせは、ドキュメントの変換 (例. PDF) や印刷です。
SharePoint Server 2013 (Standard Edition 以上) では、Word と PowerPoint においてのみ、ドキュメントの変換を実現できます。残念ながら、Excel ワークブックについては、ファイル変換機能を持つサービスはありません。なお、Office はバックグラウンド サービスからの実行および印刷をサポートしておりません。また、このような構成で他形式のファイル (例. PDF) を印刷する場合は該当アプリケーションの開発元にご確認ください。その他、オートメーション サービスを使用したカスタマイズは SSOM (サーバーサイド オブジェクト モデル) のみの提供となりますため、SharePoint Online では本機能はご利用いただけません。
Word
Word Automation Service が提供する ConversionJob.Start メソッドを使用した開発にて実現することが可能です。この機能は SharePoint Server 2010 以降にてご利用可能です。
事前準備•サーバーの全体管理コンソールの [システム設定] で、[サーバーのサービスの管理] を選択し、[Word Automation Service] が [開始] に設定されていることを確認します。•サーバーの全体管理コンソールの [アプリケーション構成の管理] で [サービス アプリケーションの管理] を選択し、[Word Automation Services] および [Word Automation Services Proxy] が [開始済み] に設定されていることを確認します。
タイトル : SharePoint 2010 Word Automation Services での開発アドレス : http://msdn.microsoft.com/ja-jp/library/ff742315(v=office.14).aspx
タイトル : ConversionJob.Start methodアドレス : http://msdn.microsoft.com/en-us/library/office/microsoft.office.word.server.conversions.conversionjob.start.aspx
下記のようなコードを実装して、ドキュメントの変換を実施します。上記サイトからの抜粋となります。
-- 抜粋 開始 -- string siteUrl = "http://localhost"; // If you manually installed Word automation services, then replace the name // in the following line with the name that you assigned to the service when // you installed it. string wordAutomationServiceName = "Word Automation Services"; using (SPSite spSite = new SPSite(siteUrl)) { ConversionJob job = new ConversionJob(wordAutomationServiceName); job.UserToken = spSite.UserToken; job.Settings.UpdateFields = true; job.Settings.OutputFormat = SaveFormat.PDF; job.AddFile(siteUrl + "/Shared%20Documents/Test.docx", siteUrl + "/Shared%20Documents/Test.pdf"); job.Start(); }-- 抜粋 終了 --
PowerPoint
PowerPoint Automation Service が提供する PdfRequest.BeginConvert メソッドを実行することでドキュメントの変換が可能です。
事前準備•サーバーの全体管理コンソールの [システム設定] で、[サーバーのサービスの管理] を選択し、[PowerPoint Conversion Service] が [開始] に設定されていることを確認します。•サーバーの全体管理コンソールの [アプリケーション構成の管理] で [サービス アプリケーションの管理] を選択し、[PowerPoint Conversion Service Application] および [PowerPoint Conversion Service Application Proxy] が [開始済み] に設定されていることを確認します。
タイトル : SharePoint 2013 の PowerPoint Automation Servicesアドレス : http://msdn.microsoft.com/ja-jp/library/office/fp179894(v=office.15).aspx
タイトル : PdfRequest classアドレス : http://msdn.microsoft.com/en-us/library/office/microsoft.office.server.powerpoint.conversion.pdfrequest(v=office.15).aspx
-- 抜粋 開始 -- string siteURL = "http://localhost"; using (SPSite site = new SPSite(siteURL)) { using (SPWeb web = site.OpenWeb()) { Console.WriteLine("Begin conversion");
// Get a reference to the "Shared Documents" library // and the presentation file to be converted. SPFolder docs = web.Folders[siteURL + "/Shared Documents"]; SPFile file = docs.Files[siteURL + "/Shared Documents/Pres1.ppt"];
// Convert the file to a stream and create an // SPFileStream object for the conversion output. Stream fStream = file.OpenBinaryStream(); SPFileStream stream = new SPFileStream(web, 0x1000);
// Create the presentation conversion request. PresentationRequest request = new PresentationRequest(fStream, ".ppt", stream);
// Send the request synchronously, passing // in a ‘null’ value for the callback parameter, // and capturing the response in the result object. IAsyncResult result = request.BeginConvert( SPServiceContext.GetContext(site), null, null); // Use the EndConvert method to get the result. request.EndConvert(result); // Add the converted file to the document library. SPFile newFile = docs.Files.Add( "newPres1.pptx", stream, true); Console.WriteLine("Output: {0}", newFile.Url); } }-- 抜粋 終了 --
いかがでしたでしょうか。Open XML および SharePoint Server 2013 における 2 つのオートメーション サービスについてご説明しました。上記情報をお役立ていただき、少しでも移行先のテクノロジーに対する抵抗をなくしていただけますと幸いです。今回の投稿は以上となります。
今回の投稿では、すでに Web キャスト等でも公開しております Web パーツを含むページが予期せぬエラー等で表示できなくなった際のトラブル シューティング方法について SharePoint 2013 をベースとしてご説明します。
この投稿には SharePoint 2013 での最新情報は少ないものの、バージョンを問わずトラブルシューティングの基礎となりますため、情報を更新する目的で投稿します。
SharePoint では、製品に用意された様々な Web パーツや、それらをカスタマイズした Web パーツ、または Visual Studio によってカスタマイズしたオリジナルの Web パーツを追加して独自のページを作成することができます。しかし、様々なページを実現できるがゆえに、エラーが発生した場合は、どう対処すべきかわからないという状況が想定されます。
この投稿では、Web パーツ ページが表示できなくなった場合のトラブル シューティングについて説明していきます。また、この投稿で使用している画面ショットは、SharePoint 2013 のものを使用していますが、それ以前のバージョンにおいても有効な方法をご紹介します。
エラー画面
SharePoint では、Web パーツを含むページの表示処理などにおいてエラーが発生し、例外がハンドルされない場合、このように "申し訳ございません。何らかの問題が発生しました。" などのエラー画面が表示されます。
このような問題が発生した場合は、次のような手順を行ってください。
トラブル シューティング手順
Web パーツ ページが表示できない場合のトラブル シューティングを実施するにあたって、最も簡単な方法は Web パーツの管理の画面を使用します。最初にこの問題がそのページ特有の現象かどうかを確認するために、URL を直接指定して影響範囲を確認します。影響範囲がページ固有である場合は、以下にその手順についてトラブルシューティングの流れをご説明いたします。
手順概要
さらに、現象発生の原因を追究する場合は、現象発生時のバックアップ データなどをテスト環境に復元し、テスト環境にて継続して調査を実施することをお勧めします。
手順詳細
1. Web パーツの管理のページにアクセスします。
エラー発生画面に [Web パーツの管理のページ] といったリンクが表示されている場合は、このリンクをクリックすることで、Web パーツ ページの管理画面に遷移し、トラブル シューティングを行うことが可能です。
しかしながら、エラーの種類や深刻さなどによっては、このエラー画面が表示されないことも考えられます。その場合は、ブラウザのアドレス バーにて URL の末尾に ?contents=1 を入力して該当するページの Web パーツ ページの管理画面に遷移することができます。
また ?contents=1 を追加する方法は、SharePoint Server 2010, 2007 等の以前のバージョンの SharePoint においても使用できます。
2. 管理画面から 1 つ 1 つ Web パーツを閉じ、元のページにアクセスします。
3. 手順 2. を正常に表示されるまで繰り返します。
4. 現象が回避できた時点で、最後に閉じた Web パーツが問題の Web パーツとして断定できます。
Web パーツ ページの管理画面に遷移したら、Web パーツにチェックを入れ [閉じる] をクリックして、Web パーツを閉じていきます。
問題の Web パーツを特定するため、1 つ閉じるごとにページが正常に表示されるかを確認していきます。正常に表示できた時点で、最後に閉じた Web パーツが問題を引き起こしていることが確認できます。
5. この問題となる Web パーツを閉じたまま、その他の Web パーツを元に戻していきます。
問題の Web パーツが特定できた後は、その特定の Web パーツを除く全ての Web パーツをあらためて追加します。
Web パーツ ページの管理画面にて、[閉じる] をクリックして閉じられた Web パーツは、Web パーツを追加する際のカテゴリにて "閉じられた Web パーツ" というカテゴリの中に全て登録されています。
この Web パーツを選択し、[追加] ボタンをクリックすることで、閉じるまでの設定情報を引き継いた Web パーツを再度ページに復元することができます。この手順を、問題の Web パーツ以外にて適用し、閲覧できないコンテンツの影響を最小限にとどめます。
原因追求
原因追求については、ダウンタイムを最小限にするためだけでなく、根本原因について十分に調査を実施するためにも、テスト環境で実施することをお勧めします。
Web.config の編集
調査方法の 1 つとしては、web.config を以下のように設定し、スタックを含めたより詳細なエラー内容を画面上に表示させることが効果的です。Internet Information Services (IIS) 管理ツールにて、Web サイトを右クリックしてエクスプローラ表示します。
該当フォルダ内の web.config を開き、以下の 3 つの設定を変更します。
1) SafeMode 要素要素 : configuration/SharePoint/SafeMode属性 : CallStack値 : true
2) CustomErrors 要素要素 : configuration/system.web/customErrors属性 : mode値 : Off または RemoteOnly (サーバー端末のみ Off / リモートは On)
3) Compilation 要素要素 : configuration/system.web/compilation属性 : debug値 : true
上記の設定後には、予期せぬエラー画面が、以下のようなエラーの詳細表示画面に切り替わります。
Visual Studio を使用したデバッグ
現象発生した Web パーツのソース コードをお持ちの場合は、Visual Studio を使用して Web パーツを表示している IIS のワーカー プロセスにアタッチ ([デバッグ] – [プロセスにアタッチ]) し、デバッグを行うことで原因追求が可能です。
なお、このような状況に備えるため、SharePoint アプリケーション開発者は、カスタム ソリューションをリリースするにあたり、納品したバージョンに相当するソース ファイルと、コンパイル時に生成されたシンボル ファイル (*.pdb) を必ずご管理いただくことを推奨します。
診断ログ
多くの場合、ハンドルされていない例外は、診断ログに記録されますので、現象発生時の状況を確認する上で診断ログは非常に重要となります。
最初の注意事項として、このファイルは保存期間が決められていますので、削除される前に現象発生時のものを即座に控えておく必要があります。SharePoint 2013 の Web フロント エンド サーバーにおいて、インストール フォルダ下の LOGS フォルダ (既定では "C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\LOGS") にあるすべてのログ ファイルをコピーしてください。
補足 : お客様にて診断ログの保存先を変更されている場合には、変更後の保存先を参照してください。診断ログの保存先フォルダは、サーバーの全体管理サイトより [監視] – [診断ログの構成] にアクセスしていただき、[トレース ログ] セクションの [パス] よりトレース ログのパスを参照することで確認することができます。
今回の例では、以下のようなログが確認できます。
03/09/2013 17:02:21.37 w3wp.exe (0x1A78) 0x1BAC SharePoint Foundation General 8nca Medium Application error when access /SitePages/Home.aspx, Error=エラー at UnhandledExceptionWebPart.UnhandledExceptionWebPart.UnhandledExceptionWebPart.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 7e05069c-8134-708a-27e3-156c2f362b2e
開発者ダッシュボードについて
SharePoint 2010 以降では、トラブルを防止するための機能として、開発者ダッシュ ボードがあります。
この機能を使用することで、ページが表示されるまでの処理において、どの処理に時間がかかったかを確認することができます。この機能を使用するには、2 つの手順が必要となります。
使用までの手順
1. 管理シェルを起動し、以下のコマンドレットを実行して、開発者ダッシュボードを呼び出せるよう設定しておきます。
$DevDashboardSettings = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings$DevDashboardSettings.DisplayLevel = 'OnDemand'$DevDashboardSettings.TraceEnabled = $true$DevDashboardsettings.Update()
タイトル : SPDeveloperDashboardSettings classアドレス : http://msdn.microsoft.com/en-us/library/ee557630.aspx
SharePoint 2010 の開発者ダッシュボードの有効化手順は、上記と異なります。詳細については以下をご確認ください。
タイトル : 開発者ダッシュボードの使用アドレス : http://msdn.microsoft.com/ja-jp/library/ff512745(v=office.14).aspx
2. ページの右上にあるアイコンをクリックし、実際にページ上に開発者ダッシュボードを呼び出します。
以下のように開発者ダッシュボードが起動します。新しい開発者ダッシュボードでは、ページ表示までに関連する様々な内部動作の要因 (例. SQL, SPRequest, サービス呼び出し, ULS) を分析する機能です。
画面に表示されているように、各 Web パーツの表示においてどれだけの時間がかかったか、データベース、Web サービスなどのバックエンドのデータ ソースにアクセスした時間なども詳細タブに記載されることから、どの処理において時間がかかるか、データが増えるに応じてどのように推移するかなどをページの公開前にあらかじめ把握しておくことができます。
平常時において、潜在的なリスクを事前に把握しておくことが可能になりますので、是非とも、この新機能を活用いただければと思います。
こんにちは SharePoint サポートの森 健吾 (kenmori) です。今回の投稿では、SharePoint Web アプリケーションの認証プロバイダー設定を、クラシックベースの Windows 認証からクレーム ベースの Windows 認証に切り替えた際に生じるカスタム ソリューションへの影響について簡単にご紹介します。
SharePoint 2010 ではクラシックベース (既定) とクレームベースが選択可能でしたが、SharePoint 2013 では画面を見てもクレームベースしか選択できない設計となりました。このため、アップグレード シナリオなどで、クラシック ベースからクレームベースにアップグレードすることが多くなり、問題に直面しやすいと考え情報公開することに至っています。
従来型のクラシックベースでは Web アプリケーションごとに 1 つの認証プロバイダーを指定していました。しかし、クレームベースでは、Security Token Service (STS) が認証を仲介します。このことで、複数の認証プロバイダーを同時に Web アプリケーションに関連づけることができ、委任先の各認証プロバイダーがユーザー認証すれば STS が該当 Web アプリケーションに対するアクセス権を付与すべくクレーム トークンを発行するという動作になります。
簡単に説明すると上記の通りですが、スペースの限られたブログでクレームベースを深く説明することは難しいですので、詳細については TechNet などを確認ください。
タイトル : 認証方法を計画する (SharePoint Server 2010)アドレス : http://technet.microsoft.com/ja-jp/library/cc262350(office.14).aspx
1. ユーザー アカウントの表記が変わる
クラシック ベースにおいて、Windows ユーザー アカウント名は Domain\User でした。クレーム ベースでは、アカウント名は i:0#.w|Domain\User という表記に変更となります。アカウント名をもとに条件分岐するコードは稀であるにせよ、サイトにユーザーを自動で登録する処理など様々なソリューションが考えられます。そのような処理を実装している場合は、アカウント名の変更の影響をきちんと把握しておく必要があります。
命名規則を簡単に紹介すると、以下の様になります。
命名規則
1 文字目 : "i" (メンバの場合) / "c" (ロールの場合)2 文字目 : ":" (固定)3 文字目 : "0" (固定)4 文字目 : "#" (ユーザーの場合) / "-" (ロールの場合) / その他5 文字目 : "." (文字列の場合)6 文字目 : "w" (Windows 認証の場合) / "f" (Form 認証の場合) / その他以降1 : "|" (Windows 認証の場合は省略)以降2 : 例.aspnetmembership (発行元の名前 : Windows 認証の場合は省略)以降3 : "|" (固定)以降4 : 例.Admin1 (ユーザー名 / ロール名)
プログラムでユーザー名からエンコードされたプレフィックスを含むアカウント名を取得するのであれば、以下のような処理で可能です。ここで取得したアカウント名を使用して、ユーザーを登録 (SPUserCollection.Add) することも可能です。
Windows 認証の場合 (C#)
// 変数の指定string userIdentifier = "DOMAIN\\user";// 実際の処理SPClaim claim = SPClaimProviderManager.CreateUserClaim(userIdentifier,SPOriginalIssuerType.Windows);string loginName = SPClaimProviderManager.Local.EncodeClaim(claim);
タイトル : SPClaimProviderManager Classアドレス : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.claims.spclaimprovidermanager(v=office.14).aspx
タイトル : SharePoint クレームベース IDアドレス ; http://msdn.microsoft.com/ja-jp/library/ee535242(v=office.14).aspx
2. Windows ユーザー トークンに関連したカスタマイズに対する影響
クラシックベースの Windows 認証では、ASP.NET 偽装により実行スレッドが Web アクセスしたユーザー権限に偽装されます。この原理を利用して、これまで Web パーツなどの様々なカスタム ソリューションにおいて、様々な処理が実装されてきたと思います。
2-1. Windows ユーザー トークンを使用した問題の発生するシナリオ
シナリオ 1) Kerberos 認証による委任の設定を構築した上で、外部サーバー リソース (SQL Server, ファイル サーバー、Web サービス等) にパススルーでアクセスする。 (C#)
String connectionString = "Data Source=DBServer;Initial Catalog=AdventureWorks;Integrated Security=SSPI;";using (SqlConnection connection = new SqlConnection(connectionString)){ connection.Open();}
(解説)クラシックベース認証で Windows 認証を構築した場合、SharePoint サーバーは ASP.NET 偽装の動作に基づき、Windows 資格情報を使用してユーザーが Web アプリケーションに対して認証後は、HTTP 要求スレッドはブラウザーにログインしたユーザーの実行権限で偽装されました。そのため、Kerberos による委任を構築している前提があれば、現在の資格情報であるスレッド実行ユーザー アカウントを使用して第 2 のサーバーにアクセスすることができました。ところが、クレームベース認証で Windows 認証を構築した際、Windows 資格情報を使用してユーザーが Web アプリケーションに対して認証後は、HTTP 要求スレッドは ClaimsIdentity として偽装され、スレッドの実行ユーザーは匿名ユーザーとなります。ブラウザーでアクセスしたユーザーではなく匿名ユーザーとして HTTP 要求スレッドが動作するため、第 2 のサーバーにそのままアクセスする権限を獲得することはできません。そのため、従来通りの方法では、Kerberos 認証を構築したパススルー認証を実施することができなくなります。対処策は後述いたします。
クラシックベースの Windows 認証では NTLM のダブルホップ制約を回避するため、Kerberos 委任を構成して第 2 のサーバーにアクセスするというソリューションが多く存在していました。
タイトル : ASP ページの認証問題のトラブルシューティングアドレス : http://msdn.microsoft.com/ja-jp/library/ms180891(v=vs.90).aspx参考箇所 : ダブルホップの問題
特にパススルーが必須となるシナリオの例として、第 2 のサーバー側で要求元のアクセス権を検証する必要がある場合や、要求元のユーザー アカウントに紐づく情報を返す必要がある場合 (ユーザー プロファイル, メール, カレンダー等) などがあります。このようなシナリオでは、RevertToSelf (ASP.NET 偽装解除、RunWithElevatedPrivileges etc.) 、つまりアプリケーション プール実行アカウントへのスレッド偽装による回避ができません。パススルー シナリオでは、SecureStoreService という回避策もありますが、要求元先で 1:1 のアカウント、パスワードのマッピングを維持することはとても運用工数がかかるため、広く選択されなかった経緯があります。これらの要因から、Kerberos 委任によるパススルー認証をクレームベースにおいても使用したいという要望は、現在も多数存在するものと想定しています。
シナリオ 2) 現在の実行ユーザーが特定のセキュリティ グループに所属しているか (WindowsPrincipal.IsInRole) を確認して、表示項目を絞り込む (C#)
WindowsPrincipal wp = new WindowsPrincipal(WindowsIdentity.GetCurrent());wp.IsInRole(@"BUILTIN\Administrators");
WindowsPrincipal.IsInRole メソッドは、実行アカウントのトークン情報をもとにセキュリティ グループへの所属確認が可能です。トークンには所属するセキュリティ グループの一覧情報も含まれているため、AD に対するネットワーク接続なしにセキュリティ グループを確認できるため、パフォーマンス上低コストな実装として広く使用されてきた経緯があります。
しかし、残念ながら、上記のコードもクレームベース認証に移行後はそのままで動作することはありません。上述の通り、クレームベース認証において、HTTP 要求スレッドは ClaimsIdentity として偽装されるため、コンテキスト情報から WindowsPrincipal を取得 (new WindowsPrincipal(WindowsIdenitity.GetCurrent())) しても匿名ユーザーとして認識されます。そのため、上記のコードはクラシックベースで想定した通りの動作になりません。
2-2. Claim To Windows Token Service (C2WTS) を使用した対処策
クレーム ベース認証環境において、クラシックベースで実施していたソリューションを実行する方法があります。継続して上記シナリオのような Windows トークンを使用したカスタマイズを実装したい場合は、C2WTS を使用してクレーム トークンから Windows トークンを変換して取得する処理を実装する方法が有効です。
C2WTS は、非 Windows セキュリティ トークンから UPN を抽出し、偽装レベルの Windows セキュリティ トークンを生成する Windows Identity Foundation (WIF) の機能です。
2014/05/16 追記 制限付き委任を構成する
クラシックベースにおける委任シナリオでは、無制限の委任により第 2 のサーバーに認証情報を受け渡すことが可能です。しかし、C2WTS による Windows トークンの取得時には、該当の設定のままでは他サーバーに対するアクセス許可を取得することができません。クレーム トークンから Windows トークンに変換する際には、サービスアカウントの委任設定において、"制限付き委任" を構成することが必須となります。
1) ドメイン コントローラーにログインします。2) Active Directory ユーザーとコンピューターで、Active Directory オブジェクトのプロパティを開きます。 - 補足 ドメイン ユーザーの場合は、該当のユーザーアカウントを指定します。 ローカル システムなどのコンピュータ アカウントの場合は、コンピュータ アカウントを指定します。3) [委任] タブを表示します。4) [指定されたサービスへの委任でのみこのユーザーを信頼する] を選択します。5) [任意の認証プロトコルを使う] を選択します。6) [追加] ボタンをクリックします。7) [ユーザーまたはコンピューター] を選択します。8) 委任するサービスを実行中のサービス アカウントを選択します。 9) 接続先の SPN を指定します。 - 補足 接続先サービス アカウントがローカル システムなどのコンピュータ アカウントでない場合は、SPN を別途登録した上でこの画面で利用可能なサービスを選択します。10) [OK] をクリックします。11) "このアカウントが委任された資格情報を提示できるサービス" に選択した SPN が表示されていることを確認します。12) [OK] をクリックします。
上記手順を実施後、必要に応じて変更を加えたサービス アカウントで稼働しているプロセス (w3wp.exe や c2wts サービス) がありましたら、プロセスを再起動 (アプリケーション プールのリサイクル、サービスの再起動) します。
以下にサービスを有効化する方法を記載します。
C2WTS を開始する方法
1) [サーバーの全体管理] サイトにアクセスします2) [システム設定] セクションの [サーバーのサービスの管理] をクリックします3) [サーバーのサービス] 画面の右上 [サーバー] の設定が Web Front サーバーであることを確認します4) "Claims to Windows Token Service" の "処理" の "開始" をクリックします5) [サーバーのサービスの管理] 画面が再度表示された際、"状態" の内容 が "開始済み" になっていることを確認します6) [サーバーのサービス] 画面の右上 [サーバー] の設定より、対象の Web Front サーバーを変更します7) 手順 3) ～ 6) をファーム上の全ての Web Front サーバーに対してご実施ください
上記サービスを構成するにあたっては、以下の設定も同時に実施しておいた方が良いので合わせてご紹介します。
C2WTS が自動起動しない現象を防ぐ方法
1) C2WTS を実行するサーバーに、ローカルの管理者権限のあるユーザーでログオンします。2) コマンド プロンプトを管理者として開きます。3) 以下のコマンドを実行します。depend= の後に半角スペースが入ることに注意してください。
>sc config "c2wts" depend= CryptSvc
4) [スタート] - [管理ツール] - [サービス] をクリックします。5) "Windows トークン サービスに対するクレーム" を探してダブルクリックします。6) [依存関係] タブをクリックし、[このサービスが依存するシステム コンポーネント] に "Cryptographic Services" が表示されていることをご確認ください。7) C2WTS を実行するサーバーが複数ある場合は、すべてのサーバーでこの手順を実施します。
詳細は以下のサイトをご参考にしてください。
タイトル : Claims to Windows Token Service (c2WTS) not starting after rebooting serverアドレス : http://support.microsoft.com/kb/2512597
C2WTS は既定はローカル システム アカウントで実行されますが、ドメイン ユーザーで実行する場合は追加手順が必要となります。以下をご確認ください。
タイトル : Windows トークン サービスに対するクレーム (C2WTS)アドレス : http://technet.microsoft.com/ja-jp/library/hh231678.aspx参考箇所 : C2WTS の構成に必要な基本的な手順
このサービスが有効化された後は、以下のようなコーディングでクレーム トークンから Windows トークンを生成することができます。
C2WTS によるトークン変換実装方法 (C#)
IClaimsIdentity ci = System.Threading.Thread.CurrentPrincipal.Identity as IClaimsIdentity;if (ci != null){ if (ci.Claims.Count > 0) { //look for the UPN claim string upn = string.Empty; foreach (Microsoft.IdentityModel.Claims.Claim c in ci.Claims) { if (c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Upn) {
upn = c.Value; break; } } WindowsIdentity wid = S4UClient.UpnLogon(upn);
// シナリオ 1 ) 偽装 using (WindowsImpersonationContext context = wid.Impersonate()) { // ここに他サーバーに接続・要求する処理を書きます。 }
// シナリオ 2) セキュリティ グループ所属確認 WindowsPrincipal wp = new WindowsPrincipal(wid); wp.IsInRole(@"BUILTIN\Administrators"); }}
2014/05/16 追記 SharePoint オブジェクトモデルを使用した C2WTS によるトークン変換実装方法 (C#)
上記のような WIF のコードをラップした SharePoint オブジェクト モデルによる実装方法も確認できましたので、下記に記載します。WindowsIdentity wid = WindowsIdentity.GetCurrent();SPSecurity.RunWithElevatedPrivileges(delegate(){ wid = SPSecurityContext.GetWindowsIdentity();});// シナリオ 1 ) 偽装using (WindowsImpersonationContext context = wid.Impersonate()){ // ここに他サーバーに接続・要求する処理を書きます。
}// シナリオ 2) セキュリティ グループ所属確認WindowsPrincipal wp = new WindowsPrincipal(wid);wp.IsInRole(@"BUILTIN\Administrators");
上記に記載した通り取得した WindowsIdentity クラスのインスタンスを使用し、Impersonate メソッドを実行して WindowsImpersonationContext オブジェクトを生成して偽装する、セキュリティ グループへの所属を確認する (WindowsPrincipal.IsInRole) といった従来のクラシックベース認証で実施できていたカスタマイズ コードが実装可能となります。
タイトル : WindowsImpersonationContext クラスアドレス : http://msdn.microsoft.com/ja-jp/library/vstudio/system.security.principal.windowsimpersonationcontext(v=vs.90).aspx
タイトル : WindowsPrincipal.IsInRole メソッド (String)アドレス : http://msdn.microsoft.com/ja-jp/library/vstudio/fs485fwh(v=vs.90).aspx
タイトル : Claims to Windows Token Service (c2WTS) の概要アドレス : http://msdn.microsoft.com/ja-jp/library/ee517278.aspx
タイトル : c2WTS からトークンを要求する方法アドレス : http://msdn.microsoft.com/ja-jp/library/ee517258.aspx
補足Excel Service や BI 機能では、以下のホワイト ペーパーに C2WTS を使用した委任の構成について手順を含めた方法が紹介されています。併せて参考にしていただき、知識を深めていただけますと幸いです。
タイトル : Microsoft SharePoint 2010 製品の Kerberos 認証の構成アドレス : http://www.microsoft.com/ja-jp/download/details.aspx?id=23176
タイトル : Excel Services の ID 委任 (SharePoint Server 2010)アドレス : http://technet.microsoft.com/ja-jp/library/gg502605(v=office.14).aspx
いかがでしたでしょうか。是非ともアップグレードなどの移行シナリオにおいて、事前にご確認いただき、運用への影響を抑えていただけますと幸いです。
SharePoint Server 2013 Service Pack 1 がリリースされました。
※2014/4/23 更新 - 修正版 SP1 がリリースされました。http://blogs.technet.com/b/sharepoint_support/archive/2014/04/23/sharepoibnt-2013-sp1-rerelease.aspx
以下のリンクよりダウンロードできます。
注意点
関連 KB
入手先
関連情報
こんにちは SharePoint サポートの森 健吾 (kenmori) です。今回の投稿では、ワークフローをご使用のお客様より時折発生すると報告のあるデッドロックという現象について説明します。
診断ログの抜粋
07/27/2011 12:06:00.80 w3wp.exe (0x353C) 0x3170 Windows SharePoint Services Workflow Infrastructure 72fr UnexpectedWorkflow Save Instance: System.Data.SqlClient.SqlException: トランザクション (プロセス ID 115) が、ロック 個のリソースで他のプロセスとデッドロックして、このトランザクションがそのデッドロックの対象となりました。トランザクションを再実行してください。 場所 System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) 場所 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) 場所 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) 場所 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) 場所 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) 場所 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) 場所 System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) 場所 System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) 場所 System.Data.SqlClient.SqlCommand.ExecuteNonQuery() 場所 Microsoft.SharePoint.Utilities.SqlSession.ExecuteNonQuery(SqlCommand command) 場所 Microsoft.SharePoint.Workflow.SPWorkflowManager.SaveInstanceData(Guid trackingId, Stream instanceStream, DateTime wakeupTime, Boolean workflowCompleted, Boolean workflowSuspended, Boolean workflowFaulting, Boolean workflowTerminated, Boolean workflowCanceled, Boolean unlockInstance)
この現象は SharePoint 2007, 2010 で確認している現象であり、SharePoint 2013 で発生するかどうかについては確認がとれておりません。ご了承ください。本投稿では、デッドロックとは何か、ワークフローとロックについて、どのように対処すべきかについてまとめます。
デッドロックとは
デッドロックとは、SQL Server 内の異なる複数のトランザクションにおいてロックが競合したことにより、SQL Server が処理を終了させる仕組みです。SQL Server はデータの一貫性、整合性を保持するために、トランザクションごとに書き込み時、読み取り時に異なるロックを使用して更新データを保護します。このことにより、他トランザクションでの更新が確定 (コミット) される前の情報を読み込んで動作の整合性がとれなくなることのないように制御します。
他トランザクションによって更新中であるリソースを待ち続ける状況をブロッキングと言います。しかし、このブロッキングが複数のトランザクション処理間で、お互いのロックしているリソースを待つ状態になった時に、そのまま待機し続けると永遠に待機する動作となってしまうことは想像できると思います。このような状況においてはSQL Server 側が即座に検知して、片方のトランザクション内の処理をエラー終了させます。このエラー終了される動作がデッドロックです。
デッドロックを語るにあたって、一部の人は「単純に SharePioint がリソースへのアクセス順を順守していないだけで、単なるバグなのでは？」と思っている方もいらっしゃると思いますが、発生原因はそんなに簡単ではありません。
タイトル : デッドロックを避けるコツアドレス : http://blogs.msdn.com/b/jpsql/archive/2011/03/31/tips.aspx
前記にて SQL Server チーム ブログの投稿にもある通り、アプリケーション開発者が予期しない形でロックが割り当てられる可能性があります。
運用側のメンテナンス (インデックス断片化、統計情報の管理) などの結果、クエリ コンパイル結果が想定と異なって、テーブルスキャンとなりロック範囲を広げる場合や、大量書き込み処理によるロック エスカレーションの結果発生する場合もありますし、ワークフローの場合には特にユーザーの実装側に影響 (後記にて補足) をうける場合もあります。
もちろん、製品側に改善の余地があると判断される場合は全力を尽くしてフィードバックを行う所存ではあります。しかしながら、運用環境要因によってロック範囲が開発側の意図せぬ状況に陥っている場合においては、簡単に発生原因を特定して製品開発時に製品標準的に効果がある形での対処を行うということ自体が極めて難しい状況となります。
これまでにも、開発に報告して修正された現象はありますので弊社としてもベストを尽くしておりますが、いくつかの対処案はあるものの、現実的に最も有効な対処策としては現象発生時に処理を運用側で再実行するしかありません。この点につきましてはご理解いただきたいと考えています。
補足 : ユーザー側の実装によって影響をうける要因について
ワークフローは以前の投稿にも記載した通りワークフロー ランタイムに 永続性サービス が使用されており、このサービスの動作として TransactionScope (Serializable 分離レベル) を使用し、ワークフローの進行状況とデータのコミットをクライアント スレッドにて 1 つのトランザクション内に組み込んで SQL Server に対して永続化コミットを行います。
なお、そのトランザクションの範囲については、ワークフローが継続的に処理を実行できる範囲までです。例として以下のような条件が存在するところまでとなります。
・DelayActivity などの待機・ユーザー アクションの待機・ワークフロー バッチ処理のタイムアウト (5 分間) を超えるまで・PersistOnClose 属性のついたアクティビティを実行するまで
ここまでの処理がすべて 1 トランザクション内に組み入れられる動作となります。このようにワークフローでは、他機能と比較しても、一度にかけるロックの範囲が数倍にも大きくなります。つまり、アイテムから値を読み込み、タスクを更新するなどを何気なく行っていても、これらのアクションが 1 つのトランザクション内でリソースにロックをかける順序にもなっています。
SharePoint Designer を使用してワークフローをお使いの場合も想定しており、その場合ユーザーは開発知識があることが前提ではありませんので、このようなデータ アクセスの観点を正確に認識した上でワークフローを作成することは難しいと考えています。この点については、すぐには無理だとしても、設計レベルでの改善を図るようフィードバックしていきたいと考えています。
効果があると想定される対処策について
以下にこれまでのお問い合わせにおいて、お伝えして実際に有効と考えられる対処策を複数紹介します。
1. 運用に応じてインデックス断片化解消や統計情報を更新する。
SharePoint は、1 日 1 回インデックスの断片化状況をチェックし、必要性があると判断する場合はインデックスの再構築を行い、それによって統計情報が更新されます。しかし、例えば夜間や早朝のバッチでアイテムを大量に作成する運用などを別途実施する場合、既存の処理だけでは断片化の解消、あるいは統計情報の更新が十分ではない場合があります。
上記のとおり、このような状況においてはクエリが適切なテーブル スキャンなどが発生し、適切な行のみをロックするとは限らない状況となります。この状況を回避するために、必要なタイミングにてインデックスに対するメンテナンスを運用側で実施することは、運用上のリスクも低くもっとも即効性のある対処策となります。
タイトル : インデックスの再編成と再構築アドレス : http://msdn.microsoft.com/ja-jp/library/ms189858(v=sql.105).aspx
インデックスの再構築
ALTER INDEX PK_Employee_EmployeeID ON HumanResources.EmployeeREBUILD;
インデックスの再編成
ALTER INDEX PK_ProductPhoto_ProductPhotoID ON Production.ProductPhotoREORGANIZE ;
タイトル : クエリのパフォーマンスを向上させるための統計の使用アドレス : http://msdn.microsoft.com/ja-jp/library/ms190397(v=sql.105).aspx
統計情報の更新
sp_updatestats
タイトル : SharePoint Server 2010 のデータベース メンテナンスアドレス : http://technet.microsoft.com/ja-jp/library/cc262731%28v=office.14%29.aspx
2. 1 つのコンテンツ DB 内に組み入れるサイト コレクション数を減らす。
SharePoint 上で何も考えずサイトコレクションを作成すると、Web アプリケーション単位で 1 つのコンテンツ DB 内にすべてのサイト コレクションが格納される動作になります。制限値も考慮した上で、各コンテンツ DB 内に均等にサイト コレクションの格納数を保つように動作しますので、SharePoint サーバーの全体管理で新規コンテンツ DB を作成すると、新しく作成したコンテンツ DB 内に次のサイトコレクションが格納されます。
既存サイト コレクションを別コンテンツ DB に移行する場合は以下のような手順が有効です。
1) サイト コレクションのバックアップを取得する。2) サイト コレクションを削除する。3) コンテンツ DB を作成する。4) サイト コレクションを復元する。(新コンテンツ DB に格納)
3. ワークフローのコミット ポイントを増やす。
デッドロックを防ぐための 1 つの法則として、トランザクションをなるべく短く、ロックの影響を最小限にすることがあります。しかしながら、ワークフローは以下のアクションまで処理を続ける動作になります。
処理がある程度続くと判断される場合は DelayActivity または数分間停止するなどを使用して一度それまでの処理をコミットさせることをお勧めします。
4. トレース フラグ 1224 でロックエスカレーションを抑制する。(ただし��意が必要)
ロックエスカレーションは、例えば一度に大量の行ロックが発生した際に、それをテーブル レベルのロックに切り替えて処理を行う内部処理です。これは、SQL Server においてロックが大量に発生するとメモリを多く消費することを想定した動作です。結果的に、テーブル レベルにロックをかけた方がパフォーマンスの観点を考慮すると高速になることが想定されます。
トレースフラグ 1224 を使用すると、書き込み件数を考慮したロック エスカレーションの実行を抑止します。ただし、例えばフル クロール時における検索 DB に対する大量書き込み時などにおいて、メモリ使用量が増えるかたちとなりますので、この対処を実施すべきかどうかについては事前に十分な検討をする必要があります。
タイトル : ロックのエスカレーション (データベース エンジン)アドレス : http://msdn.microsoft.com/ja-jp/library/ms184286(v=sql.105).aspx
タイトル : トレース フラグ (Transact-SQL)アドレス : http://msdn.microsoft.com/ja-jp/library/ms188396(v=sql.90).aspx
タイトル : SharePoint と SQL ブロッキングの話 Part1アドレス : http://blogs.technet.com/b/sharepoint_support/archive/2012/07/03/sharepoint-sql-part1.aspx
5. SQL Server をスケールアップする。
単純に SQL Server をスケールアップするのも有効な対処策となります。例えば、CPU やメモリ、ディスクなどを増強したり増やしたりすれば、単純に処理速度が上がるためトランザクションがロックを使用する期間を短くでき、ロックが競合するに至る可能性を下げることができると考えられます。また、ロックが重複してロックエスカレーションに至った上でデッドロックに至る確率も合わせて減らすことが可能と考えております。
6. エラー発生したワークフローを再起動する運用を考慮する。
上述の対処がすべて対処不可となった場合、あるいはそこまでの検討を実施していない状況においても、デッドロックの究極の対処策はやはり運用側で再起動を実施する方法となります。この対処の具体的な説明については、先日の本ブログに対する投稿にてまとめておりますので、ご確認ください。
タイトル : 内部エラー (WinWF Internal Error) 発生を想定したSharePoint ワークフローをデザインするアドレス: http://blogs.technet.com/b/sharepoint_support/archive/2012/11/27/a-sharepoint.aspx
デッドロックという観点以外にも、ワークフローがエラー終了することはビジネスに遅延を招きますので、これまでにもリトライや通知機能などを追加するなどを開発本部にフィードバックを行ってきました。しかしながら、ワークフロー ランタイム側がユーザーの入力ミスなどといった必ず発生するエラーと、一時的に発生するエラーとを見分けることは困難であり、さらに修正 (機能追加) の範囲も膨大となるため、製品品質を保つ上でリスクを考慮して見送られている状況です。
製品としての根本解決は極めて厳しい状況であることから、我々サポートとしてもお問い合わせ時に可能な限り現象を回避するための対応を実施している状況です。また、お客様側でより迅速な問題解決を実現するために、情報提供などを実施させていただきたいと考えており、このような情報公開に踏み切っている状況です。
是非とも、これらの情報を現象発生時に何卒お役立ていただけますと幸いです。
こんにちは。SharePoint サポート川添です。
先日 SharePoint Server 2013 がリリースになり、様々な動作検証を実施したり、パイロットで使用されている方もいらっしゃるかと思います。
今回は、SharePoint 2013 での大きな変更点や様々な SharePoint 2013の有用な技術情報が掲載されているWeb サイトを紹介したいと思います。
SharePoint 2013 での大きな変更点
全ての変更点はカバーできませんが、SharePoint 2013 でのはじめの一歩として、特に大きな点について IT Pro の観点から幾つかピックアップしたいと思います(Developer の観点では、また違った変更点があります) 。詳細な技術的な説明は、別の投稿でカバーしていきます。
1. 認証/認可
・SharePoint 2010 で導入されたクレーム認証が既定となり、今まであったクラシック認証が今後廃止予定とされ、今バージョンから非推奨となります。クラシック認証を使用することも可能ですが、GUI からはクラシック認証を持つ Web アプリケーションを作成することはできません。
・新しい認証プロトコルとして、OAuth 2.0 が導入されました。この認証プロトコルは SharePoint Apps(これも新たなアプリケーションの概念ですが) で利用されたり、S2S (Server To Server : サーバー間の認証で利用されます) で使用されるもので、ユーザー認証ではななく、アプリケーションに対する認証に使用されます。
2. インストール/アップグレード
・SharePoint 2013 の前提として、Windows Server 2008R2 SP1 や Windows Server 2012 が利用可能です。また、.NET Framework も 4.5 が必要になります。
・既存の環境に、新規バージョンを上書きインストールするインプレースアップグレードが廃止されました。SharePoint 2010 からのアップグレードでは、データベース アタッチ アップグレードのみが使用可能です。
・Office Web Apps が SharePoint とは独立した別製品として提供されます。SharePoint 2010 では、既存の SharePoint Server 上にインストール、構成を行いましたが、Office Web Apps 2013 では SharePoint を必要としません。
3. インフラストラクチャ
・新規サービスアプリケーションの追加、サービス アプリケーションの廃止が行われます。基本的なサービス アプリケーションの概念は変わりませんが、SharePoint 2013 ではサービス アプリケーションに大幅な変更が加わっています。以下に一部の例を示します。
- App Management Service Application が追加されています。これは、SharePoint Apps や OAuth2.0 / S2S を基盤とする機能 (例. Access Service 2013) を利用する上で必須のサービス アプリケーションで、Searchサービス アプリケーションやUser Profile サービス アプリケーションとともに、SharePoint 2013 では重要なサービスアプリケーションの 1 つです。
- Microsoft Translation ServiceApplication では、Microsoft Translation Service に接続して翻訳できる機能を提供します。バリエーション サイトでの翻訳や、Managed Metadata Service Application の用語の翻訳に使用されます。
- Web Analytics サービス アプリケーションは、サービス アプリケーションとしての位置づけではなく、検索コンポーネントの一部として組み込まれています。そのため、Web Analytics サービス アプリケーションのアップグレードはできません。
- SharePoint 2013 では、FastSearch 2010 for SharePoint との統合が行われ、検索アーキテクチャの刷新が行われました。そのため、SharePoint 2010 とも Fast Search 2010 forSharePoint とも異なる、より進化したアーキテクチャが採用されています。
・分散キャッシュ機能の追加
Windows AppFabric の機能を利用して、キャッシュを単一サーバーで独立して持つのではなく、複数サーバー (Cache Cluster) で分散して保持する機能です。SharePoint2013 では主にソーシャル系の機能が多用しています。なお、既存のオブジェクト キャッシュ等とは別の機能です。
・Request Management 機能の追加
クライアントから発行されたリクエストに対して、ルール等を元にして処理要求先のサーバーを分散して処理する機能です。単に既存の負荷分散装置を置きかえるといったものではなく、既存の負荷分散装置とも共存することができる、SharePoint 内部に実装された機能です。
4. User Interface
・サーバーサイドでのレンダリング処理 (例. XSL など) が、クライアントサイトでレンダリング処理 (例. JavaScript) されるようになりました。すべてがクライアントサイドで処理されるわけではありませんが、サーバーでの負荷軽減やよりリッチな User Experience を提供することを目的として提供されます。メニューをクリックしたりすると、ポップアップ (CallOut) が表示されて、処理されているような状況に出くわすことが多いと思いますが、それがこの変更点にあたります。
・MDS (Minimum Download Strategy) ダウンロード最小化戦略機能では、画面全体を描画するのではなく、必要な箇所のみを取得して画面描画するようになっています。ブラウザのアドレスバーに start.aspx という URL に続いて、ページ URL が追加されているような URL では、この MDS 機能が作動しています。
・Mobile デバイスに最適な UI を提供することができるよう Device Channel 機能が提供されます。特定の User Agent に応じて、特定のレイアウト���提供できるようにする機能です。
5. ソーシャル機能
・SharePoint 2013 での大きな変更点の 1 つです。ソーシャル機能の中では、個人用サイトを中心として大幅な刷新が行われています。マイクロブログの機能、フォロー機能が追加され、フィード機能も大きく変更されています。また、マイクロブログの内容な個人用サイトに保管され、削除されることはありません。
6. Exchange Server 2013 との連携
・先に触れた S2S も関連しますが、Exchange Server 2013 と SharePoint 2013 の連携機能が拡充されています。eDiscovery やサイトメール ボックスの機能が Exchange Server 2013 との連携で実現されています。各機能について簡単に触れると、eDiscovery は主に訴訟を念頭に使用される機能で、SharePoint、Exchange やファイル サーバー等のデータを横断的に検索し、必要なデータをホールドできる機能です。サイト メール ボックスは、特定のプロジェクト等の単位で、専用のメールアドレスを持つことができる機能です。そのため、サイトメール ボックスの場合、Exchange Server 側にメール ボックスを持ちます。なお、これらの機能は2013 での新機能で、クライアントも Outlook 2013 である必要があります。
以上が、SharePoint 2013 での大きな変更点です。ここで触れたのはごく一部の内容なので、これ以外の変更も非常に多数存在しますが、まずは大きくどういった点が変更されたのか、SharePoint 2013 に触る前の取っ掛かりとして参考になればと思います。
SharePoint 2013 の有用な情報を提供するサイト
SharePoint 2013 に関する資料、Web サイトは様々ありますが、その量は現在増加中です。すでに多数の情報が発行されていますが、リリース直後のため、まだ 2010 と比べて不足している箇所もあります。
今後も、新たな資料が次々と発行されていきますので、RSS フィードが提供されている場合には、購読しておくと便利かと思います。
以下は、2013年2月 現在で有用な資料を紹介していますが、英語資料がメインになります。日本語資料がすでに提供されている場合には、言語を英語に変更するか、URL の “en-us” の箇所を “ja-jp” に変更してアクセスすれば、翻訳済の資料を確認できます。
技術情報サイト
SharePoint 2013 for IT pros
http://technet.microsoft.com/en-us/sharepoint/fp142366.aspx
SharePoint 2013 をはじめとして、製品の総合情報ポータルサイトです。累積的な修正プログラムの内容も、SharePoint2010 と同様に一覧で表示される予定です。
SharePoint 2013
http://technet.microsoft.com/en-us/library/cc303422.aspx
SharePoint 2013 の TechNet Library です。IT Pro 向けの技術的な情報は、ここに集約されます。
http://msdn.microsoft.com/en-us/library/jj162979.aspx
SharePoint 2013 の MSDN Library です。Developer向けの技術的な情報は、ここに集約されます。
SharePoint Server 2013 known issues
http://office.microsoft.com/en-au/help/sharepoint-server-2013-known-issues-HA102919021.aspx
SharePoint Foundation 2013 known issues
http://office.microsoft.com/en-001/help/sharepoint-foundation-2013-known-issues-HA102919008.aspx
SharePoint 2013 に関する現在の既知の問題に対する情報を提供しています。
ブログ、Wiki 等
Microsoft SharePoint Team Blog
http://sharepoint.microsoft.com/blog/Pages/default.aspx
SharePoint 製品部門によるブログです。SharePoint 全般、イベントの情報等をここで提供しています。
TechNet - Wiki Articles
http://social.technet.microsoft.com/wiki/contents/articles/default.aspx
Partner や MVP による Wiki ページです。Know-How 等が書かれていることがあります。
おまけ
SharePoint 2013 の Certification Exam (for IT Pro) がオープンになっています。我こそは“SharePoint2013 マスターだ！” と思わる方は是非力試しをしてみては如何でしょうか。
Exam 70-331:Core Solutions of Microsoft SharePoint Server 2013
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-331
Exam 70-332:Advanced Solutions ofMicrosoft SharePoint Server 2013
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-332
こんにちは。
SharePoint サポートチームのとよだです。
待望の新OS、Windows 7 が発売になりましたね。
もうお試しいただけましたでしょうか？
早い、軽い、使いやすいと大変評判の Windows 7。多くの MOSS ユーザー (モスラー) の方々に是非お使いいただきたいと思っております。
もちろん、MOSS 2007 とも仲睦まじく動作いたします。
さて、今回はこの Windows 7 と MOSS 2007 の関係をちょっとだけ垣間見てみたいと思います。
MOSS 2007 のドキュメント ライブラリのビューの一つに、エクスプローラ ビューというものがございます。
これは、ドキュメント ライブラリを Windows エクスプローラのように表示、管理ができるビューになります。
権限さえあれば、コピーもドラッグ & ドロップで可能で直感的に操作ができ、モスラーの皆様には当たり前の機能かと存じます。
このエクスプローラ ビュー、今まで Vista や XP では格納されているファイルが以下のように Internet Explorer 上で表示されていました。
しかし、Windows 7 でから MOSS 2007 のサイトにアクセスし、エクスプローラビューを表示すると、、、、、
以下のように Internet Explorer 上に “エクスプローラ ビューを読み込んでいます。しばらくお待ちください。エクスプローラビューが表示されない場合は、お使いのブラウザでサポートされていない可能性があります。” と表示されてしまいます。
これは困りました。“え？？表示できなくなったの？？”、”おいおい、MOSS 2007 と Windows 7、実は仲悪いんじゃない？” と思われた方もいらっしゃるかもしれません。
しかし、ご安心ください。二人の関係はこんなことでは、断ち切れません。
以下のように、別途 Windows エクスプローラが起動し、Windows エクスプローラ内にドキュメント ライブラリのアイテムが表示されます。もちろん、今まで同様の操作が可能です。
動作をまとめると、 Windows 7 にてエクスプローラビューを表示すると、Internet Explorer 上には表示されず、別途起動する Windows エクスプローラ上で表示されるようになります。
このように動作が変更になったのは、Windows 7 では、Web ブラウザの役割とファイル ブラウザの役割を明確に切り離した背景がございます。
以前のバージョンでは、Internet Explorer をファイル ブラウザとしても利用可能でした。しかしながら、Internet Explorer をファイル ブラウザとして利用する場合、Internet Explorer のオプション設定などが影響し、フォルダ内のアイテムが正しく表示できないなどの問題が多く報告されておりました。
Web ブラウザとファイル ブラウザの役割を Internet Explorer と Windows エクスプローラで明確に分けることで、お互いに与える影響を最小限に抑え、前述のような問題の発生を抑えることが可能となりました。
このことより、MOSS 2007 上でもファイルを表示するエクスプローラ ビューでは Internet Explorer ではなく、Windows エクスプローラにて動作するように変更されております。
Windows 7 環境から MOSS 2007 のサイトにアクセスし、エクスプローラ ビューをお使いの場合にはこの情報をお役立てくださいますと幸いです。
今回は Windows 7 に関連した情報をお届けいたしましたが、いかがでしたでしょうか？
Windows 7 と MOSS 2007 の関係に進展がありましたらまたの機会にご報告できたらと思います。
こんにちは。SharePoint サポートチームの多田です。
最近、MOSS 2007 の機能のひとつである代替アクセス マッピングについて質問をよくいただきます。
今回は代替アクセス マッピングの意味と簡単な設定方法を紹介したいと思います。
代替アクセス マッピングの見方
代替アクセス マッピングの見方がわからないというご質問をよくいただきます。確かに設定画面を見るとなにやら URL が 2 つ並んでおり、何が何なのかわかりません。でも見方は非常に簡単です。
Web アプリケーションを作成するとこのようにひとつ代替アクセスマッピングが作成されます。内部 URL と領域のパブリック URL がそれぞれありますね。これらの URL は Web アプリケーションの作成時に設定した負荷分散される URL が使用されます。これらの URL の意味を簡単に解釈すると、
内部 URL : SharePoint サイトに送信される URL
領域のパブリック URL : ユーザーが使用する URL
です。通常は内部 URL と領域のパブリック URL は同一になるように設定します。一方、社内ネットワークにある MOSS サイトをリバース プロキシ サーバー等を介してインターネットに公開する際には、内部 URL と領域のパブリック URL を異なる設定にする場合があります。以下に紹介する代替アクセスマッピングの設定例では前者の一般的な設定をご紹介します。後者の例については、以下の技術資料に設定例が記載されています。
タイトル : 代替アクセス マッピングを計画する (Office SharePoint Server)
アドレス : http://technet.microsoft.com/ja-jp/library/cc261814.aspx
代替アクセス マ���ピングの設定例
上記のことを踏まえたうえで、以下のシナリオではどのように代替アクセスマッピングを設定すればいいのかをご説明します。
- 環境
Web サーバー 2 台 NLB 構成
仮想ホスト名 : moss.test.com
- 条件
ユーザーが http://moss08 および http://moss.test.com で SharePoint サイトにアクセスする
- 設定手順
(1) 代替アクセス マッピングの設定ページで、"代替アクセス マッピング コレクション: " にて設定を行う Web アプリケーションが選択されていることを確認し、[パブリック URL の編集] をクリックします。
(2) "イントラネット" の欄に [http://moss.test.com] を入力し、[保存] をクリックします。
(3) 正しく設定されたことを確認します。
注意事項
パブリック URL の変更において、領域の "既定" は変更しないことをお勧めします。変更した場合にサイトがクロールできない等の現象が発生する可能性があります。
最後に
今回は基本的な代替アクセスマッピングの設定について説明いたしました。代替アクセスマッピングに関する詳細情報やその他の設定例は以下の技術資料を参照してください。今後とも MOSS 2007 をご活用いただければと思います。
タイトル : 代替アクセス マッピングを構成する
アドレス : http://technet.microsoft.com/ja-jp/library/cc263208.aspx
タイトル : Web アプリケーションの URL と IIS バインドの更新 (Office SharePoint Server)
アドレス : http://technet.microsoft.com/ja-jp/library/cc262366.aspx
SharePoint Server 2013 Service Pack 1 が再リリースされました。
こんにちは、SharePoint サポートの佐伯です。今回の投稿では、アイテム表示テンプレートを使用して検索結果の表示をカスタマイズする方法についてご紹介します。
表示テンプレートとは、検索結果で表示する情報やデザインを定義したものです。この表示テンプレートを編集して検索結果に適用することで、検索結果の表示をカスタマイズすることができます。表示テンプレートの概要については、前回の投稿をご参照ください。
今回は、下の画像のように検索結果のアイテムのタイトル、サマリー、更新者、最終更新日時、URL を表示するアイテム表示テンプレートを作成してみましょう。アイテム表示テンプレート (*.html) の作成それでは実際に、アイテム表示テンプレートを作成してみましょう。既存の表示テンプレートをコピーして作成すると簡単です。 SharePoint 既定のアイテム表示テンプレート “既定のアイテム” をもとに、アイテム表示テンプレートを作成しましょう。なお、*.html ファイルは発行インフラストラクチャをアクティブにしている場合のみ作成できます。この投稿では、発行インフラストラクチャをアクティブにしたサイトで *.html ファイルを作成する方法をご紹介します。1. [サイトの設定] - [Web デザイナー ギャラリー] - [マスター ページ] をクリックし、マスター ページ ギャラリーを開きます。2. [Display Templates]、[Search] の順にフォルダを展開し、Item_Default.html ファイルをダウンロードします。3. ダウンロードした Item_Default.html ファイルのファイル名を変更します。ここでは、Item_Custom.html に変更します。4. Item_Custom.html ファイルを開き、<body> タグの直後にある <div> の id に、この *.html ファイルのファイル名を記述します。<body> <div id="Item_Custom">5. <title> には表示テンプレートのタイトルを入力します。<title>カスタム アイテム</title>6. <mso:MasterPageDescription> には表示テンプレートの説明を記述します。<mso:MasterPageDescription msdt:dt="string">結果アイテムのタイトル、サマリー、更新者、最終更新日時、URL を表示します。</mso:MasterPageDescription>7. 検索結果に表示する管理プロパティのマッピング (タイトル、サマリー、更新者、最終更新日時、URL) を設定します。<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title','Path':'Path','EditorOWSUSER':'EditorOWSUSER','LastModifiedTime':'LastModifiedTime','HitHighlightedSummary':'HitHighlightedSummary'</mso:ManagedPropertyMapping>(補足) 管理プロパティのマッピングを追加する際は、‘<変数名>’:’<管理プロパティ名>’ と記述します。この <変数名> と <管理プロパティ名> は可能な限り同じ名称にすることをおすすめします。もし、<変数名> を <管理プロパティ名> と異なるものに指定する際は、本投稿の下部に記載している 補足) アイテムの情報を取得し表示する Javascript コードの記述方法 をご確認ください。8. <body> 内に、アイテムのタイトル、サマリー、更新者、最終更新日時、URL を取得する Javascript コードを記述します。<!--#_ //タイトルを取得します。 var title = ctx.CurrentItem.Title; var titleHtml = String.format('<a href="{0}" title="{1}" >{2}</a>', $urlHtmlEncode(ctx.CurrentItem.Path), $htmlEncode(title), $htmlEncode(title));
//URL を取得します。 var pathHtml = ctx.CurrentItem.Path;
//サマリーを取得します。 var summaryHtml = Srch.U.processHHXML(ctx.CurrentItem.HitHighlightedSummary);
//最終更新日時を取得します。 var lastModifiedTime = ctx.CurrentItem.LastModifiedTime; var lastModifiedTimeHtml = "最終更新日時 " + lastModifiedTime.getFullYear() + "年" + (lastModifiedTime.getMonth() + 1) + "月" + lastModifiedTime.getDate() +"日";
//更新者を取得します。 var editorHtml = ""; if (!$isEmptyString(ctx.CurrentItem.EditorOWSUSER)){ var editorIdentifiers = ctx.CurrentItem.EditorOWSUSER.split(" | "); if(!$isNull(editorIdentifiers[1])) { editorHtml = "更新者 " + editorIdentifiers[1]; } }_#-->9. 表示するアイテムの情報をタイトル、サマリー、更新者、最終更新日時、URL に変更するため、アイテム表示テンプレート “既定のアイテム” でアイテムの情報を表示していた以下のコードを削除します。_#=ctx.RenderBody(ctx)=#_
10. 手順 8 の Javascript コードの後ろに、アイテムのタイトル、サマリー、更新者、最終更新日時、URL を表示するコードを記述します。<h3 class="ms-srch-ellipsis">_#=titleHtml=#_</h3><!-- タイトル --><div class="ms-srch-item-path">_#=pathHtml=#_</div><!-- URL --><div class="ms-srch-item-summary">_#=summaryHtml=#_</div><!-- サマリー --><div> <span>_#=lastModifiedTimeHtml=#_</span><!-- 最終更新日時 --> <span>_#=editorHtml=#_</span><!-- 更新者--></div>手順 8、10 で記載している Javascript コードについては、本投稿の下部に記載している 補足) アイテムの情報を取得し表示する Javascript コードの記述方法 をご参照ください。11. Item_Custom.html ファイルを保存します。これでアイテム表示テンプレートの作成は完了です。Item_Custom.html ファイルは下記のようになります。<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"> <head><title>カスタム アイテム</title>
<!--[if gte mso 9]><xml><mso:CustomDocumentProperties><mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden><mso:MasterPageDescription msdt:dt="string">結果アイテムのタイトル、サマリー、更新者、最終更新日時、URL を表示します。</mso:MasterPageDescription><mso:ContentTypeId msdt:dt="string">0x0101002039C03B61C64EC4A04F5361F385106603</mso:ContentTypeId><mso:TargetControlType msdt:dt="string">;#SearchResults;#</mso:TargetControlType><mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated><mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title','Path':'Path','EditorOWSUSER':'EditorOWSUSER','LastModifiedTime':'LastModifiedTime','HitHighlightedSummary':'HitHighlightedSummary'</mso:ManagedPropertyMapping></mso:CustomDocumentProperties></xml><![endif]--></head><body> <div id="Item_Custom"><!--#_ if(!$isNull(ctx.CurrentItem) && !$isNull(ctx.ClientControl)){ var id = ctx.ClientControl.get_nextUniqueId(); var itemId = id + Srch.U.Ids.item; var hoverId = id + Srch.U.Ids.hover; var hoverUrl = "~sitecollection/_catalogs/masterpage/Display Templates/Search/Item_Default_HoverPanel.js"; $setResultItem(itemId, ctx.CurrentItem); if(ctx.CurrentItem.IsContainer){ ctx.CurrentItem.csr_Icon = Srch.U.getFolderIconUrl(); } ctx.currentItem_ShowHoverPanelCallback = Srch.U.getShowHoverPanelCallback(itemId, hoverId, hoverUrl); ctx.currentItem_HideHoverPanelCallback = Srch.U.getHideHoverPanelCallback();_#-->
<!--#_ //タイトルを取得します。 var title = ctx.CurrentItem.Title; var titleHtml = String.format('<a href="{0}" title="{1}" >{2}</a>', $urlHtmlEncode(ctx.CurrentItem.Path), $htmlEncode(title), $htmlEncode(title));
//更新者を取得します。 var editorHtml = ""; if (!$isEmptyString(ctx.CurrentItem.EditorOWSUSER)){ var editorIdentifiers = ctx.CurrentItem.EditorOWSUSER.split(" | "); if(!$isNull(editorIdentifiers[1])) { editorHtml = "更新者 " + editorIdentifiers[1]; } }_#-->
<div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="DefaultItem" class="ms-srch-item" onmouseover="_#= ctx.currentItem_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.currentItem_HideHoverPanelCallback =#_">
<h3 class="ms-srch-ellipsis">_#=titleHtml=#_</h3><!-- タイトル --> <div class="ms-srch-item-path">_#=pathHtml=#_</div><!-- URL --> <div class="ms-srch-item-summary">_#=summaryHtml=#_</div><!-- サマリー --> <div> <span>_#=lastModifiedTimeHtml=#_</span><!-- 最終更新日時 --> <span>_#=editorHtml=#_</span><!-- 更新者--> </div>
<div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div></div><!--#_ } _#--></div></body></html>- 表示テンプレート ファイルのアップロードと適用1. 作成した Item_Custom.html ファイルをマスター ページ ギャラリーにアップロードします。2. アップロード後のプロパティの編集画面で、アイテム表示テンプレート (*.html) の作成手順 4 ～ 7 で記述した設定が反映されていることを確認し、保存します。3. 検索結果 Web パーツを配置したページを開き、ページ右上の [ページの編集] をクリックします。4. 検索結果 Web パーツの [Web パーツの編集] をクリックします。5. [アイテム表示テンプレート] で、作成した表示テンプレート "カスタム アイテム" を選択します。(補足) 今回の投稿では、すべての検索結果の種類に対して、今回作成したアイテム表示テンプレートを適用します。6 ページを保存します。
それでは検索ボックスに検索キーワードを入力し、検索をしてみましょう！検索結果にアイテム表示テンプレートで編集した内容が反映されました！！補足) アイテムの情報を取得し表示する Javascript コードの記述方法表示テンプレートでは、Javascript でアイテムの情報を取得し、表示します。まずは以下の記述方法を押さえておきましょう。
<例 1>上記の 2 点の記述方法について、以下のサンプル コードを例に説明します。以下のコードでは、変数 text に "Sample" という文字列をセットし、変数 text の結果を HTML の中に出力します。<!--#_ var text = "Sample"; _#--><div style="color:#4169e1">_#=text=#_</div>HTML での出力結果は以下となります。<例 2>実際にアイテムのプロパティを取得し、出力する方法について見ていきましょう。ctx.CurrentItem は検索結果のアイテムのオブジェクトです。このオブジェクトから対象のプロパティを取得します。アイテムのタイトルを取得したい場合は、ctx.CurrentItem.Title または $getItemValue(ctx, "Title") と記述します。<!--#_ var title = ctx.CurrentItem.Title; _#--><span>_#=title=#_</span>または、<!--#_ var title = $getItemValue(ctx, "Title"); _#--><span>_#=title=#_</span>HTML での出力結果は以下となります。※なお、ここで取得するプロパティは、<mso:ManagedPropertyMapping> で管理プロパティのマッピングの設定をしておく必要があります。また、管理プロパティのマッピング ‘<変数名>’:’<管理プロパティ名>’ で、<変数名> を <管理プロパティ名> と異なる名称に設定している場合は、$getItemValue(ctx, "<変数名>") でアイテムのプロパティを取得します。例)<mso:ManagedPropertyMapping>’DisplayTitle’:’Title’</mso:ManagedPropertyMapping>…<!--#_ var title = $getItemValue(ctx, "DisplayTitle"); _#--><span>_#=title=#_</span>今回の投稿は以上です。検索結果のカスタマイズの際に、ご参考にしていただけますと幸いです。
こんにちは、SharePoint サポートの佐伯です。今回の投稿では、検索結果の表示を制御する表示テンプレートについてご紹介します。SharePoint 2013 では、検索結果の種類ごとに様々な表示テンプレートを適用することで、検索結果に応じて最適な表示を行うことできます。検索結果の種類には、既定でサイトや Web ページ、ドキュメント ライブラリ、リスト アイテムなど各々のコンテンツを対象にしたものが用意されており、表示テンプレートには、検索結果で表示されるアイテムの情報 (タイトルや更新日時、更新者等) や UI (HTML、Javascript、CSS) が定義されています。
検索結果の表示テンプレート検索結果の表示に使用する表示テンプレートには、コントロール表示テンプレート、アイテム表示テンプレート、ホバー パネル表示テンプレート の 3 種類の主要な表示テンプレートがあります。[コントロール表示テンプレート]コントロール表示テンプレートによって、検索結果を表示する全体的な構造が決まります。検索結果全体のレイアウトを制御し、ページング、並べ替え、リンクなど、すべての検索結果に共通の機能も含まれます。[アイテム表示テンプレート]アイテム表示テンプレートでは、検索結果のアイテムの表示方法が定義され、アイテムごとに適用されます。このテンプレートでは、管理プロパティを使用して、結果に表示させるアイテムの情報を選択することができます。また、合わせてデザインを変更することも可能です。[ホバー パネル表示テンプレート]ホバー パネル表示テンプレートでは、検索結果のアイテムにオンマウスをした際のアイテムのプレビューが定義されています。このテンプレートも検索結果のアイテムごとに適用されますが、ホバー パネル表示テンプレートはアイテム表示テンプレートに関連付けます。- 表示テンプレート ファイルと格納場所検索結果で使用する表示テンプレートはマスター ページ ギャラリーに格納されています。1. [サイトの設定] – [Web デザイナー ギャラリー] - [マスター ページ] にアクセスします。2. [Display Templates] フォルダを展開します。3. この [Display Templates] フォルダ内に表示テンプレートが格納されています。ここでは、検索結果 Web パーツの既定の表示テンプレートを例にあげて見ていきましょう。さらに、[Search] フォルダを展開します。4. [Display Templates] – [Search] フォルダ内には、検索結果 Web パーツで使用可能な既定の表示テンプレートが格納されています。検索結果は、下の画像で確認できるような *.js ファイルを使用して描画されます。なお、発行インフラストラクチャがアクティブの場合は、下の画像のような、*.html ファイルと *.js ファイルの一覧が確認できます。※サイト コレクションの機能 “発行インフラストラクチャ” をアクティブにすると、*.html ファイルが作成されます。この *.html ファイルと *.js ファイルは関連付けられており、*.html ファイルを編集してアップロードすると、変更内容が *.js ファイルに反映されます。(“発行インフラストラクチャ” がアクティブでも非アクティブでも、検索結果に反映されるのは *.js ファイルに記述された内容です)表示テンプレートに加えたい変更を *.html ファイルで編集すると、通常の html ファイルと同様に HTML や Javascript、CSS を記述して編集できるので便利です。発行インフラストラクチャをアクティブにしている場合は、マスター ページ ギャラリーに新たに *.html ファイルをアップロードして、カスタムの表示テンプレートを追加することが可能です。*.html ファイルをアップロードした際に、*.html ファイルに関連付けられた *.js ファイルは自動で生成されます。発行インフラストラクチャが非アクティブの場合は、*.html ファイルが存在しないため、*.js ファイルを編集してアップロードします。もしくは、発行インフラストラクチャがアクティブ化されたサイトで *.html ファイルを編集、アップロードして変更内容を反映させた *.js ファイルをコピーして、発行インフラストラクチャがアクティブ化されていないサイトに適用する方法もあります。[既定の表示テンプレートのファイル名]既定のコントロール表示テンプレートでは、"Control_" から始まります。既定のアイテム表示テンプレートとホバー パネル表示テンプレートでは "Item_"で始まり、末尾に "_HoverPanel" がついているファイルがホバー パネル表示テンプレート、ついていないファイルがアイテム表示テンプレートです。下の画像では、Control_SearchResults.html がコントロール表示テンプレート、Item_Default.html がアイテム表示テンプレート、Item_Default_HoverPanel.html がホバー パネル表示テンプレートです。[表示テンプレートのプロパティ]さらに、アイテムの [プロパティの編集] 画面より、既定のアイテム表示テンプレートの *.html ファイル (例 : 既定のアイテム) のプロパティを見てみましょう。アイテムのプロパティ "コンテンツ タイプ" には、コントロール表示テンプレートではコントロール表示テンプレート、アイテム表示テンプレートまたはホバー パネル表示テンプレートではアイテム表示テンプレートが設定されています。また、検索結果 Web パーツの表示テンプレートでは、”対象コントロールの種類 (検索)” には、SearchResults が設定され、"管理プロパティのマッピング" には、表示テンプレートで表示する管理プロパティのマッピングされています。表示テンプレートとして使用する際は、これらの設定が必要です。これらのプロパティの設定は、表示テンプレートの *.html ファイル内に記載された mso:CustomDocumentProperties 要素配下と連携しています。*.html ファイルに設定を記述してアップロードすると、プロパティの設定に反映され、反対に、プロパティの編集画面でプロパティの設定を行うと、*.html ファイルに反映されます。<mso:CustomDocumentProperties><mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden><mso:MasterPageDescription msdt:dt="string">結果アイテムの既定のテンプレートを表示します。</mso:MasterPageDescription><mso:ContentTypeId msdt:dt="string">0x0101002039C03B61C64EC4A04F5361F385106603</mso:ContentTypeId><mso:TargetControlType msdt:dt="string">;#SearchResults;#</mso:TargetControlType><mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated><mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title','Path':'Path','Description':'Description','EditorOWSUSER':'EditorOWSUSER','LastModifiedTime':'LastModifiedTime','CollapsingStatus':'CollapsingStatus','DocId':'DocId','HitHighlightedSummary':'HitHighlightedSummary','HitHighlightedProperties':'HitHighlightedProperties','FileExtension':'FileExtension','ViewsLifeTime':'ViewsLifeTime','ParentLink':'ParentLink','FileType':'FileType','IsContainer':'IsContainer','SecondaryFileExtension':'SecondaryFileExtension','DisplayAuthor':'DisplayAuthor'</mso:ManagedPropertyMapping></mso:CustomDocumentProperties>(補足) このマスター ページ ギャラリーにアップロードされた表示テンプレートは [サイトの設定] – [外観] – [デザイン マネージャー] の [5. 表示テンプレートの編集] からも参照することができます。アイテムの一覧から、表示テンプレートのタイトルとファイル名が確認できるので、表示テンプレートの対象のファイルを探したい場合はこちらのページで確認すると便利です。例えば、“おすすめコンテンツ アイテム” という表示テンプレートは Item_BestBet (*.html、*.js)であることが分かります。
例) 検索結果 Web パーツで表示テンプレートを設定する検索結果 Web パーツを例にして、検索結果の表示に使用する表示テンプレートの設定方法をみていきましょう。表示テンプレートの設定は、[Web パーツの編集] で��います。<コントロール表示テンプレート> [結果コントロール表示テンプレート] 項目のプルダウンより、使用するコントロール表示テンプレートを選択します。<アイテム表示テンプレート>アイテム表示テンプレートでは、[検索結果の種類を使用したアイテムの表示] または [単一のテンプレートを使用してアイテムを表示する] のどちらの方法で検索結果を表示するかを設定します。[検索結果の種類を使用したアイテムの表示] を選択すると、検索結果の種類 (例えば、サイトやドキュメント ライブラリ、リスト アイテム等) に合わせて適用する表示テンプレートを変えることができます。検索結果の種類と表示テンプレートの組み合わせは、上の画像の [検索結果の種類] リンクから設定ページにアクセスすることが可能です。一つの表示テンプレートをすべての検索結果の種類に適用する場合は [単一のテンプレートを使用してアイテムを表示する] を設定します。以下の画像のプルダウンより、適用する表示テンプレートを選択します。なお、ホバー パネル表示テンプレートはアイテム表示テンプレートのファイルに関連付けられているため、アイテム表示テンプレートのみを設定します。今回の投稿では、SharePoint 2013 検索結果で使用する表示テンプレートについて概要をご紹介いたしましたが、検索結果の種類の追加や表示テンプレートのカスタマイズ、また検索結果の種類に合わせた表示テンプレートの関連付けにより、お客様のニーズに合わせて柔軟に検索結果をカスタマイズすることができます。表示テンプレートの詳細なカスタマイズ方法については、今後の投稿で随時ご紹介してまいります。
こんにちは SharePoint サポートの森 (kenmori) です。
SharePoint ワークフローのパフォーマンス チューニングについて記載させていただきます。ワークフローのパフォーマンス チューニングについては、以下のページに記載された内容が非常に詳しいため目新しいことを記載できませんが、本ブログでは少しでもわかりやすく記載できるように努力させていただきます。
タイトル : Workflow Scalability and Performance in Windows SharePoint Services 3.0
アドレス : http://msdn.microsoft.com/en-us/library/dd441390.aspx
なお、WSS3.0 ベースの情報を記載しますので、SharePoint Foundation 2010 においてもほとんどは同じだと思われますが、多少変更されている箇所もあるかもしれません。
最初にワークフローにおいて設定可能な値をご紹介するにあたって前提情報を以下に記載いたします。
前提情報
ワークフローは、即座に実行、終了するイベントレシーバーなどとは異なり、長期に渡り大量の同時進行プロセスが起動するようなプログラムとなります。そのため、以下のような永続性サービスの実装は欠かせません。
多くのビジネス プロセスは、完了までに長い時間 (数か月、ときには数年) がかかります。ワークフローをメモリ内に保持することは、メモリ容量には限りがあるため現実的ではなく、また、1 つのインスタンスは 1 つのサーバー上で処理する必要があるため、拡張性もなくなります。長時間にわたって実行されるワークフローの多くは、フローや処理ロジックを活発に実行しているわけではなく、ユーザーや他のシステムからの入力待ちで事実上アイドル状態になっています。アイドル状態のインスタンスをアンロードすると、メモリを節約できるだけでなく、処理サーバー全体の高いスケーラビリティを実現できます。
(抜粋元 : http://msdn.microsoft.com/ja-jp/library/ms734764(VS.80).aspx )
SharePoint は、独自の永続性サービスを実装しています。特に長期に渡って実行されるワークフローについては、処理を必要に応じてバッチという単位に分割して実行します。適切なタイミングで適切なプロセスが該当のバッチ処理をコンテンツ DB からロードして実行していきます。
ワークフローの処理を実行する主なホストプロセスは以下となります。
1) w3wp.exe (ワーカー プロセス)
特徴 : 即座に実行 (ユーザー操作が集中すると心配・・・)
既定では 15 個以上 <Throttle> のワークフローを同時に起動しようとした場合、ワークフロー インスタンスの状態を開始処理中とマークしてワークフロー���起動を遅延させます。
主な条件 :
ブラウザからワークフロー開始
ブラウザからアイテム / タスク変更などの操作 (イベント発生) 時
2) OWSTIMER.EXE (Windows SharePoint Services Timer サービス )
特徴 : 実行対象としてキューイングされているバッチを取り出し 1 つずつ実行 (完了が遅くなります。)
既定では、”ワークフロー” タイマー ジョブが 5 分に 1 回 <Workflow Timer Interval>、最大 100 個 <Batch Size> のワークフロージョブを読み込み実行します。
主な条件 : ワークフローが永続化された後、後続の処理を実行する場合
そして、SharePoint ワークフローが永続化するタイミングが主に以下となります。細かな条件は他にもあるでしょう。
1. DelayActivity アクティビティなどを使用し、ワークフローがアイドル状態になった場合
2. SharePoint ワークフローのバッチ実行タイムアウト <Timeout> を迎えた場合
3. PersistOnCloseAttribute 属性を使用するカスタム アクティビティが完了したとき。
まとめると、ワークフローをブラウザから起動した場合、最初は w3wp.exe で実行されますが、処理内容やサーバーの状況によっては後続の処理が owstimer.exe で実行されるよう切り替わります。
そして、ワークフローではこの各種実行処理の制限値を設けることができるようになっています。
設定方法
以下の設定値の設定方法と注意点を記載します。書いておいて申し訳ないのですが、パフォーマンスチューニングにあたっては、最初にこれらの値を変更することは影響が大きいためお勧めしません。
まずは、お客様が作成しているワークフローの設計を変更して調整することを最初にご検討ください。パフォーマンスを向上するためのワークフロー設計の推奨事項は後述します。
1. Throttle
2. Batch Size
3. Timeout
4. Workflow Timer Interval
タイトル : ワークフロー : Stsadm プロパティ (Windows SharePoint Services)アドレス : http://technet.microsoft.com/ja-jp/library/cc288139.aspx
この設定により、ワークフローの同時実行数が、既定では 15 として設定されております。これを超えてワークフローが同時実行される際は、ワークフローを再試行するまで待機する動作に移ります。
設定方法は以下のサイトをご確認ください。
タ��トル : Workflow-eventdelivery-throttle : Stsadm プロパティ (Windows SharePoint Services)
アドレス : http://technet.microsoft.com/ja-jp/library/cc287939.aspx
上記制限値によって大量のワークフローが待機状態になると、それぞれのワークフローが自分の実行される順番を待機するため、ワークフローの起動が順次遅延していくことが考えられます。
パフォーマンスカウンタを使用して、開始中の状態にあるワークフローの数を "Workflow Pending" にて確認することができます。Throttle の値を大きくすると、この数が 15 を超えて推移していくことを確認できます。タイトル : ワークフロー パフォーマンス カウンタアドレス : http://msdn.microsoft.com/ja-jp/library/ms732345(VS.80).aspx
急激に大きな値を設定すると、特にワーカープロセス (w3wp.exe) に、ユーザー操作が同じ時間帯に集中すると、一度に大量のワークフローが起動できるようになるため、ページの表示速度の遅延など様々な影響を及ぼす可能性がございます。
この値を変更する場合は、運用を想定した十分なテストを実施する必要があります。
Windows SharePoint Services Timer (OWSTIMER.EXE) において、ワークフロー ジョブ (既定では 5 分に 1 回起動する) が、最大この制限値 (既定では 100) までのワークフローバッチをロードして実行します。
タイトル : Workitem-eventdelivery-batchsize : Stsadm プロパティ (Windows SharePoint Services)
アドレス : http://technet.microsoft.com/ja-jp/library/cc288293.aspx
ワークフローのジョブ実行では、この Timeout 値 (既定では 5 分) を超えて継続して実行できません。実行中のワークフロージョブが Timeout を迎えた場合は、そこで処理を中断し、後続の処理は再度キューに戻され、ワークフロー タイマージョブがまた実行するサイクルとなります。
タイトル : Workflow-eventdelivery-timeout : Stsadm プロパティ (Windows SharePoint Services)
アドレス : http://technet.microsoft.com/ja-jp/library/cc288917.aspx
ワークフロージョブの実行サイクル (既定では 5 分に 1 回) をこの設定によって変更できます。
既定だと DelayActivity などで 1 分待機する設定を実施したとしても、本タイマー ジョブの動作の関係上、最大 5 分待機せざるを得ません。本設定値を変更することで、この実行間隔を狭めることは可能です。
タイトル : Job-workflow : Stsadm プロパティ (Office SharePoint Server)
アドレス : http://technet.microsoft.com/ja-jp/library/cc424970(office.12).aspx
推奨事項
以下にワークフローのパフォーマンスを向上するにあたって推奨事項をご案内します。
1. 最初のワークフロー バッチ サイズを可能な限り小さくする
ワークフロー開始処理の負荷をワーカープロセスに集中させることを防ぐため、ワークフローの最初の方に DelayActivity などを入れて、早めに終わらせます。
ワーカープロセスで実行すると、ワークフロー開始に至ったユーザー操作とワークフロー開始処理が同時に動きます。このため、該当ユーザー操作とワークフローの処理が共通的に参照するリソースにおいて競合が発生する可能性が高まります。
開始時のエラーを避けるためにも、この対処策はベストプラクティスとなります。
2. 一度にたくさんのイベントを待たない
イベントなども w3wp.exe に処理が集中する可能性を高めます。ParallelActivity, ReplicatorActivity, ConditionedActivityGroup (CAG) Activity などによって、大量のイベントを同時に待つような実装は可能な限り避けてください。
このような実装をしている場合において、複数のイベントが同時に発生した場合に、ワークフローがハング (EventDeliveryFailedException) する現象も報告されております。本事象については、別途ブログでご紹介を予定しておりますが、この現象を避け、ワークフローを安定稼働させるためにも、この点についてはご注意ください。
3. 履歴リストにはあまり書き込まない
履歴リストも高機能を有する SharePoint のリスト アイテムである以上、あまり頻繁に履歴リストにログを記載すると、パフォーマンスに影響を及ぼします。特に、実運用に入り、ワークフローの起動数が増えていけばいくほど、深刻化する可能性があります。
イベントログ、診断ログ、独自のログ ファイルなどに書き込むようにしましょう。
4. SharePoint オブジェクトは確実に破棄しましょう。
これは、ワークフローに限った話ではないのですが、SharePoint オブジェクトモデルを使用した際には、オブジェクトを確実に破棄してください。
ホスト プロセスである w3wp.exe や OWSTIMER.EXE が再起動するまで、これらのメモリが蓄積されて保持されるため、パフォーマンスに影響が出る恐れがあります。
タイトル : ベスト プラクティス : Windows SharePoint Services の破棄可能なオブジェクトを使用する
アドレス : http://msdn.microsoft.com/ja-jp/library/aa973248(v=office.12).aspx