SYSTEM タスクはどの電話帳で VPN プロファイルを探すのか

VPN プロファイルは設定にそのままありますが、スケジュールされたタスクは接続が見つからないと報告し続けます。何も壊れていません：ネイティブの Windows VPN ストアは、プロファイルが全ユーザー用として作成されていない限りユーザーごとであり、タスクはその principal が指定するアカウントとして実行されます。通常、タスクはあなたのプロファイルを一度も含んだことのない電話帳を読んでいます。二つのコマンドと一つのタスク設定でそれを証明でき、誰かが接続を再構築する前に実行する価値があります。

二つのストアが同じプロファイル名を保持する

ネイティブの Windows VPN プロファイルは、それを作成したアカウントのストアに存在します。 グローバル ストアは別の電話帳であり、プロファイルが昇格したセッションで全ユーザー用スイッチを付けて作成されたときにだけ埋まります。どちらも同じ名前のプロファイルを保持でき、どちらも他方のビューではありません。

同じセッションから両方のストアを読み、返される名前を比較します。スイッチはグローバル ストアを選び、それを読むには通常、昇格したセッションが必要です：

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

最初のコマンドがプロファイルを一覧し、二番目が一覧しない場合、問題は認証ではなくメンバーシップであるため、別のアカウントで実行されるタスクには資格情報の変更は役立ちません。両方が一覧する場合、ストアは原因ではなく、次のセクションが当てはまります。その一度の比較で、こうしたチケットの半分が片付きます。両方の事実がなければ答えは意味を持たないため、どちらのストアが応答したか、どのアカウントで確認を実行したかを記録してください。

資格情報より先にタスクの principal を読む

タスクを開いて principal を読むと、タスクがどのストアを見られるかが分かります。SYSTEM として実行するように設定されたタスクは、追加の権限を持つあなたのアカウントではなく、独自のプロファイルを持ち、サインイン中に作成したユーザーごとの電話帳にアクセスできません。サービス アカウントもまったく同じように動作します。

サインインしているかどうかに関係なく実行するオプションも、タスクには資格情報を借りられる対話型セッションがなくなるため、これを変えます。アクションに whoami をファイルへ書き込ませ、推測するのではなく答えを読んでください。

自分のターミナルからの診断は、あなたのアカウントが見えるものを示すだけなので、この問題について何も語りません。タスクの ID の下で、そのために用意された承認済みの手順を使って比較を実行してください。管理者コンソールから貼り付けた出力は別のデータセットであり、より特権的なものではありません。そのような手順がなければ、タスク自身が答えを記録する必要があり、最後のセクションがそれを設定します。

プロファイルを見つけることはサインインではない

全ユーザー用プロファイルは構成をより広く見えるようにします。作成したアカウントの保存済みパスワードを運ぶことはなく、あなたのユーザー プロファイルに保存された秘密キーを別のアカウントに渡すこともありません。可視性と使用可能な資格情報は二つの別のテストであり、一つ目を通過しても二つ目については何も言えません。

タスクがプロファイルを見つけて認証で失敗するなら、それは前進であり、その段階は記録に属します。接続名を再び作り直すのではなく、証明書をマシン ストアへ移動するか、展開独自の仕組みで秘密を渡してください。作り直しても、同じ失敗がより新しいタイムスタンプで発生するだけです。 Microsoft は二つのスコープを文書化しており、cmdlet のスイッチはその間で選択します。

非対話型のチャレンジがその段階の背後にある罠です。PIN のプロンプトやワンタイム コードにはデスクトップのないタスクは答えられないため、手動では完璧にダイヤルするプロファイルが自動化の下では使えないことがあります。

タスク記録に必要な四つのフィールド

結果を決める値を、そのうち三つが通常は暗黙のままにされるため、一か所にまとめてください。記録には四行が必要です：

• アクション パス：タスクが実行するスクリプトまたは実行可能ファイルであり、別のアカウントでは異なる解決になるショートカットではありません。
• プロファイル名：正確な文字列であり、二つのストアが異なるサーバーを指す同じ名前を保持できるからです。
• principal：タスクが実行されるアカウント、および対話型セッションがあるかどうか。
• 認証方法：その principal が実際に完了できるもの、たとえばユーザー プロファイル内のキーではなく、マシン ストアの証明書です。

これら四行は、チケットが本当に尋ねている問い、つまり自動化がどの構成を使ったかに答えます。また、元の作者が名前の重要性を説明するために居ない、次回のタスク再構築にも耐えます。それらがなければ、同じ失敗が次の展開の後に戻り、再び同じ時間を費やします。

タスクが到達した段階を特定する

最後の実行結果から推測するのではなく、短いラッパーでアクションを計測し、ID、見えるストア、ダイヤルの結果を一か所に記録します。

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

ダイヤル コマンドは独自のエラーを出力し、通常は一般的なタスク失敗より明確です。クエリは principal と最後の結果コードを並べて返すため、ID と結果が一つのビューで見えます。この二つの事実が、次のステップがストアの変更か資格情報の変更かを決めます。

最後に、ユーザーのサインイン後に接続するタスクを、デバイス トンネルやサポートされているサインイン前のワークフローから切り分けてください。一つのプロファイルを共有することはどちらの設計でもなく、principal フィールドが三つのうちどれを構築したかを示します。ログイン前に接続が必要なら、ユーザーごとのプロファイル ストアは直すべき層ではありません。