Verwenden von DFS-Namespaces mit Azure Files

Gilt für: ✔️ SMB-Dateifreigaben

Verteilte Dateisystem-Namensräume, allgemein als DFS-Namensräume oder DFS-N bezeichnet, sind eine Windows Server-Serverrolle, die die Bereitstellung und Wartung von SMB-Dateifreigaben in der Produktion vereinfacht. DFS Namespaces bietet die Virtualisierung des Speicher-Namensraums, sodass Sie eine Schicht der Indirektion zwischen dem UNC-Pfad Ihrer Dateifreigabe und der eigentlichen Dateifreigabe schaffen können. DFS-Namespaces funktionieren mit SMB-Dateifreigaben, unabhängig davon, wo diese Dateifreigaben gehostet werden. Sie können es mit SMB-Freigaben verwenden, die auf einem lokalen Windows-Dateiserver mit oder ohne Azure-Dateisynchronisierung gehostet werden, direkt mit Azure-Dateifreigaben, mit SMB-Dateifreigaben, die in Azure NetApp Files oder anderen Angeboten von Drittanbietern gehostet werden, und sogar mit Dateifreigaben, die in anderen Clouds gehostet werden.

Im Kern bietet DFS Namespaces eine Abbildung zwischen einem benutzerfreundlichen UNC-Pfad wie \\contoso\shares\ProjectX, und dem zugrundeliegenden UNC-Pfad des SMB-Shares, wie \\Server01-Prod\ProjectX oder \\storageaccount.file.core.windows.net\projectx. Wenn der Endnutzer zu seiner Dateifreigabe navigiert, gibt er den benutzerfreundlichen UNC-Pfad ein, aber sein SMB-Client greift auf den zugrundeliegenden SMB-Pfad der Abbildung zu. Du kannst dieses Konzept auch erweitern, um einen bestehenden Dateiservernamen zu übernehmen, wie zum Beispiel \\MyServer\ProjectX. Sie können diese Funktion verwenden, um die folgenden Szenarien zu erreichen:

• Stellen Sie einen migrationssicheren Namen für einen logischen Satz von Daten bereit. Sie können \\contoso\shares\Engineering beispielsweise auf \\OldServer\Engineering abbilden. Wenn Sie Ihre Migration zu Azure Files abgeschlossen haben, können Sie die Zuordnung in \\storageaccount.file.core.windows.net\engineering ändern, sodass ein Benutzer beim Zugriff auf den benutzerfreundlichen UNC-Pfad nahtlos auf den Pfad der Azure-Dateifreigabe umgeleitet wird.

• Einen gemeinsamen Namen für eine logische Datenmenge festlegen, die auf mehrere Server an unterschiedlichen physischen Standorten verteilt ist, z. B. über Azure-Dateisynchronisierung. In diesem Beispiel wird ein Name wie \\contoso\shares\FileSyncExample mehreren UNC-Pfaden wie \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName und \\FileSyncServer3\ExampleShare zugeordnet. Wenn der Nutzer auf das benutzerfreundliche UNC zugreift, erhält er eine Liste möglicher UNC-Pfade und wählt basierend auf den Windows Server Active Directory (AD)-Standortdefinitionen den, der ihnen am nächsten ist.

• Erweitern Sie einen logischen Satz von Daten über Größen- und E/A-Schwellenwerte oder andere Schwellenwerte für die Skalierung hinweg. Diese Erweiterung ist nützlich für Benutzerverzeichnisse, in denen jeder Benutzer seinen eigenen Ordner auf einer Freigabe erhält, und für Scratch-Freigaben, bei denen Nutzer beliebigen Speicherplatz für temporäre Daten erhalten. Mit DFS-Namespaces verbinden Sie mehrere Ordner in einem zusammenhängenden Namespace. Zum Beispiel wird \\contoso\shares\UserShares\user1 zu \\storageaccount.file.core.windows.net\user1 zugeordnet, \\contoso\shares\UserShares\user2 wird zu \\storageaccount.file.core.windows.net\user2 zugeordnet und so weiter.

Ein Beispiel für die Verwendung von DFS-Namespaces mit Ihrer Azure Files-Bereitstellung finden Sie in der folgenden Videoübersicht.

Wenn Sie bereits einen DFS-Namensraum eingerichtet haben, sind keine besonderen Schritte erforderlich, um ihn mit Azure Files und File Sync zu verwenden. Wenn Sie Ihre Azure-Dateifreigabe von vor Ort nutzen, gelten die üblichen Netzwerküberlegungen. Weitere Informationen finden Sie unter Azure Files Netzwerküberlegungen.

Dieser Artikel behandelt die Teile einer DFS-Namespaces-Bereitstellung, die spezifisch für Azure Files sind. Für die zugrundeliegenden Windows Server-Konzepte und den vollständigen Satz der Namespace-Prozeduren siehe DFS-Namespaces-Übersicht und Deploymenting DFS Namespaces.

Voraussetzungen

Um DFS-Namensräume mit Azure Files und File Sync zu verwenden, benötigen Sie folgende Ressourcen:

• Eine Active Directory-Domäne. Sie können diese Domain überall hosten, zum Beispiel on-premises, in einer Azure-Virtual-Machine (VM) oder in einer anderen Cloud.

• Ein in die Domäne eingebundener Windows Server-Mitgliedsserver mit installierter DFS-Namespaces-Serverrolle. DFS-Namespaces sind in allen unterstützten Windows Server-Versionen verfügbar.

  Important

  Hoste keinen konsolidierten Root-Namespace auf einem Active Directory-Domänencontroller. Die Übernahme eines bestehenden Dateiservernamens erfordert einen dedizierten Mitgliedsserver oder einen Windows Server-Failover-Cluster.

• Eine SMB-Dateifreigabe, die in einer domänengebundenen Umgebung gehostet wird, wie z. B. eine Azure-Dateifreigabe in einem domänengebundenen Speicherkonto oder eine Dateifreigabe auf einem domänengebundenen Windows-Dateiserver mit Azure-Dateisynchronisierung. Weitere Informationen finden Sie unter Identitätsbasierte Authentifizierung.

• Netzwerkerreichbarkeit von Ihren Kunden zu den SMB-Dateifreigaben. Weitere Informationen finden Sie unter Netzwerküberlegungen für den direkten Zugriff.

• Domänenadministratorrechte oder delegierte Schreibzugriffe auf das servicePrincipalName Attribut der betroffenen Computerkonten. Das Namensübernahmeverfahren modifiziert Active Directory-Objekte und erfordert eine erhöhte Sitzung.

Installieren Sie die DFS-Namespaces-Serverrolle

Wenn Sie bereits DFS-Namespaces verwenden, überspringen Sie diesen Schritt.

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

Weitere Installationsoptionen finden Sie unter Install DFS Namespaces.

Auswählen eines Namespacetyps

DFS Namespaces bietet zwei Namensraumtypen: domänenbasiert und eigenständig. Für einen vollständigen Vergleich, einschließlich Skalierungsgrenzen, Verfügbarkeitsoptionen und Active Directory-Anforderungen, siehe Namensraumtyp wählen.

Bei Azure Files läuft die Wahl meist auf eine einzige Frage hinaus:

• Wenn Sie einen vorhandenen On-Premises-Dateiservernamen beibehalten müssen, z. B. \\MyServer\share, wählen Sie einen eigenständigen Namensraum und verwenden Sie die Stammkonsolidierung. Dieser Ansatz wird empfohlen, wenn Sie Dateifreigaben nach Azure Files migrieren, da dadurch Dokumentverknüpfungen, eingebettete Links und fest codierte UNC-Pfade nach der Migration weiter funktionsfähig bleiben. Der Rest dieses Artikels konzentriert sich auf dieses Szenario.
• Für jedes andere Szenario wählen Sie einen domänenbasierten Namensraum.

Bei eigenständigen Namensräumen sind Vor- und Nachteile zu berücksichtigen:

• Namespace-Metadaten werden in der Registry des Namespace-Servers gespeichert, nicht im Active Directory. Beziehen Sie die Namespace-Konfiguration in Ihre Server-Backup-Strategie ein.
• Man kann aus Gründen der Redundanz nicht mehrere Namespace-Server zu einem eigenständigen Namespace hinzufügen. Für hohe Verfügbarkeit hosten Sie den Namensraum auf einem Windows Server-Failover-Cluster.
• Eigenständige Namensräume unterstützen Ziele mit geringerem Maßstab als domänenbasierte Namensräume im Windows Server 2008-Modus.

Der Pfad, den Ihr Benutzer mountet, hängt vom Namensraumtyp ab:

Wenn Sie einen domänenbasierten Namensraum gewählt haben, überspringen Sie die Wurzelkonsolidierungsphasen. Das Namespace- und Ordnerzielverfahren ist für beide Typen gleich. Verwenden Sie Erstellen Sie den Namespace, und fügen Sie Ihre Azure-Dateifreigaben hinzu mit DomainV2 als Namespace-Typ.

Übernehmen vorhandener Servernamen mit Stammkonsolidierung

Durch die Verwendung der Root-Konsolidierung kann ein einzelner DFS-Namespaces-Server auf die Namen mehrerer Dateiserver reagieren und Anforderungen an die entsprechende Freigabe weiterleiten. Diese Funktion ist besonders nützlich für die Einführung von Azure Files, weil:

• Azure-Dateifreigaben können bestehende On-Premises-Servernamen nicht wiederverwenden.
• Azure-Dateifreigaben werden über den vollqualifizierten Domänennamen (FQDN) des Speicherkontos adressiert. Um beispielsweise auf die Freigabe share im Speicherkonto storageaccount zuzugreifen, verwenden Sie \\storageaccount.file.core.windows.net\share. Dieser Weg kann für Endnutzer, die einen kurzen Namen wie . erwarten, verwirrend sein.\\MyServer\share Azure Files unterstützt benutzerdefinierte Domänennamen, wenn der Speicherkontoname das Domänenpräfix ist, aber ohne DFS Namespaces können Sie keinen Namen wie \\MyServer.contoso.com\share verwenden.

Du kannst Root-Konsolidierung nur mit eigenständigen Namespaces verwenden. Wenn du bereits einen domänenbasierten Namensraum für deine Dateifreigaben hast, brauchst du keinen konsolidierten Root-Namensraum.

Um einen konsolidierten Root-Namespace hoch verfügbar zu machen, hosten Sie ihn auf einem Failover-Cluster. Um den zugrunde liegenden Cluster zu erstellen, siehe Einen Failover-Cluster erstellen. Wenn Sie diesen Ansatz verfolgen, registrieren Sie das Alias gegen das Cluster-Name-Objekt (CNO), nicht gegen einen einzelnen Knoten.

Das folgende Diagramm zeigt die hochverfügbare Implementierung einer Root-Konsolidierung. Ein Azure Load Balancer frontt einen Windows Server-Failover-Cluster von DFS-Namespaces-Servern, die die konsolidierten Root-Namespaces hosten, sodass Clients weiterhin auf die zurückgezogenen Dateiservernamen zugreifen, nachdem ihre Freigaben auf Azure Files übertragen wurden.

Die Übernahme eines bestehenden Servernamens ist ein Cutover, keine additive Änderung. Schließen Sie die folgenden Stufen in der Reihenfolge ab:

1. Aktivieren Sie die Root-Konsolidierung auf dem DFS-Namespaces-Server.
2. Erstellen Sie den Namespace und fügen Sie Ihre Azure-Dateifreigaben hinzu, und verwenden Sie dabei einen Namespace namens #<old-server-name>.
3. Übertragen Sie den Servernamen und die Service-Principal-Namen vom Quelldateiserver.
4. Erstellen Sie DNS-Einträge für bestehende Dateiservernamen.
5. Überprüfen Sie die Namensübernahme.

Root-Konsolidierung aktivieren

Führen Sie auf dem Namespace-Server in einer PowerShell-Sitzung mit erhöhten Rechten die folgenden Registrierungswerte fest und starten Sie anschließend den DFS-Namespaces-Dienst neu. Der Dienst liest diese Werte nur beim Start aus; bis er neu gestartet ist, kann man keinen Namensraum erstellen, dessen Name mit #beginnt.

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"

Bei einem Failover-Cluster legen Sie die Registrierungswerte auf jedem Knoten fest und führen dann ein Failover der Clusternamespace-Rolle durch, damit der Dienst auf jedem Knoten neu gestartet wird.

Erstelle den Namensraum und füge deine Azure-Dateifreigaben hinzu

Die grundlegende Verwaltungseinheit für DFS-Namensräume ist der Namensraum, dessen Wurzel der Ausgangspunkt des Baums ist. In \\contoso.com\Public\ ist die Namensraumwurzel Public. Innerhalb eines Namensraums verweisen Ordner mit Ordnerzielen auf die SMB-Dateifreigaben, die Ihre Inhalte enthalten, und Ordner ohne Ordnerziele fügen Struktur und Hierarchie hinzu.

Für die allgemeinen Windows Server-Verfahren siehe Erstellen eines DFS-Namensraums, Einen Ordner in einem DFS-Namensraum erstellen und Ordnerziele hinzufügen. Wenn Sie Azure-Dateifreigaben als Ziel verwenden, beachten Sie die folgenden Punkte:

• Verwenden Sie das Speicherkonto FQDN für das Ordnerziel. Verweisen Sie die Zielordner auf \\<storage-account>.file.core.windows.net\<share>. Azure Files unterstützt auch benutzerdefinierte Domainnamen, wenn der Speicherkontoname das Domainpräfix ist, aber die Verwendung eines solchen als Ordnerziel fügt hinter jeder Referral eine zweite DNS- und Kerberos-Abhängigkeit hinzu. Nutze die FQDN, es sei denn, du bist bereits auf benutzerdefinierte Domainnamen angewiesen.
• Erwarten Sie eine Konnektivitätswarnung im DFS-Management. Wenn du ein Ordnerziel für eine Azure-Dateifreigabe hinzufügst, könnte die Konsole melden, dass das storageaccount.file.core.windows.net nicht erreichbar ist. Diese Warnung ist erwartungsgemäß. Klicken Sie auf Yes (Ja), um den Vorgang fortzusetzen.
• Root-Konsolidierungsnamensräume benötigen ein # Präfix. Der Namespace-Name muss mit dem Servernamen übereinstimmen, den du ersetzt, wobei # vorangestellt wird. Um einen Server namens MyServerzu übernehmen, erstellen Sie einen Namensraum namens #MyServer. Das PowerShell-Beispiel fügt dir das Präfix hinzu. Die DFS-Verwaltungskonsole tut das nicht, also geben Sie ihn selbst ein.
• Ordnernamen müssen mit den alten Freigabenamen übereinstimmen. Ein Client, der \\MyServer\Finance öffnet, greift auf den Ordner Finance im Namensraum #MyServer zu, daher müssen die Ordnernamen exakt mit den Namen der Freigaben des Quellservers übereinstimmen.

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

Bestätigen Sie, dass der Namespace über den eigenen Namen des Namespace-Servers aufgelöst wird, bevor Sie weitermachen. Der alte Servername funktioniert noch nicht; er beginnt nach den nächsten beiden Stufen zu funktionieren.

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

Wenn der Pfad nicht aufgelöst werden kann, überprüfen Sie, ob der Client die Azure-Dateifreigabe direkt über \\<storage-account>.file.core.windows.net\<share> erreichen kann. DFS-Namespaces geben nur eine Referral zurück, also jedes Netzwerk- oder Authentifizierungsproblem mit den zugrundeliegenden Share-Oberflächen hier. Weitere Informationen finden Sie unter Netzwerküberlegungen für den direkten Zugriff.

Übertragen Sie den Servernamen und die Dienstprinzipalnamen

Die Root-Konsolidierung erlaubt es dem DFS-Namespaces-Server, auf den Namen des alten Dateiservers zu antworten, aber zwei weitere Dinge müssen wahr sein, bevor ein Client sich auf diesen Namen authentifizieren kann:

• Der SMB-Server auf dem Namespace-Server muss eine Verbindung zu einem anderen Namen als seinem eigenen Computernamen akzeptieren.
• Kerberos muss cifs/MyServer dem Konto zuordnen, das die Anforderung verarbeitet. Wenn dieser Dienstprinzipalname (SPN) noch auf dem Computerkonto des stillgelegten Dateiservers registriert ist, erhalten die Clients ein Ticket für das falsche Konto. Die Verbindung schlägt dann mit "Der Zielkontoname ist falsch" fehl oder fällt stillschweigend auf NTLM zurück.

Der Befehl netdom computername übernimmt beide Anforderungen. Er registriert den alten Namen als alternativen Computernamen auf dem Namespace-Server, der den Namen zum Serverattribut msDS-AdditionalDnsHostName addiert und die passenden HOST/<alias> SPNs registriert. Ein HOST SPN deckt implizit eine Reihe von Dienstklassen ab, die cifs umfasst, sodass eine Clientanforderung für cifs/MyServer dem Konto des Namespace-Servers zugeordnet wird. Die vollständige Liste der Serviceklassen finden Sie unter setspn.

Ersetzen Sie nicht eine handgefertigte setspn Registrierung für netdom. Die Registrierung cifs/MyServer auf dem Konto des Namespace-Servers konfiguriert Kerberos, aber nicht den SMB-Server, und der Verzeichnisdienst lehnt SPNs ab, die nicht von den eigenen Namen des Zielkontos abgeleitet sind. Weitere Informationen finden Sie unter Der Zugriff auf SMB-Dateiserverfreigaben über einen DNS-CNAME-Alias ist nicht erfolgreich.

1. Schalte den Quelldateiserver ab. Der Quellserver und der DFS-Namespaces-Server können nicht beide denselben Namen verwenden. Schalten Sie den Server aus, anstatt ihn aus der Domain zu entfernen.

2. Deaktiviere das Quellcomputer-Konto. Klicken Sie in Active Directory-Benutzer und -Computer mit der rechten Maustaste auf das Computerobjekt, und wählen Sie Konto deaktivieren aus. Um dasselbe von PowerShell auf einem Rechner mit installiertem Active Directory-Modul zu tun, führen Sie aus:

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

3. Entferne SPNs aus dem Quellcomputer-Konto. Das Deaktivieren eines Kontos entfernt seine SPNs nicht. Registrierungen, die auf dem alten Konto zurückbleiben, blockieren den nächsten Schritt, weil derselbe Name nicht auf zwei Konten registriert werden kann. Doppelte SPNs sind eine dokumentierte Ursache für KDC_ERR_PRINCIPAL_NOT_UNIQUE. Weitere Informationen finden Sie unter Kerberos gibt den Fehler KDC_ERR_S_PRINCIPAL_UNKNOWN oder KDC_ERR_PRINCIPAL_NOT_UNIQUE zurück. Führe auf, welche Einträge registriert sind, und lösche dann die HOST- und cifs-Einträge:

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

   Lösche alle expliziten cifs/ Einträge auf die gleiche Weise. Wenn setspn -L andere Dienstklassen wie TERMSRV oder MSSQLSvc anzeigt, wird der alte Name noch für etwas anderes als SMB verwendet. Lösen Sie diese Abhängigkeit, bevor Sie weitermachen.

4. Fügen Sie den alten Namen als alternativen Computernamen auf dem Namespace-Server hinzu. Führen Sie netdom in einer Eingabeaufforderung mit erhöhten Rechten auf dem Namespaceserver aus. Für einen einzelnen DFS-Namespaces-Server sollten Sie das Computerkonto dieses Servers anvisieren. Für einen clusterbasierten, eigenständigen Namensraum sollten Sie das Cluster-Namensobjekt (CNO) anvisieren, nicht die einzelnen Knotenkonten. netdom ist in den AD DS-Tools in den Remote Server Administration Tools enthalten; installieren Sie RSAT-AD-Tools, wenn der Befehl nicht verfügbar ist.

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

   Geben Sie beide Namen als voll qualifizierte Domainnamen an. netdom registriert die HOST/MyServer und HOST/MyServer.contoso.com SPNs auf dem Zielkonto und fügt den Namen zum Attribut des Kontos msDS-AdditionalDnsHostName hinzu, wodurch der SMB-Server Verbindungen zum alten Namen akzeptieren kann.

   Überprüfen Sie das Ergebnis. Der Switch /verify prüft, ob für jeden registrierten Namen ein DNS-Datensatz und ein SPN existieren:

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

   Wenn netdom gemeldet wird, dass der Name bereits verwendet wird, ist er noch an anderer Stelle im Wald registriert. Finde das widersprüchliche Objekt, bevor du weitermachst:

   setspn -T contoso -F -Q */MyServer
   

   Wenn das einzige zurückgegebene Objekt das Quellkonto ist, das du im vorherigen Schritt bearbeitet hast, wurde die Entfernung noch nicht auf den Domänencontroller übertragen, den du ansprichst. Warte, bis die Replikation konvergiert, oder führe die Befehle erneut gegen den PDC-Emulator aus.

Erstellen Sie DNS-Einträge für bestehende Dateiservernamen

Damit DFS-Namespaces auf bestehende Dateiservernamen reagieren, erstellen Sie Alias-(CNAME)-Datensätze, die die alten Dateiservernamen auf den DFS-Namespaces-Server verweisen. Das genaue Verfahren hängt davon ab, welchen DNS-Server Ihre Organisation verwendet. Die folgenden Schritte verwenden den mit Windows Server enthaltenen DNS-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

Überprüfen Sie die Namenübernahme

Testen Sie auf einem in die Domäne eingebundenen Client, auf dem Sie als Benutzer mit Berechtigungen für die Azure-Zieldateifreigabe angemeldet sind. Testen Sie nicht direkt vom DFS-Namespaces-Server, da eine Loopback-Verbindung nicht denselben Authentifizierungspfad verwendet wie ein entfernter Client.

1. Bestätigen Sie, dass die alternative Namensregistrierung auf jeden Domänencontroller repliziert wurde. Das Schlüsselverteilungszentrum des Clients ist nicht unbedingt der von Ihnen geänderte Domänencontroller, und Active Directory-Repliken sind zu keinem Zeitpunkt garantiert konsistent:

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

   Wenn ein Domänencontroller meldet False, ist die Replikation nicht abgeschlossen. Warte und überprüfe nochmal, bevor du weitermachst, denn ein Client, der sich über diesen Domain Controller authentifiziert, schlägt trotzdem fehl.

2. Bestätigen Sie, dass der alte Servername jetzt auf den DFS Namespaces-Server aufgelöst wird:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Öffnen Sie die Freigabe über den alten Namen und bestätigen Sie, dass Sie den Inhalt der Azure-Dateifreigabe sehen:

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

4. Bestätigen Sie, dass die Sitzung bei Kerberos authentifiziert wurde, anstatt auf NTLM zurückzugreifen, indem Sie prüfen, ob ein Ticket für den alten Namen erstellt wurde:

   klist
   

   Suchen Sie nach einem Ticket, dessen Serverfeld cifs/MyServer ist. Kerberos stellt dieses Ticket gegen das Konto des Namespace-Servers aus, da die HOST/MyServer Registrierung die Serviceklasse cifs abdeckt. Wenn kein solches Ticket existiert, sind die häufigsten Ursachen, dass die alternative Namensregistrierung nicht auf den vom Client verwendeten Domänencontroller dupliziert wurde, dass eine Registrierung auf dem deaktivierten Konto zurückgelassen wurde oder dass sich ein Duplikat an anderer Stelle im Forest befindet.

Wenn DNS- oder Kerberos-Änderungen nicht sofort wirksam werden, löschen Sie die clientseitigen Caches und versuchen Sie es erneut:

ipconfig /flushdns
klist purge

Das Löschen der Client-Caches hilft nicht, wenn die zugrundeliegende Änderung noch nicht repliziert wurde. Wenn ein erneuter Versuch trotzdem fehlschlägt, überprüfe die Replikationskonvergenz in Schritt 1 erneut, bevor du etwas anderes änderst.

Zugriffsbasierte Enumeration (ABE)

Zugriffsbasierte Aufzählung verbirgt Dateien und Ordner, auf die ein Benutzer keine Berechtigung hat. In DFS-Namensräumen gilt das Aktivieren von ABE auf einem Namensraum nur für die DFS-N Ordner in diesem Namensraum. Um die Auflistung der Inhalte eines Ordnerziels zu steuern, aktivieren Sie ABE direkt auf der Zieldateifreigabe selbst. ABE verlangt, dass alle Namespace-Server Windows Server 2008 oder später ausführen, und domänenbasierte Namespaces müssen den Windows Server 2008-Modus verwenden. Für Details siehe Zugriffsbasierte Aufzählung auf einem Namensraum aktivieren.

Da Sie ABE für eine Azure-Dateifreigabe nicht aktivieren können, ist die Verwendung von ABE zur Steuerung der Sichtbarkeit von Dateien und Ordnern innerhalb einer SMB-Azure-Dateifreigabe kein unterstütztes Szenario. Diese Einschränkung besteht dadurch, dass DFS-N per Referral und nicht als Proxy vor dem Ordnerziel funktioniert. Wenn ein Benutzer tippt \\mydfsnserver\share, erhält der SMB-Client die Referral \\mydfsnserver\share => \\server123\share und mountet diese direkt, sodass der DFS-N-Server nicht mehr im Datenpfad ist.

ABE funktioniert nur, wenn der DFS-N Server die Hierarchieebene hostet, die du filtern möchtest, bevor die Umleitung durchgeführt wird. Beide folgenden Layouts funktionieren, da die Ordnernamen pro Benutzer im Namensraum des DFS-N-Servers liegen:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, wobei contosouser1 ein Unterordner des users Share ist.

Wenn jeder Benutzer nach der Umleitung ein Unterordner ist, funktioniert ABE nicht, weil die per-Benutzer-Ordner vom DFS-N Server nie aufgezählt werden:

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

Siehe auch

• Konfigurieren des Dateifreigabezugriffs: Identitätsbasierte Authentifizierung und Netzwerküberlegungen für den direkten Zugriff.
• Übersicht über DFS-Namespaces
• Bereitstellen von DFS-Namespaces
• Auswählen eines Namespacetyps
• Netdom Computername
• setspn
• Der Zugriff auf SMB-Dateiserver-Freigabe ist über DNS CNAME-Alias erfolglos
• Erstellen eines Failoverclusters