SharePoint 2010 / 2013 では様々なサービス アプリケーションが利用できますが、オンプレミスの環境では、こうしたサービス アプリケーションを作成する際に、いくつかはアプリケーション プールを指定する必要があります。

ファーム構成ウィザードやサーバー全体管理サイトから作業をする場合、アプリケーション プールは新規に作成できても、削除はできません。たとえば、試しにいくつかのサービス アプリケーションを作り直すような場合、仮の名前のアプリケーション プールがそのまま残ってしまうことがあります。さらに、こうしたアプリケーション プールは Internet Information Services マネージャーからも確認できず、削除もできません。

確認や削除を行うには Windows PowerShell を使用します。

既存のサービス アプリケーション用のアプリケーション プールの確認

Get-SPServiceApplicationPool コマンドレット [http://technet.microsoft.com/ja-jp/library/ff607544%28v=office.15%29.aspx]

既存のサービス アプリケーション用のアプリケーション プールの確認

Remove-SPServiceApplicationPool コマンドレット [http://technet.microsoft.com/ja-jp/library/ff607921%28v=office.15%29.aspx]

オンプレミスでSharePoint サーバーを構築する際、SQL Server は必須です。SharePoint サーバーセットアップ時に SQL Server のインスタンス名を指定しますが、インスタンス名にはホスト名エイリアスが使えます。ようするに別名を付けてアクセスするということです。実際のサーバーインスタンス名を隠蔽できるため、SharePoint 側の設定を変更することなく、SQL Server 側のアップグレードやサーバー統合、ディザスタ リカバリー対策などがしやすくなります。

ホスト名エイリアスの追加手順は次の記事に公開されていますが英語の資料であるため、ここから手順のみを抜粋して記載しておきます。

• [参考]MSDN blog : How to Add a Hostname Alias for a SQL Server Instance

手順の概要は次の通りです。

1. DNSサーバーに目的のサーバーのAレコードを登録する
2. 1で作成したAレコードの IP アドレスのポート 1433 をSQL Server がリッスンするように構成する

ここからはホスト名エイリアスを SP-SQL とし、SharePoint からはこのエイリアスでアクセスするようファームを構築する前提でもう少し細かく手順を確認していきます。

DNSサーバーにAレコードを登録する

DNSサーバーに SP-SQL という名前の Aレコード を登録します。既存の SQL サーバー(SP-SQL14) の IP アドレスは 192.168.11.81 だとすると、Aレコードは次の通りです。

1433ポートをリッスンするように SQL Server を構成する

SQL Server 構成マネージャーを起動し、[SQL Server ネットワークの構成] > [<目的のインスタンス>] > の順にクリックします。[TCP/IP] をダブルクリックします。

 TCP/IP のプロパティ ウィンドウの [プロトコル]タブで [すべて受信待ち] を いいえ に変更し、特定のIPアドレスからのポート 1433 のみをリッスンするようにします。

[IPアドレス]タブでは、IPAll セクションで TCP 動的ポートが空白になっており、動的ポートが無効になっていることを確認します。TCPポートは 1433 を指定します。

続いて同じ[IPアドレス]タブで、リッスンするIPアドレスの構成を確認し、[有効] を はい に設定します。

以上の設定が終わったら SQL Server のインスタンスを再起動します。

SQL Server Management Studio でログを確認します。

以上で基本手順は完了です。

なお、冒頭でご紹介したMSDNのブログではSQL Server側を Kerberos 認証で構成する場合の手順や SQL Server 自体からローカルアクセスする際に必要なKB情報などが掲載されています。

• Kerberos 認証を使う場合は SQL Server サービス アカウントの SPN (サービス プリンシパル名) を追加する
• ローカル アクセスする場合、BackConnectionHostNames エントリーを追加して NTLM 認証を有効にする

ただ、ローカル アクセス云々は SharePoint ファームでは直接関係はないので、必要に応じて記事を確認するとよいでしょう。

以上、ホスト名エイリアスの登録が終わったら、SharePoint ファームを構成ウィザードで構築する際に(下図)、サーバーインスタンス名として利用できます。

 これでSQLサーバーの実際のインスタンス名に依存しない SharePoint 環境の運用が可能になります。

[2014/10/28補足]

(これから構成する方は多くないと思いますが、) FAST Search for SharePoint 2010 を構成する場合は、SQL サーバーのエイリアス設定だとうまくいかないことがあるようですので、念のためご注意ください。

• Use a custom SQL port in the scripted installation of Fast For SharePoint

8月19日付で Technet Blog に SharePoint の更新プログラムに関してわかり易く説明されている記事が公開されています。更新プログラムについては、わかりにくい部分があるため、自分のためにもポイントを要約しておきたいと思います。

• 参考記事 : 「SharePoint patching demystified」

SharePoint は累積更新プログラム (CU) が定期的にリリースされています。これにより、バグ修正などが行えるようになっています。ところで、何が "累積" されるかといえば、これまでの修正プログラムが含まれていくという意味です。ただし、SharePoint の場合には複数のコンポーネントで成り立っているため、各コンポーネントごとに累積していくという意味であることに注意しなくてはいけません。

【※図は TechNetより引用】

更新プログラムには「サーバー パッケージ」("Uber" Package ともいうそうです)　と呼ばれるものがあり、これはその月の対象コンポーネントのCUのみでなく、これまで提供された他のコンポーネントも含む更新プログラムを丸ごと含んでいるものです。

※図は TechNetより引用

これまで CU は2か月おきにこのサーバー パッケージとして提供されてきたのですが、2014年7月からは毎月 CU をリリースするよう変更されています。

"In the past we released cumulative updates every second month. Starting in June we began shipping cumulative updates every month."

そして、2014年8月のCUでは初めてサーバー パッケージではない CU が提供されています(2014年7月 CU は サーバーパッケージです)。つまり、修正が必要なコンポーネントに対する累積された更新プログラムのみが提供されるということです。

こうした変更は、より素早く Fix を提供するための措置ということです。たとえば累積された修正プログラムの一つに不具合が見つかった場合に、その修正を待ってサーバーパッケージとして完全なものを目指すと提供が遅れてしまうため、CUから問題のある Fix のみを取り除いてリリースするという判断だそうです。そのため、今後は CU といっても、サーバー パッケージでないものも適宜提供されるようになるため、更新プログラム適用の際はこの辺の状況は把握しておく必要があります。

また似たようなものに PU (Public Updates)　がありますが、これはセキュリティ修正と SharePointを利用しているユーザー全員に適用したほうがよい更新プログラムを含んでいるものです。CUのサブセットという位置づけです。これもサーバーパッケージとは異なり、修正が必要なコンポーネントのみ対応しています。PU は必要に応じて毎月でもリリースされます。といっても、実際にはこれまで毎月という頻度では提供はされていません。

以上を整理すると次の通りです。それぞれ必要があれば各月ペースで提供されます。なお、どの更新ブログラムもコンポーネント単位でみれば必ず累積されています。

• CU (サーバーパッケージ) … 従来から提供されてきているもので、これまで更新プログラムがリリースされたコンポーネントすべてに対する累積修正プログラムを含む。ユーザーは必要に応じて適用する。
• CU (サーバーパッケージでない) … 2014年6月から提供が始まった。修正が必要になったコンポーネントについては累積した更新プログラム。その月の対象でないコンポーネントは含まれない。ユーザーは必要に応じて適用する。
• PU … 基本スタンスとしてはサーバー パッケージでない CU と同様であり修正プログラムの提供は特定のコンポーネントとなるが、こちらは全ユーザーに適用を推奨している。そのためWindows Update等で配布される

上記のような背景からサーバーパッケージに関してはSharePoint Server用を適用すればよいのですが、それ以外については SharePoint Foudation 用とSharePoint Server用の両方の修正プログラムの適用が必要となるようです。

また、更新プログラムを適用する際に大切なのがベースラインの把握です。提供する立場からすれば、どの時点からの差分として更新ブログラムを提供するかという話ですね。そうしないと更新プログラムのファイル サイズも肥大化しますし。基本的にはまずはRTMがベースですが、その後は最新の PU および Service Pack がベースラインとなります。

現時点で適用されている更新プログラムの確認方法は、書籍でもサーバー全体管理サイトの「ファームのサーバー」ページの構成データベースのバージョンを確認しましょうとご紹介してきましたが、このバージョンはSharePoint foundation コンポーネントのみが管理対象であるということで、参考程度にしかならないとのこと(まったく役立たないわけではありません)。厳密にはサーバー全体管理サイトの「更新プログラムの状態の管理」ページを確認するのが正しいようです。といっても細かすぎて、すぐにわかるレベルではないので酷な話とも思いますが。。。

「更新プログラムの状態の管理」ページ