Windows の .pbk ファイルが何に属するか（そして何に属さないか）
.pbk ファイルは 一つのプロファイルまたは RRAS サーバーが所有する電話帳であり、移植可能な VPN スキーマではありません。所有者、セクション、公開されるプロパティを読み取ってください。
検索結果は .pbk ファイルを渡してくる。キー名は見覚えがあり、明白な一手はそれを任意の Windows VPN 向けの移植可能なスキーマとして扱うことだ。そうではない。形式は所有者に属し、同じキーでもどの所有者が書いたかによって意味が変わる。まずスコープを読むことが、文書化の演習をサポート外の編集に変えないための条件である。
四つの所有者、四種類の読み手
四者の異なる所有者が似たファイルを書く。ユーザーごとのネイティブ接続は現在のユーザーの電話帳に入り、すべてのユーザー向けの接続はホスト上のどのアカウントも読めるマシン全体のストアに入る。RRAS サーバーは自身のルーティング役割のためにデマンドダイヤル構成を保持し、サードパーティのクライアントは拡張子だけを共有する独自形式を保持することがある。同じ拡張子、四つの読み手、四組の規則。
表示名が一致していても、その二つのエントリが同じエントリになるわけではなく、両者の間でキーをコピーすることは、管理側が文書化したことのない何かを尊重するという前提に立っている。所有者は誰がファイルを変更できるかも決める。ユーザーごとのプロファイルはユーザーの選択であり、マシン全体のプロファイルは管理者の決定であり、サーバーのデマンドダイヤルエントリは独自の変更管理の下にあるルーティング構成である。したがって所有権の誤りは、形式の問題になる前に権限の問題になる。
所有者はファイルそのものではなく、接続を管理するコンポーネントを見て判断する。ファイルは成果物であり、どのキーをいつ読むかを決めるのは管理コンポーネントである。成果物を先に、管理者を後に読むことが、何も参照しないフィールドを編集してしまう経路である。
公開された形式があなたのファイルを説明しなくなる場所
RRAS 管理プロトコルでは電話帳は管理クライアントが書き、ルーティングサービスが読む平文である。だからこそ MS-RRASM 仕様 はデスクトップのプロファイルではなくサーバー向けのデマンドダイヤル設定を説明している。フラットな読み方が壊すのは構造の部分である。一つのエントリは複数のメディアブロックを持て、各ブロックはデバイスブロックを持ち、それが個々の番号のブロックを持つ。したがって同じキーが複数の場所で異なる意味で現れうる。
キーはそのセクションとバージョンに関する注記とともに読み、デスクトップのインターフェースにある同名のチェックボックスから値を訳してはならない。文書に見慣れたキーがあるからといって、無関係なネイティブプロファイルのすべてのフィールドを網羅していることにはならない。セクションの規則も、デスクトップの電話帳をサーバー形式で書き直す許可ではない。
| Owner | What reads the file | What a key means there |
|---|---|---|
| Per-user native connection | The user's own connection manager | A property of that user profile |
| All-user native connection | The machine-wide connection store | A property shared by everyone on the host |
| RRAS demand-dial | The RRAS service, using the documented hierarchy | A field inside a media, device or number section |
| Third-party client | That vendor's own parser | Whatever that vendor documents, if anything |
表は仕様ではなく読み方の助けであり、どの読み手に問い合わせるかを示し、読み手がフィールドの意味を示す。その読み手がサードパーティのパーサーである場合、そのフィールドを公に文書化したものは何もない、というのが正直な答えになりうる。
ファイルではなく Windows に聞く
ネイティブ接続ではファイルを読むのではなく Windows にプロファイルを尋ねる。型付きのプロパティが文書化された表面であり、サポートされた変更が修正する唯一のものである。下の二つのコマンドは 二つのネイティブストア を別々に読む。プロファイルがどちらのストアにもない場合、それを管理するクライアントはネイティブの仕組みを使っておらず、どのネイティブ cmdlet もそれを説明しない。
Get-VpnConnection -Name 'Field Ops'
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType検査ではなく展開のための文書化された経路は、名前付きスキーマを持つ管理されたプロファイル設定であり、テキストやバイナリのブロブ内部の数値編集ではない。プロファイル定義はサポートされる設定を説明するが、プロファイルが依存する証明書と秘密鍵を用意するものではない。登録は独自の権限を持つ別のプロセスであり、電話帳のキーを理解しても秘密鍵が配布されたことはない。二つの経路を分けて計画しなければ、最初の証明書展開が 二番目のインシデントになる。
一つのプロパティ、そしてその周りのライフサイクル
保存された値は適用された値ではない。承認された変更の後、新しい接続を開き、プロファイルが導入するルート、継承するリゾルバーポリシー、そして有効にするはずだった操作を確認する。すでに上がっていたセッションを再利用すると古い設定を試すことになり、偽の陰性を生む。
生のファイルを扱う前にファイルを脇にコピーする。複数のエントリを持つ電話帳は共有された成果物であり、ファイル全体を書き換える的を絞った編集は変更そのものより大きな影響範囲を持つ。無関係なエントリはそのままにし、新しいものが検証されるまで元の保護された構成を保持する。必須のフィールドが、実際に手元にある所有者とリリースについて文書化されていない場合は、未解決のサポート課題として記録する。別のマシンのファイルからエンコーディングをでっち上げることは、動作するプロファイルを参照点のないデバッグ案件に変える道である。
規律はどの段階でも同じである。所有者を名指しし、セクションを名指しし、そしてサポートされた操作を名指しする。それ以外は引用を貼り付けただけの推測である。