ノート PC はオフィスでは約四十秒でサインインし、自宅では数分かかりますが、その間にポリシーを変更した人はいません。変わったのは、似て見えて動作の異なる三つの機能の下にあるネットワーク経路です。ローミング プロファイルはレジストリの状態とプロファイル フォルダーを読み込み、フォルダー リダイレクトはシェル フォルダーをサーバー共有に向け、オフライン ファイルは対象となるネットワーク データのキャッシュを保持します。三つともサインインに時間を追加できますが、通常はそのうち一つだけが原因です。

三つの待ち時間と三つの異なる原因

ローミング プロファイルは、参加しているコンピューター間でユーザー設定をその人に追従させるもので、読み込みはセッションの早い段階で行われます。サインイン時にユーザーのレジストリ ハイブとプロファイル フォルダーがコピーまたはマージされ、サインアウト時に書き戻されます。この処理は同期実行なので、プロファイル共有への遅い経路は、遅いファイル コピーではなく、遅いデスクトップとして感じられます。

フォルダー リダイレクトは別の仕組みです。選択したシェル フォルダー(一般的な例はドキュメント)を、サポートされたネットワークの場所に移動してそこに置いたままにします。データがその中にないためプロファイルは小さいままでいられ、コストは、シェルやアプリケーションがそのフォルダーに触れるたびに発生します。

オフライン ファイルは対象となるネットワーク ファイルにローカル キャッシュと同期を追加します。これは別の問いに答え(サーバーに到達できないときに何が起きるか)、キャッシュが古いとサインインとサインアウトのたびに同期で時間を使うことがあります。三つを一つの設定として扱うことが、一方向では遅く、もう一方向では役に立たないポリシーを生み出します。

実際に待っているものを測定する

まずプロファイルがどこにあり、サーバー パスから読み込まれるかを確認します。次に、セッションが触れる各共有でディレクトリ一覧の時間を測ります(ローカル ネットワークではミリ秒で応答する共有でも、トンネルと混雑したファイル サーバーを経由すると数秒かかることがあるためです)。

この二つの事実は、どんなポリシー監査よりも速く問題を絞り込み、収集に構成の変更も要りません。影響を受けているノート PC で実行し、共有の隣にあるサーバーでは実行しないでください。

Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }

プロファイルのパスがローカルで、リダイレクトされたフォルダーが一つだけサーバーを指しているなら、ヘルプデスクのチケットが何と言おうと、プロファイルの読み込みは待ち時間ではありません。プロファイルのパスがリモートで、一覧に数秒かかるなら、サインインはその共有を待っており、修正はデスクトップそのものではなく経路かプロファイルのサイズに関するものです。この順に数値を見れば、議論はたいていそこで終わります。

接続は待ち時間が始まった後に届く

デスクトップから始まるユーザー トンネルは、プロファイルが読み込まれたずっと後に現れるため、遅かった段階を助けることはできません。Windows は利用できない経路を検知し、キャッシュされた資格情報とローカル プロファイルにフォールバックし、セッションは最終的に開きます。そのため、キャッシュされたプロファイルがあれば、同じノート PC でも自宅での最初のサインインは数分、二回目は数秒ですむことがあります。待ち時間は現実ですが、そこで必要な接続はその時点で存在しません。

修正するには、プロファイルを調整するのではなく、接続を早めに移す必要があります。コンピューター認証を使うマシン トンネルまたはサインイン前接続は、ユーザーがサインインする前に経路を確立しますが、独自の証明書ライフサイクルと独自のファイアウォール規則が必要です。キャッシュされた資格情報は設計の残りの半分で、以前にサインインしたことのあるアカウントにしか機能しません。

コンポーネントではなく順序を試します。完全にサインアウトし、リモート ユーザーがするようにトンネルを開始し、資格情報の入力要求から使用可能なデスクトップまでのサインイン時間を測ります。

ドキュメントをプロファイルの外に置く

プロファイル共有は大きなドキュメント コレクションには不適切な場所であり、Microsoft のローミング プロファイルの展開ガイドがプロファイル ストレージとリダイレクト フォルダーの共有を分けているのは、まさにそのためです。数ギガバイトのドキュメント フォルダーを抱えるプロファイルは、サインインとサインアウトのたびに遅くなり、誰かが測るまでサイズは静かに増え続けます。

データを保持するフォルダーをリダイレクトし、プロファイルには設定を残します。再構築できるキャッシュ(ブラウザーのキャッシュやアプリケーションの一時データなど)は、転送しても時間が増えるだけでユーザーに見えるものは何も変わらないため除外してください。メールボックス データやその他のアプリケーション ストアは、アプリケーションがサポートする場所に置き、ローミング パスには置かないでください。

プロファイル共有をオフラインで使用可能にしないでください。オフライン ファイルは対象となるデータ共有に属するものであり、双方向に同期するキャッシュされたプロファイル ハイブは、起こるのを待つ破損レポートです。

修正済みと言う前に四つのシナリオをすべて確認する

オフィスで速いサインインはほとんど何も証明しません。設計は、オフィスからのアクセス、トンネル経由の自宅作業、接続なしの作業、オフィスへの復帰に耐える必要があります(同期の競合が現れるのは四番目のケースだからです)。同じ四つを一つの制御されたアカウントと実際のアプリケーションで測り、数値を書き留めてください。

プロファイル サービスのログと、影響を受けたセッションから得られるポリシー セットを、管理用ワークステーションからではなく収集します。

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }

その時間をオフィスの基準値と、転送されているもののサイズと比較します。小さなプロファイルと速い共有でもサインインにまだ一分かかるなら、それはプロファイルの問題ではなく、次に見るべきはグループ ポリシーの処理か、ネットワークを待つログオン スクリプトです。そこに差があるなら、プロファイルはそもそも問題ではありませんでした。フォルダー ポリシーを変更したりキャッシュを消去したりする前に、同期と復元可能なバックアップは別の保証であることを踏まえて、同期されていない作業が保存されていることを確認してください。

関連記事