SharePoint Server 2016 のサーバーの全体管理サイトで「ファームのサービスを管理」を確認するとサーバーの状態が "アップグレードが利用可能" となっていることがあります。CUを適用後に製品構成ウィザードを実行したのにも関わらず消えない。
これについてはサポート技術文書が公開されています。
「"Upgrade Available" status in new SharePoint Server 2016 farm 」
解決方法としては 次の方法があります。
私の環境では1は効果がなく、2を実行することで問題が解消しました。
PSConfig.exe -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
先日 Windows Server 2016 が GA となりましたが、TechNet の下記のページを確認したところ、SharePoint 2016 でも正式サポートとなったようです。
「Hardware and software requirements for SharePoint Server 2016」 (最終更新日 : 2016年10月18日時点)
現在サポートされているOSは次の通りです。
Windows Server 2016
日本語のページは下記にありますが、こちらは情報がアップデートされていない模様。気を付けましょう。
「SharePoint Server 2016 のハードウェア要件およびソフトウェア要件」
ちなみに、Windows Server 2016 のRTM版でのインストールはまだ検証していません。
SharePoint 2016 から新たに「コンプライアンス ポリシー センター サイト」が利用できるようになっています。これは Office 365 で既に利用できるようになっている機能でもあります。
さて、このサイトを使うときの注意点ですが、2016年10月現在 (October 2016 CU適用済み)ではバグがあるようです。コンプライアンス センターサイトで提供される機能としては次の2点がありますが、そのままではどちらの機能も正常に動作しません。
あれこれ数日がかりで調べた結果、ようやく基本的な動作をしてくれるようになったので、結果を共有しておきます (そもそもポリシー反映に時間がかかるため検証には時間がかかります。。。)
下記TechNetに関連するきになる情報が上がっていました。
August 2016 CU でのバグフィックスの情報であり次のように書かれています。
A Compliance Policy Center isn't provisioned completely when the server time zone isn't set to UTC+0. No error is visible for the end-user, the ULS log contains the following event:
Information Policy Management asv22 Unexpected Error creating Dar Task Aggregate items for policy center.
When you set up the DLP scenario, the DAR task list stays empty. This prevents the DLP functionality to work.
つまりは、コンプライアンス センターサイトを作成する際にサーバーのシステム時刻を UTC +0 (世界協定時) に設定しておくということです。環境には October 2016 CU を適用しているため本来は Fix されているべきところですが、修正されていない可能性があるだろうとにらみ、コンプライアンスセンター サイトをいったん削除し、システム時刻を変更したあとサイトを作り直してみたところ正常に動作するようになりました。
システム時刻
正常な動作
-- ドキュメント削除ポリシー
-- DLP
念のためコンプライアンス センター サイトの地域の設定から日付を変更してみたりもしています。動作が怪しい場合はこのあたりを疑ってみた方がよさそうです。ちなみに、DLPは動作しても今度はドキュメント削除ポリシーに不具合がでてお、こちらはまだ解消できていません。現象としては上の図の通り、サイトコレクションへのApplyはできるのですが、サイトの管理設定でポリシーを変更しようとするとエラーになります。
どうもコンプライアンスセンターサイトは Beta 2 までは動作していた模様で、RCやRTMでうまくいっていないよう。先ほど英語版でかつRTMで同じように試しましたが、こちらはDLPが正常に動作していません。最低限 August CU 2016は適用しておく必要がありそうです(時間がないので、適用までは英語版の方はCU適用をためせませんでしたが)。ネットで情報を探すのですが、そもそもこの機能を試している人が少ないようで有益な情報がほとんどありません。上記の通り、かなりバグが多い印象で検証はできても運用は難しいレベルに感じています。マイクロソフト社のサポートにきちんと情報をエスカレーションした方がよさそうです。
ちなみに、eDiscovery サイトの方はシステム時刻など関係なく問題なく動作します。新機能だからこそ、バグはきちんと修正してほしいですね。
なお、DLP のポリシーはそもそも Office 365 と異なり米国、英国用のものしかなくカスタマイズもできない状況です。このあたりもどうにかしてほしいですね。念のため、日本のクレジットカード番号を試しましたが認識してくれませんでした。 ※訂正します。検証手順が悪かったようです。改めて "PCIデータ セキュリティ基準(PCI DSS)" テンプレートを使って検証したところ、認識しました。
今後の 大幅な Update を待つのか、Office 365 とのハイブリット構成に期待すべきか現時点では悩ましいところです。
SharePoint Server 2013 以降では分散キャッシュサービスが導入されています。
分散キャッシュサービスの既定のアカウントはファームアカウントであるため、必要に応じて変更します。Health Analyzer はこの状態を検知し、他の管理アカウントに変更するようにメッセージを表示します。
分散キャッシュサービスのアカウントはサーバー全体管理サイト>[セキュリティ]>[サービス アカウントの構成]で確認できます。
しかし、この画面からアカウントを変更しようとするとエラーになります。分散キャッシュのアカウントはPowerShellから変更する必要があるためです。
変更には次のコマンドを実行します。
$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount -Identity domain_name\user_name
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()
[出典] https://technet.microsoft.com/en-us/library/jj219613(v=office.16).aspx
SharePoint 2016 では、継続的クロールの停止が素早くできるようになっています。検索先のWebアプリケーションのURL変更をするには継続クロールはいったん無効化する必要があるのですが、無効化が実質上の継続的クロールの停止となります。
SharePoint 2013 までは停止にかなりの時間がかかっていたため、これは意外と助かります。