如何搭配 Azure 檔案儲存體使用 DFS 命名空間

適用於： ✔️SMB 檔案共享

分散式檔案系統命名空間，通常稱為 DFS 命名空間或 DFS-N，是一種 Windows Server 伺服器角色，旨在簡化 SMB 檔案分享在生產環境中的部署與維護。 DFS 命名空間提供儲存命名空間虛擬化，因此你可以在檔案分享的 UNC 路徑與實際檔案共享之間提供一層間接的連結。 DFS 命名空間可以與 SMB 檔案共用搭配使用，而不考慮檔案共用所在的伺服器位置。 你可以用它來搭配本地 Windows 檔案伺服器上的 SMB 共享，無論是否支援 Azure 檔案同步）、直接使用 Azure 檔案分享、在 Azure NetApp Files 或其他第三方服務中託管的 SMB 檔案分享，甚至是其他雲端的檔案分享。

DFS 命名空間的核心功能是提供使用者易於理解的 UNC 路徑（例如 \\contoso\shares\ProjectX）與 SMB 共用的底層 UNC 路徑（例如 \\Server01-Prod\ProjectX 或 \\storageaccount.file.core.windows.net\projectx）之間的對應關係。 當終端使用者導覽到檔案分享時，他們會輸入使用者友善的 UNC 路徑，但其 SMB 用戶端會存取映射的底層 SMB 路徑。 你也可以將此概念擴展至接管現有的檔案伺服器名稱，例如 \\MyServer\ProjectX。 您可以使用這項功能來達成下列案例：

• 提供邏輯數據集的移轉證明名稱。 例如，您可以將 \\contoso\shares\Engineering 對應至 \\OldServer\Engineering。 當你完成遷移到 Azure 檔案儲存體 後，可以將映射改成 \\storageaccount.file.core.windows.net\engineering，這樣當終端使用者存取使用者友善的 UNC 路徑時，就能無縫地被導向到 Azure 檔案分享路徑。

• 為分布在不同實體站點的多台伺服器（例如透過 Azure 檔案同步）建立邏輯資料集的通用名稱。在此範例中，名稱 \\contoso\shares\FileSyncExample 映射至 多條 UNC 路徑，如 \\FileSyncServer1\ExampleShare、 \\FileSyncServer2\DifferentShareName、 \\FileSyncServer3\ExampleShare和 。 當使用者存取使用者友善的 UNC 時，會獲得可能的 UNC 路徑清單，並根據 Windows Server Active Directory（AD）網站定義選擇最接近的路徑。

• 跨大小、IO 或其他縮放閾值擴充一組邏輯數據集。 此擴充功能適用於使用者目錄，每個使用者在共享資料夾中都能擁有自己的資料夾，以及臨時共享，使用者可獲得任意空間存放暫存資料。 使用 DFS 命名空間時，您會將多個資料夾合併成一個一致命名空間。 例如， \\contoso\shares\UserShares\user1 對應至 \\storageaccount.file.core.windows.net\user1、 \\contoso\shares\UserShares\user2 對應至 \\storageaccount.file.core.windows.net\user2等。

您可以在下列影片概觀中看到如何使用 DFS 命名空間搭配 Azure 檔案服務部署的範例。

如果你已經有 DFS 命名空間，使用 Azure 檔案儲存體 和檔案同步不需要特別步驟。如果你從本地存取 Azure 檔案分享，則需遵守一般的網路考量。 如需詳細資訊，請參閱 Azure 檔案儲存體網路功能考量。

本文介紹了 DFS 命名空間部署中專屬於 Azure 檔案儲存體 的部分。 關於 Windows Server 底層概念及完整命名空間程序，請參見 DFS 命名空間概述與部署 DFS 命名空間。

先決條件

要使用 DFS 命名空間搭配 Azure 檔案儲存體 和 File Sync，你需要以下資源：

• Active Directory 網域。 你可以在任何地方託管這個網域，例如本地部署、Azure 虛擬機（VM）或其他雲端。

• 一台已加入網域且已安裝 DFS 命名空間伺服器角色的 Windows Server 成員伺服器。 所有支援的 Windows Server 版本都提供 DFS 命名空間。

  Important

  不要在 Active Directory 網域控制器上架設根合併命名空間。 接管現有檔案伺服器名稱需要專用成員伺服器或 Windows Server 故障轉移叢集。

• 在網域加入環境中託管的 SMB 檔案分享，例如網域加入儲存帳號中的 Azure 檔案分享，或是支援 Azure 檔案同步 的網域加入 Windows 檔案伺服器上的檔案分享。更多資訊請參見基於身份的認證。

• 從您的用戶端到 SMB 檔案共用的網路可達性。 如需詳細資訊，請參閱 直接存取的網路考慮。

• 網域管理員權限，或對受影響電腦帳戶的 servicePrincipalName 屬性具有委派寫入權限。 名稱接管程序會修改 Active Directory 物件，且需要已提升權限的工作階段。

安裝 DFS 命名空間伺服器角色

如果你已經在使用 DFS 命名空間，請跳過這個步驟。

Install-WindowsFeature -Name "FS-DFS-Namespace", "RSAT-DFS-Mgmt-Con"

欲了解更多安裝選項，請參閱 安裝 DFS 命名空間。

選擇命名空間類型

DFS 命名空間提供兩種命名空間類型： 基於網域 的命名空間與 獨立命名空間。 欲完整比較，包括擴展限制、可用性選項及 Active Directory 需求，請參閱「選擇命名空間類型」。

對於 Azure 檔案儲存體，選擇通常歸結為一個問題：

• 如果你需要保留現有的本地檔案伺服器名稱 ，例如 \\MyServer\share，請選擇 獨立命名空間 並使用 root consolidation。 當你將檔案分享遷移到 Azure 檔案儲存體 時，建議採用這種方法，因為它能讓文件捷徑、嵌入連結和硬編碼的 UNC 路徑在遷移後依然正常運作。 本文其餘部分將聚焦於此情境。
• 在任何其他情況下，請選擇以網域為基礎的命名空間。

獨立命名空間有一些需要事先規劃的取捨：

• 命名空間的元資料儲存在命名空間伺服器的登錄檔中，而非 Active Directory。 將命名空間配置納入你的伺服器備份策略中。
• 你不能為了冗餘而在獨立命名空間中加入多個命名空間伺服器。 為了高可用性，將命名空間架設在 Windows Server 故障轉移叢集上。
• 在 Windows Server 2008 模式下，獨立命名空間支援的目標數量少於網域型命名空間。

使用者掛載的路徑取決於命名空間類型：

如果你選擇了基於網域的命名空間，請跳過根整合階段。 命名空間與資料夾目標程序在兩種類型中相同。 使用建立命名空間並新增您的 Azure 檔案共用，並將 DomainV2 作為命名空間類型。

使用根整合接管現有伺服器名稱

透過根整合，單一 DFS 命名空間伺服器可以回應多個檔案伺服器名稱，並將請求路由至適當的共享。 這項功能對於採用 Azure 檔案儲存體 特別有用，因為：

• Azure 檔案分享無法重用現有的本地伺服器名稱。
• 你可以用儲存帳號的完全限定網域名稱（FQDN）來處理 Azure 檔案分享。 例如，若要存取儲存體帳戶 \\storageaccount.file.core.windows.net\share 中的共用 share，請使用 storageaccount。 這條路徑對於期待短名稱（如 \\MyServer\share）的終端使用者來說可能會感到困惑。 當儲存帳號名稱是網域前綴時，Azure 檔案儲存體 支援自訂網域名稱，但沒有 DFS 命名空間，你無法使用像 \\MyServer.contoso.com\share.

您只能將根目錄合併與獨立式命名空間搭配使用。 如果你已經有基於網域的檔案共享命名空間，就不需要根整合命名空間。

若要讓根合併命名空間具備高可用性，請將其託管於容錯移轉叢集上。 要建立底層叢集，請參見 建立故障轉移叢集。 如果你採用這種方法，請將別名註冊在叢集名稱物件（CNO）上，而非針對單一節點。

下列圖表顯示高可用性的根整併部署架構。 Azure Load Balancer 位於由 DFS 命名空間伺服器組成的 Windows Server 容錯移轉叢集前端，這些伺服器承載根彙總命名空間，因此在其共用移轉至 Azure 檔案儲存體 之後，用戶端仍可繼續存取已淘汰的檔案伺服器名稱。

接手現有伺服器名稱是切換，而非附加變更。 依序完成以下階段：

1. 啟用 DFS 命名空間伺服器上的根整合。
2. 建立命名空間，並使用名為 #<old-server-name>. 的命名空間新增你的 Azure 檔案分享。
3. 從來源檔案伺服器轉移伺服器名稱與服務主體名稱。
4. 為現有檔案伺服器名稱建立 DNS 條目。
5. 確認名稱遭占用

啟用根整合

在命名空間伺服器上，從已提升權限的 PowerShell 工作階段中設定下列登錄值，然後重新啟動 DFS Namespaces 服務。 服務只會在啟動時讀取這些值;在重新啟動之前，你無法建立名稱以 為開頭 #的命名空間。

New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Type Registry `
    -ErrorAction SilentlyContinue
Set-ItemProperty `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Name "ServerConsolidationRetry" `
    -Type DWord `
    -Value 1

Restart-Service -Name "Dfs"

在故障轉移叢集中，先設定每個節點的登錄檔值，然後讓叢集命名空間角色失敗，讓每個節點重新啟動服務。

建立命名空間並新增你的 Azure 檔案分享

DFS 命名空間的基本管理單位是 命名空間，其根節點即為樹的起點。 在 \\contoso.com\Public\中，命名空間根為 Public。 在命名空間中，有資料夾目標的 資料夾 指向存放你內容的 SMB 檔案共享，而沒有資料夾目標的資料夾則增加結構和階層結構。

關於一般的 Windows Server 程序，請參見「建立 DFS 命名空間」、「在 DFS 命名空間建立資料夾」以及「新增資料夾目標」。 當你鎖定 Azure 檔案分享時，請留意以下幾點：

• 使用儲存帳號 FQDN 作為資料夾目標。 將資料夾目標指向 \\<storage-account>.file.core.windows.net\<share>。 Azure 檔案儲存體 也支援自訂網域名稱，前提是儲存體帳戶名稱為網域前綴；但若將其用於資料夾目標，則會在每個轉介背後增加第二個 DNS 和 Kerberos 相依性。 除非你已經依賴自訂網域名稱，否則建議使用 FQDN。
• 預期 DFS 管理系統會顯示連線警告。 當你為 Azure 檔案分享新增資料夾目標時，主控台可能會回報storageaccount.file.core.windows.net無法聯絡。 這是預期的警告。 選取是 以繼續。
• 根整合命名空間需要一個 # 前綴。 命名空間名稱必須與你要替換的伺服器相符，且前綴 #。 若要接管名為 MyServer的伺服器，建立一個名為 #MyServer的命名空間。 PowerShell 範例會幫你加上前綴。 DFS 管理主控台不會自動顯示，因此請自行輸入。
• 資料夾名稱必須與舊的共享名稱相符。 開啟 \\MyServer\Finance 的用戶端會由 Finance 命名空間中的 #MyServer 資料夾提供服務，因此資料夾名稱必須與來源伺服器的共用名稱完全一致。

# Variables
$namespace = "MyServer"                   # Namespace root name. For root consolidation, use the
                                          # name of the file server you're replacing.
$type = "Standalone"                      # "Standalone" for a stand-alone namespace, or "DomainV2"
                                          # for a domain-based namespace (Windows Server 2008 mode).
$takeOverName = $true                     # Set to $false if you aren't using root consolidation.
$shareName = "Finance"                    # Folder name within the namespace. For root consolidation,
                                          # match the share name on the source file server exactly.
$targetUNC = "\\storageaccount.file.core.windows.net\finance"

# Root consolidation namespaces must be prefixed with "#".
if ($takeOverName -and $type -eq "Standalone" -and $namespace -notlike "#*") {
    $namespace = "#$namespace"
}

$dfsnServer = $env:ComputerName
$namespaceServer = if ($type -like "Domain*") {
    Get-CimInstance -ClassName "Win32_ComputerSystem" | `
        Select-Object -ExpandProperty Domain
} else { $dfsnServer }

# Create the SMB share that backs the namespace root. Read-only access matches the DFS Management
# default, because this share serves referrals rather than data.
$smbSharePath = "C:\DFSRoots\$namespace"
if (!(Test-Path -Path $smbSharePath)) {
    New-Item -Path $smbSharePath -ItemType Directory | Out-Null
}
New-SmbShare -Name $namespace -Path $smbSharePath -ReadAccess "Everyone"

# Create the namespace root.
Import-Module -Name DFSN
$namespacePath = "\\$namespaceServer\$namespace"
New-DfsnRoot -Path $namespacePath -TargetPath "\\$dfsnServer\$namespace" -Type $type

# Create the folder and point it at the Azure file share.
New-DfsnFolder -Path "$namespacePath\$shareName" -TargetPath $targetUNC

# Verify the namespace root and folder target.
Get-DfsnRoot -Path $namespacePath
Get-DfsnFolderTarget -Path "$namespacePath\$shareName"

在繼續之前，請確認命名空間可透過命名空間伺服器本身的名稱解析。 舊的伺服器名稱目前尚未生效；它會在接下來兩個階段完成後開始生效。

Test-Path -Path "\\CloudDFSN\#MyServer\Finance"

如果路徑無法解析，請確認用戶端能直接存取Azure檔案共享。\\<storage-account>.file.core.windows.net\<share> DFS 命名空間只會回傳轉介，因此基礎共用上的任何網路或驗證問題都會在這裡顯現出來。 如需詳細資訊，請參閱 直接存取的網路考慮。

轉移伺服器名稱與服務主體名稱

根整合讓 DFS 命名空間伺服器能回應舊檔案伺服器的名稱，但在用戶端能認證該名稱之前，還有兩件事必須成立：

• 命名空間伺服器上的 SMB 伺服器必須接受使用其本身電腦名稱以外的名稱所建立的連線。
• Kerberos 必須將 cifs/MyServer 解析為處理該要求的帳戶。 如果該服務主體名稱（SPN）仍註冊在已除役檔案伺服器的電腦帳戶上，用戶端就會取得發給錯誤帳戶的票證。 接著連線會失敗，顯示「目標帳號名稱錯誤」或默默回退到 NTLM。

netdom computername 指令可同時滿足這兩項需求。 它會將舊名稱註冊為命名空間伺服器上的替代電腦名稱，該名稱會加入伺服器 msDS-AdditionalDnsHostName 屬性，並註冊匹配 HOST/<alias> 的 SPN。 HOST SPN 隱含涵蓋一組服務類別，其中包括 cifs，因此用戶端對 cifs/MyServer 的請求會解析為命名空間伺服器的帳戶。 完整服務類別列表請參見 setspn。

不要用手動建立的 setspn 註冊來取代 netdom。 在命名空間伺服器的帳戶上註冊 cifs/MyServer 會設定 Kerberos，但不會設定 SMB 伺服器，而且目錄服務會拒絕不是由目標帳戶本身名稱衍生而來的 SPN。 如需更多資訊，請參閱 透過 DNS CNAME 別名存取 SMB 檔案伺服器共用失敗。

1. 關閉原始檔案伺服器。 來源伺服器和 DFS 命名空間伺服器不可能同時回應同一個名稱。 關閉伺服器電源，而不是把它從網域中移除。

2. 停用來源電腦帳號。 在 Active Directory 使用者和電腦 中，右鍵點擊電腦物件並選擇停用帳號。 若要在安裝 Active Directory 模組的機器上使用 PowerShell 執行相同操作：

   $oldServer = "MyServer"
   Disable-ADAccount -Identity ($oldServer + '$')
   

3. 從來源電腦帳號移除 SPN。 停用帳號不會移除它的 SPN。 仍留在舊帳號中的註冊資料會阻礙進行下一步，因為同一名稱不能同時註冊到兩個帳號下。 重複的 SPN 是造成 KDC_ERR_PRINCIPAL_NOT_UNIQUE 的已知原因之一。 更多資訊請參見 Kerberos 產生 KDC_ERR_S_PRINCIPAL_UNKNOWN 或 KDC_ERR_PRINCIPAL_NOT_UNIQUE 錯誤。 列出已登記的項目，然後刪除 HOST 與 cifs 條目：

   setspn -L MyServer
   setspn -D HOST/MyServer MyServer
   setspn -D HOST/MyServer.contoso.com MyServer
   

   以相同方式刪除任何明確標示為 cifs/ 的條目。 如果 setspn -L 顯示其他服務類別，如 TERMSRV 或 MSSQLSvc，舊名稱仍服務非中小企業。 在繼續之前，先解決這種依賴。

4. 在命名空間伺服器上將舊名稱新增為替代電腦名稱。 在命名空間伺服器上，從提升權限的命令提示字元執行 netdom。 對於單一 DFS 命名空間伺服器，請將目標設為該伺服器的電腦帳戶。 對於叢集獨立命名空間，應鎖定叢集名稱物件（CNO），而非個別節點帳號。 netdom 隨附於遠端伺服器管理工具中的 AD DS 工具；如果無法使用該命令，請安裝 RSAT-AD-Tools。

   netdom computername CloudDFSN.contoso.com /add:MyServer.contoso.com
   

   請將兩個名稱指定為完全合格的網域名稱。 netdom 在目標帳號上註冊 HOST/MyServer 和 HOST/MyServer.contoso.com SPN，並將該名稱加入帳號的 msDS-AdditionalDnsHostName 屬性，使 SMB 伺服器能接受使用舊名稱建立的連線。

   驗證結果。 交換器 /verify 會檢查每個註冊名稱是否存在 DNS 記錄和 SPN：

   netdom computername CloudDFSN.contoso.com /enumerate:AlternateNames
   netdom computername CloudDFSN.contoso.com /verify
   

   如果 netdom 回報該名稱已在使用中，表示該名稱仍註冊於樹系中的其他位置。 在繼續之前，先找出衝突的物件：

   setspn -T contoso -F -Q */MyServer
   

   如果唯一回傳的物件是你在前一步編輯的來源電腦帳號，那移除還沒複製到你查詢的網域控制器。 等待複寫收斂，或針對 PDC 模擬器重新執行命令。

為現有檔案伺服器名稱建立 DNS 條目

為了讓 DFS 命名空間回應現有的檔案伺服器名稱，請建立別名（CNAME）紀錄，將舊檔案伺服器名稱指向 DFS 命名空間伺服器。 具體流程取決於你組織使用的 DNS 伺服器。 以下步驟使用隨 Windows Server 附帶的 DNS 伺服器。

# Variables
$oldServer = "MyServer"
$dfsnServer = "CloudDFSN"
$domain = Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain

# Create CNAME record
Import-Module -Name DnsServer
Add-DnsServerResourceRecordCName `
    -Name $oldServer `
    -HostNameAlias "$dfsnServer.$domain" `
    -ZoneName $domain

確認名稱接管

從已加入網域的用戶端進行測試，並以對目標 Azure 檔案共用具有權限的使用者身分登入。 不要直接從 DFS 命名空間伺服器本身測試，因為迴圈連線不會使用遠端用戶端使用的認證路徑。

1. 確認備用名稱註冊已複製到所有網域控制器。 客戶端的金鑰分發中心不一定是你更改的網域控制器，且 Active Directory 副本在任何時候都無法保證保持一致：

   $oldServer = "MyServer"
   $dfsnServer = "CloudDFSN"
   Get-ADDomainController -Filter * | ForEach-Object {
       $spns = (Get-ADComputer -Identity $dfsnServer -Properties servicePrincipalName `
           -Server $_.HostName).servicePrincipalName
       [pscustomobject]@{
           DomainController = $_.HostName
           HasHostSpn       = [bool]($spns -contains "HOST/$oldServer")
       }
   }
   

   如果有任何網域控制器回報 False，複寫還沒完成。 請等一等再檢查，因為透過該網域控制器認證的客戶端仍然會失敗。

2. 確認舊伺服器名稱現在已解析為 DFS 命名空間伺服器：

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. 透過舊名稱開啟分享，確認你看到的是 Azure 檔案分享的內容：

   Test-Path -Path "\\MyServer\Finance"
   Get-ChildItem -Path "\\MyServer\Finance"
   

4. 確認該工作階段是使用 Kerberos 完成驗證，而非回退為 NTLM；方法是檢查是否已針對舊名稱簽發票證：

   klist
   

   尋找伺服器欄位為 cifs/MyServer 的工單。 Kerberos 會針對命名空間伺服器的帳戶簽發此票證，因為 HOST/MyServer 註冊涵蓋了 cifs 服務類別。 如果沒有這樣的票證，最常見的原因包括：替代名稱的註冊資訊尚未複寫到用戶端正在使用的網域控制器、停用的帳戶上仍留有該註冊資訊，或是樹系中的其他位置存在重複的註冊。

如果 DNS 或 Kerberos 的變更沒有立即生效，請清除用戶端快取並重試：

ipconfig /flushdns
klist purge

如果底層變更還沒複製，清除客戶端快取也沒用。 如果重試後仍然失敗，請先在步驟 1 重新檢查複寫收斂情況，再變更任何其他內容。

存取型列舉（ABE）

基於存取的列舉會隱藏使用者沒有權限存取的檔案和資料夾。 在 DFS 命名空間中，啟用 ABE 只適用於該命名空間中的 DFS-N 資料夾。 要控制資料夾目標內容的枚舉，請在目標檔案分享本身啟用 ABE。 ABE 要求所有命名空間伺服器必須執行 Windows Server 2008 或更新版本，而基於網域的命名空間必須使用 Windows Server 2008 模式。 詳情請參見 「啟用命名空間上的存取式列舉」。

因為您無法在 Azure 檔案共用上啟用 ABE，因此無法使用 ABE 來控制 SMB Azure 檔案共用內檔案和資料夾的可見度；這不是受支援的情境。 之所以有這項限制，是因為 DFS-N 是透過轉介機制運作，而不是作為位於資料夾目標前方的 Proxy。 當使用者輸入 \\mydfsnserver\share時，SMB 用戶端會取得 referral \\mydfsnserver\share => \\server123\share 並直接掛載 ，因此 DFS-N 伺服器不再在資料路徑中。

只有在重新導向之前，DFS-N 伺服器裝載了您想篩選的階層層級時，ABE 才會生效。 以下兩種配置皆可行，因為每位使用者的資料夾名稱都位於 DFS-N 伺服器的命名空間中：

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1，其中 contosouser1 是共享資料夾 users 的子資料夾。

如果每個使用者在重定向 後 都是一個子資料夾，ABE 就無法運作，因為每個使用者的資料夾不會被 DFS-N 伺服器列舉：

• \\DFSServer\SomePath\users => \\SA.file.core.windows.net\users

另請參閱

• 設定檔案共用存取：身分識別驗證 和 直接存取的網路因素。
• DFS 命名空間概述
• 部署 DFS 命名空間
• 選擇命名空間類型
• Netdom 電腦名稱
• setspn
• 透過 DNS CNAME 別名，SMB 檔案伺服器共享存取無法成功
• 建立容錯移轉叢集