タスクにGUIがある場合、Windows 2003でスケジュールされたタスクの実行に問題はありますか? Windows 2000では問題なく動作したものの、Windows 2003では動作しません。
詳細:
古いWindows 2000サーバー上で、長年にわたって1日1時間ごとに実行される.batジョブがあります。先週、ようやくそのサーバーを廃止し、ジョブ(および関連するプログラムとファイル)をWindows 2003サーバーに移動しました。
.batファイルは最初にいくつかのcmd行アプリを呼び出しますが、最後のステップはGUIベースの.NETアプリです(画像ファイルに対していくつかのOCRを実行してからシャットダウンします)。
新しいサーバーから、スケジュールされたタスクの所有者としてログオンしました。コマンドラインから.batファイルを正常に実行できます。
新しいサーバーから、再びスケジュールされたタスクの所有者としてログオンし、スケジューラでタスクを右クリックして、正常に実行できます。このタスクは、同じ.batファイルを実行するだけです。
スケジュールされたタスクの所有者が2003サーバーにログオンしていて、タスクがリモートサーバー(ユーザーがスケジュールされたタスクを開始し、このサーバーに接続している場所)から開始された場合も、正常に実行されます。
スケジュールされたタスクの所有者がnotがこのサーバーにログオンしている場合、スケジュールされたタスクは、GUIアプリが起動されるステップで失敗します。エラーメッセージは表示されません。そのユーザーアカウントを監視している別のセッション/ユーザーアカウントからProcMonを実行しても、何も表示されませんでした。
当面の恐ろしい回避策は、スケジュールされたタスクの所有者が画面をロックした状態でコンソールにログオンしたままにすることです。もちろん、サーバーを再起動するたびにこれは面倒になります...
スケジュールされたタスクの所有者は、「ドメインサービスアカウント」であり、他のすべてのサーバーで他のすべてのタスクを処理しています。ロックアウトされているわけではありません。
タスクスケジューラを変更して[サービスにデスクトップボックスとの対話を許可する]をチェックすることもできましたが、何も変更されませんでした。 (はい、変更後にサービスを再開しました。)
考え?
更新済み(1/19/2010)
私は少し明確にする必要があります:私が言及した.NETアプリは機能する多くのものを実行します。アプリがハングするのは、ウィンドウを開く必要があるポイントに到達するまでではありません。アプリが残したログエントリを介してアプリの進行状況を確認できるため、最後のログエントリが「OCRを開始しようとしている」という状態でアプリが正常に動作していることがわかります。
デバッグ用のプログラムのソースコードにアクセスできますか?タスクの所有者がマシンにログインしない限り、プログラムで使用できるWindowsデスクトップがないため、Windowsの作成に失敗しているようです。この記事 http://msdn.Microsoft.com/en-us/library/ms687105%28VS.85%29.aspx ウィンドウステーションとデスクトップの作成プロセスについて説明します。
タスクは特定のディレクトリで開始するように設定されていますか?読み取り/書き込み先のディレクトリに権限が正しく設定されています。
タスクの「別のユーザーとして実行」が正しく設定されていることを前提としています(基本を確認する必要があります!:))
アカウントがタスクを実行していることを確認するためにチェックしましたか?「バッチジョブとしてログオンする」権利が付与されています(ローカルセキュリティポリシー\ローカルポリシー\ユーザー権利の割り当て\バッチジョブとしてログオン)
ここでの問題は、実行しているプログラムがGUIを必要とすることです。タスクにはWindows GUIがありません。したがって、GUIなしでプログラムを実行できる場合は、問題ありません。