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

[SP2016] MinRole の役割変更

SharePoint 2016 から MinRole の概念が導入されています。サーバー構成時にフロントエンド、検索、アプリケーションなど役割を指定できるようになっています。しかし、検証環境では最初に "単一サーバーファーム(Single Server Farm)" としてインストールすることも多いでしょう。これを後から役割変更できるのですが、意外にうまくいかないようです。確実に成功させるには "ファーム構成ウィザード" 実行前に役割を変更することです。実行後の変更は結構やっかいであるようです。

役割変更はサーバー全体管理サイトからでもPowerShellからでも行えます。ファーム構成ウィザード実行後に例えばアプリケーションの役割に変更しようとしてもサーバー全体管理サイトからの設定ではエラーが発生します。英語版でも試しましたが同様です。

2016-10-30_16-25-59[システム設定]>[このファームの役割を変換する]から変更

2016-10-30_15-46-53 Event ID : "a72id" というエラーが発生する

ファーム構成ウィザード実行前だと成功します。

2016-10-30_17-14-38

2016-10-30_17-28-15

この対処方法としては下記のブログ記事のように構成データベースのでタッチとアタッチが有効ですが、試すとサーバー全体管理サイトのサービスがホストされなくなるようで、これをPowerShellにより個別に開始する必要がでてきます。

このため、すでにファーム構成ウィザードを実行済みの場合は、役割変更はWindows PowerShellから実施とこのようなエラーにはならないようです。コマンド実行後、タイマージョブにより設定が変更されるため数分待つ必要があるので注意しましょう。サーバーの状態を見て"アプリケーション" となっていれば基本的にはよいのですが MinRole への準拠が "いいえ" となり表示される "修正" をクリックすると 単一サーバーファームへとロールが戻ってしまう現象が発生しています。

まずは、セットアップしに役割変更しなくて済むように構成しておくことが大切だといえそうです。またファーム構成ウィザード実行前ならまだ間に合うといったところですこの問題への対処は追加情報が分かり次第、追って記載したいと思います。


[SP2016] サーバーの状態が "アップグレードが利用可能" のままになる

SharePoint Server 2016 のサーバーの全体管理サイトで「ファームのサービスを管理」を確認するとサーバーの状態が "アップグレードが利用可能" となっていることがあります。CUを適用後に製品構成ウィザードを実行したのにも関わらず消えない。

2016-10-24_18-08-17

これについてはサポート技術文書が公開されています。

"Upgrade Available" status in new SharePoint Server 2016 farm

解決方法としては 次の方法があります。

  1. SharePoint 2016管理シェルを使ってサーバー全体管理サイトのデータベース内のコンポーネントをアップグレードする
  2. 製品構成ウィザードをコマンドから実行する

私の環境では1は効果がなく、2を実行することで問題が解消しました。

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


[SP2016] Windows Server 2016 サポート

先日 Windows Server 2016 が GA となりましたが、TechNet の下記のページを確認したところ、SharePoint 2016 でも正式サポートとなったようです。

Hardware and software requirements for SharePoint Server 2016」 (最終更新日 : 2016年10月18日時点)

現在サポートされているOSは次の通りです。

  • The 64-bit edition of Windows Server 2012 R2 Standard or Datacenter
  • Windows Server 2016

日本語のページは下記にありますが、こちらは情報がアップデートされていない模様。気を付けましょう。

SharePoint Server 2016 のハードウェア要件およびソフトウェア要件

ちなみに、Windows Server 2016 のRTM版でのインストールはまだ検証していません。

 


[SP2016] Compliance Policy Center Site のバグ

SharePoint 2016 から新たに「コンプライアンス ポリシー センター サイト」が利用できるようになっています。これは Office 365 で既に利用できるようになっている機能でもあります。

2016-10-18_16-55-56

さて、このサイトを使うときの注意点ですが、2016年10月現在 (October 2016 CU適用済み)ではバグがあるようです。コンプライアンス センターサイトで提供される機能としては次の2点がありますが、そのままではどちらの機能も正常に動作しません。

  • ドキュメント削除ポリシー
  • データ損失防止 (DLP)

あれこれ数日がかりで調べた結果、ようやく基本的な動作をしてくれるようになったので、結果を共有しておきます (そもそもポリシー反映に時間がかかるため検証には時間がかかります。。。)

下記TechNetに関連するきになる情報が上がっていました。

  • http://social.technet.microsoft.com/wiki/contents/articles/35100.sharepoint-2016-august-2016-cu-issue-fixed.aspx

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 されているべきところですが、修正されていない可能性があるだろうとにらみ、コンプライアンスセンター サイトをいったん削除し、システム時刻を変更したあとサイトを作り直してみたところ正常に動作するようになりました。

システム時刻

2016-10-18_12-33-20

正常な動作

-- ドキュメント削除ポリシー

2016-10-18_12-26-00

2016-10-18_12-25-42

-- DLP

2016-10-18_12-37-14

念のためコンプライアンス センター サイトの地域の設定から日付を変更してみたりもしています。動作が怪しい場合はこのあたりを疑ってみた方がよさそうです。ちなみに、DLPは動作しても今度はドキュメント削除ポリシーに不具合がでてお、こちらはまだ解消できていません。現象としては上の図の通り、サイトコレクションへのApplyはできるのですが、サイトの管理設定でポリシーを変更しようとするとエラーになります。

2016-10-18_16-44-43

どうもコンプライアンスセンターサイトは 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 はこの状態を検知し、他の管理アカウントに変更するようにメッセージを表示します。

2016-10-18_7-32-27

分散キャッシュサービスのアカウントはサーバー全体管理サイト>[セキュリティ]>[サービス アカウントの構成]で確認できます。

2016-10-18_7-36-28

しかし、この画面からアカウントを変更しようとするとエラーになります。分散キャッシュのアカウントはPowerShellから変更する必要があるためです。

2016-10-18_7-16-46

変更には次のコマンドを実行します。

$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