Webアプリケーションがアプリケーションサーバーにホストされる
過去に記載した記事の構成(フロントエンド(分散キャッシュを使用)+アプリケーション(検索を使用))で、新規にWebアプリケーションを作成してみると、、
アプリケーションサーバーにもWebアプリケーションが作成されてる!!
SharePoint 2013までは、全体管理の「サーバーのサービス」のところで「Microsoft SharePoint Foundation Web Application」が「開始済み」となっているサーバーがWebアプリケーションをホストするので、さっそく確認してみました。
「Microsoft SharePoint Foundation Web Application」がない!!
しょうがないのでコマンドで見てみましょう。SharePoint管理シェルを管理者権限で起動して、以下のコマンドを実行
1 |
Get-SPServiceInstance -server <アプリケーションサーバー名> | ? { $_.TypeName -eq "Microsoft SharePoint Foundation Web Application" } | fl |
アプリケーションサーバーで「Microsoft SharePoint Foundation Web Application」がオンラインになっている!!
なるほど、これをオフラインにすればいいのか。簡単簡単。
1 |
Stop-SPServiceInstance <上記で確認したサービスのID> |
そして次の日、たまたま確認してみると、、
またアプリケーションサーバーでWebアプリケーションが作成されているし、「Microsoft SharePoint Foundation Web Application」もオンラインになっている!!
なんでや、、と思い調べてみると以下の記事を発見。
What’s new in SharePoint Server 2016 Installation and Deployment
To ensure role-based servers remain in compliance with their specified configuration – SharePoint Server 2016 includes new SharePoint Health Analyzer Health Rules to evaluate individual server role compliance and notify administrators of any changes to a predefined server role.
訳)SharePoint 2016では新しくヘルスアナライザーの正常性ルールが定義されていて、サーバーの役割毎に正常かどうか確認して自動修復するよ。
For example, if a server role is provisioned as a Web Front End and an unexpected service (I.e. Search) is provisioned on that machine, the SharePoint Health Analyzer will detect the deviation and generate a warning indicating the server is out of compliance in addition to providing an option to programmatically resolve the issue and bring the server back within compliance with its configured role definition.
訳)例えば、フロントエンドの役割のサーバーで検索サービスが動いていたとしたら、それはフロントエンドの役割が保持するサービスではないから元に戻す(オフラインにする)よ。
Administrators can change the scan schedule and/or disable the scan entirely in addition to disabling the auto-fix capabilities designed to ensure a server remains within compliance with its assigned role.
訳)管理者はスキャンスケジュールを変更したり、ルールを無効にしたり、自動修復を無効にすることが出来るよ。
なるほどね、SharePoint 2016の便利お節介な追加機能が原因だったのですね。それではそのルールを確認しに行きましょう。全体管理から[監視]-[ルール定義の確認]をクリック。
いたわー、こいつかー、「サーバーの役割の構成に誤りがあります。」。
この画面を見ると気になる点が3つありますね。さっそく検証。
- [範囲]を「いずれかのサーバー」へ変更
→変更後、アプリケーションサーバーで「Microsoft SharePoint Foundation Web Application」をオフラインにし、[今すぐ再解析]をしてみたら、またオンラインになった。 - [オン]のチェックを外す
→この正常性確認のルールが実行されなくなる。 - [自動修復する]のチェックを外す
→自動修復されなくなるが、ヘルスアナライザーでエラーが出力されたままとなる。
となると、個人的には2の対応策をとることになりそうでした。
まとめ
SharePoint 2016では私のような2台構成とする場合、要件によって以下の作業手順が必要ですね。
- 全体管理の[監視]-[ルール定義の確認]から、「サーバーの役割の構成に誤りがあります。」を無効にする。
- SharePoint管理シェルを管理者権限で実行し、以下のコマンドを実行
12Get-SPServiceInstance -server <アプリケーションサーバー名> | ? { $_.TypeName -eq "Microsoft SharePoint Foundation Web Application" } | flStop-SPServiceInstance <上記で確認したサービスのID>
メモメモ。というか、「Microsoft SharePoint Foundation Web Application」は本来アプリケーションサーバーで動かすものなのかな。。
2016/12/05 追記
「サーバーの役割の構成に誤りがあります。」ルールは、動くべきサービスが止まっていたら、自動的に開始してくれます(その逆も)。もともと有効なルールですし、無効にしない方法はないかと試行錯誤して見つけました。
サービスインスタンスの削除です。
以下のコマンドでアプリケーションサーバーが保有する「Microsoft SharePoint Foundation Web Application」を削除することが出来ます。
1 2 |
$SI = Get-SPServiceInstance -server <アプリケーションサーバー名> | ? { $_.TypeName -eq "Microsoft SharePoint Foundation Web Application" } $SI.Delete() |
そしてこの削除、自動修復が有効な「サーバーの役割の構成に誤りがあります。」の再解析が動いても、復活しません!無効にしただけだと復活してしまうのですが、削除されていれば再構成しようとせず、ヘルスアナライザーの警告にも出ないのです!
「さすがに削除までしてたら意図的に削除してるのね、障害じゃないのね」という監視ルールの声が聞こえてきそうです。