Windowsのスケジュールされたタスクに「開始」が必要なのはなぜですか？
WindowsまたはLinuxにデプロイできるWebアプリケーションを開発しています。 Linuxの実装ではcronを使用し、Windowsの実装ではスケジュールされたタスクを使用して、システムのすべてのスケジュールされたタスクを処理する単一のPHPスクリプトを実行します。
タスクは、次のように、インストールプロセス中にschtasksを使用してスケジュールされます。
これは常にW2003とW2008の両方で機能してきました。 1週間前に、スケジュールされたタスクが実行されていないと顧客から報告されました。彼はWindows 2008で実行されています。スケジュールされたタスクの "start in"フォルダーとして.vbsスクリプトを含むフォルダーを入力することにより、何度も何度もチェックして問題を解決しました。
つまり、タスクのXML定義を使用せずにschtasksから「開始」の値を設定する方法はありません。 XML定義はWindows 2003では機能しないため、Windowsのバージョン検出をインストーラーに追加したり、追加のテストを行ったりする必要があります（可能な限りこれを回避したいと思います）。
インストールに関して私が気付いた唯一の異例なことは、システムがデフォルトのC:\Program Files (x86)\ではなくD:\にインストールされていることですが、これがどのように重要であるかはわかりません。すべてのパスは、すべてのスクリプトで絶対パスです。
誰もがこれに対する合理的な解決策を提案できますか？
「開始」は主に、実行するタスクに相対パスがある場合に、スクリプトを実行するディレクトリを認識できるようにすることです。
そうは言っても、このリンクはあなたを助けるかもしれません： https://stackoverflow.com/questions/1020023/specifying-start-in-directory-in-schtasks-command-in-windows
正確には何の解決策ですか？
start inの値は、アプリケーション/プログラム/スクリプトが開始するディレクトリとまったく同じです。これは、他のリソースを呼び出すときに重要です。そのsomecustom.exeディレクトリにないstart inを呼び出すと、ディレクトリは見つかりません。アプリケーション/プログラム/スクリプトはエラーになります。絶対にすべてをパスで呼び出す場合は問題ではありませんが、記述している動作は実際にはそれを実行していないことを示しているように見えるため、その動作を修正するか、簡単な回避策（醜い種類の場合）実際にコードを正しく取得するためのくだらない解決策は、ディレクトリを%PATH%変数に追加することです。そのため、参照パスなしで実行可能ファイルが呼び出されると、Windowsは常にディレクトリをチェックします。
Windows 2008/7/Vistaで作業している場合、 スイッチを使用してstart inディレクトリをschtasks /v1で設定 することもできます。 SYSTEMアカウントでタスクを実行します。開発者に自分のコードをデバッグしてもらいたいと思いますが、YMMVです。