Jak używać przestrzeni nazw systemu plików DFS w usłudze Azure Files

Dotyczy: ✔️ udostępnienia plików SMB

Przestrzenie nazw rozproszonych systemów plików, powszechnie nazywane przestrzeniami nazw DFS lub DFS-N, to rola serwera Windows Server, która upraszcza wdrażanie i utrzymanie współudziału plików SMB w produkcji. Przestrzenie nazw DFS zapewniają wirtualizację przestrzeni nazw pamięci masowej, dzięki czemu możesz zapewnić warstwę pośrednictwa między ścieżką UNC twojego udostępnionego pliku a rzeczywistym udostępnionym plikiem. Przestrzenie nazw systemu plików DFS współdziałają z udziałami plików SMB, które są niezależne od tego, gdzie te udziały plików są hostowane. Możesz go używać z udziałami SMB hostowanymi na lokalnym serwerze plików systemu Windows, z usługą Azure File Sync lub bez niej, bezpośrednio z udziałami plików platformy Azure, z udziałami plików SMB hostowanymi w usłudze Azure NetApp Files lub w innych rozwiązaniach innych firm, a nawet z udziałami plików hostowanymi w innych chmurach.

Zasadniczo przestrzeń nazw DFS zapewnia mapowanie między przyjazną dla użytkownika ścieżką UNC, taką jak \\contoso\shares\ProjectX, a bazową ścieżką UNC udziału SMB, taką jak \\Server01-Prod\ProjectX lub \\storageaccount.file.core.windows.net\projectx. Gdy użytkownik końcowy przechodzi do swojego folderu plików, wpisuje przyjazną ścieżkę UNC, ale klient SMB korzysta z bazowej ścieżki SMB mapowania. Możesz także rozszerzyć tę koncepcję, przejmując istniejącą nazwę serwera plików, na przykład .\\MyServer\ProjectX Tej możliwości można użyć do osiągnięcia następujących scenariuszy:

Podaj nazwę odporną na migracje dla logicznego zestawu danych. Na przykład można mapować \\contoso\shares\Engineering na \\OldServer\Engineering. Po zakończeniu migracji do Azure Files możesz zmienić mapowanie na \\storageaccount.file.core.windows.net\engineering, tak aby użytkownik końcowy, gdy uzyskuje przyjazną dla użytkownika ścieżkę UNC, był płynnie przekierowywany do ścieżki Azure file share.
Ustal wspólną nazwę dla logicznego zestawu danych rozpowszechnianych na wielu serwerach w różnych fizycznych lokalizacjach, na przykład przez Azure File Sync. W tym przykładzie nazwa taka jak jest \\contoso\shares\FileSyncExample przypisana do wielu ścieżek UNC, takich jak \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, oraz \\FileSyncServer3\ExampleShare. Gdy użytkownik uzyskuje dostęp do przyjaznego adresu UNC, otrzymuje listę możliwych ścieżek UNC i wybiera tę, która jest mu najbliższa, na podstawie definicji lokacji w usłudze Windows Server Active Directory (AD).
Rozszerzyć logiczny zestaw danych przez rozmiar, IO lub inne progi skalowania. To rozszerzenie jest przydatne dla katalogów użytkowników, gdzie każdy użytkownik ma własny folder na udostępnionym miejscu, oraz dla udostępnień scratch, gdzie użytkownicy mają dowolną przestrzeń na tymczasowe dane. Za pomocą przestrzeni nazw DFS łączysz wiele folderów w spójną przestrzeń nazw. Na przykład \\contoso\shares\UserShares\user1 odpowiada \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 odpowiada \\storageaccount.file.core.windows.net\user2, i tak dalej.

W poniższym filmie omówieniowym możesz zobaczyć przykład użycia przestrzeni nazw DFS z wdrożeniem usługi Azure Files.

Uwaga

Przejdź do 10:10 w filmie wideo, aby zobaczyć, jak skonfigurować przestrzenie nazw systemu plików DFS.

Jeśli masz już DFS Namespace, nie trzeba żadnych specjalnych kroków, aby korzystać z niego z Azure Files i File Sync. Jeśli uzyskujesz dostęp do udostępnienia plików Azure lokalnie, obowiązują normalne kwestie sieciowe. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące sieci usługi Azure Files.

Ten artykuł obejmuje części wdrożenia DFS Namespaces specyficzne dla Azure Files. Aby poznać podstawowe koncepcje Windows Server oraz pełny zestaw procedur przestrzeni nazw, zobacz przegląd przestrzeni nazw DFS oraz Deploying DFS Namespaces.

Wymagania wstępne

Aby korzystać z przestrzeni nazw DFS z Azure Files i File Sync, potrzebujesz następujących zasobów:

Domena usługi Active Directory. Możesz hostować tę domenę wszędzie, na przykład lokalnie, w maszynie wirtualnej Azure (VM) lub w innej chmurze.
Serwer członkowski systemu Windows Server dołączony do domeny, z zainstalowaną rolą serwera DFS Namespaces. Przestrzenie nazw DFS są dostępne we wszystkich obsługiwanych wersjach systemu Windows Server.

Ważna

Nie umieszczaj głównej skonsolidowanej przestrzeni nazw na kontrolerze domeny Active Directory. Przejęcie nazwy istniejącego serwera plików wymaga dedykowanego serwera członkowskiego lub klastra awaryjnego Windows Server.
Udostępnienie plików SMB hostowane w środowisku dołączonym do domeny, takie jak udostępnienie plików Azure na koncie pamięci masowej połączonej z domeną, lub udostępnianie plików na serwerze plików Windows z Azure File Sync połączonym z domeną. Więcej informacji można znaleźć w artykule Uwierzytelnianie oparte na tożsamości.
Zasięg sieci od klientów do udziałów plików SMB. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące sieci dotyczące bezpośredniego dostępu.
Prawa administratora domeny lub delegowane uprawnienia do zapisu w atrybucie servicePrincipalName kont komputerów, których dotyczy problem. Procedura przejmowania nazw modyfikuje obiekty Active Directory i wymaga sesji podwyższonej.

Instalowanie roli serwera przestrzeni nazw systemu plików DFS

Jeśli już używasz przestrzeni nazw DFS, pomiń ten krok.

Menedżer serwera
PowerShell

Otwórz Menedżer serwera i wybierz Zarządzaj,>dodaj role i funkcje. Wybierz instalację opartą na rolach lub na funkcjach. Na stronie Role serwera wybierz Przestrzenie nazw DFS w obszarze Usługi plików i magazynowania>Usługi plików i iSCSI. Czarodziej dodaje wymagane role lub funkcje wspierające.

Zrzut ekranu kreatora Dodawanie ról i funkcji z wybraną rolą Przestrzeni nazw DFS.

W oknie programu PowerShell uruchomionym z podwyższonymi uprawnieniami uruchom:

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

Więcej opcji instalacji znajdziesz w Instalowanie przestrzeni nazw DFS.

Wybieranie typu przestrzeni nazw

Przestrzenie nazw DFS oferują dwa typy przestrzeni nazw: oparte na domenie oraz samodzielne. Aby uzyskać pełne porównanie, w tym limity skalowania, opcje dostępności i wymagania Active Directory, zobacz Wybierz typ przestrzeni nazw.

Zrzut ekranu z wyboru między przestrzenią nazw opartą na domenie a samodzielną przestrzenią nazw w Kreatorze Nowej Przestrzeni Nazw.

W przypadku Azure Files wybór zwykle sprowadza się do jednego pytania:

Jeśli musisz zachować istniejącą nazwę serwera plików lokalnie , taką jak \\MyServer\share, wybierz samodzielną przestrzeń nazw i użyj konsolidacji root. To podejście jest zalecane podczas migracji plików do Azure Files, ponieważ pozwala zachować działanie skrótów dokumentów, osadzonych linków i zakodowanych na stałe ścieżek UNC po migracji. Reszta tego artykułu skupia się na tym scenariuszu.
W przypadku innych scenariuszy wybierz przestrzeń nazw opartą na domenie.

Samodzielne przestrzenie nazw wiążą się z pewnymi kompromisami, które należy uwzględnić podczas planowania:

Metadane przestrzeni nazw są przechowywane w rejestrze serwera przestrzeni nazw, a nie w Active Directory. Włącz konfigurację przestrzeni nazw do strategii kopii zapasowej serwera.
Nie można dodać wielu serwerów przestrzeni nazw do samodzielnej przestrzeni nazw w celu zapewnienia nadmiarowości. Dla wysokiej dostępności hostuj przestrzeń nazw na klastrze awaryjnym Windows Server.
Samodzielne przestrzenie nazw obsługują cele o niższej skali niż przestrzenie nazw oparte na domenie w trybie Windows Server 2008.

Ścieżka montowana przez użytkowników zależy od typu przestrzeni nazw:

Konfiguracja przestrzeni nazw	Ścieżka wykorzystania
Samodzielna przestrzeń nazw z konsolidacją korzeni	`\\<old-server>\<share>`
Samodzielna przestrzeń nazw	`\\<DFS-server>\<namespace>\<share>`
Przestrzeń nazw oparta na domenach	`\\<domain-name>\<namespace>\<share>`

Jeśli wybrałeś przestrzeń nazw opartą na domenach, pomiń etapy konsolidacji korzeni. Procedura dotycząca przestrzeni nazw i folderu docelowego jest taka sama dla obu typów. Użyj opcji Utwórz przestrzeń nazw i dodaj swoje udziały plików platformy Azure z typem przestrzeni nazw DomainV2.

Przejęcie istniejących nazw serwerów za pomocą scalania root

Dzięki konsolidacji katalogów głównych pojedynczy serwer przestrzeni nazw DFS może obsługiwać wiele nazw serwerów plików i kierować żądania do odpowiedniego udziału. Ta funkcja jest szczególnie przydatna przy wdrażaniu Azure Files, ponieważ:

Udziały plików platformy Azure nie mogą używać ponownie nazw istniejących serwerów lokalnych.
Dostęp do udziałów plików Azure uzyskuje się przy użyciu w pełni kwalifikowanej nazwy domenowej (FQDN) konta magazynu. Na przykład, aby uzyskać dostęp do konta storageaccountshare share in storage , użyj \\storageaccount.file.core.windows.net\share. Ta ścieżka może być myląca dla użytkowników końcowych, którzy oczekują krótkiej nazwy, takiej jak \\MyServer\share. Azure Files obsługuje niestandardowe nazwy domen, gdy prefiks domeny jest adresem konta magazynowego, ale bez przestrzeni nazw DFS nie można używać nazwy takiej jak \\MyServer.contoso.com\share.

Konsolidację katalogów głównych można stosować tylko z autonomicznymi przestrzeniami nazw. Jeśli masz już domenową przestrzeń nazw dla swoich udostępnionych plików, nie potrzebujesz rootowej skonsolidowanej przestrzeni nazw.

Aby zapewnić wysoką dostępność głównej skonsolidowanej przestrzeni nazw, umieść ją w klastrze przełączania awaryjnego. Aby zbudować klaster bazowy, zobacz Utwórz klaster failover. Jeśli zastosujesz to podejście, zarejestruj alias w obiekcie nazwy klastra (CNO), a nie dla pojedynczego węzła.

Poniższy schemat przedstawia wdrożenie konsolidacji głównej o wysokiej dostępności. Azure Load Balancer obsługuje klaster awaryjnego Windows Server z serwerami DFS Namespaces, które hostują skonsolidowane przestrzenie nazw root, dzięki czemu klienci nadal docierają do wycofanych nazw serwerów plików po przeniesieniu ich udziałów do Azure Files.

Przejęcie istniejącej nazwy serwera to przełączenie, a nie zmiana przyrostowa. Wykonaj następujące etapy w kolejności:

Włącz konsolidację root na serwerze DFS Namespace.
Stwórz przestrzeń nazw i dodaj swoje udostępnione pliki Azure, używając przestrzeni nazw o nazwie #<old-server-name>.
Przenieś nazwę serwera oraz nazwy głównych usług z serwera plików źródłowego.
Utwórz wpisy DNS dla istniejących nazw serwerów plików.
Zweryfikowaj przejęcie nazwy.

Ważna

Etapy 3 i 4 wyłączają źródłowy serwer plików, więc przerwa między jego wyłączeniem a zakończeniem zmiany DNS to awaria dla użytkowników. Zaplanuj okno obsługi.

Zanim zaczniesz, sporządź wykaz wszystkiego, co wskazuje na nazwę serwera źródłowego. Kolejki drukowania, członkowie replikacji DFS, aliasy bazy danych, zaplanowane zadania, zadania kopii zapasowej oraz zakodowane skrypty odwołujące się do starej nazwy przestają działać, gdy nazwa jest przekierowana do serwera DFS Namespace, ponieważ serwer danych zwraca tylko referencje SMB. Najpierw przenieś lub wycofaj te zależności.

Włącz konsolidację korzeni

W sesji programu PowerShell uruchomionej z podwyższonymi uprawnieniami na serwerze przestrzeni nazw ustaw następujące wartości rejestru, a następnie uruchom ponownie usługę DFS Namespaces. Usługa odczytuje te wartości tylko przy starcie; dopóki nie zostanie zrestartowana, nie możesz utworzyć przestrzeni nazw, której nazwa zaczyna się na .#

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"

W klastrze failover ustaw wartości rejestru na każdym węźle, a następnie przełącz rolę w klasterowej przestrzeni nazw, aby każdy węzeł mógł ponownie uruchomić usługę.

Stwórz przestrzeń nazw i dodaj swoje udostępnione pliki Azure

Podstawową jednostką zarządzania przestrzeniami nazw DFS jest przestrzeń nazw, której korzeń jest punktem startowym drzewa. W \\contoso.com\Public\ głównym elementem przestrzeni nazw jest Public. W przestrzeni nazw foldery z folderami docelowymi wskazują na udziały plików SMB, które przechowują Twoją zawartość, a foldery bez folderów docelowych dodają strukturę i hierarchię.

Aby poznać ogólne procedury Windows Server, zobacz: Utworzenie przestrzeni nazw DFS, Utworzenie folderu w przestrzeni nazw DFS oraz Dodaj cele folderów. Celując w udostępnienia plików Azure, miej na uwadze następujące kwestie:

Użyj FQDN konta pamięci jako target folderu. Ustaw foldery docelowe na \\<storage-account>.file.core.windows.net\<share>. Azure Files obsługuje także niestandardowe nazwy domen, gdy prefiks domeny jest nazwą konta magazynowego, ale użycie takiej nazwy dla folderu docelowego dodaje drugą zależność DNS i Kerberos za każdym skierowaniem. Używaj FQDN, chyba że już polegasz na niestandardowych nazwach domen.
Należy oczekiwać ostrzeżenia dotyczącego łączności w Zarządzaniu DFS. Gdy dodasz folder target dla udostępnionego pliku Azure, konsola może zgłosić, że nie da się z nim storageaccount.file.core.windows.net skontaktować. To ostrzeżenie jest oczekiwane. Wybierz przycisk Tak, aby kontynuować.
Główne przestrzenie nazw konsolidacji wymagają prefiksu #. Nazwa przestrzeni nazw musi odpowiadać serwerowi, który zastępujesz, z dodatkiem #. Aby przejąć serwer o nazwie MyServer, utwórz przestrzeń nazw o nazwie #MyServer. Przykład PowerShell dodaje prefiks za ciebie. Konsola zarządzania DFS tego nie robi, więc wpisz to sam.
Nazwy folderów muszą odpowiadać starym nazwam udostępnień. Klient, który otwiera \\MyServer\Finance, jest obsługiwany przez folder Finance w przestrzeni nazw #MyServer, więc nazwy folderów muszą dokładnie odpowiadać nazwom udziałów serwera źródłowego.

Zarządzanie DFS
PowerShell

W konsoli zarządzania DFS wybierz Przestrzenie nazw>Nowa przestrzeń nazw, a następnie postępuj zgodnie z instrukcjami Kreatora nowej przestrzeni nazw. Następnie wybierz nową przestrzeń nazw, wybierz Nowy folder, wprowadź nazwę folderu i wybierz Dodaj, aby określić ścieżkę UNC udziału plików platformy Azure jako lokalizację docelową folderu.

Zrzut ekranu okna dialogowego Nowy folder z dodanym folderem docelowym.

Wykonaj następujące polecenia z podwyższonej sesji PowerShell na serwerze DFS Namespace. Zaktualizuj zmienne w pierwszym bloku dla swojego środowiska.

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

Potwierdź, że przestrzeń nazw jest rozpoznawana przy użyciu własnej nazwy serwera przestrzeni nazw, zanim przejdziesz dalej. Stara nazwa serwera jeszcze nie działa; zaczyna działać po kolejnych dwóch etapach.

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

Jeśli ścieżka się nie rozwiązuje, sprawdź, czy klient może bezpośrednio dotrzeć do udostępnienia plików Azure pod adresem \\<storage-account>.file.core.windows.net\<share>. Przestrzenie nazw DFS zwracają tylko referencję, więc wszelkie problemy sieciowe lub uwierzytelniające z podstawowym współdziałem pojawiają się tutaj. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące sieci dotyczące bezpośredniego dostępu.

Przenieś nazwę serwera i nazwy głównych usług

Konsolidacja root pozwala serwerowi DFS Namespaces odpowiadać na nazwę starego serwera plików, ale muszą być spełnione dwie inne rzeczy, zanim klient będzie mógł uwierzytelnić się do tej nazwy:

Serwer SMB na serwerze przestrzeni nazw musi zaakceptować połączenie nawiązane do nazwy innej niż własna nazwa komputera.
Kerberos musi skojarzyć cifs/MyServer z kontem, które obsługuje żądanie. Jeśli ta główna nazwa usługi (SPN) jest nadal zarejestrowana na koncie komputerowego wycofanego serwera plików, klienci otrzymują zgłoszenie za niewłaściwe konto. Połączenie wtedy się nie udaje z komunikatem "Nazwa konta docelowego jest błędna" lub cicho wraca do NTLM.

Komenda netdom computername spełnia oba wymagania. Rejestruje starą nazwę jako alternatywną nazwę komputera na serwerze nazw, powodując dodanie tej nazwy do atrybutu msDS-AdditionalDnsHostName serwera oraz zarejestrowanie odpowiadających jej identyfikatorów SPN HOST/<alias>. Nazwa SPN HOST niejawnie obejmuje zestaw klas usług, w tym cifs, więc żądanie klienta dotyczące cifs/MyServer jest rozwiązywane do konta serwera przestrzeni nazw. Pełną listę klas służbowych można znaleźć w setspn.

Nie zastępuj netdom ręcznie utworzoną rejestracją setspn. Rejestracja cifs/MyServer na koncie serwera przestrzeni nazw konfiguruje Kerberos, ale nie serwer SMB, a usługa katalogowa odrzuca SPN-y, które nie pochodzą z nazw konta docelowego. Aby uzyskać więcej informacji, zobacz Dostęp do udziału serwera plików SMB za pośrednictwem aliasu DNS CNAME nie działa.

Warning

Nie usuwaj konta źródłowego komputera. Wyłączenie konta pozwala zachować konto, jego identyfikator zabezpieczeń (SID) oraz przynależność do grup, dzięki czemu można cofnąć przełączenie, ponownie włączając konto i przywracając jego nazwy SPN. Usunięcie konta znacznie utrudnia rollback.

Ważna

Uruchom zmiany katalogu w tej procedurze na tym samym kontrolerze domeny, a najlepiej na emulatorze PDC. Active Directory korzysta z replikacji multi-master z luźną spójnością, więc nie ma gwarancji, że repliki będą ze sobą spójne w żadnym momencie. Jeśli usuniesz starą rejestrację na jednym kontrolerze domeny, a następnie dodasz ją względem innego, mechanizm sprawdzania duplikatów może nadal widzieć usuniętą rejestrację i odmówić zapisania. Aby znaleźć emulator PDC, uruchom (Get-ADDomain).PDCEmulator, a następnie wykonaj polecenia z sesji na tym serwerze.

Wyłącz serwer plików źródłowych. Serwer źródłowy i serwer DFS Namespaces nie mogą odpowiadać na tę samą nazwę. Wyłącz serwer zamiast usuwać go z domeny.
Wyłącz konto źródłowego komputera. W Użytkownicy i komputery usługi Active Directory kliknij prawym przyciskiem myszy na obiekt komputera i wybierz Wyłącz konto. Aby zrobić to samo z PowerShell na komputerze z zainstalowanym modułem Active Directory, wykonaj:
```
$oldServer = "MyServer"
Disable-ADAccount -Identity ($oldServer + '$')
```
Usuń SPN z konta komputera źródłowego. Wyłączenie konta nie usuwa jego SPN-ów. Rejestracje pozostawione na starym koncie blokują kolejny krok, ponieważ nie można zarejestrować tej samej nazwy na dwóch kontach. Duplikowane SPN są udokumentowaną przyczyną .KDC_ERR_PRINCIPAL_NOT_UNIQUE Aby uzyskać więcej informacji, zobacz Kerberos generuje błąd KDC_ERR_S_PRINCIPAL_UNKNOWN lub KDC_ERR_PRINCIPAL_NOT_UNIQUE. Wypisz zarejestrowane wpisy, a następnie usuń wpisy HOST i cifs:
```
setspn -L MyServer
setspn -D HOST/MyServer MyServer
setspn -D HOST/MyServer.contoso.com MyServer
```
Usuń wszelkie jawne cifs/ wpisy w ten sam sposób. Jeśli setspn -L pokazuje inne klasy usług, takie jak TERMSRV lub MSSQLSvc, stara nazwa nadal obsługuje coś innego niż SMB. Usuń tę zależność, zanim przejdziesz dalej.
Dodaj starą nazwę jako alternatywną nazwę komputera na serwerze przestrzeni nazw. Uruchom netdom z podwyższonego wiersza poleceń na serwerze przestrzeni nazw. Dla pojedynczego serwera DFS Namespaces celuj w konto komputerowe tego serwera. Dla klasterowej, samodzielnej przestrzeni nazw celuj w obiekt nazw klastra (CNO), a nie na konta poszczególnych węzłów. netdom jest dostarczane z narzędziami AD DS w pakiecie Remote Server Administration Tools; zainstaluj RSAT-AD-Tools, jeśli polecenie nie jest dostępne.
```
netdom computername CloudDFSN.contoso.com /add:MyServer.contoso.com
```
Określ obie nazwy jako w pełni kwalifikowane nazwy domen. netdom rejestruje nazwy SPN HOST/MyServer i HOST/MyServer.contoso.com na koncie docelowym oraz dodaje nazwę do atrybutu msDS-AdditionalDnsHostName tego konta, co pozwala serwerowi SMB akceptować połączenia nawiązane przy użyciu starej nazwy.

Sprawdź wynik. Przełącznik /verify sprawdza, czy dla każdej zarejestrowanej nazwy istnieją rekord DNS i SPN:
```
netdom computername CloudDFSN.contoso.com /enumerate:AlternateNames
netdom computername CloudDFSN.contoso.com /verify
```
Jeśli netdom zgłasza, że nazwa jest już używana, oznacza to, że nadal jest zarejestrowana gdzie indziej w lesie. Zlokalizuj konfliktowy obiekt, zanim przejdziesz dalej:
```
setspn -T contoso -F -Q */MyServer
```
Jeśli jedynym zwróconym obiektem jest konto źródłowe komputerowe, które edytowałeś w poprzednim kroku, usunięcie nie zreplikowało się jeszcze do kontrolera domeny, do którego zadajesz zapytanie. Zaczekaj, aż replikacja się zsynchronizuje, albo uruchom polecenia ponownie względem emulatora PDC.

Utwórz wpisy DNS dla istniejących nazw serwerów plików

Aby przestrzenie nazw DFS reagowały na istniejące nazwy serwerów plików, utwórz rekordy aliasowe (CNAME), które wskazują stare nazwy serwerów plików na serwer DFS Namespace. Dokładna procedura zależy od serwera DNS, którego używa Twoja organizacja. Poniższe kroki wykorzystują serwer DNS dołączony do Windows Server.

Menedżer DNS
PowerShell

Na serwerze DNS Windows otwórz konsolę zarządzania DNS i przejdź do strefy wyszukiwania do przodu dla swojej domeny. Kliknij prawym przyciskiem myszy na strefę i wybierz Nowy alias (CNAME). W oknie dialogowym wpisz krótką nazwę serwera plików, który wymieniasz. Następnie wpisz nazwę serwera DFS-N w polu tekstowym W pełni kwalifikowana nazwa domenowa (FQDN) hosta docelowego. Wybierz OK , aby utworzyć rekord CNAME.

Zrzut ekranu okna dialogowego Nowy rekord zasobów dla wpisu DNS CNAME.

Na serwerze DNS Windows wykonaj następujące polecenia z podwyższonej sesji PowerShell. Wypełnij $oldServer nazwę serwera plików, który wymieniasz, oraz $dfsnServer krótką nazwę serwera DFS Namespace. W przypadku przestrzeni nazw klastrowej używaj nazwy sieci klastra zamiast nazwy węzła. Zmienna ta $domain jest wypełniana z domeny lokalnego komputera.

# 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

Sprawdź przejęcie nazwy

Testuj z klienta dołączonego do domeny, zalogowanego jako użytkownik z uprawnieniami na docelowym udziale plików Azure. Nie przeprowadzaj testów bezpośrednio na serwerze przestrzeni nazw DFS, ponieważ połączenie zwrotne nie używa tej samej ścieżki uwierzytelniania, jakiej używa klient zdalny.

Potwierdź, że rejestracja alternatywnej nazwy replikowała się do każdego kontrolera domeny. Centrum dystrybucji kluczy klienta niekoniecznie jest kontrolerem domeny, który zmieniłeś, a repliki Active Directory nie gwarantują spójności w żadnym momencie:
```
$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")
    }
}
```
Jeśli jakikolwiek kontroler domeny zgłasza False, replikacja nie jest zakończona. Poczekaj i sprawdź jeszcze raz, zanim będziesz kontynuować, bo klient uwierzytelniający się przez ten kontroler domeny nadal zawodzi.
Potwierdź, że poprzednia nazwa serwera jest teraz rozpoznawana jako serwer przestrzeni nazw DFS:
```
Resolve-DnsName -Name "MyServer" -Type CNAME
```
Otwórz udostępnienie pod starą nazwą i popewnij, że widzisz zawartość udostępnionego pliku Azure:
```
Test-Path -Path "\\MyServer\Finance"
Get-ChildItem -Path "\\MyServer\Finance"
```
Potwierdź, że sesja uwierzytelniła się za pomocą Kerberos, a nie wracając do NTLM, sprawdzając, czy wydano zgłoszenie na starą nazwę:
```
klist
```
Znajdź zgłoszenie, którego pole serwera ma wartość cifs/MyServer. Kerberos wystawia ten bilet dla konta serwera nazw, ponieważ rejestracja HOST/MyServer obejmuje klasę usługi cifs. Jeśli taki bilet nie istnieje, najczęstsze przyczyny to brak replikacji rejestracji alternatywnej nazwy do kontrolera domeny używanego przez klienta, pozostawienie rejestracji przy wyłączonym koncie lub istnienie duplikatu w innym miejscu lasu.

Jeśli zmiany DNS lub Kerberos nie wchodzą w życie od razu, wyczyść pamięci podręczne po stronie klienta i spróbuj ponownie:

ipconfig /flushdns
klist purge

Czyszczenie pamięci podręcznej klienta nie pomaga, jeśli podstawowa zmiana jeszcze się nie powtórzyła. Jeśli powtórka nadal się nie powiedzie, sprawdź ponownie zbieżność replikacji w kroku 1, zanim cokolwiek zmienisz.

Enumeracja oparta na dostępie (ABE)

Enumeracja oparta na dostępie ukrywa pliki i foldery, do których użytkownik nie ma uprawnień. W systemie nazw DFS włączenie funkcji ABE dla przestrzeni nazw dotyczy tylko folderów DFS-N w tej przestrzeni nazw. Aby kontrolować wyświetlanie zawartości folderu docelowego, włącz ABE na samym docelowym udziale plików. ABE wymaga, aby wszystkie serwery przestrzeni nazw działały na Windows Server 2008 lub nowszym, a przestrzenie nazw oparte na domenach muszą korzystać z trybu Windows Server 2008. Szczegóły można znaleźć w artykule Włącz enumerację opartą na dostępie na przestrzeni nazw.

Ponieważ nie można włączyć ABE w udziale plików platformy Azure, użycie ABE do sterowania widocznością plików i folderów w udziale plików SMB platformy Azure nie jest obsługiwane. To ograniczenie występuje, ponieważ DFS-N działa poprzez odwołania, a nie jako serwer proxy przed folderem docelowym. Gdy użytkownik wpisuje \\mydfsnserver\share, klient SMB otrzymuje polecenie \\mydfsnserver\share => \\server123\share i montuje je bezpośrednio, więc serwer DFS-N nie znajduje się już na ścieżce danych.

ABE działa tylko wtedy, gdy serwer DFS-N hostuje poziom hierarchii, który chcesz filtrować, przed przekierowaniem. Oba poniższe układy działają, ponieważ nazwy folderów przypisane użytkownikowi znajdują się w przestrzeni nazw na serwerze DFS-N:

\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, gdzie contosouser1 jest podfolderem udziału users.

Jeśli każdy użytkownik jest podfolderem za przekierowaniem, ABE nie działa, ponieważ foldery poszczególnych użytkowników nigdy nie są enumerowane przez serwer DFS-N:

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

Zobacz też

Konfigurowanie dostępu do udostępniania plików: uwierzytelnianie oparte na tożsamościach i kwestie sieciowe dotyczące bezpośredniego dostępu.
Przestrzenie nazw systemu plików DFS — omówienie
Wdrażanie przestrzeni nazw systemu plików DFS
Wybieranie typu przestrzeni nazw
Netdom Computername
setspn
Dostęp do współdzielenia serwera plików SMB jest nieskuteczny przez alias DNS CNAME
Tworzenie klastra awaryjnego

Opinia

Czy ta strona była pomocna?

Last updated on 2026-08-28