Azure File Sync のデプロイ

[アーティクル]
08/02/2024

Azure File Sync を使用すると、オンプレミスのファイルサーバーの柔軟性、パフォーマンス、互換性を維持したまま Azure Files で組織のファイル共有を一元化できます。 Azure File Sync により、ご利用の Windows Server が Azure ファイル共有の高速キャッシュに変わります。 SMB、NFS、FTPS など、Windows Server 上で利用できるあらゆるプロトコルを使用して、データにローカルにアクセスできます。キャッシュは、世界中にいくつでも必要に応じて設置することができます。

この記事に記載されている手順を完了する前に、「Azure Files のデプロイの計画」と「Azure File Sync のデプロイの計画」を読むことを強くお勧めします。

前提条件

Azure File Sync をデプロイするのと同じリージョンに Azure ファイル共有が存在すること。詳細については、以下を参照してください。
- Azure File Sync の「利用可能なリージョン」
- ファイル共有を作成する方法の詳細な手順を示す「ファイル共有の作成」
ストレージアカウントへの Azure File Sync アクセスを許可するには、次のストレージアカウント設定を有効にする必要があります:
- SMB セキュリティ設定 では、 SMB 3.1.1 プロトコルバージョン、 NTLM v2 認証と、 AES-128-GCM 暗号化を許可する必要があります。ストレージアカウントの SMB セキュリティ設定を確認するには、「SMB セキュリティ設定」を参照してください。
- ストレージアカウントキーのアクセスを許可 するには 有効にする必要があります。この設定を確認するには、ストレージアカウントに移動し、[設定] セクションで [構成] を選択します。
Azure File Sync と同期する、サポートされている Windows Server の少なくとも 1 つのインスタンス。サポートされる Windows Server のバージョンと推奨されるシステムリソースの詳細については、「Windows ファイルサーバーに関する考慮事項」を参照してください。
Windows Server に次の Windows 更新プログラムをインストールする必要があります。
- Windows Server 2012 R2: KB5021653
- Windows Server 2016: KB5040562
- Windows Server 2019: KB5005112 と KB5040430
省略可能: Windows Server フェールオーバークラスターで Azure File Sync を使用する場合は、クラスター内の各ノードに Azure File Sync エージェントをインストールする前に、汎用のファイルサーバー ロールを構成する必要があります。フェールオーバークラスターで汎用のファイルサーバー ロールを構成する方法の詳細については、「クラスター化された 2 ノードファイルサーバーの展開」を参照してください。

注意

Azure File Sync によってサポートされる唯一のシナリオは、クラスター化されたディスクを使用する Windows Server フェールオーバークラスターです。 Azure File Sync については「フェールオーバークラスタリング」セクションをご覧ください。
クラウド管理は Azure portal で行うことができますが、PowerShell 5.1 または PowerShell 6 以降でローカルで実行することを意図した PowerShell コマンドレットを介して、高度な登録済みサーバー機能が提供されます。 Windows Server 2012 R2 では、$PSVersionTable オブジェクトの PSVersion プロパティの値を調べることによって、少なくとも PowerShell 5.1.* を実行していることを確認できます。
```
$PSVersionTable.PSVersion
```
PSVersion の値が 5.1.* 未満の場合は、Windows Management Framework (WMF) 5.1 をダウンローおよびインストールしてアップグレードする必要があります。 Windows Server 2012 R2 でダウンロードしてインストールする適切なパッケージは、Win8.1AndW2K12R2-KB*******-x64.msu です。

PowerShell 6+ は、サポートされているすべてのシステムで使用でき、その GitHub ページ経由でダウンロードできます。

Azure File Sync をデプロイするのと同じリージョンに Azure ファイル共有が存在すること。詳細については、以下を参照してください。
- Azure File Sync の「利用可能なリージョン」
- ファイル共有を作成する方法の詳細な手順を示す「ファイル共有の作成」
ストレージアカウントへの Azure File Sync アクセスを許可するには、次のストレージアカウント設定を有効にする必要があります:
- SMB セキュリティ設定 では、 SMB 3.1.1 プロトコルバージョン、 NTLM v2 認証と、 AES-128-GCM 暗号化を許可する必要があります。ストレージアカウントの SMB セキュリティ設定を確認するには、「SMB セキュリティ設定」を参照してください。
- ストレージアカウントキーのアクセスを許可 するには 有効にする必要があります。この設定を確認するには、ストレージアカウントに移動し、[設定] セクションで [構成] を選択します。
Azure File Sync と同期する、サポートされている Windows Server の少なくとも 1 つのインスタンス。サポートされる Windows Server のバージョンと推奨されるシステムリソースの詳細については、「Windows ファイルサーバーに関する考慮事項」を参照してください。
Windows Server に次の Windows 更新プログラムをインストールする必要があります。
- Windows Server 2012 R2: KB5021653
- Windows Server 2016: KB5040562
- Windows Server 2019: KB5005112 と KB5040430
省略可能: Windows Server フェールオーバークラスターで Azure File Sync を使用する場合は、クラスター内の各ノードに Azure File Sync エージェントをインストールする前に、汎用のファイルサーバー ロールを構成する必要があります。フェールオーバークラスターで汎用のファイルサーバー ロールを構成する方法の詳細については、「クラスター化された 2 ノードファイルサーバーの展開」を参照してください。

注意

Azure File Sync によってサポートされる唯一のシナリオは、クラスター化されたディスクを使用する Windows Server フェールオーバークラスターです。 Azure File Sync については「フェールオーバークラスタリング」セクションをご覧ください。
PowerShell 5.1 または PowerShell 6 以降。 Azure File Sync 用の Az PowerShell モジュールは、サポートされているすべてのシステム (Windows 以外のシステムを含む) で使用できますが、サーバー登録コマンドレットは常に、登録している Windows Server インスタンスで実行する必要があります (これは直接、または PowerShell リモート処理経由で行うことができます)。 Windows Server 2012 R2 で、$PSVersionTable オブジェクトの PSVersion プロパティの値を調べることによって、少なくとも PowerShell 5.1.* を実行していることを確認します。
```
$PSVersionTable.PSVersion
```
PSVersion の値が 5.1.* 未満の場合は、Windows Management Framework (WMF) 5.1 をダウンローおよびインストールしてアップグレードする必要があります。 Windows Server 2012 R2 でダウンロードしてインストールする適切なパッケージは、Win8.1AndW2K12R2-KB*******-x64.msu です。

PowerShell 6+ は、サポートされているすべてのシステムで使用でき、その GitHub ページ経由でダウンロードできます。
PowerShell 5.1 を使用することを選択した場合は、少なくとも .NET 4.7.2 がインストールされていることを確認してください。詳細については、使用しているシステムで「.NET Framework のバージョンおよび依存関係」を参照してください。
重要

Windows Server Core で .NET 4.7.2+ をインストールする場合は、quiet フラグと norestart フラグを指定してインストールする必要があります。そうしないと、インストールが失敗します。たとえば、.NET 4.8 をインストールする場合、コマンドは次のようになります。
```
Start-Process -FilePath "ndp48-x86-x64-allos-enu.exe" -ArgumentList "/q /norestart" -Wait
```
Az PowerShell モジュール。これは、次の手順に従ってインストールできます。Azure PowerShell をインストールして構成します。

Note

Az PowerShell モジュールをインストールするときに、Az.StorageSync モジュールが自動的にインストールされるようになりました。

Azure File Sync をデプロイするのと同じリージョンに Azure ファイル共有が存在すること。詳細については、以下を参照してください。
- Azure File Sync の「利用可能なリージョン」
- ファイル共有を作成する方法の詳細な手順を示す「ファイル共有の作成」
ストレージアカウントへの Azure File Sync アクセスを許可するには、次のストレージアカウント設定を有効にする必要があります:
- SMB セキュリティ設定 では、 SMB 3.1.1 プロトコルバージョン、 NTLM v2 認証と、 AES-128-GCM 暗号化を許可する必要があります。ストレージアカウントの SMB セキュリティ設定を確認するには、「SMB セキュリティ設定」を参照してください。
- ストレージアカウントキーのアクセスを許可 するには 有効にする必要があります。この設定を確認するには、ストレージアカウントに移動し、[設定] セクションで [構成] を選択します。
Azure File Sync と同期する、サポートされている Windows Server の少なくとも 1 つのインスタンス。サポートされる Windows Server のバージョンと推奨されるシステムリソースの詳細については、「Windows ファイルサーバーに関する考慮事項」を参照してください。
Windows Server に次の Windows 更新プログラムをインストールする必要があります。
- Windows Server 2012 R2: KB5021653
- Windows Server 2016: KB5040562
- Windows Server 2019: KB5005112 と KB5040430
省略可能: Windows Server フェールオーバークラスターで Azure File Sync を使用する場合は、クラスター内の各ノードに Azure File Sync エージェントをインストールする前に、汎用のファイルサーバー ロールを構成する必要があります。フェールオーバークラスターで汎用のファイルサーバー ロールを構成する方法の詳細については、「クラスター化された 2 ノードファイルサーバーの展開」を参照してください。

注意

Azure File Sync によってサポートされる唯一のシナリオは、クラスター化されたディスクを使用する Windows Server フェールオーバークラスターです。 Azure File Sync については「フェールオーバークラスタリング」セクションをご覧ください。
Azure CLI のインストール

必要に応じて、Azure Cloud Shell を使用してこのチュートリアルの手順を完了することもできます。 Azure Cloud Shell は、ブラウザーを介して使用する対話型のシェル環境です。次のいずれかの方法で Cloud Shell を起動します。
- コードブロックの右上隅にある [使ってみる] を選択します。 [使ってみる] によって Azure Cloud Shell が開きますが、コードが Cloud Shell に自動的にコピーされることはありません。
- https://shell.azure.com に移動して Cloud Shell を開きます
- Azure portal の右上にあるメニューバーの [Cloud Shell] ボタンを選択します
サインインします。

CLI のローカルインストールを使用する場合は、az login コマンドを使用してサインインします。
```
az login
```
ターミナルに表示される手順に従って、認証プロセスを完了します。
Azure CLI 拡張機能 az filesync をインストールする
```
az extension add --name storagesync
```
拡張機能のリファレンス storagesync をインストールすると、次の警告が表示されます。
```
The installed extension 'storagesync' is experimental and not covered by customer support. Please use with discretion.
```
クラウド管理は Azure CLI で行うことができますが、PowerShell 5.1 または PowerShell 6 以降でローカルで実行することを意図した PowerShell コマンドレットを介して、高度な登録済みサーバー機能が提供されます。 Windows Server 2012 R2 では、$PSVersionTable オブジェクトの PSVersion プロパティの値を調べることによって、少なくとも PowerShell 5.1. を実行していることを確認できます。
```
$PSVersionTable.PSVersion
```
PSVersion の値が 5.1.* 未満の場合は、Windows Management Framework (WMF) 5.1 をダウンローおよびインストールしてアップグレードする必要があります。 Windows Server 2012 R2 でダウンロードしてインストールする適切なパッケージは、Win8.1AndW2K12R2-KB*******-x64.msu です。

PowerShell 6+ は、サポートされているすべてのシステムで使用でき、その GitHub ページ経由でダウンロードできます。

Azure File Sync で使用する Windows Server の準備

フェールオーバークラスターの各サーバーノードなど、Azure File Sync で使用する各サーバーで、Internet Explorer セキュリティ強化の構成を無効にします。これは、初回のサーバー登録でのみ必要です。サーバーの登録後に再び有効にできます。

Note

Windows Server Core で Azure File Sync をデプロイする場合は、この手順を省略できます。

サーバーマネージャーを開きます。
[ローカルサーバー] をクリックします。
[プロパティ] サブウィンドウで、 [IE セキュリティ強化の構成] リンクを選択します。
[Internet Explorer セキュリティ強化の構成] ダイアログボックスで、 [管理者] と [ユーザー] の両方で [オフ] を選択します。

Internet Explorer セキュリティ強化の構成を無効にするには、管理者特権の PowerShell セッションから次を実行します。

$installType = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\").InstallationType

# This step is not required for Server Core
if ($installType -ne "Server Core") {
    # Disable Internet Explorer Enhanced Security Configuration 
    # for Administrators
    Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}" -Name "IsInstalled" -Value 0 -Force

    # Disable Internet Explorer Enhanced Security Configuration 
    # for Users
    Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}" -Name "IsInstalled" -Value 0 -Force

    # Force Internet Explorer closed, if open. This is required to fully apply the setting.
    # Save any work you have open in the Internet Explorer browser. This will not affect other browsers,
    # including Microsoft Edge.
    Stop-Process -Name iexplore -ErrorAction SilentlyContinue
}

ストレージ同期サービスのデプロイ

Azure File Sync のデプロイでは最初に、選択したサブスクリプションのリソースグループにストレージ同期サービス リソースを配置します。必要に応じて、これらをプロビジョニングすることをお勧めします。サーバーとこのリソースの間に信頼関係を作成します。サーバーは、1 つのストレージ同期サービスにのみ登録できます。そのため、サーバーのグループを分離するために必要な数だけのストレージ同期サービスをデプロイすることをお勧めします。異なるストレージ同期サービスを使用するサーバー間では同期できないことに注意してください。

Note

ストレージ同期サービスは、デプロイされたサブスクリプションとリソースグループからアクセス許可を継承します。アクセス権を持つユーザーを慎重に確認することをお勧めします。書き込みアクセス権を持つエンティティは、このストレージ同期サービスに登録されたサーバーからファイルの新しいセットの同期を開始することができ、それらにアクセスできる Azure Storage にデータが送られます。

ストレージ同期サービスをデプロイするには、Azure portal に移動し、[リソースの作成] を選択して、Azure File Sync を検索します。検索結果から [Azure File Sync] を選択した後、[作成] を選択して [ストレージ同期のデプロイ] タブを開きます。

開いたウィンドウに、次の情報を入力します。

Name:ストレージ同期サービスの (リージョンごとに) 一意の名前。
サブスクリプション:ストレージ同期サービスを作成するサブスクリプション。組織の構成方針によっては、1 つ以上のサブスクリプションにアクセスできることがあります。 Azure サブスクリプションは、各クラウドサービス (Azure Files など) に対する課金の最も基本的なコンテナーです。
[リソースグループ] :リソースグループは、ストレージアカウントやストレージ同期サービスなどの Azure リソースの論理グループです。 Azure File Sync 用の新しいリソースグループを作成するか、既存のリソースグループを選択できますリソースグループをコンテナーとして使用して、組織のリソースを論理的に分離することをお勧めします。たとえば、HR リソースや特定のプロジェクトのリソースをグループ化します。
[場所] :Azure File Sync をデプロイするリージョン。この一覧ではサポートされているリージョンのみを使用できます。

完了したら、[作成] を選択して、ストレージ同期サービスをデプロイします。

<Az_Region>、<RG_Name>、および <my_storage_sync_service> を独自の値に置き換え、次のコマンドを使用してストレージ同期サービスを作成およびデプロイします。

$hostType = (Get-Host).Name

if ($installType -eq "Server Core" -or $hostType -eq "ServerRemoteHost") {
    Connect-AzAccount -UseDeviceAuthentication
}
else {
    Connect-AzAccount
}

# this variable holds the Azure region you want to deploy 
# Azure File Sync into
$region = '<Az_Region>'

# Check to ensure Azure File Sync is available in the selected Azure
# region.
$regions = @()
Get-AzLocation | ForEach-Object { 
    if ($_.Providers -contains "Microsoft.StorageSync") { 
        $regions += $_.Location 
    } 
}

if ($regions -notcontains $region) {
    throw [System.Exception]::new("Azure File Sync is either not available in the selected Azure Region or the region is mistyped.")
}

# the resource group to deploy the Storage Sync Service into
$resourceGroup = '<RG_Name>'

# Check to ensure resource group exists and create it if doesn't
$resourceGroups = @()
Get-AzResourceGroup | ForEach-Object { 
    $resourceGroups += $_.ResourceGroupName 
}

if ($resourceGroups -notcontains $resourceGroup) {
    New-AzResourceGroup -Name $resourceGroup -Location $region
}

$storageSyncName = "<my_storage_sync_service>"
$storageSync = New-AzStorageSyncService -ResourceGroupName $resourceGroup -Name $storageSyncName -Location $region

Azure File Sync エージェントをインストールする

Azure File Sync エージェントは、Windows Server を Azure ファイル共有と同期できるようにするダウンロード可能なパッケージです。

このエージェントは、Microsoft ダウンロードセンターからダウンロードできます。ダウンロードが完了したら、MSI パッケージをダブルクリックして Azure File Sync エージェントのインストールを開始するか、エージェントをサイレントインストールします。「新しい Azure File Sync エージェントのインストールにサイレントインストールを実行する方法」を参照してください。

重要

フェールオーバークラスターで Azure File Sync を使用する場合は、クラスターのすべてのノードに Azure File Sync エージェントをインストールする必要があります。 Azure File Sync で動作するようにクラスター内の各ノードを登録する必要があります。

次を実行することをお勧めします。

トラブルシューティングとサーバーのメンテナンスを簡素化するために、既定のインストールパス (C:\Program Files\Azure\StorageSyncAgent) をそのまま使用します。
Microsoft Update を有効にして、Azure File Sync を最新の状態に保ちます。機能の更新プログラムと修正プログラムを含め、Azure File Sync エージェントに対するすべての更新が Microsoft Update から実行されます。最新の更新プログラムを Azure File Sync に適用することをお勧めします。詳細については、Azure File Sync の更新ポリシーに関する記事をご覧ください。

Azure File Sync エージェントのインストールが完了すると、サーバー登録 UI が自動的に開きます。登録の前にストレージ同期サービスが必要です。ストレージ同期サービスを作成する方法については、次のセクションをご覧ください。

次の PowerShell コードを実行して、お使いの OS に適したバージョンの Azure File Sync エージェントをダウンロードし、システムにインストールします。

重要

# Gather the OS version
$osver = [System.Environment]::OSVersion.Version

# Download the appropriate version of the Azure File Sync agent for your OS.
if ($osver.Equals([System.Version]::new(10, 0, 20348, 0))) {
    Invoke-WebRequest `
        -Uri https://aka.ms/afs/agent/Server2022 `
        -OutFile "StorageSyncAgent.msi" 
} elseif ($osver.Equals([System.Version]::new(10, 0, 17763, 0))) {
    Invoke-WebRequest `
        -Uri https://aka.ms/afs/agent/Server2019 `
        -OutFile "StorageSyncAgent.msi" 
} elseif ($osver.Equals([System.Version]::new(10, 0, 14393, 0))) {
    Invoke-WebRequest `
        -Uri https://aka.ms/afs/agent/Server2016 `
        -OutFile "StorageSyncAgent.msi" 
} elseif ($osver.Equals([System.Version]::new(6, 3, 9600, 0))) {
    Invoke-WebRequest `
        -Uri https://aka.ms/afs/agent/Server2012R2 `
        -OutFile "StorageSyncAgent.msi" 
} else {
    throw [System.PlatformNotSupportedException]::new("Azure File Sync is only supported on Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 and Windows Server 2022")
}

# Install the MSI. Start-Process is used to PowerShell blocks until the operation is complete.
# Note that the installer currently forces all PowerShell sessions closed - this is a known issue.
Start-Process -FilePath "StorageSyncAgent.msi" -ArgumentList "/quiet" -Wait

# Note that this cmdlet will need to be run in a new session based on the above comment.
# You may remove the temp folder containing the MSI and the EXE installer
Remove-Item -Path ".\StorageSyncAgent.msi" -Recurse -Force

Windows Server をストレージ同期サービスに登録する

Windows Server をストレージ同期サービスに登録すると、サーバー (またはクラスター) とストレージ同期サービスの間に信頼関係が確立されます。 1 つのサーバーは、1 つのストレージ同期サービスにのみ登録でき、同じストレージ同期サービスに関連付けられている他のサーバーおよび Azure ファイル共有と同期できます。

Note

サーバーの登録では、Azure 資格情報を使用して、ストレージ同期サービスと Windows Server の間に信頼関係が作成されます。その後、サーバーによって独自の ID が作成され使用されます、その ID は、サーバーが登録され、現在の Shared Access Signature (SAS) トークンが有効である限り有効となります。サーバーの登録が解除されるとサーバーに新しい SAS トークンを発行できなくなるので、サーバーは Azure ファイル共有にアクセスできず、すべての同期を停止します。

サーバーを登録する管理者は、特定のストレージ同期サービスに対する所有者または共同作成者の管理ロールのメンバーである必要があります。これは、Azure portal においてストレージ同期サービスに対する [アクセス制御 (IAM)] で構成できます。

また、サーバーを登録できる管理者と、ストレージ同期サービスで同期を構成することも許可されている管理者を、区別することもできます。その場合、サーバーの登録のみが許可される管理者の一覧を取得するカスタムロールを作成し、そのカスタムロールに次のアクセス許可を付与する必要があります。

"Microsoft.StorageSync/storageSyncServices/registeredServers/write"
"Microsoft.StorageSync/storageSyncServices/read"
"Microsoft.StorageSync/storageSyncServices/workflows/read"
"Microsoft.StorageSync/storageSyncServices/workflows/operations/read"

Azure File Sync エージェントがインストールされると、サーバー登録 UI が自動的に開きます。開かない場合、ファイルの場所 C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe から手動で開くことができます。サーバー登録 UI が開いたら、 [サインイン] を選択して開始します。

サインインすると、次の情報の入力を求められます。

サーバー登録 UI のスクリーンショット

Azure サブスクリプション: ストレージ同期サービスを含むサブスクリプション (「ストレージ同期サービスのデプロイ」をご覧ください)。
リソースグループ:ストレージ同期サービスを含むリソースグループ。
ストレージ同期サービス: 登録するストレージ同期サービスの名前。

適切な情報を選択したら、[登録] を選択してサーバー登録を完了します。登録プロセスの一環として、追加のサインインを求められます。

$registeredServer = Register-AzStorageSyncServer -ParentObject $storageSync

同期グループとクラウドエンドポイントを作成する

同期グループは、一連のファイルの同期トポロジを定義します。同期グループ内のエンドポイントは、相互に同期を維持されます。同期グループには、Azure ファイル共有と 1 つ以上のサーバーエンドポイントを表す、1 つのクラウドエンドポイントが含まれている必要があります。サーバーエンドポイントは、登録されているサーバー上のパスを表します。 1 つのサーバーが、複数の同期グループにサーバーエンドポイントを持つことができます。目的の同期トポロジを適切に記述するために必要なだけいくつでも同期グループを作成できます。

クラウドエンドポイントは、Azure ファイル共有へのポインターです。すべてのサーバーエンドポイントはクラウドエンドポイントと同期するので、クラウドエンドポイントはハブになります。 Azure ファイル共有のストレージアカウントは、ストレージ同期サービスと同じリージョンに存在する必要があります。 Azure ファイル共有の全体が同期されますが、1 つ例外があり、NTFS ボリューム上の非表示の "システムボリューム情報" フォルダーに相当する特別なフォルダーがプロビジョニングされます。このディレクトリの名前は ".SystemShareInformation" です。このディレクトリには、他のエンドポイントに同期されない重要な同期メタデータが含まれます。使用したり削除したりしないでください。

重要

同期グループ内の任意のクラウドエンドポイントまたはサーバーエンドポイントで変更を行うことにより、ファイルを同期グループ内の他のエンドポイントに同期できます。クラウドエンドポイント (Azure ファイル共有) を直接変更した場合、その変更は、Azure File Sync の変更検出ジョブによって最初に認識される必要があります。クラウドエンドポイントに対する変更検出ジョブは、24 時間に 1 回のみ起動されます。詳細については、「Azure Files についてよく寄せられる質問 (FAQ)」を参照してください。

クラウドエンドポイントを作成する管理者は、クラウドエンドポイントで参照されている Azure ファイル共有が含まれるストレージアカウントの所有者管理ロールのメンバーである必要があります。これは、Azure portal でストレージアカウントに対する [アクセス制御 (IAM)] で構成します。

同期グループを作成するには、Azure Portal でストレージ同期サービスに移動し、 [+ 同期グループ] を選びます。

Azure Portal で新しい同期グループを作成する

表示されるウィンドウで次の情報を入力して、同期グループとクラウドエンドポイントを作成します。

同期グループ名: 作成する同期グループの名前。この名前は、ストレージ同期サービス内で一意である必要がありますが、理にかなった任意の名前を指定できます。
サブスクリプション:「ストレージ同期サービスのデプロイ」でストレージ同期サービスをデプロイしたサブスクリプション。
ストレージアカウント: [ストレージアカウントの選択] を選んだ場合は、同期する Azure ファイル共有を持っているストレージアカウントを選択できる別のウィンドウが表示されます。
Azure ファイル共有: 同期する Azure ファイル共有の名前。

同期グループを作成するには、次の PowerShell を実行します。 <my-sync-group> は、同期グループの適切な名前に置き換えます。

$syncGroupName = "<my-sync-group>"
$syncGroup = New-AzStorageSyncGroup -ParentObject $storageSync -Name $syncGroupName

同期グループが正常に作成された後は、クラウドエンドポイントを作成できます。 <my-storage-account> と <my-file-share> は適切な値に置き換えてください。

# Get or create a storage account with desired name
$storageAccountName = "<my-storage-account>"
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroup | Where-Object {
    $_.StorageAccountName -eq $storageAccountName
}

if ($storageAccount -eq $null) {
    $storageAccount = New-AzStorageAccount `
        -Name $storageAccountName `
        -ResourceGroupName $resourceGroup `
        -Location $region `
        -SkuName Standard_LRS `
        -Kind StorageV2 `
        -EnableHttpsTrafficOnly:$true
}

# Get or create an Azure file share within the desired storage account
$fileShareName = "<my-file-share>"
$fileShare = Get-AzStorageShare -Context $storageAccount.Context | Where-Object {
    $_.Name -eq $fileShareName -and $_.IsSnapshot -eq $false
}

if ($fileShare -eq $null) {
    $fileShare = New-AzStorageShare -Context $storageAccount.Context -Name $fileShareName
}

# Create the cloud endpoint
New-AzStorageSyncCloudEndpoint `
    -Name $fileShare.Name `
    -ParentObject $syncGroup `
    -StorageAccountResourceId $storageAccount.Id `
    -AzureFileShareName $fileShare.Name

az storagesync sync-group コマンドを使用して、新しい同期グループを作成します。すべての CLI コマンドでリソースグループを既定に設定するには、az configure を使用します。

az storagesync sync-group create --resource-group myResourceGroupName \
                                 --name myNewSyncGroupName \
                                 --storage-sync-service myStorageSyncServiceName \

az storagesync sync-group cloud-endpoint コマンドを使用して、新しいクラウドエンドポイントを作成します。

az storagesync sync-group cloud-endpoint create --resource-group myResourceGroup \
                                                --storage-sync-service myStorageSyncServiceName \
                                                --sync-group-name mySyncGroupName \
                                                --name myNewCloudEndpointName \
                                                --storage-account mystorageaccountname \
                                                --azure-file-share-name azure-file-share-name

サーバーエンドポイントを作成する

サーバーエンドポイントは、登録済みサーバー上の特定の場所を表します。たとえば、サーバーボリュームのフォルダーなどです。サーバーエンドポイントは、次の条件に従います。

サーバーエンドポイントは (マウントされた共有ではなく) 登録済みサーバー上のパスである必要があります。ネットワーク接続ストレージ (NAS) はサポートされていません。
サーバーエンドポイントがシステムボリューム上に存在してもかまいませんが、システムボリューム上のサーバーエンドポイントではクラウドを使った階層化を使用できません。
ボリューム上でサーバーエンドポイントを確立した後でパスまたはドライブ文字を変更することはサポートされていません。登録済みサーバーで最終的なパスを使用していることを確認します。
登録済みサーバーは、複数のサーバーエンドポイントをサポートできます。ただし、同期グループには、常に登録済みサーバーあたり 1 つのサーバーエンドポイントしか含めることができません。同期グループ内のその他のサーバーエンドポイントは、異なる登録済みサーバー上に存在する必要があります。

サーバーエンドポイントを追加するには、新しく作成した同期グループに移動します。 [サーバーエンドポイント] で、[+ サーバーエンドポイントの追加] を選びます。 [サーバーエンドポイントの追加] ブレードが開きます。次の情報を入力してサーバーエンドポイントを作成します。

[サーバーエンドポイントの追加] ブレードを示すスクリーンショット。

登録済みサーバー: サーバーエンドポイントを作成するサーバーまたはクラスターの名前。
パス: Azure ファイル共有に同期する Windows Server 上のパス。パスには、フォルダー (D:\Data など)、ボリュームルート (D:\ など)、またはボリュームマウントポイント (D:\Mount など) を指定できます。
クラウドの階層化: クラウドの階層化を有効または無効にするスイッチ。クラウドの階層化によって、使用頻度やアクセス頻度が低いファイルを Azure Files に階層化できます。クラウドを使った階層化を有効にする場合は、クールファイルを階層化するタイミングを Azure File Sync に知らせるために設定するポリシーとして、ボリュームの空き領域ポリシーおよび日付ポリシー の 2 つのポリシーがあります。
- ボリュームの空き領域: サーバーエンドポイントが配置されているボリュームに確保する空き領域のサイズ。たとえば、1 つだけのサーバーエンドポイントがあるボリュームでボリュームの空き領域を 50% に設定すると、データの約半量が Azure Files に階層化されます。クラウドの階層化が有効かどうかにかかわらず、Azure ファイル共有は、データの完全なコピーを常に同期グループ内に保持します。
- 日付ポリシー: 指定した日数アクセスされていない (これは読み書きされて) ファイルがクラウドに階層化されます。たとえば、アクセスされずに 15 日以上経過したファイルが通常はアーカイブファイルであることがわかった場合は、日付ポリシーを 15 日に設定します。
[初期同期]: 同期グループの最初のサーバーエンドポイントでのみ使用できます (1 つの同期グループに複数のサーバーエンドポイントを作成すると、セクションが [初期ダウンロード] に変化します)。 [初期同期] セクション内で、初期アップロードと初期ダウンロードのビヘイビアーを選択できます。
- 初回アップロード: Azure ファイル共有にサーバーが初めてデータをアップロードする方法を選べます。
  - 方法 1: このサーバーパスのコンテンツを Azure ファイル共有内のコンテンツとマージします。同じ名前とパスのファイルは、コンテンツが異なると競合が生じます。そのようなファイルは、両方のバージョンが互いに隣り合うように保存されます。サーバーパスまたは Azure ファイル共有が空の場合は、常にこのオプションを選択してください。
  - 方法 2: Azure ファイル共有内のファイルとフォルダーを、このサーバーのパスにあるコンテンツで強制的に上書きします。この方法では、ファイルの競合が回避されます。
  詳しくは、初期同期をご覧ください。
- 初回ダウンロード: Azure ファイル共有からサーバーに初めてデータをダウンロードする方法を選べます。この設定は、ファイルを含む Azure ファイル共有にサーバーが接続する場合に重要です。 "名前空間" は、ファイルとフォルダーの構造を表します (ファイルコンテンツは含みません)。 "階層化されたファイル" のファイルコンテンツは、ローカルアクセスまたはポリシーによってクラウドからサーバーに回収されます。
  - 方法 1: 最初に名前空間をダウンロードしておき、ローカルディスクの容量を上限としてファイルのコンテンツをリコールします。
  - 方法 2: 名前空間のみダウンロードします。ファイルのコンテンツは、実際にアクセスされた時点でリコールされます。
  - 方法 3: 階層化されたファイルを避けます。ファイルは、完全にダウンロードされてからサーバーに表示されます。
  詳しくは、初期ダウンロードをご覧ください。

サーバーエンドポイントを追加するには、 [作成] を選びます。 Azure ファイル共有と Windows Server でファイルの同期が維持されます。

Note

Azure Files Sync は、サーバーエンドポイントを作成する前に、Azure ファイル共有のスナップショットをバックアップとして取得します。このスナップショットを使用して、サーバーエンドポイントが作成される前の状態に共有を復元できます。スナップショットは、サーバーエンドポイント作成後に自動的に削除されることはないため、不要な場合は手動で削除できます。 Azure File Sync によって作成されたスナップショットを見つけるには、Azure ファイル共有のスナップショットを確認し、[イニシエーター] 列で AzureFileSync を確認します。

サーバーエンドポイントを作成するには、次の PowerShell コマンドを実行します。<your-server-endpoint-path> と <your-volume-free-space> は適切な値に置き換えてください。オプションの初期ダウンロードポリシーと初期アップロードポリシーの設定をチェックします。

$serverEndpointPath = "<your-server-endpoint-path>"
$cloudTieringDesired = $true
$volumeFreeSpacePercentage = <your-volume-free-space>
# Optional property. Choose from: [NamespaceOnly] default when cloud tiering is enabled. [NamespaceThenModifiedFiles] default when cloud tiering is disabled. [AvoidTieredFiles] only available when cloud tiering is disabled.
$initialDownloadPolicy = "NamespaceOnly"
$initialUploadPolicy = "Merge"
# Optional property. Choose from: [Merge] default for all new server endpoints. Content from the server and the cloud merge. This is the right choice if one location is empty or other server endpoints already exist in the sync group. [ServerAuthoritative] This is the right choice when you seeded the Azure file share (e.g. with Data Box) AND you are connecting the server location you seeded from. This enables you to catch up the Azure file share with the changes that happened on the local server since the seeding.

if ($cloudTieringDesired) {
    # Ensure endpoint path is not the system volume
    $directoryRoot = [System.IO.Directory]::GetDirectoryRoot($serverEndpointPath)
    $osVolume = "$($env:SystemDrive)\"
    if ($directoryRoot -eq $osVolume) {
        throw [System.Exception]::new("Cloud tiering cannot be enabled on the system volume")
    }

    # Create server endpoint
    New-AzStorageSyncServerEndpoint `
        -Name $registeredServer.FriendlyName `
        -SyncGroup $syncGroup `
        -ServerResourceId $registeredServer.ResourceId `
        -ServerLocalPath $serverEndpointPath `
        -CloudTiering `
        -VolumeFreeSpacePercent $volumeFreeSpacePercentage `
        -InitialDownloadPolicy $initialDownloadPolicy `
        -InitialUploadPolicy $initialUploadPolicy
} else {
    # Create server endpoint
    New-AzStorageSyncServerEndpoint `
        -Name $registeredServer.FriendlyName `
        -SyncGroup $syncGroup `
        -ServerResourceId $registeredServer.ResourceId `
        -ServerLocalPath $serverEndpointPath `
        -InitialDownloadPolicy $initialDownloadPolicy
}

新しいサーバーエンドポイントを作成するには、az storagesync sync-group server-endpoint コマンドを使用します。

# Create a new sync group server endpoint 
az storagesync sync-group server-endpoint create --resource-group myResourceGroupName \
                                                 --name myNewServerEndpointName
                                                 --registered-server-id 91beed22-7e9e-4bda-9313-fec96c286e0
                                                 --server-local-path d:\myPath
                                                 --storage-sync-service myStorageSyncServiceNAme
                                                 --sync-group-name mySyncGroupName

# Create a new sync group server endpoint with additional optional parameters
az storagesync sync-group server-endpoint create --resource-group myResourceGroupName \
                                                 --storage-sync-service myStorageSyncServiceName \
                                                 --sync-group-name mySyncGroupName \
                                                 --name myNewServerEndpointName \
                                                 --registered-server-id 91beed22-7e9e-4bda-9313-fec96c286e0 \
                                                 --server-local-path d:\myPath \
                                                 --cloud-tiering on \
                                                 --volume-free-space-percent 85 \
                                                 --tier-files-older-than-days 15 \
                                                 --initial-download-policy NamespaceOnly [OR] NamespaceThenModifiedFiles [OR] AvoidTieredFiles
                                                 --initial-upload-policy Merge [OR] ServerAuthoritative

オプション:ファイアウォールと仮想ネットワークの設定を構成する

ポータル

ファイアウォールと仮想ネットワークの設定で動作するように Azure File Sync を構成したい場合、次の手順を実行します:

Azure portal から、セキュリティを確保するストレージアカウントに移動します。
左側のメニューで [ネットワーク] を選択します。
[許可するアクセス元] の下で [選択されたネットワーク] を選択します。
ご利用のサーバーの IP または仮想ネットワークが、 [アドレスの範囲] セクションに一覧表示されていることを確認します。
[信頼された Microsoft サービスによるこのストレージアカウントに対するアクセスを許可します] チェックボックスがオンになっていることを確認します。
[Save](保存) を選択して設定を保存します。

オプション：以前のバージョンおよび VSS (ボリュームシャドウコピーサービス) を使用するセルフサービス復元

以前のバージョンとは、ボリュームのサーバー側 VSS スナップショットを利用してファイルの復元可能なバージョンを SMB クライアントに提供する、Windows の機能です。これにより、IT 管理者に復元を依頼しなくても、インフォメーションワーカーが直接利用できる強力なシナリオが実現します。これは一般に、セルフサービス復元と呼ばれます。

VSS スナップショットと以前のバージョンは、Azure File Sync からは独立して機能します。ただし、クラウドを使った階層化を互換モードに設定する必要があります。多くの Azure File Sync サーバーエンドポイントが、同じボリューム上に存在できます。クラウドを使った階層化を使用しているか使用する予定のサーバーエンドポイントが 1 つでもあるボリュームでは、次の PowerShell 呼び出しを実行する必要があります。

Import-Module '<SyncAgentInstallPath>\StorageSync.Management.ServerCmdlets.dll'
Enable-StorageSyncSelfServiceRestore [-DriveLetter] <string> [[-Force]]

ボリューム全体の VSS スナップショットが作成されます。既定では、スナップショットを保存する十分なスペースがある場合、特定のボリュームに対して最大で 64 のスナップショットを保持することができます。 VSS はこれを自動的に処理します。既定のスナップショットスケジュールでは、月曜日から金曜日まで、1 日に 2 つのスナップショットを作成します。このスケジュールは、Windows のスケジュールされたタスクを使用して構成できます。上記の PowerShell コマンドレットは、以下の 2 つのことを行います。

指定されたボリューム上の Azure File Sync のクラウドを使った階層化を以前のバージョンと互換性を持つように構成し、ファイルがサーバー上でクラウドに対して階層化されている場合でも、確実に以前のバージョンから復元できるようにします。
既定の VSS スケジュールを有効にします。後で変更することもできます。

Note

注意すべき重要な点が 2 つあります。

-Force パラメーターを使用し、かつ VSS が現在有効になっている場合、現在の VSS スナップショットスケジュールは上書きされ、既定のスケジュールで置き換えられます。コマンドレットを実行する前に、必ずカスタム構成を保存してください。
クラスターノード上でこのコマンドレットを使用している場合、クラスター内の他のすべてのノードでも実行する必要があります。

セルフサービス復元の互換性が有効かどうかを確認するには、次のコマンドレットを実行します。

Get-StorageSyncSelfServiceRestore [[-Driveletter] <string>]

これにより、サーバー上のすべてのボリュームと、そのそれぞれの、クラウドを使った階層化との互換性が維持される日数の一覧が表示されます。この日数は、ボリュームごとに可能な最大のスナップショット数と、既定のスナップショットスケジュールに基づいて自動的に計算されます。そのため既定では、インフォメーションワーカーに提示されている以前のバージョンはすべて、復元のために使用することができます。既定のスケジュールを、より多くのスナップショットを作成するように変更する場合も同様です。ただし、ボリュームで利用可能なスナップショットの中で、互換性が維持される日数の値よりも古いものが生じるようにスケジュールを変更した場合、ユーザーはその古いスナップショット (以前のバージョン) を使用して復元を行うことはできなくなります。

Note

セルフサービス復元を有効にすると、Azure ストレージの使用量と請求に影響があります。この影響は、現時点でサーバー上で階層化されているファイルだけに限定されます。この機能を有効にすると、以前のバージョン (VSS スナップショット) のエントリによって参照できる、クラウドで利用可能なファイルバージョンが必ず存在するようになります。

この機能を無効にすると、互換性が維持される日数が経過するまで、Azure ストレージの使用量は徐々に低下していきます。これを速める方法はありません。

ボリュームごとの既定の VSS スナップショット最大数 (64) とそれを作成する既定のスケジュールでは、インフォメーションワーカーが以前のバージョンから復元できる最大日数は 45 日間になります (ボリューム上でどれほどの VSS スナップショットを保存できるかによって異なります)。

ボリュームごとの VSS スナップショット最大数として 64 が適切な設定ではない場合、レジストリキーでその値を変更することができます。新しい制限値を有効にするには、既に有効にされている、以前のバージョンの互換性を有効にするためのコマンドレットを各ボリュームで再実行する必要があります。ボリュームごとの新しい VSS スナップショット最大数を反映するために、-Force フラグを使用します。これにより、互換性が維持される日数が新しく計算されます。この変更は、新しく階層化されたファイルでのみ有効になり、既に実行した VSS スケジュールへのカスタマイズはすべて上書きされます。

VSS スナップショットは、既定ではボリューム領域の最大 10% を消費できます。 VSS スナップショットに使用できるストレージの量を調整するには、vssadmin resize shadowstorage コマンドを使用します。

Azure File Sync には、世界各地に分散している企業向けに、ローカルユーザーがファイルにアクセスする前に、リモートリージョンのサーバーキャッシュを事前に設定しておくことができるモードがあります。このモードがサーバーエンドポイントで有効になっている場合、Azure ファイル共有で作成または変更されたファイルがこのサーバーによって呼び戻されます。

シナリオ

世界各地に分散しているある企業は、米国およびインドにブランチオフィスを構えています。新しいプロジェクトのために、朝 (米国時間)、情報担当者が新しいフォルダーとファイルを作成して、1 日中それに取り組みます。 Azure File Sync によって、フォルダーとファイルが Azure ファイル共有 (クラウドエンドポイント) に同期されます。インドにいるインフォメーションワーカーは、インドのタイムゾーンでプロジェクトの作業を続行します。彼らが朝に作業に取り掛かる際、インドにあるローカルの Azure File Sync 対応サーバーでは、インドチームが効率的にローカルキャッシュで作業できるように、これらの新しいファイルがローカルで利用できるようになっている必要があります。このモードを有効にすることで、オンデマンドの呼び戻しによる最初のファイルアクセスが遅くなることを回避し、Azure ファイル共有でファイルが変更または作成されるとすぐにサーバーによって事前にファイルが呼び戻されるようになります。

重要

ここまで詳細に Azure ファイル共有の変更をサーバー上で追跡すると、エグレストラフィックとAzure からの請求額が増加する可能性があります。サーバーに呼び戻されたファイルが実際にはローカルで必要でない場合、サーバーへの不要な呼び戻しは推奨されません。このモードは、クラウドの最近の変更をサーバー上のキャッシュに事前に保存しておくことで、そのサーバー上のファイルを使用しているユーザーやアプリケーションに良い影響を与えることがわかっている場合にのみ使用してください。

ポータル
PowerShell

Azure portal で、ストレージ同期サービスにアクセスし、適切な同期グループを選択して、Azure ファイル共有 (クラウドエンドポイント) で変更を詳細に追跡するサーバーエンドポイントを特定します。
[クラウドを使った階層化] セクションで、Azure ファイル共有のダウンロードトピックを探します。現在選択されているモードが表示され、それを変更して Azure ファイル共有の変更をより詳細に追跡し、サーバーに事前に呼び戻すことができます。

現在有効になっているサーバーエンドポイントにおける Azure ファイル共有のダウンロード動作と、それを変更するためのメニューを開くボタンを示す画像。

PowerShell で Set-AzStorageSyncServerEndpoint コマンドレットを使用することで、サーバーエンドポイントのプロパティを変更できます。

# Optional parameter. Default: "UpdateLocallyCachedFiles", alternative behavior: "DownloadNewAndModifiedFiles"
$recallBehavior = "DownloadNewAndModifiedFiles"

Set-AzStorageSyncServerEndpoint -InputObject <PSServerEndpoint> -LocalCacheMode $recallBehavior

オプション：サーバーエンドポイント上の QUIC 経由の SMB

Azure ファイル共有 (クラウドエンドポイント) は、クラウドまたはオンプレミスからの直接アクセスが可能な完全な SMB エンドポイントですが、クラウド側でファイル共有データへのアクセスを希望するお客様は、多くの場合、Azure VM でホストされている Windows Server インスタンスに Azure File Sync サーバーエンドポイントをデプロイします。 Azure ファイル共有に直接アクセスするのではなく、サーバーエンドポイントを追加する最も一般的な理由は、Azure ファイル共有で直接行われた変更が Azure File Sync によって検出されるまでに最大で 24 時間以上かかる場合があるのに対し、サーバーエンドポイントで行われた変更はほぼ直ちに検出され、他のすべてのサーバーエンドポイントとクラウドエンドポイントに同期されることです。

この構成は、ユーザーの大部分がリモートである環境では非常に一般的です。従来、パブリックインターネットを介して SMB を使用してファイル共有にアクセスすることは、Windows ファイルサーバーまたは Azure Files に直接ホストされているファイル共有の両方を含め、ほとんどの組織と ISP がポート 445 をブロックするため、困難な場合があります。この制限はプライベートエンドポイントと VPN で回避できますが、Windows Server 2022 Azure Edition には追加のアクセス戦略 (QUIC トランスポートプロトコル経由の SMB) が用意されています。

QUIC 経由の SMB は、ほとんどの組織と ISP が HTTPS トラフィックをサポートするために開いている、ポート 443 経由で通信されます。 QUIC 経由で SMB を使用すると、Windows 11 以上を使用するクライアントが Azure File Sync サーバーエンドポイントでホストされているファイル共有にアクセスするために必要なネットワークが大幅に簡素化されます。 Windows Server Azure Edition で QUIC 経由の SMB をセットアップして構成する方法の詳細については、Windows ファイルサーバーでの QUIC 経由の SMB に関するページを参照してください。

Azure File Sync でのオンボード

Azure File Sync での最初のオンボードで完全なファイル忠実性とアクセス制御リスト (ACL) を維持しながらダウンタイムをゼロにするための推奨手順を以下に示します。

ストレージ同期サービスをデプロイします。
同期グループを作成します。
完全なデータセットがあるサーバーに Azure File Sync エージェントをインストールします。
そのサーバーを登録し、共有にサーバーエンドポイントを作成します。
同期で、Azure ファイル共有 (クラウドエンドポイント) への完全アップロードを行います。
初期アップロードが完了したら、残りの各サーバーに Azure File Sync エージェントをインストールします。
残りの各サーバーに新しいファイル共有を作成します。
必要に応じて、クラウドの階層化ポリシーを使用して新しいファイル共有にサーバーエンドポイントを作成します。 (この手順では、初期セットアップに使用できる追加のストレージが必要です。)
Azure File Sync エージェントで、実際にデータ転送を行わずに完全な名前空間の迅速な復元を行います。完全な名前空間の同期後、同期エンジンは、サーバーエンドポイントのクラウドの階層化ポリシーに基づいてローカルディスク領域を満たします。
同期の完了を確認した後、必要に応じてトポロジをテストします。
ユーザーとアプリケーションをこの新しい共有にリダイレクトします。
必要に応じて、サーバー上の重複する共有を削除できます。

別途初期オンボーディング用のストレージがなく、既存の共有にアタッチしたい場合は、ストレージ同期サービスを使用してデータをアップロードする代わりに別のデータ転送ツールを使用して、Azure ファイル共有内のデータを事前シードすることができます。事前シードのアプローチが推奨されるのは、ダウンタイムを受け入れることができ、初期のオンボードプロセス中にサーバー共有上のデータが変更されないことを確実に保証できる場合のみです。

オンボードプロセス中にいずれのサーバー上のデータも変更されないようにします。
REST 経由での AzCopy または SMB (Robocopy など) で任意のデータ転送ツールを使用してサーバーデータを Azure ファイル共有に事前シードします。 Robocopy を使用する場合は、ドメイン ID は使用せず、ストレージアカウントのアクセスキーを使用して Azure ファイル共有をマウントする必要があります。 AzCopy を使用する場合は、必ず適切なスイッチを設定して、ACL タイムスタンプと属性を保持してください。
既存の共有を指している目的のサーバーエンドポイントで Azure File Sync トポロジを作成します。
同期によるすべてのエンドポイントでの調整プロセスを完了します。
調整が完了したら、変更のために共有を開くことができます。

現時点では、事前シード処理にはいくつかの制限があります。

同期トポロジが完全に稼働する前にサーバー上のデータを変更すると、サーバーエンドポイントで競合が発生することがあります。
クラウドエンドポイントを作成した後、Azure File Sync は、最初の同期を開始する前にクラウド内のファイルを検出するプロセスを実行します。このプロセスの完了にかかる時間は、ネットワークの速度、使用可能な帯域幅、ファイルとフォルダーの数などの要因によって異なります。プレビューリリースでの大まかな見積もりでは、検出プロセスは約 10 ファイル/秒で実行されます。そのため、データがクラウドに事前シードされる場合は、事前シード処理の実行が高速であっても、システムが完全に稼働するまでの全体的な時間が大幅に長くなることがあります。

DFS レプリケーション (DFS-R) のデプロイを Azure File Sync に移行する

DFS-R のデプロイを Azure File Sync に移行するには:

置き換える DFS-R トポロジを表すための同期グループを作成します。
移行する DFS-R トポロジの完全なデータセットがあるサーバーで開始します。そのサーバーに Azure File Sync をインストールします。
そのサーバーを登録し、移行する最初のサーバーのサーバーエンドポイントを作成します。クラウドを使った階層化を有効にしないでください。
すべてのデータが Azure ファイル共有 (クラウドエンドポイント) に同期されるようにします。
残りの各 DFS-R サーバーに、Azure File Sync エージェントをインストールします。
DFS-R を無効にします。
各 DFS-R サーバーにサーバーエンドポイントを作成します。クラウドを使った階層化を有効にしないでください。
同期の完了を確認した後、必要に応じてトポロジをテストします。
DFS-R の使用を終了します。
必要に応じて、任意のサーバーエンドポイントでクラウドを使った階層化を有効できるようになりました。

詳しくは、Azure File Sync と分散ファイルシステム (DFS) の相互運用に関するページをご覧ください。

次の方法で共有

Azure File Sync のデプロイ

前提条件

Azure File Sync で使用する Windows Server の準備

ストレージ同期サービスのデプロイ

Azure File Sync エージェントをインストールする

Windows Server をストレージ同期サービスに登録する

同期グループとクラウドエンドポイントを作成する

サーバーエンドポイントを作成する

オプション:ファイアウォールと仮想ネットワークの設定を構成する

ポータル

オプション：以前のバージョンおよび VSS (ボリュームシャドウコピーサービス) を使用するセルフサービス復元

シナリオ

オプション：サーバーエンドポイント上の QUIC 経由の SMB

Azure File Sync でのオンボード

DFS レプリケーション (DFS-R) のデプロイを Azure File Sync に移行する

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure File Sync のデプロイ

前提条件

Azure File Sync で使用する Windows Server の準備

ストレージ同期サービスのデプロイ

Azure File Sync エージェントをインストールする

Windows Server をストレージ同期サービスに登録する

同期グループとクラウド エンドポイントを作成する

サーバー エンドポイントを作成する

オプション:ファイアウォールと仮想ネットワークの設定を構成する

ポータル

オプション：以前のバージョンおよび VSS (ボリューム シャドウ コピー サービス) を使用するセルフサービス復元

オプション：新規および変更されたファイルを Azure ファイル共有から事前にリコールする

シナリオ

サーバー エンドポイントで Azure ファイル共有の変更内容を事前に呼び戻すよう有効にする

オプション：サーバー エンドポイント上の QUIC 経由の SMB

Azure File Sync でのオンボード

DFS レプリケーション (DFS-R) のデプロイを Azure File Sync に移行する

次のステップ

フィードバック

その他のリソース

同期グループとクラウドエンドポイントを作成する

サーバーエンドポイントを作成する

オプション：以前のバージョンおよび VSS (ボリュームシャドウコピーサービス) を使用するセルフサービス復元

サーバーエンドポイントで Azure ファイル共有の変更内容を事前に呼び戻すよう有効にする

オプション：サーバーエンドポイント上の QUIC 経由の SMB