ドライブをマップしたり同期ジョブを開始したりするログオンスクリプトは、トンネルがアドレスを取得する前に実行されるため、静かに失敗し、ユーザーが毎朝手作業で修復することになる。WindowsはほとんどのクライアントにVPNごとの接続コールバックを提供しないが、ネットワークの変更は記録しており、その記録を使って適切な瞬間に処理を開始できる。選択肢は、その記録に反応するか、リソースをポーリングするか、失敗を目立たせていたプロンプトを削除するかである。

三つの仕組みを保証内容で比較する方が、洗練度で順位づけするより優れている。それぞれ失敗の仕方が違い、その失敗の仕方こそが後々付き合うものになる。

ログオンが早すぎる理由

ログオンとスタートアップはVPNアダプターがアドレスを受け取る前に実行されるため、その時点で試みたドライブマッピング、内部URL、データベース接続にはルートもリゾルバーもない。要求は失敗し、セッションはユーザーが手作業で直さなければならない状態に残る。同じスクリプトをスタートアップフォルダーへ移しても、順序の問題が一緒に移動するため何も変わらない。トリガーはセッションイベントではなく、ネットワークの変更でなければならない。

ログオン時に任意の遅延を付けたスケジュールタスクは修正に見えるが、実際は当て推量である。速い回線では機能し、遅い回線では失敗する。これは信頼性として最も役に立たない種類だ。

三つのフックの比較

仕組みは、何を監視するか、どれだけ速く反応するか、その日の後半の再接続にどう対処するかで異なる。表はそれら三点で比較しており、どれが賢く聞こえるかでは比較していない。

MechanismReacts toCovers a mid-session reconnectTypical failure
Network profile eventA network connect recordYes, when the event repeatsRuns on the wrong network
Resource poll with backoffThe resource becoming reachableYesLog noise and a wasted window
Stored credentials aloneNothing; it removes a promptNoStill fires before the tunnel

表は行ごとに読む。イベントフックは最速で最も騒がしい。WindowsはカフェのWi-Fiを含むすべてのネットワークを記録するため、アクションは何かをする前にリソースを検証する必要がある。ポーリングはより遅くより正確で、共有またはホスト名が応答したまさにそのときに成功し、どのクライアントがインストールされているかを知る必要がない。保存された資格情報はそもそも競合する選択肢ではない。パスワードのプロンプトを削除するものであり、ログオン時のマッピングが失敗する二つ目の独立した理由である。

最初の二つのどちらを選ぶかは、クライアントに使えるイベントがあるかどうかで決まる。ある場合は、イベントとリソースチェックの組み合わせがより良い既定値だ。

イベントトリガーを正しく構築する

記録はMicrosoft-Windows-NetworkProfile/Operationalログにあり、ID 10001は接続したばかりのネットワークを示す。そのログ、そのプロバイダー名、その識別子を対象とするイベント時トリガーでタスクを作成する。マシンが参加するすべてのネットワークで発火するため、アクションには想定ではなくガード条件が必要であり、作業がマップ済みドライブに触れる場合はユーザーがログオンしている間だけ実行すべきだ。

ガード条件は、共有パスやサービスポートなど、タスクが実際に必要とするものをテストし、到達できないときは静かに終了するべきだ。アダプター名のテストでは不十分である。クライアントは一つのアダプターを複数のプロファイルで再利用できるからだ。静かな終了はログを読みやすく保ち、リソースを決して提供しないネットワークに対する再試行の嵐を防ぐ。

タスクが適切な瞬間に実行されることをテストする

設定ではなくタイミングを証明する。以下のコマンドは、タスク定義、最近のネットワークプロファイルイベント、タスクが実行されるアカウントからリソースに到達できるかを示す。手動起動の後ではなく、実際の再接続の後に実行する。

schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami

ネットワークイベントが一致しないのにタスク履歴のエントリが存在する場合、アクションではなくトリガーが間違っている。イベントが現れてもタスクが実行されない場合、そのタスクはリソースが見えないアカウントで実行されている可能性があり、アカウントの出力が手がかりになる。マッピングがまだ欠けているのにリソースチェックが通る場合は、接続性ではなくセッションコンテキストを指す。これら三つの観察はそれぞれ別の修正へ導く。

実行ごとに、アドレス、リソースの結果、最終結果を含むログ行を一行書く。そうすれば次の失敗で、タスクが早く実行されたのか、間違ったネットワークで実行されたのか、まったく実行されなかったのかが分かる。

関連記事