Reporting Services とインターネット インフォメーション サービスのサイド バイ サイド インストール (SSRS ネイティブ モード)
2014 Reporting Services (SSRS) とインターネット インフォメーション サービス (IIS) SQL Serverを同じコンピューターにインストールして実行できます。 対処する必要のある相互運用性の問題は、使用している IIS のバージョンによって異なります。
| 適用対象: ネイティブ モードReporting Services |
| IIS のバージョン | 発行 | 説明 |
|---|---|---|
| IIS 6.0、7.0、8.0、8.5 | あるアプリケーションに対して送信された要求が、別のアプリケーションによって受け付けられます。 URL 予約には、HTTP.SYS による優先順位規則が適用されます。 同じ仮想ディレクトリ名を持ち、共にポート 80 を監視するアプリケーションが複数存在するとき、これらのアプリケーションに宛てて送信された要求は、目的のアプリケーションの URL 予約が、もう一方のアプリケーションの URL 予約よりもあいまいに指定されていた場合、意図したターゲットに到達しない可能性があります。 |
特定の条件下では、URL 予約体系において他の URL エンドポイントに優先する登録済みのエンドポイントが、他のアプリケーション宛ての HTTP 要求を受信する場合があります。 この競合は、レポート サーバー Web サービスおよびレポート マネージャーに対し、一意の仮想ディレクトリ名を使用することによって回避できます。 このシナリオについては、このトピックで詳しく説明します。 |
URL 予約の優先順位規則
IIS と Reporting Services 間の相互運用性の問題を解決するには、まず URL 予約の優先順位規則を理解しておく必要があります。 優先順位規則とは、簡単に言えば、"より明示的に定義された値を持つ URL 予約が、その URL に合致した要求を先に受け取ることができる" ということです。
仮想ディレクトリを指定する URL 予約は、仮想ディレクトリが省略された URL 予約よりも明示的である。
単一アドレスが指定された URL 予約 (IP アドレス、完全修飾ドメイン名、ネットワーク コンピューター名、またはホスト名) は、ワイルドカードよりも明示的である。
厳密なワイルドカードを指定する URL 予約は、弱いワイルドカードよりも明示的である。
次の表は、一連の URL 予約の例を、最も明示的なものから順に列挙したものです。
| 例 | 要求 |
|---|---|
| http://123.234.345.456:80/reports | ドメイン ネーム サービスが IP アドレスをそのホスト名に http://123.234.345.456/reports 解決できる場合、または http://< computername>/reports に送信されるすべての要求を受信します。 |
| http://+:80/reports | URL に "reports" という仮想ディレクトリ名が含まれている限り、任意の IP アドレス (またはそのコンピューターの有効なホスト名) に送信されたすべての要求が受信されます。 |
| http://123.234.345.456:80 | ドメイン ネーム サービスが IP アドレスをそのホスト名に解決できる場合は、 または http://< computername> を指定http://123.234.345.456する要求を受け取ります。 |
| http://+:80 | [すべて割り当て]にマップされたすべてのアプリケーション エンドポイントについて、まだ他のアプリケーションによって受信されていない要求が受信されます。 |
| http://*:80 | [すべて未割り当て]にマップされたアプリケーション エンドポイントについて、まだ他のアプリケーションによって受信されていない要求が受信されます。 |
ポートが競合している場合は、「System.IO.FileLoadException: ファイルが別のプロセスで使用されているため、プロセスはファイルにアクセスできません (HRESULT からの例外: 0x80070020)」というエラー メッセージが表示されます。
IIS 6.0、7.0、8.0、8.5 の URL 予約 (SQL Server 2014 Reporting Services
前のセクションで取り上げた優先順位規則を踏まえて考えると、Reporting Services と IIS に対して定義された URL 予約が、両者の相互運用性にどのように貢献しているかがわかります。 Reporting Services は、そのアプリケーションの仮想ディレクトリ名を明示的に指定する要求を受信します。一方、IIS は、それ以外のすべての要求を受信し、それらを IIS のプロセス モデル内で実行されるアプリケーションに送ることになります。
| Application | URL 予約 | 説明 | 受信する要求 |
|---|---|---|---|
| レポート サーバー | http://+:80/ReportServer | 厳密なワイルドカード、ポート 80、レポート サーバーの仮想ディレクトリ | レポート サーバーの仮想ディレクトリを指定するすべての要求をポート 80 で受信します。 レポート サーバー Web サービスは、http://< computername>/reportserver に対するすべての要求を受け取ります。 |
| レポート マネージャー | http://+:80/Reports | 厳密なワイルドカード、ポート 80、Reports という仮想ディレクトリ | reports という仮想ディレクトリを指定するすべての要求をポート 80 で受信します。 レポート マネージャーは、http://< computername>/reports に対するすべての要求を受け取ります。 |
| IIS | http://*:80/ | 弱いワイルドカード、ポート 80 | まだ他のアプリケーションによって受信されていない残りの要求をすべてポート 80 で受信します。 |
IIS 6.0、7.0、8.0、8.5 での SQL Server 2014 および SQL Server 2005 Reporting Servicesの並列展開
IIS と Reporting Services 間の相互運用性の問題は、IIS Web サイトに、Reporting Services で使用されているものと同じ仮想ディレクトリ名が存在する場合に発生します。 たとえば、次のような構成を考えてみます。
ポート 80、仮想ディレクトリ名 "Reports" に割り当てられた IIS Web サイトが存在。
既定の構成にインストールされているSQL Server 2014 レポート サーバー インスタンス。URL 予約ではポート 80 も指定され、レポート マネージャー アプリケーションでは仮想ディレクトリ名に "Reports" も使用されます。
この構成により、http://< computername>:80/reports に送信される要求は、レポート マネージャーによって受信されます。 IIS の Reports 仮想ディレクトリを介してアクセスされるアプリケーションは、SQL Server 2014 レポート サーバー インスタンスがインストールされた後に要求を受け取らなくなります。
Reporting Services の新旧のバージョンをサイド バイ サイド配置で実行した場合、前述したルーティングの問題が発生する可能性があります。 これは、すべてのバージョンのReporting Servicesは、レポート サーバーとレポート マネージャー アプリケーションの仮想ディレクトリ名として "ReportServer" と "Reports" を使用するため、IIS に "レポート" と "reportserver" 仮想ディレクトリが存在する可能性が高くなります。
すべてのアプリケーションが確実に要求を受信できるようにするには、次のガイドラインに従います。
Reporting Services のインストールでは、Reporting Services と同じポート上の IIS Web サイトで使用されていない仮想ディレクトリ名を使用するようにします。 競合が生じた場合は、Reporting Services を "ファイルのみ" のモード (インストール ウィザードで [サーバーを構成せずにインストールする] オプションを使用) でインストールします。こうすることで、セットアップの完了後に、仮想ディレクトリを自分で構成できるようになります。 構成が競合している場合は、「System.IO.FileLoadException: ファイルが別のプロセスで使用されているため、プロセスはファイルにアクセスできません (HRESULT からの例外: 0x80070020)」というエラー メッセージが表示されます。
手動構成のインストールでは、構成する URL に既定の名前付け規則を採用します。 SQL Server 2014 Reporting Services (SSRS) を名前付きインスタンスとしてインストールする場合は、仮想ディレクトリの作成時にインスタンス名を含めます。
参照
レポート サーバー URL の構成 (SSRS Configuration Manager)
URL の構成 (SSRS 構成マネージャー)
Reporting Services ネイティブ モードのレポート サーバーのインストール