Come usare i namespace DFS con File di Azure

Si applica a: ✔️ condivisioni file SMB

I Namespace dei File System Distribuiti, comunemente noti come DFS Namespace o DFS-N, sono un ruolo server di Windows Server che semplifica la distribuzione e la manutenzione delle condivisioni di file SMB in produzione. DFS Namespaces fornisce virtualizzazione di namespace di storage, così puoi fornire uno strato di indirezione tra il percorso UNC della tua condivisione file e la condivisione file reale. Gli spazi dei nomi DFS funzionano con le condivisioni file SMB, indipendentemente da dove sono ospitate. Puoi usarlo con le condivisioni SMB ospitate su un Windows File Server on-premises con o senza Sincronizzazione file di Azure, condivisioni file Azure direttamente, condivisioni file SMB ospitate in Azure NetApp Files o altre offerte di terze parti, e persino con condivisioni file ospitate in altri cloud.

Alla base, i Namespace DFS forniscono una mappatura tra un percorso UNC user-friendly, come \\contoso\shares\ProjectX, e il percorso UNC sottostante della condivisione SMB, come \\Server01-Prod\ProjectX o \\storageaccount.file.core.windows.net\projectx. Quando l'utente finale accede alla condivisione di file, digita il percorso UNC intuitivo, ma il client SMB accede al percorso SMB sottostante associato alla mappatura. Puoi anche estendere questo concetto per prendere il nome di un server file esistente, come \\MyServer\ProjectX. È possibile usare questa funzionalità per ottenere gli scenari seguenti:

• Specificare un nome resistente alla migrazione per un set logico di dati. Ad esempio, è possibile eseguire il mapping \\contoso\shares\Engineering a \\OldServer\Engineering. Quando completi la migrazione verso File di Azure, puoi cambiare la mappatura in \\storageaccount.file.core.windows.net\engineering, così che quando un utente finale accede al percorso UNC user-friendly, venga reindirizzato senza soluzione di continuità al percorso di condivisione file di Azure.

• Stabilire un nome comune per un insieme logico di dati distribuiti a più server in diversi siti fisici, ad esempio tramite Sincronizzazione file di Azure. In questo esempio, un nome come \\contoso\shares\FileSyncExample è mappato su più percorsi UNC come \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, e \\FileSyncServer3\ExampleShare. Quando l'utente accede all'UNC user-friendly, riceve una lista di possibili percorsi UNC e sceglie quello più vicino a essi in base alle definizioni del sito Windows Server Active Directory (AD).

• Estendere un set logico di dati tra dimensioni, I/O o altre soglie di scalabilità. Questa estensione è utile per le directory utente, dove ogni utente ha la propria cartella su una condivisione, e per le condivisioni scratch, dove gli utenti dispongono di spazio arbitrario per dati temporanei. Con gli spazi dei nomi DFS, è possibile unire più cartelle in uno spazio dei nomi coeso. Ad esempio, \\contoso\shares\UserShares\user1 esegue il mapping a \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 esegue il mapping a \\storageaccount.file.core.windows.net\user2e così via.

È possibile vedere un esempio di come usare i DFS Namespaces con l'implementazione di File di Azure nel seguente video.

Se hai già un Namespace DFS, non sono necessari passaggi particolari per usarlo con File di Azure e File Sync. Se accedi alla tua condivisione file Azure da on-premises, si applicano le normali considerazioni di rete. Per ulteriori informazioni, vedere considerazioni sulla rete di File di Azure.

Questo articolo tratta le parti di una distribuzione di Namespace DFS specifiche per File di Azure. Per i concetti sottostanti di Windows Server e l'insieme completo di procedure di namespace, vedi panoramica sugli spazi di nomi DFS e Implementazione degli spazi di nomi DFS.

Prerequisiti

Per utilizzare i namespace DFS con File di Azure e File Sync, hai bisogno delle seguenti risorse:

• Un dominio di Active Directory. Puoi ospitare questo dominio ovunque, ad esempio on-localies, in una macchina virtuale Azure (VM) o in un altro cloud.

• Un server membro di Windows Server collegato al dominio con il ruolo di server DFS Namespaces installato. Le namespace DFS sono disponibili su tutte le versioni supportate di Windows Server.

  Importante

  Non ospitare uno spazio di nomi consolidato root su un controller di dominio Active Directory. Prendere il controllo di un nome di file server esistente richiede un server membro dedicato o un cluster failover di Windows Server.

• Una condivisione file SMB ospitata in un ambiente unito al dominio, come una condivisione file Azure in un account di archiviazione connessa al dominio, o una condivisione file su un Windows File Server collegato al dominio con Sincronizzazione file di Azure. Per ulteriori informazioni, vedi Autenticazione basata sull'identità.

• La raggiungibilità della rete dai tuoi clienti alle condivisioni file SMB. Per altre informazioni, vedere Considerazioni sulla rete per l'accesso diretto.

• Diritti di Amministratore del Dominio, o accesso delegato alla scrittura all'attributo servicePrincipalName degli account informatici interessati. La procedura di presa di nome modifica gli oggetti Active Directory e richiede una sessione elevata.

Installare il ruolo server degli spazi dei nomi DFS

Se già usi i namespace DFS, salta questo passaggio.

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

Per ulteriori opzioni di installazione, consulta Installa namespace DFS.

Scegli un tipo di namespace

Gli spazi di nomi DFS offrono due tipi di namespace: basati su dominio e stand-alone. Per un confronto completo, inclusi limiti di scala, opzioni di disponibilità e requisiti di Active Directory, vedi Scegli un tipo di namespace.

Per File di Azure, la scelta di solito si riduce a una sola domanda:

• Se devi mantenere un nome di file server locale esistente, come \\MyServer\share, scegli uno spazio dei nomi stand-alone e usa il consolidamento della radice. Questo approccio è consigliato quando si migra le condivisioni file su File di Azure, perché mantiene funzionanti scorciatoie di documenti, link incorporati e percorsi UNC hardcodati dopo la migrazione. Il resto di questo articolo si concentra su questo scenario.
• Per qualsiasi altro scenario, scegli uno spazio di nomi basato su dominio.

Gli spazi di nomi stand-alone hanno compromessi da pianificare:

• I metadati dello spazio dei nomi sono memorizzati nel registro del server dello spazio dei nomi, non in Active Directory. Includi la configurazione del namespace nella strategia di backup del server.
• Non puoi aggiungere più server di namespace a uno spazio stand-alone per la ridondanza. Per un'alta disponibilità, ospita il namespace su un cluster di failover di Windows Server.
• Gli spazi di nomi autonomi supportano target di scala inferiore rispetto agli spazi di dominio in modalità Windows Server 2008.

Il percorso che i tuoi utenti montano dipende dal tipo di namespace:

Se scegli uno spazio di nomi basato su dominio, salta le fasi di consolidamento delle radici. La procedura di namespace e destinazione cartelle è la stessa per entrambi i tipi. Utilizza Crea il namespace e aggiungi le condivisioni file di Azure con DomainV2 come tipo di namespace.

Acquisire i nomi dei server esistenti con il consolidamento radice

Utilizzando la consolidazione root, un singolo server DFS Namespaces può rispondere a più nomi di server file e instradare le richieste alla condivisione appropriata. Questa funzionalità è particolarmente utile per l'adozione di File di Azure, perché:

• Le condivisioni file Azure non possono riutilizzare nomi server on-premises esistenti.
• Indirizzi le condivisioni file di Azure utilizzando il nome di dominio completo (FQDN) dell'account di archiviazione. Ad esempio, per accedere alla condivisione share nell'account storageaccountdi archiviazione, usa \\storageaccount.file.core.windows.net\share. Quel percorso può risultare confuso per gli utenti finali che si aspettano un nome breve, come \\MyServer\share. File di Azure supporta nomi di dominio personalizzati quando il nome dell'account di storage è il prefisso di dominio, ma senza i namespace DFS non puoi usare un nome come \\MyServer.contoso.com\share.

Puoi usare la consolidazione delle radici solo con namespace stand-alone. Se hai già un namespace basato sul dominio per le tue condivisioni di file, non hai bisogno di un namespace consolidato di livello radice.

Per rendere un namespace consolidato root altamente disponibile, ospitalo su un cluster di failover. Per costruire il cluster sottostante, vedi Creare un cluster di failover. Se adotti questo approccio, registra l'alias nell'oggetto nome cluster (CNO), non in un singolo nodo.

Il diagramma seguente mostra una distribuzione di consolidamento root ad alta disponibilità. Azure Load Balancer è posto davanti a un cluster di failover di Windows Server costituito da server di DFS Namespaces che ospitano i namespace radice consolidati, in modo che i client continuino a raggiungere i nomi dei file server dismessi dopo che le relative condivisioni sono state spostate in File di Azure.

Prendere il controllo di un nome server esistente è un cutover, non un cambiamento additivo. Completate le seguenti fasi in ordine:

1. Abilita la consolidazione delle radici sul server DFS Namespaces.
2. Crea il namespace e aggiungi le condivisioni file di Azure, usando un namespace denominato #<old-server-name>.
3. Trasferire il nome del server e i nomi del principale servizio dal file server sorgente.
4. Crea voci DNS per i nomi dei file server esistenti.
5. Verifica l'acquisizione del nome.

Abilita la consolidazione delle radici

Da una sessione PowerShell elevata sul server di namespace, imposta i seguenti valori del registro e poi riavvia il servizio DFS Namespaces. Il servizio legge questi valori solo all'avvio; finché non si riavvia, non puoi creare uno spazio di nomi il cui nome inizi con #.

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"

In un cluster di failover, imposta i valori del Registro di sistema in ogni nodo, quindi esegui il failover del ruolo namespace clusterizzato in modo che ogni nodo riavvii il servizio.

Crea il namespace e aggiungi le condivisioni di file di Azure

L'unità di gestione di base per gli spazi di nomi DFS è lo spazio di nomi, la cui radice è il punto di partenza dell'albero. In \\contoso.com\Public\, la radice dello spazio dei nomi è Public. All'interno di un namespace, le cartelle con destinazioni di cartella indirizzano alle condivisioni file SMB che contengono il contenuto, mentre le cartelle senza destinazioni di cartella aggiungono struttura e gerarchia.

Per le procedure generali di Windows Server, vedi Crea un namespace DFS, Crea una cartella in un namespace DFS e Aggiungi destinazioni di cartella. Quando specifichi le condivisioni file di Azure come destinazione, tieni presenti i seguenti punti:

• Usa l'account di archiviazione FQDN come target della cartella. Indirizza le cartelle di destinazione a \\<storage-account>.file.core.windows.net\<share>. File di Azure supporta anche nomi di dominio personalizzati quando il prefisso dell'account di archiviazione è il prefisso di dominio, ma usarne uno per un target di cartella aggiunge un secondo DNS e una seconda dipendenza di Kerberos dietro ogni riferimento. Usa la FQDN a meno che tu non dipenda già da nomi di dominio personalizzati.
• Aspettatevi un avviso di connettività in DFS Management. Quando aggiungi una cartella target per una condivisione file Azure, la console potrebbe segnalare che storageaccount.file.core.windows.net non può essere contattata. Questo avviso è previsto. Selezionare Sì per continuare.
• I namespace di consolidamento radice richiedono un prefisso #. Il nome dello spazio dei nomi deve corrispondere al server che stai sostituendo, preceduto da #. Per prendere il controllo di un server chiamato MyServer, crea uno spazio di nomi chiamato #MyServer. L'esempio in PowerShell aggiunge automaticamente il prefisso. La console Gestione DFS non lo fa, quindi devi digitarlo manualmente.
• I nomi delle cartelle devono corrispondere ai vecchi nomi delle condivisioni. Un client che apre \\MyServer\Finance è servito dalla cartella Finance nello spazio dei nomi #MyServer, quindi i nomi delle cartelle devono corrispondere esattamente ai nomi delle condivisioni del server di origine.

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

Conferma che il namespace si risolva tramite il nome stesso del server di namespace prima di continuare. Il vecchio nome del server non funziona ancora; inizia a funzionare dopo i due livelli successivi.

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

Se il percorso non si risolve, verifica che il client possa raggiungere direttamente la condivisione file Azure a \\<storage-account>.file.core.windows.net\<share>. DFS Namespaces restituisce solo un referral, quindi qui emergono eventuali problemi di rete o autenticazione con la condivisione sottostante. Per altre informazioni, vedere Considerazioni sulla rete per l'accesso diretto.

Trasferire il nome del server e i nomi dell'entità servizio

La consolidazione delle radici permette al server DFS Namespaces di rispondere al nome del vecchio file server, ma altre due cose devono essere vere prima che un client possa autenticarsi con quel nome:

• Il server SMB sul server dello spazio dei nomi deve accettare una connessione effettuata a un nome diverso dal proprio nome del computer.
• Kerberos deve risolvere cifs/MyServer nell'account che gestisce la richiesta. Se quel Service Principal Name (SPN) è ancora registrato nell'account del computer del file server dismesso, i client ricevono un ticket per l'account sbagliato. La connessione poi fallisce con "Il nome dell'account target è errato" oppure torna silenziosamente a NTLM.

Il netdom computername comando gestisce entrambi i requisiti. Registra il vecchio nome come nome alternativo del computer sul server dello spazio dei nomi, che aggiunge il nome all'attributo msDS-AdditionalDnsHostName del server e registra gli SPN corrispondenti HOST/<alias> . Un HOST SPN copre implicitamente un insieme di classi di servizio che include cifs, quindi una richiesta client per cifs/MyServer si risolve all'account del server del namespace. Per l'elenco completo delle classi di servizio, vedi setspn.

Non sostituire una registrazione creata manualmente setspn con netdom. La registrazione cifs/MyServer sull'account del server di namespace configura Kerberos ma non il server SMB, e il servizio di directory rifiuta gli SPN che non derivano dai nomi dell'account target. Per ulteriori informazioni, vedi l'accesso alla condivisione del server file SMB non è riuscito tramite l'alias DNS CNAME.

1. Spegni il file server sorgente. Il server sorgente e il server DFS Namespaces non possono rispondere entrambi allo stesso nome. Spegni il server invece di rimuoverlo dal dominio.

2. Disabilita l'account computer di origine. In Utenti e computer di Active Directory, clicca con il tasto destro sull'oggetto computer e seleziona Disabilita account. Per fare lo stesso da PowerShell su una macchina con il modulo Active Directory installato, esegui:

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

3. Rimuovi gli SPN dall'account del computer sorgente. La disabilitazione di un account non rimuove gli SPN. Le registrazioni lasciate sul vecchio account bloccano il passo successivo, perché lo stesso nome non può essere registrato su due account. Gli SPN duplicati sono una causa documentata di KDC_ERR_PRINCIPAL_NOT_UNIQUE. Per ulteriori informazioni, vedi Kerberos genera errore KDC_ERR_S_PRINCIPAL_UNKNOWN o KDC_ERR_PRINCIPAL_NOT_UNIQUE. Elenca gli elementi registrati, quindi elimina le voci e :

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

   Elimina tutte le voci esplicite cifs/ allo stesso modo. Se setspn -L mostra altre classi di servizio come TERMSRV o MSSQLSvc, il vecchio nome serve ancora qualcosa di diverso da SMB. Risolvi questa dipendenza prima di continuare.

4. Aggiungi il vecchio nome come nome alternativo del computer sul server di namespace. Esegui netdom da un prompt dei comandi con privilegi elevati sul server dello spazio dei nomi. Per un singolo server DFS Namespace, punta all'account computer di quel server. Per un namespace autonomo clusterizzato, punta all'oggetto nome cluster (CNO), non agli account dei singoli nodi. netdom viene fornito con gli strumenti AD DS in Remote Server Administration Tools; installa RSAT-AD-Tools se il comando non è disponibile.

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

   Specifica entrambi i nomi come nomi di dominio completamente qualificati. netdom registra gli HOST/MyServer SPN e HOST/MyServer.contoso.com sull'account target e aggiunge il nome all'attributo dell'account msDS-AdditionalDnsHostName , il che permette al server SMB di accettare connessioni effettuate con il vecchio nome.

   Verificare il risultato. Lo /verify switch verifica che per ogni nome registrato esistano un record DNS e uno SPN:

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

   Se netdom segnala che il nome è già in uso, significa che è ancora registrato altrove nella foresta. Individua l'oggetto in conflitto prima di continuare:

   setspn -T contoso -F -Q */MyServer
   

   Se l'unico oggetto restituito è l'account computer sorgente che hai modificato nel passaggio precedente, la rimozione non è ancora stata replicata sul controller di dominio che stai interrogando. Attendi che la replica venga completata oppure riesegui i comandi sull'emulatore PDC.

Crea voci DNS per nomi di server file esistenti

Affinché i namespace DFS rispondano ai nomi esistenti dei file server, crea record alias (CNAME) che indirizzino i vecchi nomi dei file server al server di DFS Namespaces. La procedura esatta dipende dal server DNS che la tua organizzazione utilizza. I passaggi seguenti utilizzano il server DNS incluso con 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

Verifica l’appropriazione del nome

Esegui il test da un client aggiunto a un dominio, accedendo come utente con autorizzazioni sulla condivisione file di Azure di destinazione. Non testare direttamente dal server DFS Namespaces, perché una connessione loopback non usa lo stesso percorso di autenticazione che un client remoto usa.

1. Conferma che la registrazione del nome alternativo sia stata replicata su ogni controller di dominio. Il centro di distribuzione delle chiavi del client non è necessariamente il controller di dominio che hai cambiato, e le repliche di Active Directory non sono garantite che siano coerenti in nessun 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 qualche controller di dominio segnala False, la replica non è completa. Aspetta e controlla di nuovo prima di continuare, perché un client che si autentica tramite quel controller di dominio continua a fallire.

2. Conferma che il vecchio nome del server ora si risolve sul server DFS Namespaces:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Apri la condivisione tramite il vecchio nome e conferma di vedere il contenuto della condivisione file Azure:

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

4. Conferma che la sessione si sia autenticata con Kerberos invece di tornare a NTLM controllando che sia stato emesso un biglietto per il vecchio nome:

   klist
   

   Cerca un ticket il cui campo server sia cifs/MyServer. Kerberos emette questo ticket sull'account del server del namespace perché la HOST/MyServer registrazione copre la cifs classe di servizio. Se non esiste tale ticket, le cause più comuni sono che la registrazione del nome alternativo non si è replicata al domain controller utilizzato dal client, che una registrazione è stata lasciata sull'account disabilitato, o che un duplicato esiste altrove nella foresta.

Se le modifiche DNS o Kerberos non entrano in vigore immediatamente, svuota le cache lato client e riprova:

ipconfig /flushdns
klist purge

Svuotare le cache client non aiuta se la modifica sottostante non si è ancora replicata. Se un ritentativo fallisce comunque, ricontrolla la convergenza della replica al passo 1 prima di cambiare altro.

Enumerazione basata su accesso (ABE)

L'enumerazione basata su Access nasconde file e cartelle a cui l'utente non ha il permesso di accedere. Negli spazi di nomi DFS, abilitare ABE su uno spazio di nomi si applica solo alle cartelle DFS-N in quell'spazio di nomi. Per controllare l'enumerazione dei contenuti di una cartella target, abilita ABE direttamente sulla condivisione file target. ABE richiede che tutti i server di namespace eseguino Windows Server 2008 o versioni successive, e gli spazi di nomi basati su domini devono utilizzare la modalità Windows Server 2008. Per dettagli, vedi Abilita l'enumerazione basata sull'accesso su uno spazio dei nomi.

Poiché non puoi abilitare ABE su una condivisione file Azure, usare ABE per controllare la visibilità di file e cartelle all'interno di una condivisione file SMB Azure non è uno scenario supportato. Questa limitazione esiste perché DFS-N funziona tramite referral piuttosto che come proxy davanti al target della cartella. Quando un utente digita \\mydfsnserver\share, il client SMB riceve il referral \\mydfsnserver\share => \\server123\share e monta direttamente quest'ultimo, così il server DFS-N non si trova più nel percorso dati.

ABE funziona solo dove il server DFS-N ospita il livello della gerarchia che vuoi filtrare, prima della redirezione. Entrambi i seguenti layout funzionano, perché i nomi delle cartelle per utente vivono nello spazio dei nomi sul server DFS-N:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, in cui contosouser1 è una sottocartella della condivisione users.

Se ogni utente è una sottocartella dopo la redirezione, ABE non funziona, perché le cartelle per utente non vengono mai enumerate dal server DFS-N:

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

Vedere anche

• Configurazione dell'accesso alla condivisione file: Autenticazione basata su identità e considerazioni sulla rete per l'accesso diretto.
• Panoramica degli spazi dei nomi DFS
• Distribuzione di namespace DFS
• Scegliere un tipo di spazio dei nomi
• Netdom Computername
• setspn
• L'accesso alla condivisione del file server SMB non è riuscito tramite l'alias DNS CNAME
• Creare un cluster di failover