- ベストアンサー
XCOPYをタスクマネージャで実行できない
- Windows2000 OSのドメイン参加環境からワークグループ環境へのフォルダコピーでXCOPYが実行できない問題について
- バッチファイルでXCOPYコマンドを実行するとコピー先フォルダにはコピーできるが、Windowsタスクで実行すると0個のファイルをコピーする結果になる
- タスク実行アカウントはAdministratorであり、共有フォルダのアクセス権限の問題ではなさそうだが、タスク実行はUNCパスと相性が悪いという情報がある
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
>・なぜドメイン環境では実行できたのか? >・テスト環境では同OSでもタスク実行できた。本番環境で実行できないのはなぜか?(サービス、設定依存か?) おそらく、どのユーザとして実行しているのか、に影響されています。 作成したタスクのプロパティを開き、 [タスク]タブの[パスワードの設定]ボタンを押すと、 どのユーザーとして実行するかを指定できます。 上記問題が発生するのは、このユーザ指定の問題と、 タスク実行時にどのユーザでログオンしているかに依存していると推測します。 ログアウトしている状態も含め、検証が必要でしょう。 UNCパス名と相性が悪い、と言われるのは、このあたりが理由ではないでしょうか。 この問題を解決するひとつの方法ですが、バッチファイル内で、 net use コマンドを使い、予めドライブレターを振ってしまう (ネットワークドライブとしてマウントしてしまう)ことを提案します。 バッチファイルの最後で net use ~ /delete を使えば アンマウントできるので繋ぎっぱなしという事態も防げます。 但し、ユーザー名とパスワードを平文で書いてしまうため セキュリティ面をどうするかが別の問題として浮上します。
その他の回答 (2)
- kani7
- ベストアンサー率47% (110/231)
>cmd.exeつける理由はなぜでしょうか? *.bat ファイルは cmd.exe が実行するべき命令を書いたスクリプト、だからです。 cmd.exe はコマンドプロンプトの実体です。 *.bat ファイルをダブルクリックすると コマンドプロンプトの様なウインドウが開き、 バッチファイルの内容が実行されるかと思いますが、 これは *.bat が cmd.exe に引き渡されているからです。 余談になりますが、質問の例ですと、タスクのコマンドラインに %SystemRoot%\system32\cmd.exe /c XCOPY C:\○○ \\111.111.111.111\FOLDER\FOLDER1 でも同じ結果が得られると思います。 cmd.exe を経由せずに XCOPY 直書きで動いたかは定かでありません。
お礼
わかりました! ありがとうございます。 タスク実行時にそういえばプロンプト画面が開かなかった気がします。 タスクマネージャのサービスで対話許可のチェックが外れてたからかと思ってましたが・・・ 違うんですね
補足
何度もすみません・・・ さらに気になったのですが、 ・なぜドメイン環境では実行できたのか? ・テスト環境では同OSでもタスク実行できた。本番環境で実行できないのはなぜか?(サービス、設定依存か?) 申し訳ありません、よかったら教えてください
- kani7
- ベストアンサー率47% (110/231)
作成したタスクのコマンドラインの頭に %SystemRoot%\system32\cmd.exe /c を付けてみてください。
お礼
試してみます。 ずうずうしいのですが、cmd.exeつける理由はなぜでしょうか? なんとなく、わかる気がするのですが・・・
お礼
cmd.exe /cで実行できました! ありがとうございます。 まったく思いつきませんでした・・・・。 kani7さんの経験の賜物ですね。 よい書籍あればまた紹介ください