DFS-naamruimten gebruiken met Azure Files

Van toepassing op: ✔️ SMB-bestandsshares

Gedistribueerde bestandssystemen naamruimtes, algemeen bekend als DFS Naamruimten of DFS-N, zijn een Windows Server-serverrol die de implementatie en het onderhoud van SMB-bestandsshares in productie vereenvoudigt. DFS Namespaces biedt virtualisatie van opslagnaamruimtes, zodat je een laag van indirectie kunt bieden tussen het UNC-pad van je bestandsdeling en de daadwerkelijke bestandsdeling. DFS-naamruimten werken met SMB-bestandsshares, onafhankelijk van waar deze bestandsshares worden gehost. Je kunt het gebruiken met SMB-shares die worden gehost op een on-premises Windows File Server met of zonder Azure File Sync, Azure file shares direct, SMB file shares gehost in Azure NetApp Files of andere externe diensten, en zelfs met bestandsshares die in andere clouds worden gehost.

In essentie verzorgt DFS Namespaces een toewijzing tussen een gebruiksvriendelijk UNC-pad, zoals \\contoso\shares\ProjectX, en het onderliggende UNC-pad van de SMB-share, zoals \\Server01-Prod\ProjectX of \\storageaccount.file.core.windows.net\projectx. Wanneer de eindgebruiker naar hun bestandsdeling navigeert, typt hij het gebruiksvriendelijke UNC-pad, maar zijn SMB-client benadert het onderliggende SMB-pad van de mapping. Je kunt dit concept ook uitbreiden om een bestaande bestandsservernaam over te nemen, zoals \\MyServer\ProjectX. U kunt deze mogelijkheid gebruiken om de volgende scenario's te bereiken:

• Geef een migratiebestendige naam op voor een logische set gegevens. U kunt bijvoorbeeld \\contoso\shares\Engineering aan \\OldServer\Engineering toewijzen. Wanneer je je migratie naar Azure Files voltooit, kun je de mapping wijzigen naar \\storageaccount.file.core.windows.net\engineering, zodat wanneer een eindgebruiker toegang krijgt tot het gebruiksvriendelijke UNC-pad, deze naadloos wordt doorgestuurd naar het Azure-bestandsdelingspad.

• Stel een gemeenschappelijke naam vast voor een logische set data die naar meerdere servers op verschillende fysieke locaties wordt verspreid, bijvoorbeeld via Azure File Sync. In dit voorbeeld wordt een naam zoals gemapt \\contoso\shares\FileSyncExample aan meerdere UNC-paden zoals \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, en \\FileSyncServer3\ExampleShare. Wanneer de gebruiker toegang krijgt tot de gebruiksvriendelijke UNC, krijgt hij een lijst met mogelijke UNC-paden en kiest hij het pad dat het dichtst bij hen ligt, gebaseerd op Windows Server Active Directory (AD) sitedefinities.

• Breid een logische set gegevens uit over de grootte, IO of andere schaaldrempels. Deze extensie is handig voor gebruikersdirectories, waar elke gebruiker zijn eigen map op een share krijgt, en voor scratch shares, waar gebruikers willekeurige ruimte krijgen voor tijdelijke data. Met DFS-naamruimten kunt u meerdere mappen samenvoegen in een samenhangende naamruimte. U kunt bijvoorbeeld \\contoso\shares\UserShares\user1 toewijzen aan \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 toewijzen aan \\storageaccount.file.core.windows.net\user2, enzovoort.

In het volgende videooverzicht ziet u een voorbeeld van het gebruik van DFS-naamruimten met uw Azure Files-implementatie.

Als je al een DFS-naamruimte hebt, zijn er geen speciale stappen nodig om deze te gebruiken met Azure Files en File Sync. Als je je Azure-bestandsdeling vanuit on-premises benadert, gelden normale netwerkoverwegingen. Zie Azure Files-netwerkoverwegingen voor meer informatie.

Dit artikel behandelt de onderdelen van een DFS Namespaces-implementatie die specifiek zijn voor Azure Files. Voor de onderliggende Windows Server-concepten en de volledige set namespaceprocedures, zie DFS Namespaces overzicht en Deploying DFS Namespaces.

Prerequisites

Om DFS Namespaces te gebruiken met Azure Files en File Sync, heb je de volgende resources nodig:

• Een Active Directory-domein. Je kunt dit domein overal hosten, bijvoorbeeld on-premises, in een Azure virtuele machine (VM), of in een andere cloud.

• Een domeingebonden Windows Server-lidserver met de DFS Namespaces-serverrol geïnstalleerd. DFS-naamruimten zijn beschikbaar in alle ondersteunde Windows Server-versies.

  Important

  Host geen root-geconsolideerde naamruimte op een Active Directory-domeincontroller. Het overnemen van een bestaande bestandsservernaam vereist een dedicated member server of een Windows Server failover-cluster.

• Een SMB-bestandsdeling die wordt gehost in een domein-gekoppelde omgeving, zoals een Azure-bestandsdeling in een domein-gekoppeld opslagaccount, of een bestandsdeling op een domein-gekoppelde Windows File Server met Azure File Sync. Voor meer informatie, zie Identiteitsgebaseerde authenticatie.

• Netwerkbereik van je klanten tot de SMB-bestandsdelen. Zie Netwerkoverwegingen voor directe toegang voor meer informatie.

• Domeinbeheerdersrechten, of gedelegeerde schrijfrechten voor het servicePrincipalName attribuut van de getroffen computeraccounts. De naamovernameprocedure wijzigt Active Directory-objecten en vereist een verhoogde sessie.

De serverfunctie DFS-naamruimten installeren

Als je al DFS-namespaces gebruikt, sla dan deze stap over.

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

Voor meer installatieopties, zie Install DFS Namespaces.

Een naamruimtetype kiezen

DFS Namespaces biedt twee typen namespaces: domeingebaseerd en standalone. Voor een volledige vergelijking, inclusief schaallimieten, beschikbaarheidsopties en Active Directory-eisen, zie Kies een naamruimtetype.

Voor Azure Files komt de keuze meestal neer op één enkele vraag:

• Als je een bestaande on-premises bestandsservernaam wilt behouden , zoals \\MyServer\share, kies dan een zelfstandige naamruimte en gebruik rootconsolidatie. Deze aanpak wordt aanbevolen bij het migreren van bestandsdelingen naar Azure Files, omdat het documentsnelkoppelingen, ingebedde links en hardgecodeerde UNC-paden na de migratie werkend houdt. De rest van dit artikel richt zich op dit scenario.
• Kies voor elk ander scenario een domeingebaseerde naamruimte.

Zelfstandige naamruimten hebben compromissen waarmee u rekening moet houden:

• Namespace-metadata wordt opgeslagen in het register van de namespace-server, niet in Active Directory. Neem de namespace-configuratie op in je serverback-upstrategie.
• Je kunt niet meerdere namespace-servers toevoegen aan een standalone namespace voor redundantie. Voor hoge beschikbaarheid host je de naamruimte op een Windows Server failovercluster.
• Zelfstandige namespaces ondersteunen doelen met lagere schaal dan domeingebaseerde namespaces in Windows Server 2008-modus.

Het pad dat je gebruikers mounten hangt af van het type namespace:

Als je een domeingebaseerde naamruimte kiest, sla dan de rootconsolidatiefasen over. De procedure voor naamruimte en map target is voor beide types hetzelfde. Gebruik Create the namespace en voeg je Azure-bestandsdelingen toe met DomainV2 als naamruimtetype.

Bestaande servernamen overnemen met rootconsolidatie

Door gebruik te maken van rootconsolidatie kan een enkele DFS Namespaces-server reageren op meerdere bestandsservernamen en verzoeken routeren naar de juiste share. Deze mogelijkheid is vooral nuttig voor het adopteren van Azure Files, want:

• Azure-bestandsdelingen kunnen bestaande on-premises servernamen niet hergebruiken.
• Je benadert Azure-bestandsshares met behulp van de volledig gekwalificeerde domeinnaam (FQDN) van het opslagaccount. Om bijvoorbeeld toegang te krijgen tot share share in storage account storageaccount, gebruik \\storageaccount.file.core.windows.net\share. Dat pad kan verwarrend zijn voor eindgebruikers die een korte naam verwachten, zoals \\MyServer\share. Azure Files ondersteunt aangepaste domeinnamen wanneer de opslagaccountnaam het domeinprefix is, maar zonder DFS Namespaces kun je geen naam als \\MyServer.contoso.com\share.

Je kunt rootconsolidatie alleen gebruiken met standalone namespaces. Als je al een domeingebaseerde naamruimte hebt voor je bestandsdelingen, heb je geen root-geconsolideerde naamruimte nodig.

Om een root-geconsolideerde naamruimte zeer beschikbaar te maken, host deze op een failover-cluster. Om het onderliggende cluster te maken, zie Create a failover cluster. Als je deze aanpak kiest, registreer dan de alias tegen het cluster name object (CNO), niet tegen een individuele node.

Het volgende diagram toont een zeer beschikbare root consolidatie-implementatie. Een Azure Load Balancer fungeert als front-end voor een Windows Server-failovercluster van DFS Namespaces-servers die de geconsolideerde hoofdnaamruimten hosten, zodat clients toegang blijven houden tot de buiten gebruik gestelde bestandsservernamen nadat hun bestandsshares naar Azure Files zijn verplaatst.

Het overnemen van een bestaande servernaam is een cutover, geen additieve wijziging. Voltooi de volgende fasen in volgorde:

1. Schakel consolidatie van roots in op de DFS Namespaces-server.
2. Maak de naamruimte aan en voeg je Azure-bestandsshares toe, met behulp van een naamruimte genaamd #<old-server-name>.
3. Draag de servernaam en de naam van de service principal over van de bronbestandserver.
4. Maak DNS-vermeldingen aan voor bestaande bestandsservernamen.
5. Controleer de overname van de naam.

Schakel wortelconsolidatie in

Vanuit een verhoogde PowerShell-sessie op de namespace-server stelt u de volgende registerwaarden in en start vervolgens de DFS Namespaces-service opnieuw op. De service leest deze waarden alleen bij het opstarten; totdat deze opnieuw opstart, kun je geen naamruimte maken waarvan de naam begint met #.

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"

Op een failover-cluster stel je de registerwaarden op elke node in en laat je vervolgens de geclusterde naamruimterol een failover uitvoeren, zodat elke node de service opnieuw start.

Maak de naamruimte aan en voeg je Azure-bestandsshares toe

De basisbeheerseenheid voor DFS-naamruimtes is de naamruimte, waarvan de wortel het startpunt van de boom is. In \\contoso.com\Public\ is Public de root van de naamruimte. Binnen een naamruimte wijzen mappen met mapdoelen naar de SMB-bestandsshares die je inhoud bevatten, en mappen zonder mapdoelen voegen structuur en hiërarchie toe.

Raadpleeg voor de algemene procedures voor Windows Server Create a DFS namespace, Create a folder in a DFS namespace en Add folder targets. Wanneer je je richt op Azure-bestandsdelingen, houd dan de volgende punten in gedachten:

• Gebruik het opslagaccount FQDN voor het mapdoel. Wijs mapdoelen toe aan \\<storage-account>.file.core.windows.net\<share>. Azure Files ondersteunt ook aangepaste domeinnamen wanneer de opslagaccountnaam het domeinprefix is, maar het gebruik van een domein als mapdoel voegt een tweede DNS- en Kerberos-afhankelijkheid toe achter elke verwijzing. Gebruik de FQDN, tenzij je al afhankelijk bent van aangepaste domeinnamen.
• Verwacht een connectiviteitswaarschuwing in DFS Management. Wanneer je een mapdoel toevoegt voor een Azure-bestandsdeling, kan de console melden dat dat storageaccount.file.core.windows.net niet bereikbaar is. Deze waarschuwing wordt verwacht. Selecteer Ja om door te gaan.
• Rootconsolidatie-namespaces hebben een # prefix nodig. De naam van de naamruimte moet overeenkomen met de server die je vervangt, met voorafgegaan door #. Om een server genaamd MyServerover te nemen, maak je een naamruimte aan genaamd #MyServer. Het PowerShell-voorbeeld voegt het voorvoegsel voor u toe. De DFS Management-console doet dat niet, dus typ het zelf in.
• Mappennamen moeten overeenkomen met de oude sharenamen. Een client die opent \\MyServer\Finance , wordt bediend door de map Finance in de #MyServer naamruimte, dus mapnamen moeten exact overeenkomen met de sharenamen van de bronserver.

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

Controleer of de namespace via de eigen naam van de namespaceserver wordt opgelost voordat je verdergaat. De oude servernaam werkt nog niet; hij begint te werken na de volgende twee fasen.

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

Als het pad niet oplost, controleer dan of de client direct toegang heeft tot de Azure-bestandsdeling op \\<storage-account>.file.core.windows.net\<share>. DFS Namespaces geven alleen een doorverwijzing terug, dus elk netwerk- of authenticatieprobleem met de onderliggende gedeelde map komt hier naar voren. Zie Netwerkoverwegingen voor directe toegang voor meer informatie.

Zet de servernaam en de naam van de diensthoofd over

Rootconsolidatie laat de DFS Namespaces-server reageren op de naam van de oude bestandsserver, maar twee andere zaken moeten waar zijn voordat een client zich kan authenticeren op die naam:

• De SMB-server op de namespace-server moet een verbinding accepteren die is gemaakt met een andere naam dan zijn eigen computernaam.
• Kerberos moet cifs/MyServer herleiden tot het account dat het verzoek verwerkt. Als die naam van de service principal (SPN) nog steeds geregistreerd is op het computeraccount van de uitgeschakelde bestandsserver, krijgen clients een ticket voor het verkeerde account. De verbinding faalt dan met "De naam van het doelaccount is onjuist" of valt stilletjes terug naar NTLM.

Het netdom computername commando verzorgt beide vereisten. Het registreert de oude naam als een alternatieve computernaam op de naamruimteserver, die de naam toevoegt aan het msDS-AdditionalDnsHostName attribuut van de server en de overeenkomende HOST/<alias> SPN's registreert. Een HOST SPN omvat impliciet een reeks serviceklassen, waaronder cifs, zodat een clientaanvraag voor cifs/MyServer wordt omgezet naar het account van de naamruimteserver. Voor de volledige lijst van serviceklassen, zie setspn.

Vervang geen handgemaakte setspn registratie voor netdom. Door cifs/MyServer te registreren voor het account van de namespace-server wordt Kerberos geconfigureerd, maar niet de SMB-server, en de directoryservice wijst SPN's af die niet zijn afgeleid van de namen van het doelaccount zelf. Raadpleeg voor meer informatie Toegang tot een SMB-bestandsserver-share via een DNS CNAME-alias mislukt.

1. Sluit de bron-bestandsserver af. De bronserver en de DFS Namespaces-server kunnen niet allebei dezelfde naam beantwoorden. Zet de server uit in plaats van hem uit het domein te verwijderen.

2. Schakel het broncomputeraccount uit. In Active Directory: gebruikers en computers klik je met de rechtermuisknop op het computerobject en selecteer je Account uitschakelen. Om hetzelfde te doen vanuit PowerShell op een machine met de Active Directory-module geïnstalleerd, voer je uit:

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

3. Verwijder SPN's van het broncomputeraccount. Het uitschakelen van een account verwijdert de SPN's niet. Registraties die achterblijven op het oude account blokkeren de volgende stap, omdat dezelfde naam niet op twee accounts geregistreerd kan worden. Dubbele SPN's zijn een gedocumenteerde oorzaak van KDC_ERR_PRINCIPAL_NOT_UNIQUE. Voor meer informatie, zie Kerberos genereert KDC_ERR_S_PRINCIPAL_UNKNOWN of KDC_ERR_PRINCIPAL_NOT_UNIQUE fout. Noteer wat is geregistreerd en verwijder vervolgens de items HOST en cifs:

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

   Verwijder expliciete cifs/ vermeldingen op dezelfde manier. Als setspn -L andere serviceklassen zoals TERMSRV of MSSQLSvc weergeeft, wordt de oude naam nog steeds voor iets anders dan SMB gebruikt. Los die afhankelijkheid op voordat je verder gaat.

4. Voeg de oude naam toe als een alternatieve computernaam op de namespace-server. Voer netdom uit vanaf een verhoogde opdrachtprompt op de namespace-server. Voor een enkele DFS Namespaces-server richt je je op het computeraccount van die server. Voor een geclusterde, standalone namespace, richt je je op het clusternaamobject (CNO), niet op de individuele nodeaccounts. netdom Wordt geleverd met de AD DS-tools in Remote Server Administration Tools; installeer RSAT-AD-Tools als het commando niet beschikbaar is.

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

   Specificeer beide namen als volledig gekwalificeerde domeinnamen. netdom registreert de HOST/MyServer en HOST/MyServer.contoso.com SPN's op het doelaccount en voegt de naam toe aan het msDS-AdditionalDnsHostName attribuut van het account, waardoor de SMB-server verbindingen met de oude naam kan accepteren.

   Controleer het resultaat. De /verify switch controleert of er voor elke geregistreerde naam een DNS-record en een SPN bestaan:

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

   Als netdom meldt dat de naam al in gebruik is, is deze nog steeds elders in het forest geregistreerd. Zoek het tegenstrijdige object voordat je verder gaat:

   setspn -T contoso -F -Q */MyServer
   

   Als het enige object dat wordt geretourneerd het broncomputeraccount is dat je in de vorige stap hebt bewerkt, is de verwijdering nog niet gerepliceerd naar de domeincontroller die je opvraagt. Wacht tot replicatie convergeert, of voer de commando's opnieuw uit met de PDC-emulator.

Maak DNS-vermeldingen aan voor bestaande bestandsservernamen

Om DFS-namespaces te laten reageren op bestaande bestandsservernamen, maak je alias (CNAME) records die de oude bestandsservernamen naar de DFS Namespaces-server verwijzen. De exacte procedure hangt af van welke DNS-server jouw organisatie gebruikt. De volgende stappen gebruiken de DNS-server die bij Windows Server wordt geleverd.

# 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

Controleer de naamovername

Test vanaf een domein-gekoppelde client, aangemeld als gebruiker met rechten op de doel-Azure-bestandsdeling. Test niet vanaf de DFS Namespaces-server zelf, omdat een loopback-verbinding niet hetzelfde authenticatiepad gebruikt als een externe client.

1. Bevestig dat de alternatieve naamregistratie is gerepliceerd naar elke domeincontroller. Het sleuteldistributiecentrum van de client is niet per se de domeincontroller die je hebt aangepast, en Active Directory-replica's zijn niet gegarandeerd op elk moment consistent:

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

   Als een domeincontroller meldt False, is de replicatie niet voltooid. Wacht en controleer opnieuw voordat je doorgaat, want een client die via die domeincontroller authenticeert faalt nog steeds.

2. Controleer of de oude servernaam nu verwijst naar de DFS Namespaces-server:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Open de share via de oude naam en bevestig dat je de inhoud van de Azure-bestandsshare ziet:

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

4. Bevestig dat de sessie is geauthenticeerd bij Kerberos in plaats van terug te vallen op NTLM door te controleren of er een ticket is uitgegeven voor de oude naam:

   klist
   

   Zoek naar een ticket waarvan het serverveld cifs/MyServer is. Kerberos verstrekt dit ticket voor het account van de naamruimteserver, omdat de registratie van HOST/MyServer de serviceklasse cifs dekt. Als zo'n ticket niet bestaat, zijn de meest voorkomende oorzaken dat de registratie van de alternatieve naam niet is gerepliceerd naar de domeincontroller die de client gebruikt, dat er een registratie op het uitgeschakelde account is achtergebleven, of dat er elders in het forest een duplicaat bestaat.

Als DNS- of Kerberos-wijzigingen niet direct van kracht worden, wis dan de client-side caches en probeer het opnieuw:

ipconfig /flushdns
klist purge

Het wissen van de clientcaches helpt niet als de onderliggende wijziging nog niet is gerepliceerd. Als een herpoging toch mislukt, controleer dan de replicatieconvergentie opnieuw in stap 1 voordat je iets anders verandert.

Toegangsgebaseerde enumeratie (ABE)

Toegangsgebaseerde enumeratie verbergt bestanden en mappen waar een gebruiker geen toegang toe heeft. In DFS-namespaces geldt het inschakelen van ABE op een namespace alleen voor de DFS-N mappen in die namespace. Om de enumeratie van de inhoud van een mapdoel te beheersen, schakel ABE in op de doelbestandsdeling zelf. ABE vereist dat alle namespace-servers Windows Server 2008 of later draaien, en domeingebaseerde namespaces moeten Windows Server 2008-modus gebruiken. Voor details, zie Toegangsgebaseerde enumeratie inschakelen op een naamruimte.

Omdat je ABE niet kunt inschakelen voor een Azure-bestandsshare, wordt het gebruik van ABE om de zichtbaarheid van bestanden en mappen in een SMB Azure-bestandsshare te beheren niet ondersteund. Deze beperking bestaat omdat DFS-N werkt via verwijzing in plaats van als proxy voor het mapdoel. Wanneer een gebruiker \\mydfsnserver\share typt, ontvangt de SMB-client de verwijzing \\mydfsnserver\share => \\server123\share en koppelt deze laatste rechtstreeks, zodat de DFS-N-server zich niet langer in het gegevenspad bevindt.

ABE werkt alleen waar de DFS-N server het niveau van de hiërarchie host dat je wilt filteren, vóór de omleiding. Beide volgende lay-outs werken, omdat de mappennamen per gebruiker in de naamruimte op de DFS-N server staan:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, waarbij contosouser1 een submap van de users share is.

Als elke gebruiker zich na de omleiding in een submap bevindt, werkt ABE niet, omdat de mappen per gebruiker nooit door de DFS-N-server worden opgesomd:

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

Zie ook

• Toegang tot bestandsshares configureren: Identiteitsgebaseerde authenticatie en Netwerkoverwegingen voor directe toegang.
• Overzicht van DFS-naamruimten
• DFS-naamruimten implementeren
• Een naamruimtetype kiezen
• Netdom Computernaam
• setspn
• SMB-bestandsserver-deeltoegang is niet succesvol via DNS CNAME alias
• een failovercluster maken