Azure File Sync のデプロイを計画する

ファイルは 、Azure ファイル共有のクラウドに格納されます。 Azure ファイル共有は、次の 2 つの方法で使用できます。 どのデプロイ オプションを選択するかによって、デプロイの計画時に考慮する必要がある側面が変わります。

• サーバー メッセージ ブロック (SMB) プロトコルを使用して Azure ファイル共有を直接マウントする: Azure Files は SMB アクセスを提供するため、Windows、macOS、Linux で使用できる標準の SMB クライアントを使用して、オンプレミスまたはクラウドで Azure ファイル共有をマウントできます。 Azure ファイル共有はサーバーレスであるため、実稼働シナリオ用にデプロイする場合、ファイル サーバーまたはネットワーク接続ストレージ (NAS) デバイスを管理する必要はありません。 この選択は、ソフトウェアパッチを適用したり、物理ディスクをスワップアウトしたりする必要がないことを意味します。

• Azure File Sync を使用してオンプレミスの Azure ファイル共有をキャッシュする: Azure File Sync を使用すると、オンプレミスのファイル サーバーの柔軟性、パフォーマンス、互換性を維持しながら、Azure Files で組織のファイル共有を一元化できます。 Azure File Sync は、オンプレミス (またはクラウド) の Windows Server インスタンスを Azure ファイル共有のクイック キャッシュに変換します。

管理の概念

Azure では、リソースは、Azure サブスクリプションと リソース グループ内で作成および構成する管理可能な項目です。 リソースは、 特定の種類のリソースを提供する管理サービスであるリソース プロバイダーによって提供されます。 Azure File Sync をデプロイするには、次の 2 つの重要なリソースを操作します。

• Microsoft.Storage リソース プロバイダーによって提供されるストレージ アカウント。 ストレージ アカウントは、ストレージ アカウントの種類に応じて 、クラシック ファイル共有 またはその他のストレージ リソースをデプロイできるストレージ、IOPS、スループットの共有プールを表す最上位のリソースです。 ストレージ アカウントにデプロイされているすべてのストレージ リソースにより、そのストレージ アカウントに適用される制限が共有されます。 従来のファイル共有では、SMB ファイル共有プロトコルと NFS ファイル共有プロトコルの両方がサポートされていますが、SMB ファイル共有では Azure File Sync のみを使用できます。

  注

  Azure Files では、 Microsoft.FileShares リソース プロバイダーを介した最上位の Azure リソースとしてのファイル共有のデプロイもサポートされていますが、これらのファイル共有は、Azure File Sync ではサポートされていない NFS ファイル システム プロトコルのみをサポートします。

• Microsoft.StorageSync リソース プロバイダーによって提供されるストレージ同期サービス。 ストレージ同期サービスは、Windows ファイル サーバーを登録し、Azure File Sync の同期関係を定義できる管理コンテナーとして機能します。

Azure ファイル共有管理の概念

従来のファイル共有(ストレージ アカウントにデプロイされたファイル共有)は、Azure Files のファイル共有をデプロイする従来の方法です。 SMB と NFS、SSD と HDD のメディア層、すべての冗長性の種類、すべてのリージョンなど、Azure Files でサポートされているすべての主要な機能がサポートされています。 クラシック ファイル共有の詳細については、 クラシック ファイル共有に関するページを参照してください。

クラシック ファイル共有のデプロイには、主に次の 2 種類のストレージ アカウントが使用されます。

• プロビジョニングされたストレージ アカウント: プロビジョニングされたストレージ アカウントは、 FileStorage ストレージ アカウントの種類を使用して区別されます。 プロビジョニングされたストレージ アカウントを使用すると、プロビジョニングされたクラシック ファイル共有を SSD または HDD ベースのハードウェアにデプロイできます。 プロビジョニングされたストレージ アカウントは、クラシック ファイル共有の格納にのみ使用でき、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを使用することはできません。 すべての新しいクラシック ファイル共有のデプロイには、プロビジョニングされたストレージ アカウントを使用することをお勧めします。
• 従量課金制ストレージ アカウント: 従量課金制ストレージ アカウントは、 StorageV2 ストレージ アカウントの種類を使用して区別されます。 従量課金制ストレージ アカウントを使用すると、HDD ベースのハードウェアに従量課金制のファイル共有をデプロイできます。 従量課金制ストレージ アカウントを使用すると、クラシック ファイル共有や、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを格納できます。

Azure File Sync 管理の概念

ストレージ同期サービス内では、次の情報をデプロイできます。

• 登録済みサーバー。記憶域同期サービスとの信頼関係を持つ Windows ファイル サーバーを表します。 登録済みサーバーは個々のサーバーまたはクラスターのいずれかになりますが、サーバー/クラスターは一度に 1 つのストレージ同期サービスにのみ登録できます。

• 同期グループ。クラウド エンドポイントと 1 つ以上のサーバー エンドポイントの間の同期関係を定義します。 同期グループ内のエンドポイントは、相互に同期を維持されます。 たとえば、Azure File Sync で管理する 2 つの個別のファイル セットがある場合は、2 つの同期グループを作成し、各同期グループに異なるエンドポイントを追加します。

  • Azure ファイル共有を表すクラウド エンドポイント。
  • サーバー エンドポイント。Azure Files に同期されている登録済みサーバー上のパスを表します。 名前空間が重複していない場合、登録済みサーバーには複数のサーバー エンドポイントを含めることができます。

必要なストレージ同期サービスの数

ストレージ同期サービスは、Azure File Sync のルート Azure Resource Manager リソースです。Windows Server のインストールと Azure ファイル共有の間の同期関係を管理します。 各ストレージ同期サービスには、複数の同期グループと複数の登録済みサーバーを含めることができます。

各 Windows Server インスタンスは、1 つのストレージ同期サービスにのみ登録できます。 登録後、サーバーは、Resource Manager プリンシパルを使用してサーバー上にサーバー エンドポイントを作成することで、そのストレージ同期サービス内の複数の同期グループに参加できます。

Azure File Sync トポロジを設計するときは、ストレージ同期サービスのレベルでデータを明確に分離してください。 たとえば、企業で 2 つの異なるビジネス ユニットに個別の Azure File Sync 環境が必要であり、これらのグループ間で厳密なデータ分離が必要な場合は、グループごとに専用のストレージ同期サービスを作成する必要があります。 この構成では完全な分離が保証されないため、両方のビジネス グループの同期グループを同じストレージ同期サービス内に配置しないでください。

Azure で個別のサブスクリプションまたはリソース グループを使用してデータを分離する方法の詳細については、 Azure リソース プロバイダーと種類を参照してください。

バランスの取れた同期トポロジの計画

リソースをデプロイする前に、ローカル サーバーで同期する内容と Azure ファイル共有を計画することが重要です。 プランを作成すると、必要なストレージ アカウント、Azure ファイル共有、および同期リソースの数を決定するのに役立ちます。 これらの考慮事項は、データが現在 Windows Server インスタンスに存在しない場合や、長期的に使用するサーバー上に存在しない場合でも関連します。 この記事の 移行セクション は、状況に適した移行パスを決定するのに役立ちます。

この手順では、必要な Azure ファイル共有の数を決定します。 1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。

現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。 このシナリオを理解する最も簡単な方法は、1:1 で Azure ファイル共有にマップするオンプレミスの共有を想像することです。 1 つの Windows Server インスタンスに対して 30 を下回る、十分な数の共有がある場合は、1 対 1 のマッピングをお勧めします。

共有の数が 30 を超える場合、通常オンプレミスの共有を 1 対 1 で Azure ファイル共有にマッピングする必要はありません。 次のオプションを検討してください。

共有のグループ化

たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。 1 つの Azure ファイル共有にオンプレミスの共有を複数格納しても、ローカルの Windows Server インスタンスに通常の 15 個の SMB 共有を作成できます。 これは、単にこれらの 15 個の共有のルート フォルダーを共通フォルダーの下のサブフォルダーとして整理することを意味します。 その後、この共通フォルダーを Azure ファイル共有に同期します。 そうすることで、このオンプレミス共有グループに必要な Azure ファイル共有はクラウドに 1 つだけです。

ボリュームの同期

Azure File Sync では、ボリュームのルートを Azure ファイル共有に同期することをサポートしています。 ボリューム ルートを同期すると、すべてのサブフォルダーとファイルが同じ Azure ファイル共有に移動します。

ボリュームのルートを同期することが常に最適なオプションであるとは限りません。 複数の場所に同期することには利点があります。 たとえば、そうすることで、同期スコープあたりの項目数を少なく抑えることができます。 Azure ファイル共有と Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダ) を保持できるようテストされています。 ただし、ベスト プラクティスとしては、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。

Azure File Sync に含める項目数を少数に設定することは、ファイルの同期にとって有益というだけではありません。項目の数が少ないと、次のようなシナリオでも利点があります。

• クラウド コンテンツの初期スキャンは、高速に完了できます。その結果、Azure File Sync が有効になっているサーバーに名前空間が表示されるまでの待ち時間が短縮されます。
• Azure ファイル共有スナップショットからのクラウド側の復元の方が高速です。
• オンプレミスサーバーのディザスター リカバリーが大幅にスピードアップされます。
• Azure ファイル共有 (同期の外部) で直接行われた変更を検出して、より迅速に同期できます。

デプロイ マップに対する構造化されたアプローチ

後の手順でクラウド ストレージをデプロイする前に、オンプレミス フォルダーと Azure ファイル共有の間にマップを作成することが重要です。 このマッピングにより、プロビジョニングする Azure File Sync 同期グループ リソースの数と数が通知されます。 同期グループは、Azure ファイル共有とサーバー上のフォルダーを連携させ、同期接続を確立します。

マップを最適化し、必要な Azure ファイル共有の数を決定するには、次の制限とベスト プラクティスを確認します。

• Azure File Sync エージェントがインストールされているサーバーは、最大 30 個の Azure ファイル共有と同期できます。

• Azure ファイル共有は、ストレージ アカウント内にデプロイされます。 この配置により、このストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。

  Azure ファイル共有をデプロイするときは、ストレージ アカウントの IOPS の制限に注意してください。 理想的には、ファイル共有をストレージ アカウントに 1:1 でマップする必要があります。 ただし、組織と Azure の両方で、さまざまな制限や制限があるため、このマッピングが常に可能であるとは限りません。 1 つのストレージ アカウントに 1 つのファイル共有のみをデプロイできない場合は、どの共有が非常にアクティブになり、どの共有のアクティブが低下するかを検討してください。 最もホットなファイル共有を同じストレージ アカウントにまとめて配置しないでください。

  Azure ファイル共有をネイティブで使用する Azure にアプリをリフトする場合は、Azure ファイル共有のパフォーマンスをさらに上げる必要があります。 将来的にでもこのように使用することが考えられる場合は、1 つの標準の Azure ファイル共有を独自のストレージ アカウントに作成するのが最善です。

• 1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージ アカウント数は 250 に制限されています。

状況によっては、一連のフォルダーを同じ Azure ファイル共有に論理的に同期できます (前に説明した共通ルート アプローチを使用します)。 ただし、フォルダーをグループ化し直して、1 つではなく 2 つの Azure ファイル共有に同期することをお勧めします。 このアプローチを使用すると、ファイル共有あたりのファイルとフォルダーの数をサーバー間に分散させることができます。 また、オンプレミス共有を分割し、より多くのオンプレミス サーバー間で同期して、追加のサーバーごとにさらに 30 個の Azure ファイル共有と同期する機能を追加することもできます。

ファイル同期の一般的なシナリオと考慮事項

マッピング テーブルを作成する

前述の情報を使用して、必要な Azure ファイル共有の数を決定し、既存のデータのどの部分がどの Azure ファイル共有に格納されるかを判断します。

必要なときに参照できるように、自分の考えを記録するテーブルを作成します。 多数の Azure リソースを一度にプロビジョニングする場合、マッピング 計画の詳細が失われる可能性があるため、整理を維持することが重要です。 次の Excel ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。

名前空間マッピング テンプレートをダウンロードします。

Windows ファイル サーバーに関する考慮事項

Windows Server で同期機能を有効にするには、Azure File Sync のダウンロード可能なエージェントをインストールする必要があります。 Azure File Sync エージェントには、2 つの主要コンポーネントがあります。

• FileSyncSvc.exeは、サーバー エンドポイントでの変更の監視と同期セッションの開始を担当するバックグラウンド Windows サービスです。
• StorageSync.sysは、クラウドの階層化と高速なディザスター リカバリーを可能にするファイル システム フィルターです。

オペレーティング システムの要件

Azure File Sync は、次のバージョンの Windows Server でサポートされています。

Azure File Sync で使用するすべてのサーバーは、Windows Update の最新の更新プログラムを使用して常に最新の状態を保つことをお勧めします。

最小システム リソース

Azure File Sync には、次のすべての属性を持つサーバー (物理または仮想) が必要です。

• 少なくとも 1 つの CPU。
• 少なくとも 2 GiB のメモリ。 動的メモリが有効になっている仮想マシンでサーバーが実行されている場合は、少なくとも 2,048 MiB のメモリで VM を構成します。
• NTFS ファイル システムでフォーマットされたローカル接続ボリューム。

ほとんどの運用ワークロードでは、最小要件のみを使用して Azure File Sync で同期サーバーを構成することはお勧めしません。

推奨されるシステム リソース

他のサーバー機能やアプリケーションと同様に、デプロイのスケールによって、Azure File Sync のシステム リソース要件が決まります。サーバー上の大規模なデプロイでは、より大きなシステム リソースが必要です。

Azure File Sync の場合、サーバー エンドポイント全体のオブジェクトの数とデータセットのチャーンによってスケールが決まります。 1 つのサーバーが複数の同期グループにサーバー エンドポイントを持つことができます。 次の表に示すオブジェクトの数は、サーバーがアタッチされている完全な名前空間を表します。

たとえば、 1,000 万オブジェクトを持つサーバー エンドポイント A と、1,000 万オブジェクト = 2,000 万オブジェクトのサーバー エンドポイント B などです。 その例のデプロイでは、8 個の CPU と、安定状態の場合は 16 GiB メモリ、初期移行の場合は (可能であれば) 48 GiB のメモリが推奨されます。

名前空間データは、パフォーマンス上の理由からメモリに格納されます。 この構成により、より大きな名前空間では、優れたパフォーマンスを維持するために必要なメモリが増えます。 チャーンが多いほど、処理に必要な CPU が増えます。

次の表は、名前空間のサイズと、一般的な汎用ファイル共有の容量への変換の両方を示しています。平均ファイル サイズは 512 KiB です。 ファイル サイズが小さい場合は、同じ容量のメモリを追加することを検討してください。 名前空間のサイズに基づいてメモリを構成します。

*1億を超えるファイルとディレクトリを同期することはお勧めしません。 これは、テストされたしきい値に基づくソフト制限です。 詳細については、「Azure File Sync のスケール ターゲット」をご覧ください。

評価コマンドレット

Azure File Sync をデプロイする前に、Azure File Sync 評価コマンドレットを使用して、システムと互換性があるかどうかを評価する必要があります。 このコマンドレットは、サポートされていない文字やサポートされていないオペレーティング システムのバージョンなど、ファイル システムとデータセットに関する潜在的な問題をチェックします。 これらのチェックでは、この記事で説明されている機能の大部分 (ただし、すべてではありません) が対象になります。 デプロイがスムーズに進むよう、このセクションの残りの部分をよく読んでおくことをお勧めします。

Az PowerShell モジュールをインストールすることで、評価コマンドレットをインストールできます。 手順については、「 Azure PowerShell のインストール」を参照してください。

使用法

システム チェック、データセット チェック、またはその両方を実行することで、評価ツールを呼び出すことができます。 システムチェックとデータセットチェックの両方を実行するには:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

データセットのみをテストするには:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

システム要件のみをテストするには:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

結果を .csv ファイルに表示するには:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

ファイル システムの互換性

Azure File Sync は、直接接続された NTFS ボリュームでのみサポートされます。 Windows Server 上の直接接続ストレージ (DAS) は、Windows Server オペレーティング システムがファイル システムを所有していることを意味します。 DAS を提供するには、ファイル サーバーにディスクを物理的に接続するか、仮想ディスクをファイル サーバー VM (Hyper-Vでホストされている VM など) に接続するか、または iSCSI を使用します。

NTFS ボリュームのみがサポートされています。 ReFS、FAT、FAT32、およびその他のファイル システムはサポートされていません。

次の表は、NTFS ファイル システム機能の相互運用性の状態を示しています。

Azure File Sync では、特定の一時ファイルとシステム フォルダーもスキップされます。

ローカル ディスクの空き領域

Azure File Sync を使用する予定の場合は、サーバー エンドポイントのローカル ディスクに必要な空き領域の量を検討してください。

Azure File Sync では、ローカル ディスクの領域を占有する次の項目を考慮する必要があります。

• クラウドを使った階層化が有効な場合:

  • 階層化されたファイルの再解析ポイント
  • Azure File Sync メタデータ データベース
  • Azure File Sync ヒートストア
  • ホットキャッシュに完全にダウンロードされたファイル (存在する場合)
  • ボリュームの空き領域のポリシー要件

• クラウドを使った階層化が無効な場合:

  • 完全にダウンロードされたファイル
  • Azure File Sync ヒートストア
  • Azure File Sync メタデータ データベース

次の例は、ローカル ディスクに必要な空き領域の量を見積もる方法を示しています。 たとえば、Azure File Sync エージェントを Azure Windows VM にインストールし、ディスク F にサーバー エンドポイントを作成する予定であるとします。100 万個のファイル (およびそれらのすべてを階層化する)、100,000 個のディレクトリ、4 KiB のディスク クラスター サイズがあります。 ディスク サイズは 1,000 GiB です。 クラウドの階層化を有効にし、ボリュームの空き領域ポリシーを 20%に設定します。

• NTFS は、階層化された各ファイルにクラスター サイズを割り当てます。

  100 万ファイル * 4 KiB クラスター サイズ = 4,000,000 KiB (4 GiB)

  クラウドの階層化を最大限に活用するには、各階層化されたファイルがクラスターを占有するため、より小さい NTFS クラスター サイズ (64 KiB 未満) を使用することをお勧めします。 また、NTFS は、階層化されたファイルが占有する領域を割り当てます。 この領域は、どの UI にも表示されません。

• 同期メタデータは、項目ごとにクラスター サイズを占有します。

  (100 万ファイル + 100,000 ディレクトリ) * 4 KiB クラスター サイズ = 4,400,000 KiB (4.4 GiB)

• Azure File Sync ヒートストアは、ファイルあたり 1.1 KiB を占有します。

  100 万ファイル * 1.1 KiB = 1,100,000 KiB (1.1 GiB)

• ボリュームの空き領域ポリシーは 20%:

  1000 GiB * 0.2 = 200 GiB

この場合、Azure File Sync には約 209,500,000 KiB (209.5 GiB) の領域が必要になります。 このディスクに必要と思われる空き領域にこの量を追加します。

フェールオーバー クラスタリング

Azure File Sync では、 一般的なデプロイ オプションとしてファイル サーバー の Windows Server フェールオーバー クラスタリングがサポートされています。 フェールオーバー クラスターで 一般的な役割を持つファイル サーバー を構成する方法の詳細については、「 2 ノードクラスター化ファイル サーバーのデプロイ」を参照してください。

Azure File Sync でサポートされる唯一のシナリオは、クラスター化されたディスクを含む Windows Server フェールオーバー クラスターです。 フェールオーバー クラスタリングは、Scale-Out ファイル サーバー、クラスター共有ボリューム (CSV)、またはローカル ディスクではサポートされていません。

同期を正しく機能させるには、フェールオーバー クラスター内のすべてのノードに Azure File Sync エージェントをインストールする必要があります。

データ重複除去

Windows Server 2025、Windows Server 2022、Windows Server 2019、および Windows Server 2016

データ重複除去は、Windows Server 2025、Windows Server 2022、Windows Server 2019、および Windows Server 2016 のボリューム上の 1 つ以上のサーバー エンドポイントでクラウドの階層化が有効か無効かに関係なくサポートされます。 クラウドを使った階層化が有効なボリュームでデータ重複除去を有効にすると、より多くのストレージをプロビジョニングしなくても、より多くのファイルをオンプレミスでキャッシュできます。

クラウドの階層化が有効になっているボリュームでデータ重複除去を有効にすると、サーバー エンドポイントの場所内の重複除去最適化ファイルは、クラウド階層化のポリシー設定に基づいて、通常のファイルと同様に階層化されます。 重複除去最適化ファイルを階層化すると、データ重複除去ガベージ コレクション ジョブが自動的に実行されます。 ボリューム上の他のファイルが参照しなくなった不要なチャンクを削除することで、ディスク領域を再利用します。

データ重複除去がインストールされている場合、重複除去ガベージ コレクションがトリガーされた後、使用可能なボリューム領域が予想以上に増える可能性があります。 次の例では、ボリューム領域のしくみについて説明します。

1. クラウド階層化の空き領域ポリシーは、20%に設定されます。
2. 空き領域が少ない場合、Azure File Sync に通知されます (たとえば、19%)。
3. 階層化により、1% 多くの領域を解放する必要がありますが、5% を追加する必要があるため、最大 25% (30 GiB など) を階層化します。
4. ファイルは、30 GiB に達するまで階層化されます。
5. データ重複除去との相互運用性の一環として、Azure File Sync は階層化セッションの終了時にガベージ コレクションを開始します。

ボリュームの節約は、サーバーにのみ適用されます。 Azure ファイル共有内のデータは重複除去されません。

Windows Server 2012 R2

Azure File Sync については、データ重複除去とクラウドを使った階層化は、Windows Server 2012 R2 の同じボリューム上ではサポートされていません。 ボリュームでデータ重複除去を有効にする場合は、クラウドの階層化を無効にする必要があります。

注記

• Azure File Sync エージェントをインストールする前にデータ重複除去をインストールする場合は、同じボリュームでのデータ重複除去とクラウドの階層化をサポートするために再起動が必要です。

• クラウドの階層化を有効にした後でボリュームでデータ重複除去を有効にした場合、初期重複除去最適化ジョブでは、まだ階層化されていないボリューム上のファイルが最適化されます。 このジョブは、クラウドの階層化に次の影響を与えます。

  • 空き領域ポリシーは、ヒートマップを使用して、ボリューム上の空き領域に従ってファイルを階層化し続けます。
  • 日付ポリシーは、重複除去最適化ジョブがファイルにアクセスしているため、階層化の対象となる可能性があるファイルの階層化をスキップします。

• 継続的な重複除去の最適化ジョブでは、ファイルがまだ階層化されていない場合、データ重複除去 MinimumFileAgeDays 設定によって、データ ポリシーによるクラウドの階層化が遅れます。

  • たとえば、 MinimumFileAgeDays 設定が 7 日で、クラウド階層化のデータ ポリシーが 30 日である場合、日付ポリシーは 37 日後にファイルを階層化します。
  • Azure File Sync でファイルが階層化されると、重複除去の最適化ジョブによってファイルがスキップされます。

• Azure File Sync エージェントがインストールされている Windows Server 2012 R2 を実行しているサーバーを Windows Server 2025、Windows Server 2022、Windows Server 2019、または Windows Server 2016 にアップグレードする場合は、同じボリュームでデータ重複除去とクラウド階層化をサポートするために、次の手順を実行する必要があります。

  1. Windows Server 2012 R2 用の Azure File Sync エージェントをアンインストールして、サーバーを再起動します。
  2. 新しいサーバー オペレーティング システム バージョン (Windows Server 2025、Windows Server 2022、Windows Server 2019、または Windows Server 2016) の Azure File Sync エージェントをダウンロードします。
  3. Azure File Sync エージェントをインストールして、サーバーを再起動します。

  エージェントをアンインストールして再インストールすると、サーバーは Azure File Sync 構成設定を保持します。

分散ファイル システム

Azure File Sync では、DFS 名前空間 (DFS-N) および DFS レプリケーション (DFS-R) との相互運用性がサポートされています。

DFS-N

Azure File Sync は、DFS-N 実装で完全にサポートされています。 Azure File Sync エージェントを 1 つ以上のファイル サーバーにインストールして、サーバー エンドポイントとクラウド エンドポイントの間でデータを同期させることができます。その後、DFS-N を使用して名前空間サービスを提供できます。 詳しくは、DFS 名前空間の概要に関するページと、Azure Files での DFS 名前空間に関するページを参照してください。

DFS-R

DFS-R と Azure File Sync はどちらもレプリケーション ソリューションであるため、ほとんどの場合、DFS-R を Azure File Sync に置き換えることをお勧めします。 ただし、次のシナリオでは、DFS-R と Azure File Sync を一緒に使用する必要があります。

• DFS-R のデプロイから Azure File Sync のデプロイに移行しているとき。 詳細については、「 DFS-R デプロイを Azure File Sync に移行する」を参照してください。
• ファイル データのコピーが必要なオンプレミスのサーバーの中に、インターネットに直接接続することができないものが含まれる場合。
• ブランチ サーバーは、Azure File Sync を使用する単一のハブ サーバーにデータを統合します。

Azure File Sync と DFS-R を併用するには、次のことが必要です。

• DFS-R でレプリケートされるフォルダーを含むボリュームで、Azure File Sync のクラウドの階層化を無効にする必要があります。
• DFS-R の読み取り専用レプリケーション フォルダーには、サーバー エンドポイントを構成しないようにする必要があります。
• DFS-R の場所との重複が可能なサーバー エンドポイントは 1 つだけです。 複数のサーバー エンドポイントが、他のアクティブな DFS-R の場所と重複すると、競合が発生する可能性があります。

詳細については、「 DFS 名前空間と DFS レプリケーションの概要」を参照してください。

Sysprep

Azure File Sync エージェントがインストールされているサーバーで Sysprep を使用することはサポートされていないため、予期しない結果になる可能性があります。 エージェントのインストールとサーバーの登録は、サーバー イメージをデプロイし、Sysprep ミニセットアップを完了した後に行う必要があります。

Windows Search

サーバー エンドポイントでクラウドの階層化が有効になっている場合、Windows Search は階層化されたファイルをスキップし、インデックスを作成しません。 Windows Search では、階層化されていないファイルのインデックスが正しく作成されます。

Windows クライアントは、クライアント コンピューターで [常にファイル名とコンテンツを検索 する] 設定が有効になっている場合に、ファイル共有を検索すると呼び戻しが発生します。 既定では、この設定は無効になっています。

その他の HSM ソリューション

Azure File Sync では、他の階層ストレージ管理 (HSM) ソリューションを使用しないでください。

パフォーマンスと拡張性

Azure File Sync エージェントは、Azure ファイル共有に接続する Windows Server コンピューター上で実行されるため、有効な同期パフォーマンスはインフラストラクチャ内の次の要因によって異なります。

• Windows Server と基になるディスク構成
• サーバーと Azure ストレージの間のネットワーク帯域幅
• ファイル サイズ
• データセットの合計サイズ
• データセットのアクティビティ

Azure File Sync はファイル レベルで動作します。 Azure File Sync に基づくソリューションのパフォーマンス特性は、1 秒あたりに処理されるオブジェクト (ファイルとディレクトリ) の数で測定する方が優れています。

詳細については、Azure File Sync のパフォーマンス メトリックと Azure File Sync スケール ターゲットに関するページを参照してください。

ID

サーバーを登録してクラウド エンドポイントを作成する管理者は、ストレージ同期サービスの管理ロール Azure File Sync 管理者、所有者、または共同作成者のメンバーである必要があります。 このロールは、ストレージ同期サービスの Azure portal ページの アクセス制御 (IAM) で構成できます。

Azure File Sync は、同期の設定以外に特別なセットアップを行うことなく、標準の Active Directory ベースの ID と連携します。Azure File Sync を使用している場合、一般的な期待は、ほとんどのアクセスが Azure ファイル共有ではなく、Azure File Sync キャッシュ サーバーを経由することです。 サーバー エンドポイントは Windows Server 上にあり、Windows Server は Active Directory と Windows スタイルの ACL をサポートしているため、記憶域同期サービスに登録されている Windows ファイル サーバーがドメインに参加していることを確認する以外に何も必要ありません。 Azure File Sync は、Azure ファイル共有内のファイルに ACL を格納し、それらの ACL をすべてのサーバー エンドポイントにレプリケートします。

Azure ファイル共有に直接加えられた変更は、同期グループ内のサーバー エンドポイントとの同期に時間がかかりますが、クラウド内のファイル共有に Active Directory のアクセス許可を直接適用できるようにすることもできます。 この構成を行うには、Windows ファイル サーバーのドメイン参加方法と同様に、ストレージ アカウントをオンプレミスの Active Directory インスタンスにドメイン参加させる必要があります。 ストレージ アカウントを顧客所有の Active Directory インスタンスに参加させるドメインの詳細については、「 SMB アクセスのための Azure Files ID ベースの認証の概要」を参照してください。

Networks

Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。 どちらのプロトコルも、ポート 443 経由で常に HTTPS を使用します。 SMB は、Windows Server インスタンスと Azure ファイル共有の間でデータをアップロードまたはダウンロードするために使用されることはありません。 ほとんどの組織では、ほとんどの Web サイトにアクセスするための要件としてポート 443 経由の HTTPS トラフィックを許可しているため、通常、Azure File Sync をデプロイするために特別なネットワーク構成は必要ありません。

組織のポリシーまたは固有の規制要件に基づいて、Azure とのより制限の厳しい通信が必要になる場合があります。 Azure File Sync には、ネットワークを構成するためのいくつかのメカニズムが用意されています。 要件に応じて、次のことができます。

• Azure ExpressRoute または Azure 仮想プライベート ネットワーク (VPN) 経由のトンネル同期とファイルのアップロード/ダウンロード トラフィック。
• サービス エンドポイントやプライベート エンドポイントなどの Azure Files と Azure ネットワーク機能を利用します。
• お使いの環境でプロキシをサポートするよう Azure File Sync を構成。
• Azure File Sync からネットワーク アクティビティを調整。

SMB 経由で Azure ファイル共有と通信したいが、ポート 445 がブロックされている場合は、QUIC 経由の SMB の使用を検討してください。 この方法では、ポート 443 経由の QUIC トランスポート プロトコルを介して Azure ファイル共有に SMB アクセスするための構成がゼロの VPN が提供されます。 Azure Files は QUIC 経由の SMB を直接サポートしていませんが、Azure File Sync を使用して Windows Server 2022 Azure Edition VM に Azure ファイル共有の軽量キャッシュを作成できます。このオプションの詳細については、「 SMB over QUIC」を参照してください。

Azure File Sync とネットワークの詳細については、「Azure File Sync のネットワークに関する考慮事項」を参照してください。

暗号化

Azure File Sync には、Windows Server の保存時ストレージでの暗号化、Azure File Sync エージェントと Azure の間の転送中の暗号化、Azure ファイル共有内のデータの保存時の暗号化という 3 つの暗号化レイヤーが用意されています。

Windows Server の保存時の 暗号化

Windows Server 上のデータを暗号化するための 2 つの方法は、通常、Azure File Sync で動作します。

• ファイル システムの下の暗号化。ファイル システムとそのシステムに書き込まれるすべてのデータが暗号化されるようにする
• ファイル形式自体内の暗号化

これらのメソッドは相互に排他的ではありません。 暗号化の目的が異なるため、それらを組み合わせて使用することもできます。

ファイル システムの下に暗号化を提供するために、Windows Server には BitLocker 受信トレイが用意されています。 BitLocker は、Azure File Sync に対して完全に透過的です。BitLocker などの暗号化メカニズムを使用する主な理由は次のとおりです。

• ディスクを盗むユーザーによるオンプレミス データセンターからのデータの物理的な流出を防ぐ
• 未承認の OS をサイドローディングして、データへの未承認の読み取りと書き込みを実行できないようにする

詳しくは、「BitLocker の概要」をご覧ください。

BitLocker と同様に機能するパートナー製品は、NTFS ボリュームの下に配置されるため、Azure File Sync で完全かつ透過的に動作する必要があります。

データを暗号化するもう 1 つの主な方法は、アプリケーションがファイルを保存するときにファイルのデータ ストリームを暗号化することです。 一部のアプリケーションでは、このタスクをネイティブに実行できますが、通常は実行されません。

ファイルのデータ ストリームを暗号化する方法の例としては、Azure Information Protection、Azure Rights Management (Azure RMS)、Active Directory Rights Management Services があります。 Azure Information Protection や Azure RMS などの暗号化メカニズムを使用する主な理由は、別の場所 (フラッシュ ドライブなど) にコピーしたユーザーによるファイル共有からのデータの流出を防いだり、承認されていないユーザーに電子メールで送信したりすることです。 ファイルのデータ ストリームがファイル形式の一部として暗号化されている場合、このファイルは引き続き Azure ファイル共有で暗号化されます。

Azure File Sync は、ファイル システムの上にあり、ファイルのデータ ストリームの下にある NTFS 暗号化ファイル システムまたはパートナー暗号化ソリューションと相互運用できません。

転送中の暗号化

Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。 どちらのプロトコルも、ポート 443 経由で常に HTTPS を使用します。 Azure File Sync では、暗号化されていない要求が HTTP 経由で送信されることはありません。

Azure ストレージ アカウントには、転送中の暗号化を要求するためのスイッチが含まれています。 このスイッチは既定で有効になっています。 ストレージ アカウント レベルのスイッチが無効になっていて、Azure ファイル共有への暗号化されていない接続が可能な場合でも、Azure File Sync は暗号化されたチャネルのみを使用してファイル共有にアクセスします。

ストレージ アカウントの転送中の暗号化を無効にする主な理由は、Azure ファイル共有と直接通信するレガシ アプリケーションをサポートすることです。 このようなアプリケーションは、Windows Server 2008 R2 や古い Linux ディストリビューションなどの古いオペレーティング システムで実行する必要があります。 レガシ アプリケーションがファイル共有の Windows Server キャッシュに接続する場合、この設定を変更しても効果はありません。

転送中のデータの暗号化を有効にすることを強くお勧めします。 転送中の暗号化の詳細については、「 セキュリティで保護された接続を確保するためにセキュリティで保護された転送を要求する」を参照してください。

Azure ファイル共有の保存時の暗号化

Azure Files に格納されているすべてのデータは、Azure Storage サービス側暗号化 (SSE) によって保存時に暗号化されます。 SSE は、Windows 上の BitLocker と同様に機能します。データはファイル システム レベルの下で暗号化されます。

データは Azure ファイル共有のファイル システムの下で暗号化されるため、ディスクにエンコードされるため、Azure ファイル共有の読み取りまたは書き込みにクライアントの基になるキーにアクセスする必要はありません。 保存時の暗号化は、SMB と NFS の両方のプロトコルに適用されます。

規定では、Azure Files に格納されるデータは、Microsoft マネージド キーで暗号化されます。 Microsoft が管理するキーを使用すると、Microsoft はデータの暗号化と暗号化解除を行うキーを保持します。 Microsoft は、これらのキーを定期的にローテーションする責任を負います。

また、お客様が自分でキーを管理することもでき、その場合はお客様がローテーション プロセスを制御できます。 お客様が管理するキーによるファイル共有の暗号化を選択した場合、クライアントからの読み取りと書き込みの要求を処理するため、Azure Files にはキーへのアクセスが承認されます。 カスタマー マネージド キーを使用すると、いつでもこの承認を取り消すことができます。 ただし、この承認がなければ、SMB または FileREST API を使用して Azure ファイル共有にアクセスできなくなります。

Azure Files では、Azure Blob Storage などの他の Azure Storage サービスと同じ暗号化スキームが使用されます。 Azure Storage SSE の詳細については、 保存データの Azure Storage 暗号化に関するページを参照してください。

ストレージ層

Azure Files には、ソリッド ステート ディスク (SSD) とハード ディスク ドライブ (HDD) の 2 つのメディア層のストレージが用意されています。 これらのレベルを使用すると、シナリオのパフォーマンスと価格の要件に合わせて共有を調整できます。

• SSD (Premium): SSD ファイル共有は、I/O 集中型ワークロードに対して、ほとんどの I/O 操作で一貫した高パフォーマンスと低待機時間を 1 桁ミリ秒以内に提供します。 SSD ファイル共有は、データベース、Web サイトホスティング、開発環境など、さまざまなワークロードに適しています。

  SMB プロトコルと NFS プロトコルの両方で SSD ファイル共有を使用できます。 SSD ファイル共有は、 プロビジョニングされた v2 および プロビジョニングされた v1 課金モデルで使用できます。 SSD ファイル共有は、HDD ファイル共有よりも 高い可用性 SLA を 提供します。

• HDD (標準): HDD ファイル共有は、汎用ファイル共有にコスト効率の高いストレージ オプションを提供します。 HDD ファイル共有は 、プロビジョニングされた v2 および 従量課金 制の課金モデルで使用できますが、ファイル共有の新しいデプロイにはプロビジョニングされた v2 モデルをお勧めします。 SLA の詳細については、 オンライン サービスの Azure SLA ページを参照してください。

ワークロードのメディア層を選択するときは、パフォーマンスと使用の要件を考慮してください。 ワークロードで 1 桁の待機時間が必要な場合、またはオンプレミスで SSD ストレージ メディアを使用している場合は、おそらく SSD ファイル共有が最適です。 待機時間が短い場合は、コストの観点から HDD ファイル共有の方が適している可能性があります。 たとえば、待ち時間が短い場合、Azure からオンプレミスにマウントされたチーム共有や、Azure File Sync を使用してオンプレミスにキャッシュされたチーム共有に関する懸念が少なくなる可能性があります。

ストレージ アカウントにファイル共有を作成した後は、別のメディア層に直接移動することはできません。 たとえば、HDD ファイル共有を SSD メディア層に移動するには、新しい SSD ファイル共有を作成し、 元の共有から新しいファイル共有にデータをコピーする必要があります。

SSD および HDD メディア層の詳細については、「 Azure Files の課金モデルについて」および「Azureファイル共有のパフォーマンスを理解して最適化する」を参照してください。

Azure File Sync の利用可能なリージョン

リージョン別の可用性については、「 リージョン別の製品の可用性 」を参照し、 ストレージ アカウントを検索します。

次のリージョンでは、Azure File Sync を使用する前に、Azure Storage へのアクセス権を要求する必要があります。

• フランス南部
• 南アフリカ西部
• アラブ首長国連邦中部

これらのリージョンへのアクセスを要求するには、 この記事のプロセスに従います。

冗長性

Azure ファイル共有内のデータをデータの損失や破損から保護するために、Azure Files には、書き込まれる各ファイルの複数のコピーが格納されます。 要件に応じて、冗長性の程度を選択できます。 Azure Files では現在、データの冗長性に関して次のオプションがサポートされています。

• ローカル冗長ストレージ (LRS):ローカル冗長では、すべてのファイルが Azure ストレージ クラスターに 3 回格納されます。 この方法は、不適切なディスク ドライブなどのハードウェア障害によるデータ損失から保護するのに役立ちます。 ただし、データセンターで火災や洪水などの災害が発生した場合、LRS を使用するストレージ アカウントのすべてのレプリカが失われたり回復不能になる可能性があります。

• ゾーン冗長ストレージ (ZRS):ゾーン冗長では、各ファイルの 3 つのコピーが格納されます。 ただし、これらのコピーは、Azure 可用性ゾーンの 3 つの異なるストレージ クラスターに物理的に分離されます。 可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 ストレージへの書き込みは、3 つの可用性ゾーンすべてのストレージ クラスターに書き込まれるまで受け付けられません。

• geo 冗長ストレージ (GRS): geo 冗長では、プライマリ リージョンとセカンダリ リージョンがあります。 ファイルは、プライマリ リージョンの Azure ストレージ クラスターに 3 回格納されます。 書き込みは、Microsoft によって定義されたセカンダリ リージョンに非同期的にレプリケートされます。

  geo 冗長性により、2 つの Azure リージョン間に分散されたデータのコピーが 6 つ提供されます。 自然災害やその他の同様のイベントによる Azure リージョンの永続的な損失など、大規模な災害が発生した場合、Microsoft はフェールオーバーを実行します。 この場合、セカンダリがプライマリになり、すべての操作が処理されます。

  プライマリ リージョンとセカンダリ リージョン間のレプリケーションは非同期であるため、大規模な障害が発生した場合、セカンダリ リージョンにまだレプリケートされていないデータは失われます。 geo 冗長ストレージ アカウントのフェールオーバーは、手動で実行することもできます。

• geo ゾーン冗長ストレージ (GZRS): geo ゾーンの冗長性により、ファイルはプライマリ リージョンの 3 つの異なるストレージ クラスターに 3 回格納されます。 その後、すべての書き込みが Microsoft で定義されたセカンダリ リージョンに非同期的にレプリケートされます。 geo ゾーン冗長のフェールオーバー プロセスは、geo 冗長性の場合と同じように機能します。

HDD ファイル共有では、4 種類の冗長性がすべてサポートされます。 SSD ファイル共有では、LRS と ZRS のみがサポートされます。

従量課金制ストレージ アカウントには、Azure Files でサポートされていない他の 2 つの冗長性オプションが用意されています。読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS)。 これらのオプションを設定してストレージ アカウントに Azure ファイル共有をプロビジョニングできますが、Azure Files ではセカンダリ リージョンからの読み取りはサポートされていません。 RA-GRS または RA-GZRS ストレージ アカウントにデプロイされた Azure ファイル共有は、それぞれ geo 冗長または geo ゾーン冗長として課金されます。

移行

Windows Server 2012 R2 以降に既存のファイル サーバーがある場合は、Azure File Sync を直接インストールできます。 新しいサーバーにデータを移動する必要はありません。

Azure File Sync の導入の一環として新しい Windows ファイル サーバーに移行する予定の場合、またはデータが現在 NAS にある場合は、このデータで Azure File Sync を使用する移行方法がいくつか考えられます。 どの移行方法を選択するかは、現在データが存在する場所によって異なります。

詳細なガイダンスについては、「 SMB Azure ファイル共有への移行」を参照してください。

ウイルス対策

ウイルス対策は既知の悪意のあるコードのファイルをスキャンすることによって機能するため、ウイルス対策製品によって階層化されたファイルが再呼び出され、エグレス料金が高くなる可能性があります。 階層化されたファイルには、セキュリティで保護された Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 設定されています。 この属性が設定されているファイルの読み取りをスキップするようにソリューションを構成する方法については、ソフトウェア ベンダーに相談することをお勧めします。 (多くは自動的に行います。)

Microsoft ウイルス対策ソリューションの Windows Defender と System Center Endpoint Protection は、この属性が設定されているファイルの読み取りを自動的にスキップします。 それらをテストし、1 つの小さな問題を特定しました。既存の同期グループにサーバーを追加すると、800 バイト未満のファイルが新しいサーバーに呼び出されます (ダウンロードされます)。 これらのファイルは新しいサーバーに残り、階層化サイズの要件 (64 KiB を超える) を満たしていないため、階層化されません。

ウイルス対策ベンダーは、Microsoft ダウンロード センターの Azure File Sync ウイルス対策互換性テスト スイート を使用して、製品と Azure File Sync の間の互換性を確認できます。

Backup

クラウドの階層化を有効にする場合は、サーバー エンドポイントを直接バックアップするソリューションや、サーバー エンドポイントを含む VM を使用しないでください。

クラウドの階層化により、データのサブセットのみがサーバー エンドポイントに格納されます。 完全なデータセットは、Azure ファイル共有に存在します。 使用するバックアップ ソリューションに応じて、階層化されたファイルは次のいずれかになります。

• FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS属性が設定されているため、スキップされ、バックアップされません
• ディスクに呼び戻され、エグレス料金が高くなります

Azure ファイル共有を直接バックアップするには、クラウド バックアップ ソリューションを使用することをお勧めします。 詳細については、「 Azure Files バックアップについて」を参照してください。 または、Azure ファイル共有のバックアップがサポートされているかどうかをバックアップ プロバイダーに問い合わせてください。

オンプレミスのバックアップ ソリューションを使用する場合は、クラウド階層化が無効になっている同期グループ内のサーバーでバックアップを実行します。 階層化されたファイルがないことを確認します。

復元を実行する場合は、ボリューム レベルまたはファイル レベルの復元オプションを使用します。 ファイル レベルの復元オプションを使用して復元されたファイルは、同期グループ内のすべてのエンドポイントに同期されます。 既存のファイルは、バックアップから復元されたバージョンに置き換えられます。 ボリューム レベルの復元では、Azure ファイル共有またはその他のサーバー エンドポイントの新しいファイル バージョンは置き換えられません。

データの分類

データ分類ソフトウェアがインストールされている場合、クラウド階層化を有効にすると、次の 2 つの理由でコストが増加します。

• クラウドの階層化を有効にすると、最もホットなファイルがローカルにキャッシュされます。 最もクールなファイルは、クラウド内の Azure ファイル共有に階層化されます。 データ分類でファイル共有内のすべてのファイルが定期的にスキャンされる場合は、クラウドに階層化されたファイルがスキャンされるたびに呼び戻す必要があります。
• データ分類ソフトウェアがファイルのデータ ストリーム内のメタデータを使用する場合は、ソフトウェアが分類を検出するためにファイルを完全に呼び戻す必要があります。

これにより、取り消しの数と呼び戻されるデータの量の両方でコストが増加する可能性があります。

Azure ファイル同期エージェントの更新ポリシー

Azure File Sync エージェントは、新機能の追加や問題の解決のために定期的に更新されます。 新しいバージョンが利用可能な場合は、Azure File Sync エージェントの更新をお勧めします。

エージェントのメジャー バージョンとマイナー バージョン

• エージェントのメジャー バージョンには、多くの場合、新しい機能が含まれています。メジャー バージョンでは、バージョン番号の先頭部分の数値が増えていきます。 例: 18.0.0.0。
• マイナー エージェント バージョンは パッチ とも呼ばれ、メジャー バージョンよりも頻繁にリリースされます。 多くの場合、バグの修正と軽微な機能強化が含まれ、新しい機能は含まれません。 例: 18.2.0.0。

パスを更新する

Azure File Sync エージェントの更新プログラムをインストールするには、次の 5 つの承認済みおよびテスト済みの方法があります。

• Azure File Sync 自動更新機能を使用してエージェントの更新プログラムをインストールします。Azure File Sync エージェントは自動的に更新されます。 最新のエージェント バージョンが使用可能な場合はインストールするか、現在インストールされているエージェントの有効期限が近い場合は更新するかを選択できます。 詳細については、次のセクション「 エージェントライフサイクルの自動管理」を参照してください。
• エージェントの更新プログラムを自動的にダウンロードしてインストールするように Microsoft Update を構成する: サーバー エージェントの最新の修正プログラムにアクセスできるように、すべての Azure File Sync 更新プログラムをインストールすることをお勧めします。 Microsoft Update では、更新プログラムのダウンロードとインストールを自動的に実行することで、このプロセスをシームレスにしています。
• AfsUpdater.exe を使用してエージェントの更新プログラムをダウンロードしてインストールします。 AfsUpdater.exe ファイルはエージェントのインストール ディレクトリにあります。 実行可能ファイルをダブルクリックして、エージェントの更新プログラムをダウンロードしてインストールします。 リリース バージョンによっては、サーバーの再起動が必要な場合があります。
• Microsoft Update パッチ ファイルまたは .msp 実行可能ファイルを使用して既存の Azure File Sync エージェントにパッチを適用する: Microsoft Update カタログから最新の Azure File Sync 更新プログラム パッケージをダウンロードできます。 .msp 実行可能ファイルを実行すると、Microsoft Update が自動的に使用するのと同じ方法で Azure File Sync のインストールが更新されます。 Microsoft Update パッチを適用すると、Azure File Sync インストールのインプレース更新が実行されます。
• 最新の Azure File Sync エージェント インストーラーをダウンロードします。 Microsoft ダウンロード センターでインストーラーを入手できます。 既存の Azure File Sync エージェントのインストールを更新するには、以前のバージョンをアンインストールしてから、ダウンロードしたインストーラーから最新バージョンをインストールします。 エージェントの設定 (サーバー登録やサーバー エンドポイントなど) は、Azure File Sync エージェントがアンインストールされるときに維持されます。

エージェントのライフサイクルの自動管理

Azure File Sync エージェントは自動的に更新されます。 次のいずれかのモードを選択し、サーバーで更新を試行するメンテナンス期間を指定できます。 この機能は、エージェントの有効期限を防ぐガードレールを提供するか、手間のかからない最新の設定を可能にすることで、エージェントのライフサイクル管理を支援するように設計されています。

• 既定の設定では、エージェントの有効期限が切れないようにします。 エージェントのポストされた有効期限日から 21 日以内に、エージェントは自己更新を試みます。 更新の試行は、有効期限が切れる 21 日以内に週に 1 回、選択したメンテナンス期間に開始されます。 このオプションでは、通常の Microsoft Update パッチを適用する必要はありません。

• 新しいエージェント バージョンが使用可能になるとすぐに、エージェントが自動的に更新されるように選択できます。 この機能は、現在、クラスター化されたサーバーには適用されません。

  この更新は選択されているメンテナンス期間中に行われ、サーバーは、新機能と機能強化が一般提供されるとすぐに、それらを活用できるようになります。 この推奨される心配のない設定では、メジャー エージェント バージョンと通常の更新プログラムの修正プログラムがサーバーに提供されます。 リリースされるすべてのエージェントは GA 品質です。

  このオプションを選択すると、Microsoft は最新のエージェント バージョンをフライトします。 クラスター化サーバーは除外されます。 フライティングが完了すると、エージェントは Microsoft Update と Microsoft ダウンロード センターでも使用できるようになります。

自動更新の設定を変更する

次の手順では、インストーラーを完了した後に設定を変更する方法について説明します (変更する必要がある場合)。

PowerShell コンソールを開き、同期エージェントをインストールしたディレクトリに移動し、サーバー コマンドレットをインポートします。 既定では、このアクションは次の例のようになります。

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Get-StorageSyncAgentAutoUpdatePolicy を実行して、現在のポリシー設定を確認し、変更するかどうかを判断できます。

現在のポリシー設定を遅延更新追跡に変更する場合は、以下を使用できます。

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

現在のポリシー設定を即時更新追跡に変更する場合は、以下を使用できます

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

エージェントのライフサイクルと変更管理の保証

Azure File Sync は、新機能と機能強化を継続的に導入するクラウド サービスです。 特定の Azure File Sync エージェントのバージョンは、限られた期間だけサポートできます。 デプロイを容易にするために、次の規則では、変更管理プロセスでエージェントの更新に対応するのに十分な時間と通知があることを保証します。

• エージェントのメジャー バージョンは、最初のリリースから少なくとも 12 か月間サポートされます。
• メジャー エージェント バージョンのサポート間には、少なくとも 3 か月の重複があります。
• 登録されたサーバーに対して警告が発行されるのは、有効期限が切れる少なくとも 3 か月前to-be 期限切れのエージェントです。 ストレージ同期サービスの登録済みサーバーに関するセクションで、登録済みサーバーが古いバージョンのエージェントを使用しているかどうかを確認できます。
• マイナー エージェントの有効期間は、メジャー バージョンに関連付けられています。 たとえば、エージェント バージョン 18.0.0.0 が期限切れに設定されている場合、エージェント バージョン 18.*.*.* はすべて一緒に期限切れになります。

関連コンテンツ

• Azure File Sync のプロキシとファイアウォールの設定
• SMB Azure ファイル共有を作成する
• Azure File Sync をデプロイする
• Azure File Sync の監視