いつもお使いのレポートが突然「期限切れ」と表示されると驚いてしまうかもしれません。特に終了日を設定していないはずなのに、なぜスケジュールが停止してしまうのか、本記事で詳しく解説していきます。
SSRS共有スケジュールが「期限切れ」になる原因とは？
SSRS（SQL Server Reporting Services）の共有スケジュールが「期限切れ（Expired）」と表示されてしまう現象は、主にSQL Server Agentの起動・停止状態や、スケジュールそのものの設定ミス、不整合などが原因とされています。正常に動作しているつもりでも、些細な設定漏れやSQL Server環境の不具合によりスケジュールが期限切れと判定されることがあります。
共有スケジュールがスケジュールとして正しく認識されない
本来、共有スケジュールでは「開始日時」や「終了日時」を明示的に設定していない限り、自動的に期限切れになることはありません。しかし、何らかの理由で内部的に「正常な設定ではない」と認識されると、終了日時があるかのように扱われる可能性があります。
SQL Server Agentジョブとの関連
SSRSのスケジュール実行はSQL Server Agentのジョブとして登録・管理されます。SQL Server Agentが停止していたりエラー状態で動作していなかったりすると、SSRSは「スケジュールが機能していない」とみなすことがあります。結果的に、共有スケジュールが正しく動いていない＝期限切れと同様の扱いになってしまうのです。
SQL Server Agentが果たす役割
SQL Server AgentはSQL Server上でジョブ（処理のまとまり）をスケジューリングして実行するサービスです。SSRSでスケジュールを組んだレポート送信（サブスクリプション）は、バックエンドではSQL Server Agentが管理する「ジョブ」に変換されます。ここではAgentの役割や確認ポイントについてもう少し詳しく見ていきましょう。
SQL Server Agentサービスの状態確認
もしAgentサービスが停止していたり、起動していない状態であれば、以下の操作を試してください。
- Windowsの「サービス」アプリケーションを開く。
- 「SQL Server Agent(MSSQLSERVER)」などの名称を探す。
- ステータスが「停止」となっている場合は「開始」ボタンをクリックし、正常に起動するか確認する。
Agentが起動中かつ自動で開始される設定（スタートアップの種類：自動）になっているかも合わせてチェックしてください。
SQL Server Agentが起動しない原因の例
- サービスアカウントのパスワード期限切れ
- SQL Serverのアップデート後に構成ファイルが変更された
- ファイアウォールやウイルス対策ソフトの設定でブロックされている
- サーバーのリソース不足（ディスク容量やメモリ不足）
これらの要因でAgentが正常に起動できず、スケジュールが「期限切れ」と判断される場合があります。
サブスクリプション設定の確認
スケジュールが「期限切れ」と表示されている場合、サブスクリプションそのものの設定を見直すことも重要です。具体的には、終了日の指定が誤って行われていないかや、開始日と終了日の組み合わせに矛盾がないかを確認します。また、サーバーの日時設定が誤っているケースもあります。
サーバーの時刻同期の重要性
もしサーバーの時刻が大幅にずれている場合、SSRSは共有スケジュールの開始日時や終了日時を正しく認識できません。例えば、実際の日付が1月1日なのに、サーバー内部では既に2月1日と認識している場合、スケジュールによっては「期限切れ」とみなされることがあります。
サブスクリプションの終了日時設定例
通常、終了日時を明示的に指定していない場合は「無期限」で動作する設定になっています。しかし、誤操作やポリシーによって強制的に期限を設定していることもあります。以下の手順で再度確認してみましょう。
- レポートマネージャーまたはWebポータルにアクセス
- 対象レポートの「Manage」（管理）や「Subscribe」（サブスクライブ）を選択
- サブスクリプションの編集画面で「スケジュール設定」のタブを確認
- 「終了日」の設定が有効になっていないかチェック
もし終了日が設定されていれば、それを削除または解除することで「期限切れ」状態を回避できる場合があります。
SQL Server Agentジョブ履歴やSSRSログの確認
SSRSでスケジュールが動いているかどうかを調べるには、SQL Server Agentのジョブ履歴とSSRSのログが手がかりとなります。実際にジョブが失敗したり中断されたりすると、その履歴が残りますので、どのようなエラーが発生しているかを詳細に追跡できます。
SQL Server Agentジョブ履歴の見方
SQL Server Management Studio（SSMS）を使って、以下のステップでジョブの履歴を確認可能です。
- SSMSを起動し、対象のSQL Serverに接続
- [SQL Server Agent] – [ジョブ]を展開
- SSRSに関連するジョブを右クリックし、[履歴の表示]を選択
- 失敗しているステップやエラーメッセージがないかチェック
よくあるエラーメッセージ
| エラーコード/メッセージ | 原因 | 対処方法 |
|---|---|---|
| SQLServerAgent could not be started | サービス起動権限の問題やアカウントのパスワード期限切れ | サービスアカウント情報を確認し再設定 |
| The job failed. Unable to determine if the owner… | ジョブの所有者アカウントが無効/存在しない | 所有者を現行の有効なアカウントに変更 |
| Conversion failed… datetime format… | 日付の形式変換エラー（ロケールやフォーマット設定） | サーバーの地域設定やSQLクエリを確認 |
SSRSログのチェックポイント
SSRSのログは通常、レポートサーバーのインストールディレクトリ以下に存在します。たとえば、標準的なインストールの場合、以下のようなディレクトリを探すと見つかることが多いです。
C:\Program Files\Microsoft SQL Server\MSRSXX.<インスタンス名>\Reporting Services\LogFiles
※ディレクトリ構成はSQL Serverのバージョンやインスタンス名によって異なります。
ログにはサブスクリプションの実行時における詳細な情報（開始時間、終了時間、エラー内容など）が記録されているので、エラーメッセージがないかどうか確認しましょう。
スケジュールの再作成・再配置の手順
既存の共有スケジュールが誤って期限切れ扱いになっている場合、スケジュールそのものを作り直すと問題が解決するケースがあります。これは、設定の不整合や内部的なID紐づけの問題が原因であるときに有効です。
共有スケジュールの再作成手順
- レポートマネージャー（またはWebポータル）で「Site Settings」（サイトの設定）を開く
- 「Schedules」（スケジュール）のページへ移動
- 当該の共有スケジュールを選択し、「Delete」（削除）または「無効化」
- 画面右上または適切な場所にある「New Schedule」（新しいスケジュールの作成）をクリック
- 以前と同じ設定（開始日時、繰り返しの間隔など）を入力
- 完了後、正常に動作するかテストする
再作成時のポイント
- スケジュールの名前をわかりやすいものに変更する（以前と同名でも問題ないが、識別できると後々便利）
- 実行間隔が現実的な値になっているか見直す（1分ごとなど過度に短いスパンは負荷が大きく失敗率も上がる）
- 開始日時がすでに過去の日付になっていないか確認する
再配置（移行）の際に気をつけること
サーバー移行やバックアップからの復元後にスケジュールが期限切れとなる場合があります。そのようなときは、SSRSのデータベース（ReportServerおよびReportServerTempDB）の整合性やSQL Server Agentの設定を確認し、再度スケジュールを1から設定し直すことが解決の近道です。
サーバーOSやSQL Serverのアップデートに伴う注意点
サーバーOS（Windows Server）やSQL Server本体をアップデートした直後、設定ファイルやサービス構成が変更される可能性があります。それによりスケジュールが期限切れと認識されるケースがあるため、アップデート後は以下のような点を確認するとよいでしょう。
サービス構成の再確認
- SQL Server Agentが自動で起動する設定になっているか
- SSRSサービスが「自動」かつ正常に開始されているか
- 必要に応じて、Reporting Services Configuration Managerで各種設定を再度確認
権限設定やセキュリティポリシーの変化
アップデートにより、グループポリシーやファイアウォールのルールが変更されることがあります。特にサービスアカウントに与えられていた特権が取り消される場合があるため、Agentのジョブオーナー権限やSSRSの実行権限を再点検することが重要です。
不具合発生時の追加Tips
トラブルシューティングの際に役立つTIPSをいくつかご紹介します。
ReportServer データベースのテーブルを直接確認する
SSRSの設定はReportServerデータベースの様々なテーブルに格納されています。共有スケジュールに関連するテーブルを直接確認することで、スケジュールIDや関連するジョブIDがどのように設定されているかを把握できます。
たとえば、ScheduleテーブルやSubscriptionsテーブルなどを参照し、終了日時（EndDate列など）が正しく設定されているかチェックすると、意外なヒントが得られる場合があります。
クエリ例
以下のようにSSMSから簡易的にクエリを実行してみると、スケジュールの一覧が確認できます。
SELECT
ScheduleID,
LastRunTime,
NextRunTime,
EndDate,
Type,
StartDate
FROM ReportServer.dbo.Schedule
ORDER BY NextRunTime DESC;
ここでEndDateが予期せず設定されていないかを確認できます。
ジョブ所有者の設定確認
SQL Server Agentのジョブを実行するためには所有者のアカウントに実行権限が必要です。SSRSによって自動生成されたジョブは通常、RSReportServerやNT AUTHORITY\NETWORK SERVICEといったアカウントで所有されていることが多いですが、環境によってはカスタムのドメインアカウントを使用しているケースもあります。
所有者アカウントが削除されていたり無効化されていると、ジョブが動作せず、結果的にスケジュールも期限切れ扱いになる可能性があります。
複数インスタンス環境での落とし穴
1台のサーバーに複数のSQL Serverインスタンスをセットアップしている環境では、SSRSインスタンスやAgentサービスの優先度・設定が混在しやすく、どのインスタンスに紐づいているか把握できていないとトラブルシューティングに苦戦することがあります。
インスタンス名を意識して、「目的のReportServerインスタンスのAgentが稼働しているか」を丁寧に確認してください。
トラブルシューティングのまとめ
共有スケジュールが「期限切れ」と表示される場合、その原因は主に以下に集約されます。
- SQL Server Agentが停止・エラーを起こしている
- スケジュールやサブスクリプションに誤った終了日時や不整合が設定されている
- サーバーのシステム日時がずれている
- アップデートや構成変更でSSRSやAgentの設定が変わった
問題を解決するためには、まずSQL Server Agentが正常に動作しているかを確認し、サブスクリプションの終了日時の有無やシステム時刻の正しさを検証します。そのうえで、ジョブ履歴やSSRSログを細かくチェックし、必要に応じてスケジュールを再作成するのが効果的です。
今後の予防策
最後に、同じ問題を繰り返さないための予防策をまとめておきます。
定期的なサーバーのヘルスチェック
WindowsのイベントログやSQL Serverのエラーログを定期的に確認し、AgentやSSRSに関する異常を早期発見できるようにしておきましょう。スクリプトや監視ソフトウェアを導入し、自動アラートを設定しておくこともおすすめです。
バックアップおよびテスト環境での事前検証
SQL Server本体やWindows Serverのアップデートを実施する際は、テスト環境で一通りの動作確認を行い、スケジュールやサブスクリプションが正常に動くかチェックしてください。本番環境に適用する前に問題を洗い出せば、ダウンタイムやトラブルを最小限に抑えられます。
権限管理とアカウントポリシーの見直し
企業のセキュリティポリシーやパスワード有効期限の設定によって、AgentやSSRSの実行アカウントがロックされてしまうことがあります。どのアカウントでジョブが実行されているのかを把握し、必要に応じて独立したサービスアカウントを準備するなどの対処を行いましょう。
メンテナンス期間とスケジュールの調整
システムメンテナンス中にスケジュールが実行されると、予期せぬ失敗が蓄積して期限切れ扱いになる恐れもあります。メンテナンス日はスケジュールを一時的に停止し、終了後に再開するといった運用ルールを決めておくことも大切です。
まとめ
SSRSの共有スケジュールが突然「期限切れ」と表示されてしまう現象は、驚きと不便をもたらしますが、その多くはSQL Server Agentの状態やサブスクリプション設定の些細な不整合、サーバー時刻のズレなどが原因となっています。Agentが停止していないか、サブスクリプションで誤った終了日時が設定されていないかをチェックし、ログを精査することが解決への近道です。さらに再作成やアップデート後の構成確認、権限の見直しなどを総合的に進めることで、スケジュールが「期限切れ」と認識される問題を未然に防ぐことが可能になります。日頃から監視と点検を怠らず、定期的なバックアップとテスト環境での検証を取り入れることで、安心してSSRSを運用できる体制を整えましょう。
コメント