Como usar Namespaces DFS com Arquivos do Azure

Aplica-se a: ✔️ partilhas de ficheiros SMB

Espaços de Nomes de Sistemas de Ficheiros Distribuídos, comumente referidos como Espaços de Nomes DFS ou DFS-N, são um papel de servidor Windows Server que simplifica a implementação e manutenção de partilhas de ficheiros SMB em produção. Os Namespaces DFS fornecem virtualização de namespace de armazenamento, por isso podes fornecer uma camada de indireção entre o caminho UNC da tua partilha de ficheiros e a partilha real de ficheiros. Os Namespaces DFS funcionam com compartilhamentos de arquivos SMB, independentes de onde esses compartilhamentos de arquivos estão hospedados. Pode usá-lo com partilhas SMB alojadas num Windows File Server on-premises com ou sem Azure File Sync, partilhas de ficheiros Azure diretamente, partilhas SMB alojadas no Azure NetApp Files ou outras ofertas de terceiros, e até com partilhas de ficheiros alojadas noutras clouds.

No seu cerne, os Namespaces DFS fornecem um mapeamento entre um caminho UNC fácil de usar, como \\contoso\shares\ProjectX, e o caminho UNC subjacente da partilha SMB, como \\Server01-Prod\ProjectX ou \\storageaccount.file.core.windows.net\projectx. Quando o utilizador final navega até à sua partilha de ficheiros, escreve o caminho UNC amigável, mas o seu cliente SMB acede ao caminho SMB subjacente do mapeamento. Também pode estender este conceito para assumir um nome de servidor de ficheiros existente, como \\MyServer\ProjectX. Você pode usar esse recurso para obter os seguintes cenários:

• Forneça um nome de prova de migração para um conjunto lógico de dados. Por exemplo, você pode mapear \\contoso\shares\Engineering para \\OldServer\Engineering. Quando concluir a sua migração para o Ficheiros do Azure, pode alterar o mapeamento para \\storageaccount.file.core.windows.net\engineering, de modo que, quando um utilizador final acede ao caminho UNC fácil de usar, seja redirecionado de forma fluida para o caminho de partilha de ficheiros do Azure.

• Estabeleça um nome comum para um conjunto lógico de dados distribuídos para múltiplos servidores em diferentes locais físicos, como através do Azure File Sync. Neste exemplo, um nome como \\contoso\shares\FileSyncExample é mapeado para múltiplos caminhos UNC como \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, e \\FileSyncServer3\ExampleShare. Quando o utilizador acede ao UNC intuitivo, obtém uma lista de possíveis caminhos UNC e escolhe o caminho mais próximo com base nas definições de site do Windows Server Active Directory (AD).

• Expanda um conjunto lógico de dados sobre limites de tamanho, IO ou outros limites de escala. Esta extensão é útil para diretórios de utilizadores, onde cada utilizador tem a sua própria pasta numa partilha, e para partilhas de scratch, onde os utilizadores têm espaço arbitrário para dados temporários. Com os Namespaces DFS, você costura várias pastas em um namespace coeso. Por exemplo, \\contoso\shares\UserShares\user1 mapeia para \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 mapeia para \\storageaccount.file.core.windows.net\user2e assim por diante.

Você pode ver um exemplo de como usar Namespaces DFS com sua implantação de Arquivos do Azure na visão geral do vídeo a seguir.

Se já tiver um espaço de nomes DFS implementado, não são necessários passos especiais para o usar com o Ficheiros do Azure e o File Sync. Se aceder ao seu partilha de ficheiros Azure a partir do local, aplicam-se as considerações normais de rede. Para mais informações, consulte as considerações de rede do Ficheiros do Azure.

Este artigo aborda as partes de uma implementação de Namespaces DFS que são específicas do Ficheiros do Azure. Para os conceitos subjacentes do Windows Server e o conjunto completo de procedimentos de espaços de nomes, consulte a visão geral dos Espaços de Nomes DFS e Implementação de Espaços de Nomes DFS.

Pré-requisitos

Para usar espaços de nomes DFS com Ficheiros do Azure e File Sync, precisa dos seguintes recursos:

• Um domínio do Ative Directory. Pode hospedar este domínio em qualquer lugar, como on-premises, numa máquina virtual Azure (VM) ou noutra cloud.

• Um servidor membro do Windows Server associado a um domínio com a função de servidor DFS Namespaces instalada. Os Espaços de Nomes DFS estão disponíveis em todas as versões suportadas do Windows Server.

  Importante

  Não alojes um namespace consolidado raiz num controlador de domínio do Active Directory. Assumir o nome de um servidor de ficheiros existente requer um servidor membro dedicado ou um cluster de failover do Windows Server.

• Uma partilha de ficheiros SMB alojada num ambiente unido ao domínio, como uma partilha de ficheiros Azure numa conta de armazenamento ligada ao domínio, ou uma partilha de ficheiros num Windows File Server ligado ao domínio com Azure File Sync. Para mais informações, consulte Autenticação baseada em identidade.

• Alcance da rede dos seus clientes para as partilhas de ficheiros SMB. Para obter mais informações, consulte Considerações de rede para acesso direto.

• Direitos de Administrador de Domínio, ou acesso delegado de escrita ao servicePrincipalName atributo das contas de computador afetadas. O procedimento de tomada de nome modifica os objetos do Active Directory e requer uma sessão elevada.

Instalar a função de servidor Espaços de Nomes DFS

Se já usas espaços de nomes DFS, salta este passo.

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

Para mais opções de instalação, consulte Instalar espaços de nomes DFS.

Escolha um tipo de namespace

Os espaços de nomes DFS fornecem dois tipos de espaços de nomes: baseados em domínio e autónomos. Para uma comparação completa, incluindo limites de escala, opções de disponibilidade e requisitos do Active Directory, consulte Escolher um tipo de namespace.

Para o Ficheiros do Azure, a escolha geralmente resume-se a uma única pergunta:

• Se precisar de preservar um nome de servidor de ficheiros local existente , como \\MyServer\share, escolha um namespace autónomo e use a consolidação raiz. Esta abordagem é recomendada quando migra partilhas de ficheiros para o Ficheiros do Azure, porque mantém os atalhos de documentos, links incorporados e caminhos UNC codificados a funcionar após a migração. O resto deste artigo foca-se neste cenário.
• Para qualquer outro cenário, escolha um namespace baseado em domínio.

Os espaços de nomes independentes têm contrapartidas a ter em conta no planeamento:

• Os metadados do espaço de nomes são armazenados no registo do servidor do espaço de nomes, não no Active Directory. Inclua a configuração do namespace na sua estratégia de backup do servidor.
• Não podes adicionar múltiplos servidores de namespace a um namespace autónomo para redundância. Para alta disponibilidade, aloje o namespace num cluster de failover do Windows Server.
• Os namespaces independentes suportam alvos de escala inferior ao dos namespaces baseados em domínio no modo Windows Server 2008.

O caminho que os teus utilizadores montam depende do tipo de namespace:

Se escolheste um namespace baseado em domínio, salta as fases de consolidação da raiz. O namespace e o procedimento de destino da pasta é o mesmo para ambos os tipos. Utilize Crie o namespace e adicione as partilhas de ficheiros do Azure com DomainV2 como tipo de namespace.

Assuma nomes de servidores existentes com consolidação raiz

Ao usar a consolidação de roots, um único servidor DFS Namespaces pode responder a múltiplos nomes de servidores de ficheiros e encaminhar pedidos para a partilha apropriada. Esta funcionalidade é especialmente útil para adotar o Ficheiros do Azure, porque:

• As partilhas de ficheiros do Azure não conseguem reutilizar nomes de servidores existentes no local.
• Acede às partilhas de ficheiros do Azure utilizando o nome de domínio completamente qualificado (FQDN) da conta de armazenamento. Por exemplo, para aceder à partilha share na conta storageaccountde armazenamento , use \\storageaccount.file.core.windows.net\share. Esse caminho pode ser confuso para os utilizadores finais que esperam um nome curto, como \\MyServer\share. O Ficheiros do Azure suporta nomes de domínio personalizados quando o nome da conta de armazenamento é o prefixo do domínio, mas sem espaços de nomes DFS, não pode usar um nome como \\MyServer.contoso.com\share.

Pode usar a consolidação de raízes apenas com namespaces independentes. Se já tens um namespace baseado em domínio para as tuas partilhas de ficheiros, não precisas de um namespace consolidado root.

Para tornar um namespace consolidado de raiz altamente disponível, aloje-o num cluster de failover. Para construir o cluster subjacente, veja Criar um cluster de failover. Se optar por esta abordagem, registe o alias no objeto de nome do cluster (CNO), não num nó individual.

O diagrama seguinte mostra uma implementação de consolidação de raízes altamente disponível. Um Balanceador de Carga do Azure encontra-se à frente de um cluster de failover do Windows Server de servidores de DFS Namespaces que alojam os espaços de nomes consolidados de raiz, pelo que os clientes continuam a aceder aos nomes dos servidores de ficheiros desativados depois de as respetivas partilhas serem migradas para o Ficheiros do Azure.

Adotar o nome de um servidor existente é uma mudança de transição, não uma alteração incremental. Complete as seguintes fases por ordem:

1. Ative a consolidação de raízes no servidor de Espaços de Nomes DFS.
2. Crie o namespace e adicione as suas partilhas de ficheiros no Azure, usando um namespace chamado #<old-server-name>.
3. Transfira o nome do servidor e os nomes principais de serviço do servidor de ficheiros de origem.
4. Crie entradas DNS para nomes de servidores de ficheiros existentes.
5. Verifique a apropriação do nome.

Permitir a consolidação das raízes

A partir de uma sessão PowerShell elevada no servidor de namespace, defina os seguintes valores do registo e depois reinicie o serviço DFS Namespaces. O serviço lê estes valores apenas no arranque; até reiniciar, não pode criar um namespace cujo nome comece por #.

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"

Num cluster de failover, define os valores do registo em cada nó e depois falha o papel de namespace clusterizado para que cada nó reinicie o serviço.

Crie o namespace e adicione as suas partilhas de ficheiros no Azure

A unidade básica de gestão para espaços de nomes DFS é o espaço de nomes, cuja raiz é o ponto de partida da árvore. Em \\contoso.com\Public\, a raiz do espaço de nomes é Public. Dentro de um namespace, pastas com alvos de pasta apontam para as partilhas de ficheiros SMB que contêm o seu conteúdo, e pastas sem alvos de pasta acrescentam estrutura e hierarquia.

Para os procedimentos gerais do Windows Server, veja Criar um namespace DFS, Criar uma pasta num namespace DFS e Adicionar alvos de pasta. Quando tiver como destino partilhas de ficheiros do Azure, tenha em mente os seguintes pontos:

• Usa a conta de armazenamento FQDN para o destino da pasta. Apontar os destinos das pastas para \\<storage-account>.file.core.windows.net\<share>. O Ficheiros do Azure também suporta nomes de domínio personalizados quando o nome da conta de armazenamento é o prefixo do domínio, mas utilizar um desses nomes para o destino de uma pasta adiciona uma segunda dependência de DNS e de Kerberos subjacente a cada referência. Usa o FQDN a menos que já dependas de nomes de domínio personalizados.
• Espere um aviso de conectividade no DFS Management. Quando adicionas um destino de pasta para uma partilha de ficheiros do Azure, a consola pode reportar que storageaccount.file.core.windows.net não pode ser contactado. Este aviso é esperado. Selecione Sim para continuar.
• Os namespaces de consolidação de raízes precisam de um # prefixo. O nome do namespace deve corresponder ao servidor que está a substituir, precedido por #. Para assumir um servidor chamado MyServer, crie um namespace chamado #MyServer. O exemplo do PowerShell adiciona automaticamente o prefixo. A consola de Gestão de DFS não o faz, por isso escreva-o manualmente.
• Os nomes das pastas devem corresponder aos nomes antigos das partilhas. Um cliente que abre \\MyServer\Finance é servido pela pasta Finance no #MyServer namespace, por isso os nomes das pastas devem corresponder exatamente aos nomes de partilha do servidor de origem.

# 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"

Confirme que o namespace se resolve através do próprio nome do servidor antes de continuar. O nome antigo do servidor ainda não funciona; começa a funcionar depois das duas fases seguintes.

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

Se o caminho não se resolver, verifique se o cliente consegue aceder diretamente à partilha de ficheiros do Azure em \\<storage-account>.file.core.windows.net\<share>. Os espaços de nomes DFS limitam-se a devolver uma referenciação, pelo que qualquer problema de rede ou autenticação com a partilha subjacente se manifesta aqui. Para obter mais informações, consulte Considerações de rede para acesso direto.

Transferir o nome do servidor e os nomes principais do serviço

A consolidação de raízes permite que o servidor DFS Namespaces responda ao nome do antigo servidor de ficheiros, mas duas outras coisas devem ser verdadeiras antes de um cliente poder autenticar-se com esse nome:

• O servidor SMB no servidor de espaço de nomes deve aceitar uma ligação feita a um nome diferente do seu próprio nome de computador.
• O Kerberos deve resolver cifs/MyServer para a conta que atende o pedido. Se esse nome principal de serviço (SPN) ainda estiver registado na conta informática do servidor de ficheiros desativado, os clientes recebem um ticket pela conta errada. A ligação falha depois com "O nome da conta de destino está incorreto" ou reverte silenciosamente para NTLM.

O netdom computername comando trata de ambos os requisitos. Regista o nome antigo como um nome alternativo do computador no servidor de espaço de nomes, o que adiciona o nome ao atributo msDS-AdditionalDnsHostName do servidor e regista os SPNs HOST/<alias> correspondentes. Um SPN HOST abrange implicitamente um conjunto de classes de serviço que inclui cifs, pelo que um pedido de um cliente para cifs/MyServer é resolvido para a conta do servidor do namespace. Para a lista completa de classes de serviço, veja setspn.

Não substitua um registo criado manualmente setspn por netdom. Registar-se cifs/MyServer na conta do servidor de namespace configura o Kerberos mas não o servidor SMB, e o serviço de diretório rejeita SPNs que não sejam derivados dos nomes da conta alvo. Para mais informações, consulte O acesso à partilha de ficheiros SMB do servidor falha através do alias DNS CNAME.

1. Desliga o servidor de ficheiros de origem. O servidor de origem e o servidor de Namespaces DFS não podem ambos responder ao mesmo nome. Desligue o servidor em vez de o remover do domínio.

2. Desative a conta do computador de origem. No Utilizadores e Computadores do Active Directory, clique com o botão direito no objeto computador e selecione Desativar Conta. Para fazer o mesmo a partir do PowerShell numa máquina com o módulo Active Directory instalado, execute:

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

3. Remova os SPNs da conta do computador de origem. Desabilitar uma conta não remove os seus SPNs. Registos deixados na conta antiga bloqueiam o próximo passo, porque o mesmo nome não pode ser registado em duas contas. SPNs duplicados são uma causa documentada de KDC_ERR_PRINCIPAL_NOT_UNIQUE. Para mais informações, consulte Kerberos gera o erro KDC_ERR_S_PRINCIPAL_UNKNOWN ou KDC_ERR_PRINCIPAL_NOT_UNIQUE. Liste o que está registado e, em seguida, elimine as entradas HOST e cifs:

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

   Apague quaisquer entradas explícitas cifs/ da mesma forma. Se setspn -L mostrar outras classes de serviço como TERMSRV ou MSSQLSvc, o nome antigo ainda serve algo que não seja SMB. Resolve essa dependência antes de continuares.

4. Adicione o nome antigo como nome alternativo de computador no servidor de espaço de nomes. Execute netdom a partir de uma linha de comandos com privilégios elevados no servidor do espaço de nomes. Para um único servidor DFS Namespaces, especifique como destino a conta de computador desse servidor. Para um espaço de nomes autónomo clusterizado, direciona-se ao objeto nome do cluster (CNO), não às contas individuais dos nós. netdom vem com as ferramentas AD DS nas Ferramentas de Administração de Servidores Remotos; instala RSAT-AD-Tools se o comando não estiver disponível.

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

   Especifique ambos os nomes como domínios totalmente qualificados. netdom regista os SPNs HOST/MyServer e HOST/MyServer.contoso.com na conta de destino e adiciona o nome ao atributo msDS-AdditionalDnsHostName da conta, o que permite ao servidor SMB aceitar ligações feitas para o nome antigo.

   Verifique o resultado. O /verify switch verifica se existem um registo DNS e um SPN para cada nome registado:

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

   Se netdom indicar que o nome já está em uso, ele continua registado noutra parte da floresta. Localize o objeto em conflito antes de continuar:

   setspn -T contoso -F -Q */MyServer
   

   Se o único objeto devolvido for a conta do computador de origem que editaste na etapa anterior, a remoção ainda não foi replicada para o controlador de domínio que estás a consultar. Espera que a replicação converja, ou reexecute os comandos no emulador PDC.

Criar entradas DNS para nomes de servidores de ficheiros existentes

Para que os espaços de nomes DFS respondam aos nomes existentes dos servidores de ficheiros, crie-se registos de alias (CNAME) que apontem os nomes antigos dos servidores de ficheiros para o servidor de espaços de nomes DFS. O procedimento exato depende do servidor DNS que a sua organização utiliza. Os passos seguintes utilizam o servidor DNS incluído no Windows Server.

# 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

Verifique a apropriação do nome

Teste a partir de um cliente associado a um domínio, com sessão iniciada com uma conta de utilizador com permissões na partilha de ficheiros do Azure de destino. Não teste a partir do próprio servidor DFS Namespaces, porque uma ligação em loopback não usa o mesmo caminho de autenticação que um cliente remoto usa.

1. Confirme que o registo do nome alternativo foi replicado para todos os controladores de domínio. O centro de distribuição de chaves do cliente não é necessariamente o controlador de domínio que alteraste, e as réplicas do Active Directory não garantem ser consistentes em nenhum momento:

   $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")
       }
   }
   

   Se algum controlador de domínio reportar False, a replicação não está completa. Espere e verifique novamente antes de continuar, porque um cliente que se autentica através desse controlador de domínio continua a falhar.

2. Confirme que o nome antigo do servidor agora é resolvido para o servidor DFS Namespaces:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Abra a partilha através do nome antigo e confirme que vê o conteúdo da partilha de ficheiros do Azure:

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

4. Confirme que a sessão foi autenticada com o Kerberos em vez de recorrer ao NTLM verificando se foi emitido um bilhete para o nome antigo:

   klist
   

   Procure um ticket cujo campo do servidor seja igual a cifs/MyServer. A Kerberos emite este ticket contra a conta do servidor do namespace porque o HOST/MyServer registo cobre a cifs classe de serviço. Se não existir tal ticket, as causas mais comuns são que o registo do nome alternativo não foi replicado para o controlador de domínio que o cliente está a usar, que um registo foi deixado na conta desativada, ou que existe um duplicado noutro local da floresta.

Se as alterações ao DNS ou ao Kerberos não entrarem em vigor imediatamente, limpe as caches do lado do cliente e tente novamente:

ipconfig /flushdns
klist purge

Limpar as caches do cliente não ajuda se a alteração subjacente ainda não se replicou. Se uma nova tentativa continuar a falhar, volte a verificar a convergência da replicação no passo 1 antes de alterar mais alguma coisa.

Enumeração baseada em acesso (ABE)

A enumeração baseada em acesso esconde ficheiros e pastas que o utilizador não tem permissão para aceder. Nos espaços de nomes DFS, ativar o ABE num espaço de nomes aplica-se apenas às pastas DFS-N nesse espaço de nomes. Para controlar a enumeração do conteúdo de uma pasta-alvo, ative o ABE na própria partilha de ficheiros de destino. O ABE exige que todos os servidores de espaço de nomes corram o Windows Server 2008 ou posterior, e os espaços de nomes baseados em domínio devem usar o modo Windows Server 2008. Para mais detalhes, consulte Ativar enumeração baseada em acesso num namespace.

Como não podes ativar o ABE numa partilha de ficheiros do Azure, usar o ABE para controlar a visibilidade de ficheiros e pastas dentro de uma partilha de ficheiros SMB no Azure não é um cenário suportado. Esta limitação existe porque o DFS-N funciona através de referências, em vez de como um proxy à frente da pasta de destino. Quando um utilizador escreve \\mydfsnserver\share, o cliente SMB recebe a referência \\mydfsnserver\share => \\server123\share e monta esta última diretamente, pelo que o servidor DFS-N deixa de estar no caminho dos dados.

O ABE só funciona onde o servidor DFS-N hospeda o nível da hierarquia que queres filtrar, antes do redirecionamento. Ambos os layouts seguintes funcionam, porque os nomes das pastas por utilizador permanecem no namespace do servidor DFS-N:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, onde contosouser1 é uma subpasta da partilha users.

Se cada utilizador estiver numa subpasta após o redirecionamento, o ABE não funciona, porque as subpastas de cada utilizador nunca são enumeradas pelo servidor DFS-N:

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

Ver também

• Configurando o acesso ao compartilhamento de arquivos: autenticação baseada em identidade e considerações de rede para acesso direto.
• Visão geral dos espaços de nomes DFS
• Implantando namespaces DFS
• Escolha um tipo de namespace
• Netdom Computername
• setspn
• O acesso à partilha do servidor de ficheiros SMB falha através de um alias CNAME do DNS
• Criar um cluster de failover