秋の夜長に盛り上がったので。メモとして。
SCDPM をインストールするときに SSRS でエラーとなり、IIS を入れたら解消したという A さんの twitter のつぶやきから事件が始まりました…。
SQL Server 2008 以降は SSRS (SQL Server Reporting Services) をインストールすることで Web サーバーとしての機能も賄えるようになったため、IIS のインストールが不要になりました。
IIS との共存はできるのですが、特定のパスに関しては SSRS 側で処理がされる仕組みなのかと思います。
# IIS を必要としていた時の AD FS も似たような構成になっていたような気がします。
Reporting Services とインターネット インフォメーション サービスのサイド バイ サイド インストール
「IIS 入れるとインストールできるようになるのはなんでだろ??」と思って twitter を眺めていたところ A さんの環境では複数回発生しているということだったので「ほほ~」と思って、調査に取り掛かってみました。
これが秋の夜長のインストール大会になるとも知らずに…。
今回使用している環境は、
- Windows Server 2012 R2 (2013/10/20 時点のパッチ適用済み)
- SQL Server 2012 R2 SP1 (CU 未適用)
- System Center Data Protection Manager 2012 R2
- 第二世代仮想マシンとして構築
という環境です。
SQL Server 2012 R2 SP1 に関してはデフォルトの設定でインストールしています。
そのため、主要な設定は以下のような設定になっています。
インストールした機能 | データベースエンジン セマンティック検索 (フルテキスト検索) SSRS 管理ツール |
照合順序 | Japanese_CI_AS |
SQL Server サービスアカウント | NT ServiceMSSQLSERVER |
SQL Server Agent サービスアカウント | NT ServiceSQLSERVERAGENT |
SSRS サービスアカウント | NT ServiceReportServer |
管理者 | Administrators |
この状態でドメインの Administrator でログインして SCDPM をインストールしてみると、サービスアカウントの設定でいろいろとエラーになります。
サービスアカウントの設定がいろいろと出ているので変更してみます。
SQL Server のサービスアカウントの変更はサービスからでなく構成ツールから変更する必要があります。
今回の設定変更は上から順に実施し、SQL Server のサービスアカウントを変更した際にはダイアログによりサービスの再起動を行っています。
また、SQL Server Agent サービスについてはサービスから自動起動をするように変更しています。
SQL Server 構成マネージャー | SQL Server サービスアカウント | Local System |
SQL Server Agent サービスアカウント | Local System | |
Reporting Sevices 構成マネージャー | SSRS サービスアカウント | Network Service |
SSRS のサービスアカウントを変更した際の結果がこちらになります。
この結果が、のちのエラーの伏線になっていましたがこのときは気づく由もありませんでした…。
# そもそも BI 苦手。
再確認をするとエラーがなくなりましたのでインストールを続けます。
インストールが開始されると、以下のようなエラーが発生します。
レポートの構成でエラーが発生しました。
Microsoft SQL Server Reporting Services が正しくインストールされ、実行されていることを確認してください。
ID: 812
これが A さんが発生していた現象となり、私の環境でも再現しました…。ということで環境固有ではなく再現性のあるものとなります。
ということで事件の真相を追ってみたいと思います。
SSRS がらみでエラーになっていることはメッセージからわかるのですが詳細が分かりません。そこでログを確認してみます。
DPM のインストールログですが [C:Program FilesMicrosoft System Center 2012 R2DPMDPMLogsDpmSetup.log] がログファイルになりますのでこの中を確認してみます。
ログを見ていると気になるメッセージがあります。
System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: レポート サーバーは、レポート サーバー データベース内の機微なデータまたは暗号化されたデータへのアクセスに使用する対称キーの暗号化を解除できません。バックアップ キーを復元するか、または暗号化されたすべてのコンテンツを削除する必要があります。 —> Microsoft.ReportingServices.Library.ReportServerDisabledException: レポート サーバーは、レポート サーバー データベース内の機微なデータまたは暗号化されたデータへのアクセスに使用する対称キーの暗号化を解除できません。バックアップ キーを復元するか、または暗号化されたすべてのコンテンツを削除する必要があります。
SSRS 関連の構成でエラーとなり、このエラーが ID 812 のエラーとしてまとめられているようですね。
[http://localhost/Reports] にアクセスして SSRS の状態を確認してみます。
ログと同じメッセージが表示されていますね。
どうやら SSRS の構成がうまくいっておらず、DPM 用のレポートが発行できないことが犯人のようです。
なぜこのような状況になってしまったのかを調べれば原因がわかりそうですね。
今回はセットアップ時に SQL Server のサービスアカウントのエラーが発生したので、インストール時に適切なアカウントに変更しています。
SSRS のサービスアカウントを変更する際の技術情報として、 Reporting Services のサービス アカウントの構成 があります。
ここにヒントとなる記述が。
サービス ID を変更すると、一連のイベントが開始されます。サービスが再起動され、パスワードで保護された暗号化キーが更新され、URL 予約が更新されます。
ここで、SSRS のサービスアカウントを変更したときを思い出してみます。
通常は以下の二つのダイアログが表示されます。
いろいろ検証をしていたのですが、SSRS のサービスアカウントを変更した際に、暗号化キーのバックアップが実行されないことがあるようです。
暗号化キーのバックアップが表示されずにサービスアカウントを変更した場合、アカウントの変更後に暗号化キーの復元が行われず上述のエラーとなってしまうようです。
このような状態になった場合は、「暗号化されたコンテンツの削除」を実行して、暗号化されたコンテンツを削除して、「変更」で暗号化キーを置き換えるとエラーが解消されます。
# 変更はいらないかもしれませんが。
これでエラーが発生することなく DPM をインストールすることができます。
SSRS のサービスアカウントを変更した際に [暗号化キーのバックアップ] のダイアログが表示されないことがある原因まではわからなかったのですが、Reporting Services 2008 Service Account error と似たような感じなのでしょうか。
# 同様の事例はあるようです。
この現象を発生させないようにするためには、
- SQL Server のインストール時に SSRS のサービスアカウントを適切なものに設定する
- SSRS のサービスアカウントを変更する際には、事前に暗号化キーのバックアップを取得し、サービスアカウント変更時に暗号化キーのバックアップが表示されなかった場合は、取得したバックアップキーを復元する
ということを意識しておくとよいのかと。
ということで DPM のエラーというよりは SSRS のアカウント変更時の挙動による影響ということのようでした…。
[…] SCDPM 2012 R2 のインストール時に SSRS の構成でエラーとなることがある | SE の雑記http://engineermemo.wordpress.com/2013/10/26/scdpm-2012-r2-%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%8… […]
DPM データベースとしてローカル インスタンスを使用した DPM サーバーのインストール | 焦げlog
25 1月 14 at 14:38
[…] SCDPM 2012 R2 のインストール時に SSRS の構成でエラーとなることがある | SE の雑記 http://engineermemo.wordpress.com/2013/10/26/scdpm-2012-r2-%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%8… […]
DPM データベースとしてリモート インスタンスを使用した DPM サーバーのインストール | 焦げlog
31 5月 14 at 19:10