Windows Server 2003のタスクをA-AUTO 50に移行してみる

こんにちは。井下です。

今回は先月ダウンロード提供を開始した「タスクスケジューラ変換ツール」に関して書きます。

何故、「タスクスケジューラ変換ツール」を作成したか？
「タスクスケジューラ変換ツール」を作成した理由を説明する前に、2015年の7月にWindows Server 2003のサポート期限が切れてしまうことは、システムを運用されている方にとっては頭を悩ませている問題ではないでしょうか？

移行にかかる工数は大きいものですし、移行による問題も発生しやすいという課題がありますが、システムの構成や利用方法について見直せる機会でもあると思います。

今回、移行対象とするタスクスケジューラを利用しているリスクとしては、次のようなリスクが挙げられます。

• 時間指定でジョブを実行するため、業務の追い越しが発生する
• 証跡ログが取れない
• ジョブで異常が発生したとき、異常検知が遅れてしまう

ただ、これらのリスクの解消のためにタスクスケジューラからジョブ管理ツールへ乗り換えようとしても、移行にかかる工数が大きく、そのままタスクスケジューラを使い続けてしてしまうのではと考え、可能な限り移行の工数を減らせるよう、「タスクスケジューラ変換ツール」のダウンロード提供を開始しました。


「タスクスケジューラ変換ツール」の使い方
実際にこのツールを使い、Windows Server 2003のタスクをA-AUTO 50に移行してみます。
移行してみるタスクは、以下の2パターンです。

1. 一般的に利用されているシンプルな設定のパターン
2. ストレートコンバージョンできない設定のパターン

1.一般的に利用されているシンプルな設定のパターン
まず、タスクスケジューラでは以下のように登録がされています。
簡単に登録されている内容を説明すると、「毎週金曜日」の「21:00」に「C:\backup_weekly.bat」を実行するタスクです。

このタスクを下記のように「タスクスケジューラ変換ツール」を使用して、A-AUTO 50へ移行できるデータへ変換します。

タスクスケジューラを過剰利用していませんか？ コストを掛けずにリスクを回避する

こんにちは、渡辺です。

今日は、予報どおり暖かい一日となりましたね。日中はコート要らずでした。

今回は、タスクスケジューラの利用用途とリスク、そしてWindows Server 2003のタスクスケジューラからの移行について改めて書きたいと思います。


個人的な見解ではありますが、タスクスケジューラはもともとMicrosoft関連ソフトウェアのバックグラウンド処理を自動処理させることを目的として作られたものだと認識しています。
時刻指定や一定間隔での起動が基本であり、ログインしているか否か、ログインしたときなどのタイミングが用意されています。このタスクスケジューラの仕組みを利用して、Microsoft社以外のソフトウェアでも、定期的に自身のソフトウェア・アップデート・チェックを行うことに利用していたりしますね。
このように、Microsoftがタスクスケジューラを一般向けに提供するにあたっての想定としては、あくまで時刻をトリガーとしたバックアップなど、単純利用を考えているということです。
そして現在では、タスクスケジューラがWindows標準で提供されており、すぐに利用できるという点から、多くの企業で利用されています。

しかしながら、元々の設計思想の範囲を超えた利用が行われているケースも多く見受けら、結果として、次の様なリスクを伴っての利用となっていると考えます。


タスクスケジューラの過剰業務利用におけるリスク

1. 証跡ログが残らない
   Windows Server 2003のタスクスケジューラは、実行ログを記録するファイルサイズが32Kbytesに制限されています。このため、
   すぐに上書きされてしまい過去にさかのぼって実績を確認することが出来ず、業務を実行していることを考えると監査証跡の観点でリスクがあると言えます。
2. タスクの状況を俯瞰して確認出来ない
   登録したタスクで、今日予定されているタスクは何であるか、正しく実行されているのか、異常は発生していないかなどの状況を知りたい場合、個々のコンピュータにログインして確認する必要があります。俯瞰的に全体を見ることが出来ないため、異常発生の検出が遅れるといったリスクを抱えていると言えます。
3. 実行トリガーが時刻に限定されている

『Windows Server 2003のサポート終了』を改善の機会と考える

こんにちは、渡辺です。

Windows Server 2003のサポート終了まであと6カ月余りとなりました。

Windows XPのサポート切れ対応が終わったと思ったら、今度はサーバかぁと、頭を痛めている情報システム部門の方も多いのではないでしょうか？

XPサポート切れの時もそうですが、情報システム部門の方は、アプリケーションのOS・ブラウザへの対応を限られた時間の中で実施しているものと思います。

しかし、今回のWindows Server 2003のサポート切れへの対応が終わったとしても、また5年後には、Windows Server 2008 R2の延長サポート終了がやってきます。

このように、延々とサポート切れの対応に追われてしまい、本来であれば、企業の競争力・価値を向上させるべき部門であるのに、そうなれていない企業が多いのではないでしょうか。

特に情報システム部門の人数が少ない、もしくは小規模なシステムを利用されている企業においては、この傾向が強いのではないでしょうか？

なお、アプリケーションを対応しきれずに、XPや2003を使い続けている企業もいるのが実態ですよね。

では、どうするか。