Så här använder du DFS-namnområden med Azure Files

Gäller för: ✔️ SMB-fildelningar

Distribuerade filsystemnamnrymder, ofta kallade DFS-namnrymder eller DFS-N, är en Windows Server-serverroll som förenklar distribution och underhåll av SMB-fildelningar i produktion. DFS Namespaces tillhandahåller virtualisering av lagringsnamnrymder, så du kan skapa ett lager av indirektion mellan UNC-vägen för din filshare och den faktiska filsharen. DFS-namnområden fungerar med SMB-filresurser, oberoende av var dessa filresurser finns. Du kan använda det med SMB-delningar som hostas på en lokal Windows File Server med eller utan Azure File Sync, Azure-fildelningar direkt, SMB-fildelningar som hostas i Azure NetApp Files eller andra tredjepartserbjudanden, och till och med med fildelningar som är värd i andra moln.

I grunden tillhandahåller DFS Namespaces en mappning mellan en användarvänlig UNC-sökväg, som \\contoso\shares\ProjectX, och den underliggande UNC-vägen för SMB-andelen, som \\Server01-Prod\ProjectX eller \\storageaccount.file.core.windows.net\projectx. När slutanvändaren navigerar till sin fildelning skriver de den användarvänliga UNC-vägen, men deras SMB-klient får tillgång till den underliggande SMB-vägen för mappningen. Du kan också utvidga detta koncept till att ta över ett befintligt filservernamn, såsom \\MyServer\ProjectX. Du kan använda den här funktionen för att uppnå följande scenarier:

• Ange ett migreringssäkert namn för en logisk uppsättning data. Du kan till exempel mappa \\contoso\shares\Engineering till \\OldServer\Engineering. När du slutför din migrering till Azure Files kan du ändra mappningen till \\storageaccount.file.core.windows.net\engineering, så att när en slutanvändare går åt den användarvänliga UNC-sökvägen omdirigeras de sömlöst till Azure-fildelsvägen.

• Etablera ett gemensamt namn för en logisk datamängd som distribueras till flera servrar på olika fysiska platser, till exempel via Azure File Sync. I detta exempel mappas ett namn som \\contoso\shares\FileSyncExample till flera UNC-vägar såsom \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, och \\FileSyncServer3\ExampleShare. När användaren får tillgång till den användarvänliga UNC får de en lista över möjliga UNC-vägar och väljer den närmaste baserat på Windows Server služba Active Directory (AD) webbplatsdefinitioner.

• Utöka en logisk uppsättning data över storlek, I/O eller andra skalningströsklar. Detta tillägg är användbart för användarkataloger, där varje användare får sin egen mapp på en share, och för scratch-shares, där användare får godtyckligt utrymme för tillfällig data. Med DFS-namnområden sammanfogar du flera mappar i ett sammanhängande namnområde. Till exempel \\contoso\shares\UserShares\user1 mappar till \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 mappar till \\storageaccount.file.core.windows.net\user2och så vidare.

Du kan se ett exempel på hur du använder DFS-namnområden med din Azure Files-distribution i följande videoöversikt.

Om du redan har ett DFS-namnrymd på plats krävs inga särskilda steg för att använda det med Azure Files och File Sync. Om du får tillgång till din Azure-fildelning från lokal enhet gäller normala nätverksöverväganden. Mer information finns i Nätverksöverväganden för Azure Files.

Den här artikeln täcker de delar av en DFS Namespaces-distribution som är specifika för Azure Files. För de underliggande Windows Server-koncepten och hela uppsättningen av namnrymdsprocedurer, se DFS Namespaces översikt och Deploying DFS Namespaces.

Förutsättningar

För att använda DFS-namnrymder med Azure Files och File Sync behöver du följande resurser:

• En služba Active Directory-domän. Du kan hosta denna domän var som helst, till exempel lokalt, i en virtuell Azure-maskin (VM) eller i ett annat moln.

• En domänansluten Windows Server-medlemsserver med DFS Namespaces-serverrollen installerad. DFS-namnområden är tillgängliga i alla Windows Server-versioner som stöds.

  Important

  Hosta inte ett rotkonsoliderat namnrymd på en služba Active Directory-domänkontrollant. Att ta över ett befintligt filservernamn kräver en dedikerad medlemsserver eller ett Windows Server-failoverkluster.

• En SMB-filresurs som finns i en domänansluten miljö, till exempel en Azure-fildelning i ett domänanslutet lagringskonto eller en filresurs på en domänansluten Windows File Server med Azure File Sync. Mer information finns i Identitetsbaserad autentisering.

• Nätverksåtkomst från dina klienter till SMB-fildelningarna. Mer information finns i Nätverksöverväganden för direkt åtkomst.

• Domänadministratörsrättigheter, eller delegerad skrivbehörighet till attributet servicePrincipalName för de berörda datorkontona. Namnövertagandeproceduren modifierar služba Active Directory-objekt och kräver en upphöjd session.

Installera serverrollen DFS-namnområden

Om du redan använder DFS-namnrymder, hoppa över detta steg.

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

För fler installationsalternativ, se Installera DFS-namnrymder.

Välj en namnområdestyp

DFS Namespaces erbjuder två typer av namnrymder: domänbaserade och fristående. För en fullständig jämförelse, inklusive skalningsgränser, tillgänglighetsalternativ och krav på služba Active Directory, se Välj en namnrymdstyp.

För Azure Files handlar valet oftast om en enda fråga:

• Om du behöver bevara ett befintligt lokalt filservernamn, såsom \\MyServer\share, välj ett fristående namnutrymme och använd root-konsolidering. Detta tillvägagångssätt rekommenderas när du migrerar fildelar till Azure Files, eftersom det håller dokumentgenvägar, inbäddade länkar och hårdkodade UNC-vägar igång efter migreringen. Resten av denna artikel fokuserar på detta scenario.
• I alla andra fall, välj en domänbaserad namnrymd.

Fristående namnrymder har kompromisser att planera för:

• Metadata för namnrymden lagras i namnrymdsserverns register, inte i služba Active Directory. Inkludera namnrymdskonfigurationen i din serverbackupstrategi.
• Du kan inte lägga till flera namnrymdsservrar i ett fristående namnrymd för redundans. För hög tillgänglighet, hosta namnrymden på ett Windows Server-failoverkluster.
• Fristående namnrymder stödjer mål med lägre skala än domänbaserade namnrymder i Windows Server 2008-läge.

Den väg dina användare monterar beror på namnrymdstypen:

Om du väljer ett domänbaserat namnrymd, hoppa över rotkonsolideringsstegen. Namnrymden och mappmålsproceduren är densamma för båda typerna. Använd Create namespace och lägg till dina Azure-fildelningar med DomainV2 som namnrymdstyp.

Ta över befintliga servernamn med rotkonsolidering

Genom att använda root-konsolidering kan en enda DFS Namespaces-server svara på flera filservernamn och dirigera förfrågningar till rätt delning. Denna funktion är särskilt användbar för att använda Azure Files, eftersom:

• Azure-fildelningar kan inte återanvända befintliga servernamn på plats.
• Du adresserar Azure-fildelningar genom att använda lagringskontots fullt kvalificerade domännamn (FQDN). Till exempel, för att komma åt delning share i lagringskontot storageaccount, använd \\storageaccount.file.core.windows.net\share. Den vägen kan vara förvirrande för slutanvändare som förväntar sig ett kort namn, som \\MyServer\share. Azure Files stöder anpassade domännamn när lagringskontots namn är domänprefixet, men utan DFS-namnrymder kan du inte använda ett namn som \\MyServer.contoso.com\share.

Du kan använda rotkonsolidering endast med fristående namnrymder. Om du redan har ett domänbaserat namnrymd för dina fildelningar behöver du inte ett rotkonsoliderat namnrymd.

För att göra en rotkonsoliderad namnrymd mycket tillgänglig, lägg den på ett redundanskluster. För att bygga det underliggande klustret, se Skapa ett failover-kluster. Om du använder detta tillvägagångssätt, registrera aliaset mot klusternamnobjektet (CNO), inte mot en enskild nod.

Följande diagram visar en distribution för rotkonsolidering med hög tillgänglighet. En Azure Load Balancer fungerar framför ett Windows Server-redundanskluster med DFS Namespaces-servrar som är värdar för de konsoliderade namnrymderna på rotnivå, så att klienter fortfarande kan nå de avvecklade filservernamnen efter att deras filresurser har flyttats till Azure Files.

Att ta över ett befintligt servernamn är en övergång, inte en tilläggsförändring. Slutför följande steg i ordning:

1. Aktivera rotkonsolidering på DFS Namespaces-servern.
2. Skapa namnrymden och lägg till dina Azure-fildelningar, med ett namnrymd som heter #<old-server-name>.
3. Överför servernamnet och tjänstehuvudnamnen från källfilservern.
4. Skapa DNS-poster för befintliga filservernamn.
5. Verifiera namnövertagandet.

Aktivera konsolidering av root-behörigheter

Från en PowerShell-session med förhöjda rättigheter på namespace-servern anger du följande registervärden och startar sedan om tjänsten DFS Namespaces. Tjänsten läser dessa värden endast vid uppstart; tills den startar om kan du inte skapa ett namnrymd vars namn börjar med #.

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"

I ett failover-kluster anger du registervärdena på varje nod och flyttar sedan över den klustrade namnrymdsrollen så att tjänsten startas om på varje nod.

Skapa namnrymden och lägg till dina Azure-fildelningar

Den grundläggande hanteringsenheten för DFS-namnrymder är namnrymden, vars rot är trädets startpunkt. I \\contoso.com\Public\ är namnrymdsroten Public. Inom ett namnrymd pekar mappar med mappmål på SMB-filshares som innehåller ditt innehåll, och mappar utan mappmål tillför struktur och hierarki.

För de allmänna Windows Server-procedurerna, se Skapa ett DFS-namnrymd, Skapa en mapp i ett DFS-namnrymd och Lägg till mappmål. När du riktar in dig på Azure-fildelningar, tänk på följande punkter:

• Använd lagringskontots FQDN för mappmålet. Peka mappmål vid \\<storage-account>.file.core.windows.net\<share>. Azure Files stöder också anpassade domännamn när lagringskontots namn är domänprefixet, men att använda ett som mappmål lägger till en andra DNS- och Kerberos-beroende bakom varje referens. Använd FQDN om du inte redan är beroende av anpassade domännamn.
• Räkna med en anslutningsvarning i DFS Management. När du lägger till ett mappmål för en Azure-fildelning kan konsolen rapportera att det storageaccount.file.core.windows.net inte går att nå. Den här varningen förväntas. Klicka på Ja när du vill fortsätta.
• Root-konsolideringsnamnrymder behöver ett # prefix. Namnet på namnrymden måste stämma överens med servern som du ersätter, med # före. För att ta över en server med namnet MyServer, skapa ett namnrymd kallat #MyServer. PowerShell-exemplet lägger till prefixet åt dig. DFS Management-konsolen gör det inte, så skriv in det själv.
• Mappnamn måste matcha de gamla delningsnamnen. En klient som öppnar \\MyServer\Finance hanteras av mappen Finance i namnrymden #MyServer, så mappnamnen måste stämma exakt överens med källserverns resursnamn.

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

Bekräfta att namnrymden löses via namnrymdsserverns eget namn innan du fortsätter. Det gamla servernamnet fungerar inte än; det börjar fungera efter de två följande stegen.

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

Om sökvägen inte löses, kontrollera att klienten kan nå Azure-fildelningen direkt på \\<storage-account>.file.core.windows.net\<share>. DFS-namnrymder ger bara en hänvisning, så alla nätverks- eller autentiseringsproblem med den underliggande delningen visar sig här. Mer information finns i Nätverksöverväganden för direkt åtkomst.

Överför servernamnet och tjänstehuvudnamnen

Rotkonsolidering låter DFS Namespaces-servern svara på den gamla filserverns namn, men två andra saker måste vara sanna innan en klient kan autentisera sig för det namnet:

• SMB-servern på namnrymdsservern måste acceptera en anslutning till ett annat namn än dess eget datornamn.
• Kerberos måste matcha cifs/MyServer mot det konto som hanterar begäran. Om det tjänstehuvudnamnet (SPN) fortfarande är registrerat på den avvecklade filserverns datorkonto, får klienterna ett ärende för fel konto. Anslutningen misslyckas sedan med "Namnet på målkontot är felaktigt" eller återgår tyst till NTLM.

Kommandot netdom computername hanterar båda kraven. Den registrerar det gamla namnet som ett alternativt datornamn på namnrymdsservern, som lägger till namnet i serverns msDS-AdditionalDnsHostName attribut och registrerar matchande HOST/<alias> SPN:er. Ett HOST SPN täcker implicit en uppsättning tjänsteklasser som inkluderar cifs, så en klientförfrågan om cifs/MyServer löses till namnrymdsserverns konto. För hela listan över tjänsteklasser, se setspn.

Byt inte ut en handbyggd setspn registrering mot netdom. Registrering cifs/MyServer på namnrymdsserverns konto konfigurerar Kerberos men inte SMB-servern, och katalogtjänsten avvisar SPN:er som inte härstammar från målkontots egna namn. För mer information, se Åtkomst till SMB-filserverdelning misslyckas via DNS CNAME-alias.

1. Stäng ner källfilservern. Källservern och DFS Namespaces-servern kan inte båda svara på samma namn. Stäng av servern istället för att ta bort den från domänen.

2. Inaktivera källdatorns konto. I Používatelia a počítače služby Active Directory, högerklicka på datorobjektet och välj Inaktivera konto. För att göra samma sak från PowerShell på en maskin med služba Active Directory-modulen installerad, kör:

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

3. Ta bort SPN:er från källdatorns konto. Att inaktivera ett konto tar inte bort dess SPN. Registreringar som lämnas kvar på det gamla kontot blockerar nästa steg, eftersom samma namn inte kan registreras på två konton. Dubbla SPN:er är en dokumenterad orsak till KDC_ERR_PRINCIPAL_NOT_UNIQUE. För mer information, se Kerberos genererar KDC_ERR_S_PRINCIPAL_UNKNOWN eller KDC_ERR_PRINCIPAL_NOT_UNIQUE fel. Lista det som är registrerat och ta sedan bort posterna HOST och cifs:

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

   Ta bort alla explicita cifs/ poster på samma sätt. Om setspn -L visar andra tjänstklasser, till exempel TERMSRV eller MSSQLSvc, används det gamla namnet fortfarande för något annat än SMB. Lös det beroendet innan du fortsätter.

4. Lägg till det gamla namnet som ett alternativt datornamn på namnrymdsservern. Kör netdom från en upphöjd kommandoprompt på namnrymdsservern. För en enskild DFS Namespaces-server, rikta in dig på den serverns datorkonto. För ett klustrat fristående namnrymd, rikta in dig på klusternamnobjektet (CNO), inte de enskilda nodkontona. netdom levereras med AD DS-verktygen i Remote Server Administration Tools; installera RSAT-AD-Tools om kommandot inte är tillgängligt.

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

   Ange båda namnen som fullt kvalificerade domännamn. netdom registrerar HOST/MyServer och HOST/MyServer.contoso.com SPN:arna på målkontot och lägger till namnet till kontots msDS-AdditionalDnsHostName attribut, vilket gör att SMB-servern kan acceptera anslutningar till det gamla namnet.

   Kontrollera resultatet. Switchen /verify kontrollerar att det finns en DNS-post och ett SPN för varje registrerat namn:

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

   Om netdom det rapporteras att namnet redan används, är det fortfarande registrerat på andra platser i skogen. Lokalisera det motstridiga objektet innan du fortsätter:

   setspn -T contoso -F -Q */MyServer
   

   Om det enda objektet som returneras är källdatorns konto du redigerade i föregående steg, har borttagningen ännu inte replikerats till domänkontrollern du frågar i. Vänta på att replikeringen ska konvergera, eller kör kommandona igen mot PDC-emulatorn.

Skapa DNS-poster för befintliga filservernamn

För att DFS-namnrymder ska kunna svara på anrop till befintliga filservernamn skapar du aliasposter (CNAME-poster) som pekar från de gamla filservernamnen till servern för DFS-namnrymder. Den exakta proceduren beror på vilken DNS-server din organisation använder. Följande steg använder DNS-servern som ingår i 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

Verifiera namnövertagandet

Testa från en domänansluten klient, loggad in som användare med behörigheter på den aktuella Azure-fildelningen. Testa inte från DFS Namespaces-servern själv, eftersom en loopback-anslutning inte använder samma autentiseringsväg som en fjärrklient.

1. Bekräfta att den alternativa namnregistreringen replikerades till varje domänkontrollant. Klientens nyckeldistributionscenter är inte nödvändigtvis domänkontrollern du ändrade, och služba Active Directory-repliker garanteras inte vara konsekventa vid någon tidpunkt:

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

   Om någon domänkontrollant rapporterar Falseär replikeringen inte klar. Vänta och kontrollera igen innan du fortsätter, för en klient som autentiserar via den domänkontrollanten misslyckas fortfarande.

2. Bekräfta att det gamla servernamnet nu matchas mot DFS Namespaces-servern:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Öppna delningen via det gamla namnet och bekräfta att du ser innehållet i Azure-fildelningen:

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

4. Kontrollera att sessionen autentiserades med Kerberos i stället för att använda NTLM som reserv genom att kontrollera att en biljett har utfärdats för det gamla namnet:

   klist
   

   Leta efter ett ärende vars serverfält är cifs/MyServer. Kerberos skickar detta ärende mot namnrymdsserverns konto eftersom registreringen HOST/MyServer täcker cifs tjänsteklassen. Om inget sådant ärende finns är de vanligaste orsakerna att registreringen av det alternativa namnet inte replikerades till domänkontrollern som klienten använder, att en registrering lämnades kvar på det inaktiverade kontot, eller att en kopia finns någon annanstans i skogen.

Om DNS- eller Kerberos-ändringar inte träder i kraft omedelbart, rensa klientsidans cacher och försök igen:

ipconfig /flushdns
klist purge

Att rensa klientcachen hjälper inte om den underliggande ändringen inte replikerats än. Om ett nytt försök ändå misslyckas, kontrollera replikationskonvergens igen i steg 1 innan du ändrar något annat.

Åtkomstbaserad uppräkning (ABE)

Åtkomstbaserad uppräkning döljer filer och mappar som en användare inte har behörighet att komma åt. I DFS-namnområden gäller det, om ABE aktiveras för ett namnområde, endast för DFS-N-mapparna i det namnområdet. För att kontrollera visningen av innehållet i en målmapp aktiverar du ABE på själva målfildelningen. ABE kräver att alla namnrymdsservrar kör Windows Server 2008 eller senare, och domänbaserade namnrymder måste använda Windows Server 2008-läge. För detaljer, se Aktivera åtkomstbaserad uppräkning i ett namnrymd.

Eftersom du inte kan aktivera ABE på en Azure-fildelning är det inte ett stöd att använda ABE för att kontrollera visningen av filer och mappar i en SMB Azure-filshare. Denna begränsning finns eftersom DFS-N fungerar genom hänvisning snarare än som en proxy framför mappmålet. När en användare skriver \\mydfsnserver\share, får SMB-klienten referensen \\mydfsnserver\share => \\server123\share och monterar den senare direkt, så att DFS-N-servern inte längre finns i datavägen.

ABE fungerar bara där DFS-N-servern är värd för den nivå i hierarkin som du vill filtrera, innan omdirigeringen. Båda följande layouter fungerar, eftersom mappnamnen per användare finns i namnrymden på DFS-N-servern:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, där contosouser1 är en delmapp i sharen users .

Om varje användare har en undermapp efter omdirigeringen fungerar inte ABE, eftersom mapparna per användare aldrig enumereras av DFS-N-servern:

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

Se även

• Konfigurera filresursåtkomst: Identitetsbaserad autentisering och nätverksöverväganden för direkt åtkomst.
• Översikt över DFS-namnområden
• Distribuera DFS-namnområden
• Välj en namnområdestyp
• Netdom ComputerName
• setspn
• SMB-filserverdelningsåtkomst misslyckas via DNS CNAME-alias
• Skapa ett redundanskluster