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 の両方のファイル共有プロトコルがサポートされていますが、Azure File Sync は SMB ファイル共有でのみ使用できます。

  注

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

• ストレージ同期サービス。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 台のサーバーで、複数の同期グループにサーバー エンドポイントを持つことができます。 次の表に示されているオブジェクトの数は、サーバーが接続されているフル ネーム空間を表します。

たとえば、"サーバー エンドポイント A (1000 万オブジェクト) + サーバー エンドポイント B (1000 万オブジェクト) = 2000 万オブジェクト" です。 その例のデプロイでは、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 ファイル システム機能の相互運用性の状態を示しています。

Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Invoke-StorageSyncCloudTiering -Path <path>

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

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

Azure File Sync の使用を計画するときは、サーバー エンドポイントのローカル ディスクに必要な空き領域の量を考慮してください。

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

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

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

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

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

次の例は、ローカル ディスクに必要な空き領域の量を見積もる方法を示しています。 たとえば、Azure Windows VM に Azure File Sync エージェントをインストールし、ディスク F にサーバー エンドポイントを作成する予定だとします。ファイル数は 100 万 (そのすべてを階層化します)、ディレクトリ数が 10 万、ディスク クラスター サイズは 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 フェールオーバー クラスターです。 フェールオーバー クラスタリングは、スケールアウト ファイル サーバー、クラスター共有ボリューム (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. 空き領域が少なくなると (たとえば 19%)、Azure File Sync に通知されます。
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 管理者ロールを割り当てるときは、次の手順に従って最小限の特権を確保します。

1. [ 条件 ] タブで、[ 選択したプリンシパルにのみ選択したロールを割り当てることができるようにユーザーに許可する ]を選択します (権限が少なくなります)。

2. [ ロールとプリンシパルの選択 ] をクリックし、[条件 1] で [ アクションの追加] を選択します。

3. [ ロールの割り当ての作成] を選択し、[ 選択] をクリックします。

4. [ 式の追加] を選択し、[要求] を選択 します。

5. [属性ソース] で、[ロール定義 ID] を [属性] の下に選択し、[ForAnyOfAnyValues:GuidEquals] を [演算子] の下に選択します。

6. [ ロールの追加] を選択します。 閲覧者とデータ アクセス、ストレージ ファイル データ特権共同作成者、ストレージ アカウント共同作成者ロールを追加し、[保存] を選択します。

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 は SMB over QUIC を直接サポートしていませんが、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 の概要」をご覧ください。

NTFS ボリュームの下層で機能するという点で BitLocker と同様に機能するパートナー製品は、Azure File Sync と完全に透過的に連携するはずです。

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

ファイルのデータ ストリームを暗号化する方法の例としては、Azure Information Protection、Azure Rights Management (Azure RMS)、Active Directory Rights Management サービスがあります。 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 ファイル共有は、IO 集中型ワークロードの場合、ほとんどの IO 操作に対して 1 桁台のミリ秒以内で安定したハイ パフォーマンスと低待機時間を提供しています。 SSD ファイル共有は、データベース、Web サイトのホスティング、開発環境など、幅広い種類のワークロードに適しています。

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

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

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

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

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 冗長性では、データの 6 つのコピーが 2 つの Azure リージョンに分散して作成されます。 自然災害や他の同様の事象により Azure リージョンが完全に失われる場合など、重大な災害が発生した場合は、Microsoft によってフェールオーバーが実行されます。 この場合は、セカンダリがプライマリになり、すべての操作が行われます。

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

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

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

従量課金制のストレージ アカウントでは、これ以外に読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) という、Azure Files でサポートされていない 2 つの冗長性オプションが用意されています。 これらのオプション セットを使用して、ストレージ アカウントで 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 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 エージェントにパッチを適用する: 最新の Azure File Sync 更新プログラム パッケージは、Microsoft Update カタログからダウンロードできます。 .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 か月前に、有効期限が近づいているエージェントを通じて、登録済みサーバーに警告が発行されます。 ストレージ同期サービスに登録されたサーバーに関するセクションで、登録されたサーバーが以前のバージョンのエージェントを使用しているかどうかを確認できます。
• マイナー エージェントの有効期間は、メジャー バージョンに関連付けられています。 たとえば、エージェント バージョン 18.0.0.0 が期限切れに設定されると、エージェント バージョン 18.*.*.* もすべて同時に期限切れになります。

関連コンテンツ

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