SharePoint 2013 から導入された検索サービスの継続クロールですが、これを設定すると既定では15分間隔でクロールが実行されます。対象は SharePoint 上のコンテンツに限ります。ところが、この設定をしても必ず4時間おきに増分クロールがスケジュールされます。これはな何をやっているのか?

カギはユーザー プロファイルの検索にあります。ユーザー プロファイルは継続クロールの対象外であり、必ず増分クロールでないとインデックスが生成されないそうです。ちなみに、ユーザー プロファイルはフルクロールでもダメ。必要なのは増分クロールです。

つまり、ユーザー プロファイルを更新しても最大4時間待たないと検索結果に反映しないということ。

これは、SharePoint 2016 でも同様で、何より SharePoint Online も該当します。オンプレミスであれば、4時間おきですし、ファーム管理者が適宜必要なタイミングで増分クロールを実行することもできます。やっかいなのが、SharePoint Onlineです。こちらは、夜間は2時間おき、日中は最大8時間だそうですが、その日中が日本時間とは限らないため全く読めません。

結論としては SharePoint Online の場合は、ユーザープロファイルを更新してから結果が反映されるまで「一晩の寝かせる」くらいの感覚でいた方がよさそうです。漬物みたいですけどね。以前、SharePoint Online でユーザーの検索結果のカスタマイズを試していて、はまりまくりました。皆さんもお気を付けください。

[参考]

• How to trigger re-indexing of updated user profiles in SharePoint Online

昨日、研修用のデモマシンで突然 SharePoint サイトにアクセス出来なくなるトラブルに遭遇したため、備忘録として、その経緯を記載しておきます。トラブルシューティング方法の流れを確認するには参考になるのではないかと思います。

※とはいえ、これは滅多にないと思いますが。ちょうど先週はサーバー内部のファイル構造などを説明する研修を行っていたので(SharePoint Server 2013 周辺技術の基礎コース) このときデモしながら、なんか、やってしまったかも。

現象と調査過程

サーバー全体管理サイトをはじめ、すべてのSharePointサイトにアクセスできなくなる。しかも、アクセスすると 404 エラーで、サーバーにはアクセスできたが、指定したファイルがないという。

そこで、何が起きたのか確認しようとまずイベントログを見るが特に問題は上がっていない。そこで、早速問題の切り分けを試みた。

• ネットワーク設定は正常か
• IISは正常に稼働しているか
• SharePoint の DB 側は正常に稼働しているか

ネットワーク設定に問題がない。IISについては、新規に単純なIISサイトを作ってアクセス出来るか確認すると問題がない。アプリケーション プールも正常稼働している。アプリケーション プール IDも変更はない。ということは、SharePoint Web アプリケーションが使っている仮想ディレクトリにはアクセスできるということか? たとえば、<サイトURL>/_layouts/15/Images/spcommon.png などを試すと、アクセスできる。ということはサイトの設定ページにはアクセスできるということ。 <サイトURL>/_layouts/15/settings.aspx などはOK。

では、念のためDB側はどうか。アプリケーション プールIDに対して各SharePoint DBが持つべき権限を確認する。他ファームの正常なサーバーと設定比較しても、これも問題ない。次に、PowerShell から、サイトコレクションやサイトのオブジェクトを取得してみる。これも問題ない。サイトの設定変更など試みる。これも問題なくできる。ということは、SharePoint サーバーのIIS 経由でのアクセスがだめなだけで、SharePoint の本体であるDB側は問題ないよう。念のため、手持ちのSharePoint Server Side Object Model を使って作っているアプリで、サイト内のアイテムなども取得出来るか確認するがこれも問題ない。

イベントビューアにもSharePointに関するクリティカルなエラーは出ていないため、となると、やはり IIS 側が怪しい。IISに関わるローカルグループの設定も確認する。ローカルの IIS_IUSRSグループメンバー、WSS_WPGグループメンバーなど設定は既定のままだ。そこで再び、サイトの設定ページにアクセスする。サイトの権限設定ページをクリックすると、エラーとなった。

ここで関連付けIDを得られたので、当該する日付のSharePoint の URL ログを確認してみる。先ほど得た 関連付けID を元に一致する Correlation ID を持つログを確認する。どうやら seattle.master を探しに行って見つからなかったといっているようだ(ついでに、SharePoint 2013 だけでなく、過去のサーバーエディションのフォルダーも想定して探しに行っていることがわかって驚いた。15は SharePoint 2013 だが、14は SharePoint 2010 、12は SharePoint 2007, 60は SharePoint Portal Server 2003用のディレクトリ) 。

このファイルが存在しているか、確認してみたほうがよさそうだ。ということで、 SharePoint ルートディレクトリをたどっていくと、Global フォルダーごとごっそりなくなっていた。これが原因か? ゴースト化されたマスターページが参照出来なかったので、404 エラーとなっていたといこうとでつじつまも合う。

解決

他の正常稼働しているSharePoint ファームのサーバーから Global フォルダーをコピーし、デモ用マシンに再配置。これで、問題なく、どのサイトにもアクセスできるようになった。

ちなみに、今回のトラブルシューティングに関わるような内容を学べるのが、弊社オリジナルの "Microsoft SharePoint Server 2013 と周辺技術の基礎" コースです(ついでに宣伝です)。

Microsoft Office Dev Center で先日アナウンスがあったオンプレミスの SharePoint で利用できる Responsive UI Package を試してみました。ちなみに、レスポンシブ Web デザインとは、利用する端末の種類を問わず、Webブラウザーの解像度に合わせて自動的にWebページのレイアウトを調整してくれる仕組みを持ったデザインのことです。

• Announcing Responsive UI Package for SharePoint on-premises (2013 and 2016)

基本的な使い方等は下記の通り動画が公開されています。

概要

さて、このパッケージについて簡単に解説しておきましょう。

このパッケージは Microsoft 社が公開しているサンプルコード集である SharePoint Patterns & Practices (PnP) の一環として公開されています。PnPは GitHub 上で共有されています。GitHub から必要なファイル群をダウンロードすれば、パッケージの適用自体は、PowerShell で行えるようになっています。このレスポンシブWebデザインのパッケージは、JavaScript と CSS のみで動作するようになっており、既存のマスターページは一切手を入れていないというのが特徴です。適用対象はチーム サイトです。また、この機能を利用するにはサイトの拡張機能の一つである「モバイル ブラウザー ビュー」は非アクティブ化され利用できなくなります。

このパッケージでは、次の3つのレンダリングモデルをサポートしています。

• デスクトップ : 768px 以上のスクリーンサイズ
• タブレット : 481px から 768 px までのスクリーンサイズ
• スマートフォン : 480px 以下のスクリーンサイズ

スクリプトは jQueryを使っておりインターネット上の CDNを参照しているため、インターネット接続環境が必要です。インターネット接続環境が利用できない場合は、JQueryのクラスライブラリをダウンロードし、任意のライブラリに格納した上で、 PnP_Responsive-UI.js内にある参照パスをこれに書き換えます。

手順

検証した際の手順は次の通りです。ちなみに、各手順はすべて検証環境の SharePoint 上で行いました。

SharePoint 2013 でこのパッケージを利用するには最低限 2015年4月のCUが適用されている必要があります。これ以前だとPowerShell実行時にエラーとなります。現在使っているサーバーの状況を確認するには手っ取り早くビルドナンバーを確認してみましょう(SharePoint 2013 のビルドナンバー)。

1. GitHub から必要なファイルをダウンロードする。
2. ソフトウェアをセットアップする
3. PowerShell を使って Enable-SPResponsiveUI コマンドを実行する

GitHubから ZIPファイルをダウンロードします(ダウンロードリンク)。ダウンロードしたら、ZIPを解凍し、 Solutions フォルダ内の SharePoint.UI.Responsive フォルダーを開きます。

ちなみに、この中にある pnp_responsive_ui.css と PnP_Responsive-UI.js はPowerShellコマンドレット実行後に、目的のサイトの"サイトのリソース"ライブラリにアップロードされます。

続いて、OfficeDevPnP.PowerShellコマンドを利用できるよう準備します。これは次の URLからダウンロードできるためそのまま SharePoint 上で実行します。

OfficeDevPnP.PowerShell v15 package

最後に Windows PowerShell　を使って、目的のサイトに UIを適用します。まず、PowerShell コマンドでSharePoint.UI.Responsive フォルダーにカレントを移動します。

次のようなコマンドを実行します。-TargetSiteUrl では目的のサイトコレクションのURLを指定します。オプション等は GitHub のページに記載されているので、そちらを確認してください。

PS C:\> .\Enable-SPResponsiveUI.ps1  -TargetSiteUrl "https://sp2013-b.contoso.com/sites/ResponsiveUiTest"

以上でSharePoint サイトがレスポンシブUIになります。

[デスクトップ] 通常のチームサイト表示のまま

[タブレット]　サイドリンクバーが小さく折りたたまれ、検索ボックスの位置も変わる。また、本文も縦方向に並ぶ。

[スマートフォン]　タブレットよりさらにコンパクトに!

使ってみて問題点などあれば、GitHubにてフィードバックするようにしましょう!

Office 365 と オンプレミスの SharePoint Server とを連携させたハイブリッド構成に関する資料は下記のページにまとまっています。SharePoint Server 2016 関連も公開されています。ご参考まで。

• http://hybrid.office.com/downloads.html

Microsoft の Stefan Goßner さんのブログ記事に記載されていた PSConfigUI.exe と PSConfig.exe との違いについて、要点をかいつまんで、ご紹介しておきます。

[参考] Why I prefer PSCONFIGUI.EXE over PSCONFIG.EXE

CU をインストールした後に実行するのが、PSConfigUI.exe と PSConfig.exe です。PSConfigUI.exe を起動するにはスタートメニュー等から「SharePoint Server 製品構成ウィザード」を実行します。このウィザードの実体が、PSConfigUI.exe です。

このウィザードのコマンドライン版が PSConfig.exe です。この2つの違いはあまり明確に意識しておらず、原則的に「SharePoint Server 製品構成ウィザード」を使っていたのですが、結果的にはこれで正解だったようです。

CU など適用した後にPSConfig.exeでは次のようなコマンドを実行します。

PSCONFIG -cmd upgrade -inplace b2b -wait

しかし、この Exe では、SharePoint のWeb アプリケーションをホストしている IIS のルートの仮想ディレクトリ配下にある、_app_bin がアップデートの対象にならないようです。そもそも製品構成ウィザードでは、、PSConfig.exe のコマンド オプションのうち、次の処理が自動的に実行されるそうです。upgrade 以外も実行されることが分かります。

• helpcollections
• secureresourses
• services
• installfeatures
• upgrade
• applicationcontent

 これらの処理が欠如することで、後から問題が発生することがあります。そのため、PSConfig.exe を使うのであれば、下記のようなコマンドを実行する必要があります。

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources

以上ご参考まで