如何将 DFS 命名空间与 Azure 文件配合使用

适用于： ✔️ SMB 文件共享

分布式文件系统命名空间，通常称为DFS命名空间或DFS-N，是Windows Server服务器中的一种角色，旨在简化生产环境中SMB文件共享的部署和维护。 DFS 命名空间提供存储命名空间虚拟化，因此你可以在文件共享的 UNC 路径和实际文件共享之间提供一层间接连接。 DFS 命名空间适用于 SMB 文件共享，与托管这些文件共享的位置无关。 可将其用于以下 SMB 共享：托管在本地 Windows 文件服务器上的共享（无论是否使用 Azure 文件同步）、Azure 文件共享、托管在其他第三方产品中的 SMB 文件共享，甚至托管在其他云中的文件共享。

DFS 命名空间的核心是提供用户友好的 UNC 路径（如 \\contoso\shares\ProjectX，）与 SMB 共享的底层 UNC 路径（如 \\Server01-Prod\ProjectX\\storageaccount.file.core.chinacloudapi.cn\projectx或 ）之间的映射。 当终端用户访问文件共享时，他们输入的是用户友好的 UNC 路径，但 SMB 客户端访问的是映射的底层 SMB 路径。 你也可以将此概念扩展为接管已有的文件服务器名称，例如 \\MyServer\ProjectX。 可以使用此功能来实现以下方案：

• 为一组逻辑数据集提供迁移证明名称。 例如，可以将 \\contoso\shares\Engineering 映射到 \\OldServer\Engineering。 完成迁移到 Azure 文件存储 后，你可以将映射改为 \\storageaccount.file.core.chinacloudapi.cn\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.chinacloudapi.cn\user1、 \\contoso\shares\UserShares\user2 映射到 \\storageaccount.file.core.chinacloudapi.cn\user2等。

如果你已经部署了 DFS 命名空间，则将其与 Azure 文件存储 和 File Sync 配合使用时无需执行任何特殊步骤。如果你从本地环境访问 Azure 文件共享，则适用常规的网络注意事项。 有关详细信息，请参阅 Azure 文件存储 网络注意事项。

本文介绍 DFS 命名空间部署中 Azure 文件存储 特有的部分。 关于 Windows Server 底层概念和完整的命名空间流程，请参见 DFS 命名空间概述和部署 DFS 命名空间。

先决条件

要使用 DFS 命名空间配合 Azure 文件存储 和 File Sync，你需要以下资源：

• Active Directory 域。 可以在任何位置（例如本地）或Azure虚拟机（VM）中托管此域。

• 一台已加入域的 Windows Server 成员服务器，并且已安装 DFS 命名空间服务器角色。 DFS 命名空间在所有受支持的 Windows Server 版本上都可用。

  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，选择独立 命名空间 并使用根整合。 这种方法建议在迁移文件共享到 Azure 文件存储 时使用，因为它能让文档快捷方式、嵌入链接和硬编码的 UNC 路径在迁移后依然正常工作。 本文的其余部分将聚焦于这一情景。
• 对于其他情况，选择 基于域的命名空间。

独立命名空间存在一些需要提前规划的取舍：

• 命名空间元数据存储在命名空间服务器的注册表中，而非 Active Directory。 将命名空间配置纳入服务器备份策略中。
• 你不能在一个独立命名空间中添加多个命名空间服务器以增加冗余。 为了高可用性，将命名空间托管在 Windows Server 故障转移集群上。
• 独立命名空间在 Windows Server 2008 模式下支持的目标规模低于基于域的命名空间。

用户挂载的路径取决于命名空间类型：

如果你选择了基于域名的命名空间，可以跳过根整合阶段。 命名空间和文件夹目标过程在两种类型中是相同的。 使用 DomainV2 作为命名空间类型 创建命名空间并添加 Azure 文件共享。

通过根路径合并接管现有的服务器名称

通过根整合，单个DFS命名空间服务器可以响应多个文件服务器名称，并将请求路由到相应的共享。 这一功能对于采用Azure 文件存储尤其有用，因为：

• Azure 文件共享不能重用现有的本地服务器名称。
• 你可以通过使用存储账户的完全限定域名（FQDN）来管理 Azure 文件共享。 例如，要访问存储账户storageaccount中的份额share，请使用\\storageaccount.file.core.chinacloudapi.cn\share。 这条路径对于期望简短名称（如 \\MyServer\share.）的终端用户来说可能会感到困惑。 当存储账户名称是域名前缀时，Azure 文件存储支持自定义域名，但没有DFS命名空间，你不能使用类似\\MyServer.contoso.com\share的名称。

你只能在独立命名空间中使用根整合。 如果你已经有基于域名的文件共享命名空间，就不需要根合并命名空间。

为了使根合并命名空间高度可用，将其托管在故障转移集群上。 要构建底层集群，请参见 创建故障转移集群。 如果你采用这种方法，应将别名注册为集群名称对象（CNO），而不是针对单个节点。

下图显示了一个高可用的根合并部署架构。 Azure 负载均衡器 在 Windows Server 故障转移集群前端，这些 DFS 命名空间服务器托管根合并命名空间，因此客户端在共享迁移到 Azure 文件存储 后仍能访问已退休的文件服务器名称。

接管现有服务器名称是切换，而非附加性更改。 按顺序完成以下阶段：

1. 在 DFS 命名空间服务器上启用根整合。
2. 创建命名空间，并添加你的 Azure 文件共享，使用名为 #<old-server-name>的命名空间。
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.chinacloudapi.cn\<share>。 Azure 文件存储 也支持自定义域名，前提是存储帐户名称用作域前缀；但将其用于文件夹目标时，会在每次转介背后额外增加一层对 DNS 和 Kerberos 的依赖。 除非你已经依赖自定义域名，否则建议使用FQDN。
• DFS 管理中会出现连接性警告。 当你为Azure文件共享添加文件夹目标时，控制台可能会报告storageaccount.file.core.chinacloudapi.cn无法联系。 此警告是在意料之内。 选择“是”继续。
• 根合并命名空间需要一个 # 前缀。 命名空间名称必须与你替换的服务器一致，前面加上 #。 要接管名为 MyServer的服务器，创建一个名为 #MyServer的命名空间。 PowerShell示例会为你添加前缀。 DFS 管理控制台不会自动填入，因此需要你手动输入。
• 文件夹名称必须与旧共享名称一致。 打开\\MyServer\Finance的客户端由命名空间中的#MyServer文件夹Finance服务，因此文件夹名称必须与源服务器的共享名称完全一致。

# 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.chinacloudapi.cn\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.chinacloudapi.cn\<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 是通过转介机制工作的，而不是在文件夹目标前充当代理。 当用户输入 \\mydfsnserver\share时，SMB 客户端会获得推荐 \\mydfsnserver\share => \\server123\share 并直接挂载后者，因此 DFS-N 服务器不再处于数据路径中。

ABE 仅在重定向发生之前由 DFS-N 服务器托管你想要筛选的层级时才有效。 以下两种布局都可行，因为每个用户文件夹的名称都存在于 DFS-N 服务器的命名空间中：

• \\DFSServer\users\contosouser1 => \\SA.file.core.chinacloudapi.cn\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.chinacloudapi.cn\users\contosouser1，其中 contosouser1 是共享的 users 子文件夹。

如果每个用户在重定向 后 都是一个子文件夹，ABE 就无法工作，因为每个用户文件夹从未被 DFS-N 服务器枚举：

• \\DFSServer\SomePath\users => \\SA.file.core.chinacloudapi.cn\users

另请参阅

• 配置文件共享访问： 基于标识的身份验证 和 直接访问的网络注意事项。
• DFS 命名空间概述
• 部署 DFS 命名空间
• 选择命名空间类型
• Netdom 计算机名称
• setspn
• 无法通过 DNS CNAME 别名访问 SMB 文件服务器共享
• 创建故障转移群集