Microsoft AZ-140: FSLogix、プロファイル、ユーザーデータ — 学習ガイド

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Virtual Desktop Specialty AZ-140 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

FSLogixは、Azure Virtual Desktop向けにコンテナベースのユーザープロファイルを提供し、サインイン時にユーザーのプロファイルをSMB経由で仮想ディスクとしてアタッチします。この設計により、従来の移動プロファイルの落とし穴が解消され、サインインが高速化し、非永続的なセッションホスト間でのアプリの状態が安定します。FSLogixは、プロファイルの状態（Profile Container）をMicrosoft 365のデータやキャッシュ（Office Data File Container）から分離し、Cloud Cacheによって回復性を階層化できます。低レイテンシーのサインインと高いセッション密度を実現するためには、適切なストレージの選択、IDベースのSMBアクセス許可、およびプロファイルサイズのガバナンスが不可欠です。

FSLogixコンテナとデータアーキテクチャ

FSLogix Profile Containersは、ユーザープロファイル全体をSMBストレージ上にある単一の仮想ディスクファイルに保存します。サインイン時、ディスクはC:\Users\usernameにマウントされ、OSはそれをネイティブプロファイルとして認識します。

• ディスク形式：非常に古いOSとの互換性が必要な場合を除き、VHDXを使用してください。VHDXは破損に対する回復性が高く、より大きなサイズをサポートし、メタデータの問題が発生しにくく、FSLogixのデフォルトです。特定のアプリケーションやレガシードライバーが必要とする場合にのみVHDを使用してください。
• サイズ設定：コンテナはデフォルトで動的拡張です。最大サイズ（例：Profileに30 GB、Officeに10 GB）を設定し、動的な増加を許可してください。固定サイズのディスクは、パフォーマンスを向上させることはほとんどなく、ストレージ消費量と管理オーバーヘッドを増加させます。
• ロックと同時実行性：プロファイルコンテナは、最初のセッションホストによって読み取り/書き込みでロックされます。同じユーザーによる別のホストでの2番目の同時セッションは、ポリシーに応じてブロックされるか、読み取り専用で許可されます。これにより、プロファイルの整合性が保護されます。

Office Data File Container (ODFC)は、頻繁に更新されるMicrosoft 365のデータ（OutlookのOST/Datファイル、OneDriveやTeamsのキャッシュ）を独自のコンテナに分離します。利点は次のとおりです。

• OfficeのキャッシュがProfile Containerを肥大化させなくなるため、サインインが高速化します。
• ユーザープロファイルに触れることなく、Officeキャッシュを独立してクリーンアップまたは再ベースライン化できます。
• Officeキャッシュの破損がプロファイルに影響を与えるリスクが軽減されます。

redirections.xmlを使用して、揮発性のフォルダーをProfile Containerから除外し、サイズの増加を抑制してサインインを高速化します。一般的な除外対象には、Teamsのキャッシュ、ブラウザーのキャッシュ、Temp、およびログが含まれます。ODFCを使用する場合は、重複を避けるためにOffice固有のキャッシュをProfile Containerから除外してください。

redirections.xmlの例（frxtray.exeの横に配置するか、レジストリで定義します）：

<?xml version="1.0" encoding="UTF-8"?>
<FrxProfileFolderRedirection ExcludeCommonFolders="0">
  <Exclude>
    <Path>%LOCALAPPDATA%\Microsoft\Teams\Cache</Path>
    <Path>%LOCALAPPDATA%\Microsoft\Teams\Service Worker</Path>
    <Path>%LOCALAPPDATA%\Temp</Path>
    <Path>%LOCALAPPDATA%\Packages\Microsoft.MicrosoftEdge_*\AC\#!001\Cache</Path>
    <Path>%APPDATA%\Microsoft\Teams\media-stack</Path>
  </Exclude>
</FrxProfileFolderRedirection>

ストレージプラットフォームとアクセス制御

FSLogix用のSMBストレージの選択は、パフォーマンスと運用の観点からの決定事項です。

• Azure NetApp Files (ANF)：最高のIOPSと最小のレイテンシー。非常に大規模でレイテンシーに敏感なデプロイメント（例：数万人のユーザー）に最適です。予測可能なマイクロ秒から低いミリ秒のレイテンシーを持つSMBボリューム、容量プールに連動したボリュームごとのスループット、スナップショット、およびクロスリージョンレプリケーションを提供します。デスクトップエクスペリエンスを最大化し、極端な同時実行性を処理する必要がある場合に使用します。
• Azure Files Premium (FileStorage)：SSDベースで、多くのリージョンでゾーン冗長に対応し、管理が最小限で、幅広いエンタープライズ用途でコスト効率が高いです。共有のパフォーマンスはプロビジョニングされたサイズに応じてスケールし、容量が増加するにつれて共有あたり最大100,000 IOPSおよび数GB/sのスループットを提供します。ANFの管理なしでSSDのパフォーマンスが必要な場合、ほとんどのホストプールに推奨されます。
• Azure Files Standard：HDDベース。小規模なラボや軽度の使用に適しています。レイテンシーが高く、パフォーマンスが変動するため、本番環境のFSLogixプロファイルには推奨されません。

UNCパスとDNS：

• Azure Filesは、\storageaccount.file.core.windows.net\sharenameというパス形式を使用します。セッションホストがこのエンドポイントを解決し、到達できることを確認してください。トラフィックを内部に留めるために、プライベートエンドポイントが推奨されます。
• ANFは、委任されたサブネットを介してプライベートIP経由で、\anf-vol-name\shareのようなSMBボリュームパスを使用します。

IDベースのSMB認証とアクセス許可は、ディレクトリサービスとセッションホストの参加状態に依存します。

• Active Directory Domain Services (AD DS) または Azure AD DS：セッションホストはドメインに参加済みです。Kerberosを使用します。ADグループを使用して、共有アクセス許可とNTFS ACLを構成します。
• Microsoft Entra ID Kerberos for Azure Files：AD DSなしで、Entra IDに参加したセッションホストからのSMBアクセスを可能にします。ストレージアカウントでAzure RBACを割り当て、クライアントOSとFSLogixのバージョンがこのモードをサポートしていることを確認します。

一般的なシナリオにおけるAzure Filesの最小権限：

• Entra ID認証を使用する場合、ユーザーグループに対して、ストレージアカウントまたは共有スコープでStorage File Data SMB Share Contributor（Azure RBAC）を付与します。
• 共有ルートでNTFSを構成します：ユーザー（または専用のAVDユーザーグループ）にModify、サブフォルダーにCreator OwnerにFull、AdministratorsにFullを許可し、過剰なアクセスを許可する継承されたアクセス許可を削除します。
• AD DSで認証されたAzure Filesの場合、共有レベルのACLも設定して、ユーザーにModifyを許可します。

回復性、Cloud Cache、および運用の健全性

Cloud Cacheは、セッションホスト上のローカルキャッシュに書き込み、1つ以上のリモートSMBリポジトリにレプリケートします。利点には、一時的なストレージ障害発生時の継続的な運用や、リージョン間の回復性が含まれます。設計上の考慮事項：

• 回復性とログオン遅延のバランスを取るために、2〜4か所のCCDロケーションを使用します。ロケーションが多いほど、障害発生時のアタッチタイムアウトが増加します。
• ローカルキャッシュに十分なディスク領域を確保します（通常、最悪のシナリオではホスト上の同時アクティブユーザーあたり20〜40 GB）。
• ターゲットを混在させます（例：リージョン内のプライマリAzure Files Premiumと、ペアリージョン内のセカンダリAzure FilesまたはANF）。絶対に必要な場合を除き、Cloud Cacheに低速なHDDベースのターゲットを使用しないでください。

プロファイルコンテナーにCloud CacheとODFCを設定する場合の構成例（レジストリ）：

reg add HKLM\SOFTWARE\FSLogix\Profiles /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v VolumeType /t REG_SZ /d VHDX /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v SizeInMBs /t REG_DWORD /d 30720 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v IsDynamic /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v CCDLocations /t REG_MULTI_SZ /d "\\store1.file.core.windows.net\profiles\0!\\store2.file.core.windows.net\profiles\0" /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\ODFC /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\ODFC /v VolumeType /t REG_SZ /d VHDX /f
reg add HKLM\SOFTWARE\FSLogix\ODFC /v SizeInMBs /t REG_DWORD /d 10240 /f

サインインの失敗とプロファイルのロックの診断：

• イベントビューアー：[アプリケーションとサービス ログ] > [FSLogix] > [Apps] で、アタッチ、IO、Cloud Cacheの診断情報が提供されます。アクセス拒否（0x5）、共有違反（0x20）、またはタイムアウトを探します。
• 古いロック：クラッシュしたセッションホストがハンドルを開いたままにすると、VHDXが使用中として表示されることがあります。アクティブなセッションがないことを確認し、SMBサーバー側から開いているファイルを閉じて、FSLogixに再試行させます。アクティブなマウントがまったくないことを完全に確認しない限り、ロックファイルの手動削除は避けてください。
• フォールバック動作：アタッチに失敗した場合にユーザーが一時的なローカルプロファイルでサインインできるかどうかを制御するには、PreventLoginWithFailureを使用します。ストレージの性能が低下していてもアクセスを許可したい場合は、読み取り専用でのTryを検討してください。その場合、変更は永続化されないことを理解しておく必要があります。

クリーンアップとメンテナンス：

• DeleteLocalProfileWhenVHDShouldApplyを有効にして、古いローカルプロファイルを削除します。
• 一時データによってサイズが増大したVHDXファイルは、定期的にオフラインで圧縮します。
• Cloud Cacheを使用している場合、ホストが使用停止になった際には、放棄されたローカルキャッシュのクリーンアップをスケジュールします。

パフォーマンス、スケール、セッション密度

ストレージのIOPSとレイテンシーは、サインイン時間、アプリの応答性、各ホストが処理できる同時セッション数を直接決定します。

• レイテンシー目標：ログオンストーム時のストレージレイテンシーを2ミリ秒未満から1桁ミリ秒にすることで、最高のエクスペリエンスが得られます。ANFは一般的に最も低いレイテンシーを達成します。Azure Files Premiumは、プライベートエンドポイント経由でアクセスした場合、通常1桁ミリ秒前半の低いレイテンシーです。
• IOPSの特性：FSLogixは、サインイン中に顕著なバーストIOPS（ユーザーあたり数十から数百）を示し、定常状態では控えめなIOPS（ワークロードに応じて通常ユーザーあたり3〜15）となります。同時ログオン数を掛けてストレージサイズを決定します。
• Azure Files Premiumのスケーリング：プロビジョニングされた共有サイズを増やして、IOPSとスループットの上限を引き上げます。サポートされているOSでSMB Multichannelを有効にして、ホストごとのスループットを向上させます。
• ANFの容量と階層化：プロビジョニングされたTiBあたりのMiB/sに基づいてANFのパフォーマンス階層を選択します。PremiumおよびUltra階層は、OfficeやCADのヘビーユーザーに一般的です。非常に大規模なデプロイメントでは、複数のボリュームを使用してI/Oを並列化します。

ネットワークパスは重要です。プライベートエンドポイントを使用し、セッションホストがストレージと同じリージョンにあることを確認して、WANの遅延を回避します。ホストとストレージは、同じ仮想ネットワーク内、または低レイテンシーのパスを持つピアリングされたネットワーク内に配置します。

Microsoft 365データとプロファイルサイズの増大管理

ODFC、OneDriveのファイルオンデマンド、および既知のフォルダーの移動（KFM）を組み合わせて、サイズの増大を制御します。

• ODFC：OutlookのOST、OneNoteのキャッシュ、Office Wefデータを別のコンテナーでローミングします。これにより、プロファイルコンテナー内の変動が減り、ログオンが高速化されます。
• OneDriveのper-machineインストールとファイルオンデマンド：OneDriveをProgram Filesにインストールして、すべてのユーザーがバイナリを共有するようにします。ファイルオンデマンドはプロファイル内にプレースホルダーを保持し、アクセス時にコンテンツをハイドレートすることで、コンテナーサイズの増大を抑制します。
• KFM：デスクトップ、ドキュメント、ピクチャをOneDriveにリダイレクトし、どのデバイスでも同じユーザーエクスペリエンスを提供します。ファイルオンデマンドを使用すると、アクセスされたファイルのみがローカルにハイドレートされるため、サイズの増大がさらに抑制されます。
• 除外設定：コンテナーサイズを積極的に最小化する場合、redirections.xmlを介してOneDriveの同期キャッシュを除外できます。これにより、サインインごとにオンデマンドで再ハイドレートされます。このアプローチは容量を節約しますが、大きなファイルの初回オープン時のレイテンシーが増加する可能性があります。ほとんどの場合、OneDriveを除外することなく、ファイルオンデマンドだけで十分です。
• Microsoft Teamsの最適化：AVDに最適化されたTeamsを使用し、redirections.xmlで一時的なTeamsキャッシュを除外して、繰り返し発生する高負荷なI/Oを回避します。

← セッションホストのイメージとプロビジョニング · すべてのドメイン · セッションホストの運用、スケーリング、最適化 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →