Inside SharePoint: Enterprise Project Management with SharePoint

[アーティクル]
08/25/2016

SharePoint の内部SharePoint を使用したエンタープライズプロジェクトマネジメント

Pav Cherny

コードのダウンロード: ChernySharePoint2008_12.exe(959 KB)

Project Server のアーキテクチャ
SharePoint の統合
サーバーファームの展開
IIS 7 へようこそ
セッションデータベースの権限
共有サービスの権限
Windows ファイアウォール
MOPS サービスとサービスアカウント
Analysis Services の統合
まとめ

皆さんのニーズを満たすのは、どの SharePoint テクノロジでしょうか。これを検討するために、皆さんはおそらく、コラボレーションとソーシャルコンピューティング、ポータル、エンタープライズ検索、エンタープライズコンテンツの管理、ビジネスプロセスとフォーム、ビジネスインテリジェンス、開発者向けプラットフォーム機能など、途方もない数のカテゴリを調査し、さらに Windows SharePoint Services (WSS) 3.0、Microsoft Office Search Server 2008 Express、Microsoft Office Forms Server 2007、および Microsoft Office SharePoint Server (MOSS) 2007 で提供される機能の比較も行ったでしょう。ただし、マイクロソフトが "SharePoint 製品およびテクノロジ" の一覧に追加していなかったため、皆さんの検討対象にはならなかったと思われるテクノロジが 1 つあります。それは、Microsoft Office Project Server (MOPS) 2007 で可能になるエンタープライズプロジェクトマネジメント (EPM) です。

しかし、MOPS 2007 は SharePoint テクノロジです。このテクノロジは、MOSS 2007 と同様の方法で WSS 3.0 を拡張して構築されました。MOPS 2007 は、部門内および部門間でグループ作業を行うときに、タスク、リソース、および予算の管理効率を向上させる必要があり、WSS 3.0 と MOSS 2007 で提供される小規模のタスク管理機能では不十分であると感じている組織に適しています。MOPS を使用すると、チームサイトをプロジェクトワークスペースに変換し、部門内および部門間で行われるグループ作業を管理し、組織全体を対象とした強固な EPM の基盤を構築できます。ただし、まずは複雑な展開作業について理解する必要があります。

このコラムでは、MOPS 2007 を SQL Server 2005 SP2 および WSS 3.0 SP1 と共に Windows Server 2008 に展開する方法について説明します。まず MOPS のアーキテクチャを簡単に確認して、システムアーキテクトの観点から、MOPS のコンポーネントがどのように WSS 3.0 と統合されるかについて説明します。この情報は、その後に説明する、展開と統合に関する一般的な問題について理解するのに役立ちます。これらの問題には、アプリケーションプールの構成に関する問題、アクセス権が不足する問題、キューシステムの起動エラー、SQL Server 2005 Analysis Services に関する問題などがあります。

ここでは、展開およびトラブルシューティング手順をわかりやすく説明するために、サーバーファーム内に設置された 2 台のサーバー、専用のドメインコントローラ、および SQL Server を実行するもう 1 台のコンピュータで構成される基本的なテスト環境を使用します。この環境は、この SharePoint コラムでこれまで使用してきたテスト環境に似ています。TechNet Magazine Web サイトで入手できるこのコラムの付属リソースには、この環境に対応する手順が記載されたワークシートが含まれています。

Project Server のアーキテクチャ

MOPS 2007 は、最も高度で複雑な SharePoint アプリケーションの 1 つです。このアプリケーションは、WSS 3.0 プラットフォームを最大限に活用して、一元管理、サイトの準備、認証、およびセキュリティ機能を提供します。また、25 種類の汎用および用途別 MOPS Web パーツや、各 Project Web Access (PWA) サイトで使用される最大 4 種類の MOPS データベースを含む新しいコレクションなどのコンポーネントが追加されます。各コンポーネントへのアクセスには、一連のインターフェイス群として Project Server インターフェイス (PSI) を構成する 21 種類の公開済みおよび内部 MOPS Web サービスが使用されます (図 1 参照)。MOPS Web サービスの詳細については、MSDN Web サイトを参照してください。

図 1 SharePoint と MOPS 2007 の統合 (画像をクリックすると拡大表示されます)

MOPS 2007 のアーキテクチャは、クライアントワークステーション、アプリケーションサーバー、およびデータベースサーバー上のさまざまなコンポーネントに依存しています。このコラムでは、これらの中で最も重要なコンポーネントについて説明しますが、すべてのコンポーネントの技術的な詳細を確認する必要がある場合は、Project 2007 SDK に含まれる Project Server のアーキテクチャに関するドキュメントを参照してください。

この SDK の説明を読むときに頭に入れておく必要があるのは、PWA Web パーツと Microsoft Office Project Professional 2007 が、PSI Web サービスに直接アクセスしないことです。この SDK では、クライアントが直接 PSI を呼び出すことを推奨していますが、実際にはほとんどのアプリケーションが PSI フォワーダを使用します。PSI フォワーダは PWA サイトのコンポーネントで、PSI Web サービスへの間接的なアクセスを提供します。PSI を直接呼び出すのは、キューサービスやイベントサービスなど、システムレベルの権限で実行されるサーバーコンポーネントのみです。このちょっとした情報を覚えておくことが、次のような理由でトラブルシューティングを行う必要が生じたときに重要になります。

PWA サイトによってデータベースコンテキスト (各 PWA サイト用に個別の下書きデータベース、発行済みデータベース、アーカイブデータベース、およびレポートデータベースが存在します) とユーザーの権限が定義されるが、通常のユーザーアカウントに PSI Web サービスへのアクセス権が与えられない。
PSI フォワーダが権限の借用をサポートせず、PWA サイトのアプリケーションプールアカウントを使用して、ユーザーの代理で PSI Web サービスにアクセスする。
ファーム内に複数のアプリケーションサーバーインスタンスが存在する環境で、PSI の呼び出しにローカルの PSI Web サービスが使用されないことがある。

SharePoint の統合

では、実際の MOPS と SharePoint の統合について詳しく見ていきましょう。SharePoint 管理者の観点から見ると、MOPS は SharePoint 3.0 サーバーの全体管理でファームサービスとして管理される共有 Web アプリケーションです。これは、MOSS 2007 の共有サービスプロバイダ (SSP) に馴染みのある管理者にとっては比較的わかりやすい説明です。

ただし、SSP の管理経験がない WSS 3.0 管理者は、付属リソースの "Deploying Project Server 2007" ワークシートで、SharePoint ファームの共有サービスと PWA サイトを作成および構成する手順を確認する必要があります。MOPS をインストールして構成したら、IIS マネージャでシステムの実装を分析できます。MOPS アプリケーションサーバー上には、共有サービス、SSP 管理、およびサイトコレクション用に個別の Web サイトが存在します (図 2 参照)。

図 2 PWA と PSI フォワーダを経由した Project Server 2007 へのアクセス (画像をクリックすると拡大表示されます)

クライアントは、PWA サイト内の _vti_bin/PSI 仮想ディレクトリを経由して PSI Web サービスにアクセスします。ただし、PSI Web サービスはこの仮想ディレクトリ内には存在しません。_vti_bin/PSI 仮想ディレクトリがマップされる物理パスは、%COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI です。このディレクトリに格納される web.config ファイルの <httpHandlers> セクションには、*.asmx ファイル (つまり ASP.NET ベースの Web サービス) へのすべての HTTP 要求を、Microsoft.Office.Project.Server.PSIForwarderHandlerFactory を通じてインスタンス化されたカスタム HTTP ハンドラに渡す必要があることが指定されます。

このカスタム HTTP ハンドラが PSI フォワーダです。この PSI フォワーダは、実際の PSI Web サービスへの新しい HTTP 接続を確立し、クライアントの HTTP 要求を転送した後、結果をクライアントに返します。

PSI フォワーダは、Office Server Web サービスサイト内でホストされている共有サービス Web アプリケーションの PSI 仮想ディレクトリを使用して、HTTP 経由で PSI Web サービスにアクセスします。既定では、この仮想ディレクトリは物理パス %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI にマップされます。このパスのディレクトリに MOPS 2007 *.asmx ファイルが格納されます。

Office Server Web サービスについては後で説明しますが、ここで 図 2 から読み取る必要がある最も重要な情報は、PSI フォワーダが、現在 PWA サイトにアクセスしているユーザーではなく、PWA サイトの Web アプリケーションプールに割り当てられた ID を使用して PSI Web サービスと通信することです。

サーバーファームの展開

PSI フォワーダは、システムのスケーラビリティと可用性を強化する目的で、別の Web フロントエンドサーバーと Web アプリケーションサーバーを使用するサーバーファームの展開においても、重要な役割を果たします。MOPS フロントエンドサーバーは、PSI Web サービスやその他の MOPS サービス (キューサービスやイベントサービスなど) をホストしない WSS 3.0 サーバーですが、PSI フォワーダを含む PWA サイトへのアクセスをクライアントに提供します (図 3 参照)。

図 3 中規模の MOPS 2007 サーバーファーム (画像をクリックすると拡大表示されます)

一方、アプリケーションサーバーは、一連の MOPS コンポーネントと MOPS サービスがすべてインストールされた WSS 3.0 サーバーです。アプリケーションサーバーでは PWA サイトをホストできますが、多くの場合、バックエンドサービスのみがフロントエンドサーバーに提供され、WSS Web アプリケーションサービスは実行されません。サーバーの役割は、MOPS のインストール中に選択します。

図 3 は、中規模のサーバーファームの構成を示しています。組織の要件に応じて、フロントエンドサーバーを追加してスケーラビリティを強化したり、アプリケーションサーバーを追加して高可用性を確保したりできます。MOPS アプリケーションサーバー用に負荷分散クラスタを構成する必要はありません。これは、サーバーファーム内に複数の MOPS アプリケーションサーバーが存在する場合、PSI フォワーダが PSI の要求によって生じる負荷を自動的に分散するからです。MOPS の展開オプションの詳細については、「Office Project Server 2007 の展開」を参照してください。

IIS 7 へようこそ

理論の説明はこれぐらいにして、実際に MOPS 2007 を展開するときに発生する可能性があるいくつかの問題について見ていきましょう。個人的に最も関心がある問題の 1 つは、ホストによって名前が付けられる、PWA サイトのサイトコレクションです。このシナリオでは、問題なく MOPS を展開し、SSP を構成し、ホストヘッダーモードで PWA サイトを準備できます。これを行うには、[Project Web Access サイトの作成] ページで、[ホストヘッダーとして Project Web Access のパスを使用する] チェックボックスをオンにした後、PWA の完全な URL (pwa など) を入力します。すべてのリソースが準備された後、サイトを開こうとすると、PWA ではなく、標準的な IIS 7 のようこそ画面が表示されます。

既定の Web サイトを SharePoint によって拡張せず、他の Web サイトを PWA URL に適切にバインドしなかった場合、この動作が発生します。IIS は、明示的なサイトのバインドが存在しない場合、拡張されていない既定の Web サイトに pwa の要求を関連付けるので、このようこそ画面が表示されます。PWA サイトのホスト用に選択した SharePoint Web アプリケーションへの必要なバインドが、SharePoint 3.0 サーバーの全体管理によって追加されることを予想したかもしれませんが、そのような動作は発生しません。

この問題を回避するには、既定の Web サイトを SharePoint によって拡張し、付属の "Troubleshooting IIS and PWA" ワークシートに記載されている説明に従い、このサイトコレクションを使用して PWA サイトを準備します。また、IIS マネージャで、不足しているサイトのバインドを、PWA 用に選択した Web アプリケーションに手動で追加することもできます。この手順は、PWA サイトをホストするすべての WSS サーバー上で実行する必要があります。

セッションデータベースの権限

既定の Web サイトを拡張する場合は、アプリケーションプールでドメインアカウントを使用する必要があります (詳細については、「管理アカウントとサービスアカウントを計画する (Office SharePoint Server)」を参照してください)。これ以外のアカウントを使用すると、PWA サイトを準備した後に、権限に関する問題が発生します。通常は、PWA サイトに関するあまり詳しくないエラーメッセージが表示されます (図 4 参照)。

図 4 SSP データベースへのアクセスに関するエラー (画像をクリックすると拡大表示されます)

より詳しい情報を得るには、%COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\LOGS ディレクトリにあるトレースログを確認します。ファーム内に複数の負荷分散用 Web フロントエンドサーバーが存在する場合、これは面倒な作業になる可能性があります。

この場合、トラブルシューティングを行う目的で、PWA ホスト名に対応する DNS レコードの構成を変更し、一時的に 1 台のフロントエンドサーバーを参照することをお勧めします。これで、どのサーバーによってクライアントからの要求が処理されるかがわかるので、そのサーバーのトレースログファイルを確認するだけで済みます。

最後に更新されたログファイルをメモ帳で開き、"データベースを開けません" というエントリを検索します。このエントリが見つかった場合、問題はデータベースの権限にあります。たとえば、図 4 のトレースログは、アカウント LITWARE\WSS02$ にデータベース SharedServices1_DB へのアクセス権が与えられていないことを示しています。これは、PWA サイトがネットワークサービスの ID で実行されていることを意味します。

LITWARE\WSS02$ は Web フロントエンドサーバーのコンピュータアカウントで、SharedServices1_DB は共有サービスプロバイダデータベースです。Web フロントエンドサーバーはこのデータベースを使用して、ASPStateTempSessions テーブルに格納される ASP.NET セッション状態データを管理しますが、LITWARE\WSS02$ にはこのデータベースへのアクセス権が与えられません。

毎週行うデータベースメンテナンスの対象に共有サービスプロバイダデータベースを追加して、システムの安定したパフォーマンスを確保することが重要です。たとえば、「サーバーファーム環境に Project Server 2007 を展開する」の説明に従い、SQL コマンド TRUNCATE TABLE ASPStateTempSessions を使用して、有効期限が切れたセッション状態データを ASPStateTempSessions テーブルから削除します。

ネットワークサービスに関連する構成が原因で、複雑な問題が発生することもあります。次に、このような問題について詳しく見ていきます。ドメインアカウント (LITWARE\SspConfigAdmin など) は、どのコンピュータでもまったく同じになるため、サーバーファーム内のアプリケーションプールで機能します。一方、ネットワークサービスアカウント (NT AUTHORITY\NETWORK SERVICE) は、コンピュータごとに異なります。NT AUTHORITY\NETWORK SERVICE アカウントは、wss02.litware.com というフロントエンドサーバー上では LITWARE\WSS02$ に変換されますが、sql01.litware.com というサーバー上では LITWARE\SQL01$ に変換されます。ここに問題があります。

SQL Server Management Studio で SharedServices1_DB の SQL Server 権限を確認すると、NT AUTHORITY\NETWORK SERVICE アカウントには、ネットワークサービスアカウントを使用するアプリケーションプールに共有サービスプロバイダデータベースへのアクセス権を与えようとして、db_owner 権限が与えられていることがわかります。ただし、これが有効なのは 1 台のサーバーを使用する場合のみです。

LITWARE\WSS02$ と他のすべての WSS サービスアカウント (LITWARE\WSS01$ など) に SharedServices1_DB の db_owner 権限を明示的に与えることによって権限の割り当てを修正することもできますが、SharePoint によって必要なデータベース権限が与えられた同じ ID をすべてのフロントエンドサーバーから使用できるように、アプリケーションプールにドメインアカウントを使用することをお勧めします。

共有サービスの権限

なんらかの理由から、PWA サイトのアプリケーションプールでネットワークサービスアカウントを使用する場合、SSP に関連する権限が原因で問題が発生します。先ほど、PSI フォワーダがユーザーの代理で PSI Web サービスにアクセスするときに、PWA サイトのアプリケーションプールアカウントで提供されるコンテキストを使用することについて説明しました。このアカウントに Office Server Web サービスサイトへのアクセス権が与えられていない場合、再び通常の SharePoint エラーメッセージが表示されます。この場合、フロントエンドサーバーのトレースログには、"The request failed with HTTP status 401: Unauthorized" (HTTP ステータス 401: Unauthorized で要求が失敗しました) というエラーメッセージが記録されます (図 5 参照)。

図 5 HTTP ステータス 401: Unauthorized で失敗した要求 (画像をクリックすると拡大表示されます)

このエラーは、PWA におけるユーザーの権限に言及しているわけではありません。PWA サイト内で与えられる SharePoint 権限によって、どのユーザーがそのサイトの _vti_bin/PSI 仮想サブディレクトリにアクセスできるかが決まりますが、これらのユーザーには、アプリケーションサーバー上の共有サービス Web アプリケーションや PSI Web サービスへのアクセス権は与えられません。

PWA サイトコレクションの管理者としてシステムを実行する場合でも、PWA サイトのアプリケーションプールアカウントに PSI Web サービスへのアクセス権が与えられていなければ、MOPS でエラーが発生します。このエラーは特に、サーバーファーム内のアプリケーションプールでドメインアカウントを使用するという推奨事項を無視して、ネットワークサービスアカウントを使用した場合に発生します。

アプリケーションサーバー上の SSP へのアクセス権を確認するには、Office Server Web サービスサイトのルートディレクトリ (既定では %PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Root) にある web.config ファイルを調べます。<authorization> セクションに NT AUTHORITY\NETWORK SERVICE エントリが記述されていることから、ネットワークサービスアカウントを使用するアプリケーションプールに権限が与えられていることがわかります。ただし、このエントリはフロントエンドサーバーではなくローカルコンピュータのみを参照するので、タスクを完了することはできません。

最も良い方法は、ドメインアカウントを使用するようにアプリケーションプールの構成を変更することです。ただし、それでもネットワークサービスアカウントを使用する必要がある場合は、フロントエンドサーバーのアカウントに明示的に権限を与えます。

この場合、アプリケーションサーバー上の web.config ファイルを直接編集しないようにしてください。変更内容は SharePoint によって上書きされます。"Testing Shared Service Provider Access Permissions" ワークシートの説明に従い、SharePoint 3.0 サーバーの全体管理を使用して、不足している権限を与えます。また、SSPCheck (付属リソースに含まれています) など、直接 PSI Web サービスへの HTTP 接続を確立する単純な ASP.NET アプリケーションを使用して構成を検証します。信頼できる結果を得るには、PWA サイトのアプリケーションプールで ASP.NET アプリケーションを実行します。

Windows ファイアウォール

ここまでくれば、かなりの確率で PWA を開くことができます。もちろんこれは、Web フロントエンドサーバーを経由して PWA にアクセスし、さらに MOPS アプリケーションサーバー上の Windows ファイアウォールによって TCP ポート 56737 と 56738 がブロックされないことが条件です。TCP ポート 56737 と 56738 は、Office Server Web サービスサイトの HTTP 通信と HTTPS 通信に既定で割り当てられるポートです。

SharePoint が MOPS アプリケーションサーバー上に Office Server Web サービスサイトを作成するときに、自動的にこれらのポートを開くことはありません。アプリケーションサーバーで Windows ファイアウォールが有効になっている場合は、フロントエンドサーバーが PSI Web サービスにアクセスできるように、これらのポートへのトラフィックを許可するファイアウォールの規則を手動で作成する必要があります。ファイアウォールによってこれらのポートがブロックされている場合、図 6 のようなエラーメッセージが表示され、接続済みのホストが応答しなかったことを示すエラーメッセージがフロントエンドサーバーのトレースログに記録されます。

図 6 Project Web Access が Project Server に接続できないことを示すエラーメッセージ (画像をクリックすると拡大表示されます)

MOPS サービスとサービスアカウント

これでフロントエンドとバックエンドの通信に関する問題を解決できたので、Project Web Access にアクセスできるようになります。一安心したところで、次は、より複雑な MOPS 固有の問題について説明します。深呼吸して、MOPS アプリケーションサーバーのアプリケーションイベントログを開いてみましょう。キューシステムを起動できなかったことを示す無数のエラーメッセージが表示されます (図 7 参照) が、ショックを受けないでください。また、MOPS サービスの CPU 使用率が 100% 近くまで達していることもわかります。

図 7 キューシステムを起動できなかったことを示すエラーメッセージ (画像をクリックすると拡大表示されます)

キューシステムは MOPS アプリケーションインフラストラクチャの重要な構成要素で、MOPS データベースの挿入要求と更新要求の処理、クリーンアップジョブとメンテナンスジョブの実行、およびデータ分析タスク用にレポートデータベースを更新する処理を行います。詳細については、「Microsoft Office Project Server 2007 キューシステム」を参照してください。この記事によると、キューシステムは Windows サービスに依存し、アセンブリ Microsoft.Office.Project.Server.Queuing.exe に実装されています。また、このシステムは SharePoint 構成管理とタイマサービスのアカウントを使用して、ファームの構成データベースにアクセスします。

Windows サービスは起動時に、構成データベースからすべての SSP の一覧を取得します。この一覧には、対応する SSP 管理者アカウントとその暗号化済みパスワードが含まれます。その後、Windows サービスは PWA サイトに関連付けられた SSP ごとに、対応する SSP 管理者アカウントのコンテキストを使用して、追加の Microsoft.Office.Project.Server.Queuing.exe プロセスを起動します。つまり Microsoft.Office.Project.Server.Queuing.exe は、異なるアカウントを使用して自身のインスタンスを複数起動するので、MOPS アプリケーションサーバー上で実行される Microsoft.Office.Project.Server.Queuing.exe プロセスの合計数は、SSP の数に 1 を加算した数と等しくなります。

追加で起動されるプロセスインスタンスは、キューワーカープロセスです。個々のキューワーカープロセスは、自身に関連付けられた SSP を基に一連の PWA サイトを決定し、それらのサイトごとに個別のポーリングスレッドを起動して、キューに格納されているジョブの処理を開始します。処理の結果は、対応する PWA サイトデータベースに反映されます。これがキューシステムのしくみです。このしくみは、Windows タスクマネージャで確認できます。

ファーム内の MOPS アプリケーションサーバー上で、1 つの SSP が複数の PWA サイトに関連付けられる場合、2 つの Microsoft.Office.Project.Server.Queuing.exe プロセスが実行されます。1 つは構成管理アカウントとして実行されるプロセス、もう 1 つは SSP 管理者アカウントとして実行されるプロセスです。私のテスト環境では、これらのアカウントは WssConfigAdmin と SspConfigAdmin です (図 8 参照)。

図 8 アクセスが拒否されることが原因で失敗するプロセス間通信 (画像をクリックすると拡大表示されます)

では、なぜキューシステムは起動しないのでしょうか。アプリケーションイベントログ内のエラーエントリからは十分な情報が提供されませんが、SharePoint 3.0 サーバーの全体管理を開き、[サーバー構成の管理] タブの [診断ログ] で、すべてのカテゴリの [トレースログの記録対象となる重要度の最も低いイベント] を一時的に [詳細] に設定することによって、より詳しい情報を得ることができます。

図 8 は、この結果としてイベントが記録されたトレースログを示しています。詳しく見ると、ProjectQueueService (Window サービス全体) が QueueExecService (キューワーカープロセス) を起動していますが、アクセスが拒否されたことが原因で QueueExecService プロセスが失敗したことがわかります。QueueExecService が失敗した場合、ProjectQueueService は再度そのプロセスの起動を試みますが、まったく同じ理由で失敗します。このため、ProjectQueueService によって CPU サイクルが途切れることなく使用され、イベントログとトレースログに無数のエラーが記録されます。つまり無限ループが発生します。

残念ながら、最も詳しいトレースログからも、アクセスが拒否されたことを示すエラーの具体的な原因を特定することはできません。でもあきらめないでください。消去法によって、すぐに根本原因を特定できます。

SharePoint 3.0 サーバーの全体管理で SSP 管理者アカウントを変更し、構成管理アカウント (WssConfigAdmin) を指定すると、キューシステムは起動します。逆の設定も可能で、単に SSP 管理者アカウントを変更せずに (SspConfigAdmin のままにし)、それを Windows サービスのサービスアカウントとして使用しても、キューシステムは起動します。

その結果、構成管理アカウントと SSP 管理者アカウントの両方に、必要な権限がすべて与えられます。したがって、キューシステムが起動しないのは、ProjectQueueService と QueueExecService で異なるアカウントが使用された場合のみです。

これは、ローカルコンピュータ上で対話するプロセス間で、権限に関する問題が発生することを意味します。結局のところ、サービスの一貫した動作を保証するには、ProjectQueueService プロセスと QueueExecService プロセスがお互いを監視する必要があります (図 8 のトレースログに記録されている ProcessWatcher エントリを参照)。たとえば、ProjectQueueService Windows サービスを停止すると、すべての QueueExecService ワーカープロセスが終了します。

異なるセキュリティコンテキストで実行されるプロセスにアクセスしようとすると、エラーが発生します。このようなプロセスにアクセスするには、昇格された特権が必要です。サービスアカウントにこのような特権が与えられる場合もありますが、ユーザーアカウント制御 (UAC) が既定で有効になっていることが原因で、プロセスが標準の特権を使用して実行され、Windows Server 2008 によってアクセスが拒否されます。

UAC を無効にすると、昇格された特権を使用して ProjectQueueService プロセスと QueueExecService プロセスを実行できるようになるので、キューシステムは起動します。構成管理アカウントをすべての SSP の管理者アカウントとして使用し、それによってすべてのキュープロセスを同じアカウントで実行するか、UAC を無効にして MOPS アプリケーションサーバーのセキュリティを低下させるかは、皆さん次第です。

SharePoint の関連リソース

SharePoint 製品およびテクノロジ Web サイト
microsoft.com/sharepoint

Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/sharepoint

Windows SharePoint Services デベロッパーセンター
msdn.microsoft.com/sharepoint

Microsoft Office Project 2007 の全般的な参照情報
msdn.microsoft.com/library/bb258902

Microsoft SharePoint 製品とテクノロジチームのブログ
blogs.msdn.com/sharepoint

管理者アカウントとサービスアカウントを計画する (Office SharePoint Server)
technet.microsoft.com/library/cc263445

Analysis Services の統合

最後に、SQL Server 2005 Analysis Services に関する問題を取り上げます。この問題は、「Project Server 2007 キューブ作成サービスで SQL Server 2005 Analysis Services を使用するための要件」(このコラムの執筆時の最終更新日は 2007 年 4 月 5 日です) の説明に従って操作を行った場合に発生することがあります。ドキュメントの説明に従い、SQL Server 2005 データベースを作成することによって Analysis Services リポジトリを作成した場合、PWA のキューブを作成するときに図 9 のようなエラーが発生します。

図 9 Analysis Services の構成が正しくないことが原因で発生するキューブの作成エラー (画像をクリックすると拡大表示されます)

ここで重要なのは、MOPS 2007 が SQL Server 2000 Analysis Services を前提として設計されていることです。下位互換性を維持するには、追加の手順を実行して SQL Server 2005 Analysis Services を構成する必要があります。SQL Server 2000 Analysis Services は、キューブの作成に関するリポジトリの情報を Microsoft Jet データベースに格納します。Jet データベースを移行して SQL Server 2005 と連携させることもできますが、新しく展開した MOPS でこのような操作を行う必要はありません。

先ほど紹介した TechNet の記事には、Jet データベースが実際に存在するかどうかにかかわらず、Jet データベースの機能をエミュレートするように SQL Server 2005 を構成する方法が記載されています。ただしこの記事には、ある説明が不足しています。それは、Analysis Services が Jet データベースを使用するように構成されている (以前の方法) か、SQL Server 2005 データベースを使用するようにあらかじめ構成されている (推奨される方法) かにかかわらず、MOPS は、データベースサーバー上の .dso ファイル共有に記述されている、リポジトリのロックに関する情報を確認することです。

このファイル共有が存在し、SSP 管理者アカウントにこのファイル共有へのフルコントロールアクセス権が与えられていない限り、キューブの作成は図 9 のような権限エラーで失敗します。SQL Server 2005 Analysis Services を MOPS のキューブ作成サービスと正しく連携させるには、付属の "Configuring Cubes" ワークシートに記載されている手順に従ってください。

まとめ

MOPS 2007 の展開は簡単ではありません。MOPS 2007 のアーキテクチャは複雑で、正しく展開するには多くの手順を実行する必要があります。まず、サーバーファームの構成を正しく計画し、アプリケーションサーバーと Web フロントエンドサーバーにバイナリファイルをインストールして、SharePoint 製品とテクノロジ構成ウィザードを実行します。その後、SharePoint 3.0 サーバーの全体管理で、アプリケーションプール、共有サービス、SSP 管理サイト、および PWA サイトを準備し、最後に SQL Server Management Studio で Analysis Services を構成します。

展開が難しくなる原因は、Windows Server 2008 で提供される Windows ファイアウォールや UAC などのセキュリティ機能が展開の妨げになること、SharePoint 管理ツールの利便性が低いこと、および MOPS の展開に関するドキュメントが充実していないことです。SharePoint 3.0 サーバーの全体管理を使用することによって、サーバーファーム内のアプリケーションプールでネットワークサービスアカウントが使用されたときに警告を受け取ったり、必要な構成の変更 (IIS サイトのバインドや Windows ファイアウォールの規則など) をすべて自動的に適用したり、準備した PWA サイトの運用状態を確認したりすることはできません。

また、何も手を加えずにすべてがうまくいくことは期待できません。MOPS のアーキテクチャと依存関係について十分に理解し、製品の推奨事項に従う必要があります。さらに、展開が確実に成功するように、テストプロジェクトの計画を作成し、テスト用のリソースを手配して、MOPS の構成と機能を徹底的に検証するようにします。

展開には苦労しますが、MOPS はエンタープライズプラットフォームとしての SharePoint の能力を受け継いでいます。MOPS では、SharePoint テクノロジと Web サービステクノロジが活用されるので、クライアントワークステーション上で直接データベースに接続する必要がなくなります。また、キューシステムによって、ピーク時間帯 (理由はよくわかりませんが、すべてのプログラム管理者は、月曜日の朝にそれぞれのプロジェクト計画を更新しようとします) の MOPS の安定性が強化されます。その他の MOSS テクノロジを使用して、さらに多くの基幹業務アプリケーションと MOPS を統合することもできます。

過去に Project Server 2003 向けのビジネスソリューションを開発した経験からすれば、MOPS 2007 の展開に伴う問題は、過去のスケーラビリティに関する問題、低速のネットワーク接続を使用する従来の ODBC 接続、Excel を使用してすべてのサブクエリを追跡しなければならないほど多くの JOIN ステートメントを含むデータベースクエリを構築することの苦しみに比べれば、ちっぽけなものです。MOPS 2007 は EPM の進化における大きな成果であり、このアプリケーションを苦労して展開するだけの価値はあります。

Pav Cherny は、主にコラボレーションとユニファイドコミュニケーションに関するマイクロソフトテクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイトペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズサービスの専門企業 Biblioso Corporation の代表取締役です。

目次

その他のリソース