ネットワークドライブ経由でタスクスケジューラが失敗し、net useでシステムエラー86ã ã£ãŸå ´åˆã®å¯¾å‡¦æ³•

1. はじめに

　ドメインの異なるネットワーク経由を利用したファイル転送をrobocopy等で行う際に、タスクスケジューラを活用して日次で自動同期する場合がある。その際に、コマンドプロンプトを活用しながら、ネットワークドライブでファイルをコピーするのだが、実行ユーザの違いや、ID/パスワードがネックとなりスムーズに実現できないことがある。本記事では、自身の経験に基づいて対処した事例を示す。

 

2. ネットワークドライブを経由したタスクスケジューラの実行失敗

　タスクスケジューラ側で「ユーザがログオンしているかどうかに関わらず実行する」または「最上位の特権で実行する」を指定していると、仮に事前にネットワークドライブを指定していても、その割当がログオンしていたユーザのみにしか分からない状態であり、自動実行するユーザプロファイル側は「ネットワークドライブの割当なんかされていない」と判断し結果的にタスクは失敗する。

　また、ネットワークドライブをそもそも指定しておらず、Windows認証情報に接続先のIPと紐づくID/パスワードを登録していても上記と同様で「IDとパスワードは自動実行する側から見れば分からない」ということになる。

　これらの解説は「タスクスケジューラ ネットワークドライブ」で検索すれば詳細な情報はいくらでも出ており、タスクスケジューラで呼び出すバッチの中に例えば直接、以下を記述することで解決する。

@echo off
net use T: \\192.168.10.135\d$ p@ssword /user:test\administrator
robocopy <コピー元パス> T:<コピー先パス> /MIR

 

　しかし、上記に記載しているnet useコマンドがID/パスワードが合っているのにもかかわらず、システムエラー86により認証に失敗するケースがある。その場合は以下の内容を考慮しトラブルシューティングを行う。

 

3. net useの認証失敗

　net useコマンドを実行した際にシステムエラー86が発生した場合は以下について確認を行う。

　①パスワードに「％」が含まれていないか確認する。

　％はバッチファイル上、%変数%のような扱いができる関係でエスケープしなければならない文字となる。従って、例えば

net use T: \\192.168.10.135\d$ p@ss%word /user:test\administrator

と記載したところで、PC側が認識するのは

net use T: \\192.168.10.135\d$ p@ssword /user:test\administrator

である。パスワードに「％」が含まれる場合は以下のようにエスケープとして「%」を続けて記載するとnet useが成功する。ダブルクォーテーションは必要かどうかは実際に実行して有無を判断いただきたい。

net use T: \\192.168.10.135\d$ "p@ss%%word" /user:test\administrator

 

　②ローカルセキュリティポリシーの変更を試行する

　ローカルセキュリティポリシーにおい、LAN Manager 認証レベルを「NTLM 応答のみを送信する」に変更することで解決する事例がある。

　ローカルセキュリティポリシーの変更に際しては、 「コントロールパネル」→「管理ツール」→「ローカルセキュリティポリシー」→「セキュリティオプション」→「ネットワークセキュリティ：LAN Manager 認証レベル」をプロパティで「未定義」から「NTLM 応答のみを送信する」に変更するに変更する。

 

　なお、一度設定すると画面上から未定義に戻すことができないので、戻す際はファイル名を指定して実行から「regedit」でレジストリを起動し、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa」の「LmCompatibilityLevel」を消去することで未定義に戻すことができる。

 

　③/user:にドメインを指定する

　ネットワーク接続先のドメインが異なる場合はnet useの/user:の後に続いて[ドメイン名]\[ユーザID]を指定する。

net use T: \\192.168.10.135\d$ p@ssword /user:test\administrator

　

　④タスクスケジューラで作業フォルダを指定する

　タスクスケジューラにおいて、操作の編集の中の[開始(オプション)]という項目がある。この項目が空欄の場合は、カレントディレクトリが「C:\Windows\system32」が設定されるため、バッチの記載方法によっては意図していないパスを参照している可能性がある。従って、絶対パスでバッチ内の記載を行うか、バッチ内で「cd %~dp0」を記載するか、タスクスケジューラの[開始(オプション)]内に作業パスを記載するかのいずれかとなる。

 

4. まとめ

　今回はタスクスケジューラを扱う中で、ネットワークを経由したバッチの自動実行に際しnet useを使用時の異常に対するトラブルシューティングの方法について述べた。実際に自身は記事内で紹介したすべてを確認した結果、最終的に該当したのは3-①のパスワードに「％」が入っていたことであった。自身はこのほかに、バッチファイル自動実行前にvbsでネットワークドライブを自動認証するコードまで書いたが、そもそもネットワークドライブがタスクスケジューラ側で割当されていないとみなされ、その施策は空回りに終わった。

　タスクスケジューラ自体、設定項目が複数に跨り癖の強いツールであると認識している。その中で、バッチが悪いのかタスクスケジューラ側での制約であるのかの切り分けが難しく、一発で処理が通る場合が少ない。

　今回のトラブルシューティングが1つでも該当し、原因の解決につながれば幸いである。

［改訂新版］Windowsコマンドプロンプトポケットリファレンス