DFS, Netbios a FQDN jména

Tahle věc mě vytáčela řadu měsíců, vlastně roků. Nebyla ale tak důležitá, abych se tomu věnoval až do úspěšného vyřešení. Až teď. Doména, kterou v práci používáme, má prazáklady už z Windows 2000 a je postupně upgradována, schéma rozšiřováno, AD řadiče i jména domén přejmenovávány, nahrazovány atd. Až do doby nasazení Windows Vista (někdy před čtyřmi lety) jsem i z domova přes VPN bez problémů přistupoval k DFS zdrojům. Pak se něco změnilo a přístup přes DFS rozcestník přestal fungovat, takže jsem se smířil s nouzovým přístupem na cílové sdílené adresáře na příslušných serverech. Místo tvaru \\domena.local\dfs\adresar jsem si tak holt mapoval přímo \\server.domena.local\adresar.

V minulých dnech jsem ale musel řešit problém s Windows XP, které nedokázaly korektně komunikovat s AD řadiči W2008R2 (o tom ale až v následujícím článku) a při té příležitosti jsem narazil i na problém DFS přes VPN. A teď už vím, co jsme kdysi hodně dávno udělali špatně.

DFS server standardně poskytuje DFS klientovi název serveru, na kterém leží požadovaný sdílený adresář, pomocí Netbios jména. Toto chování je platné už od dob Windows 2000. V prostředích, v nichž se používají WINS, v prostředích, kde se automaticky doplňuje ke jménu název domény vše funguje naprosto parádně. Funguje vše dobře i v případě, kdy si do definice VPN přidám “DNS suffix for this connection”, případně “Append these DNS suffixes (in order)”. Proto mi to tenkrát přes VPN na WXP fungovalo, protože tam jsem všechny používané interní domény vyplnil. Ve Vistách jsem se na to vybodl a ve W7 taktéž, ve kterých jsem to pak obcházel zakládáním záznamů v HOSTS souboru. To všechno jsou ale jen obezličky, aby fungoval Netbios resolving.

Existuje způsob, jak donutit DFS místo Netbios jmen používat FQDN. Příslušným MSKB je již prehistorické číslo 244380, ovšem pořád platné. Stačí do registrů nacpat jeden záznam a server, který se podílí na DFS službě, začne místo Netbios jmen posílat FQDN jména.

Záznam je třeba vytvořit v HKLM\SYSTEM\CurrentControlSet\Services\Dfs:

Value Name: DfsDnsConfig
Data Type: REG_DWORD
Value Data: 1

Nebylo by to však správné administrátorské pošušňání, kdyby tam nebylo několik chytáků:

po přidání záznamu je třeba restartovat službu DFS, ale pozor na další body
tento záznam se musí přidat na všechny servery, které se podílí na DFS službě, tedy nejen na DFS namespace servery, ale také na všechny AD řadiče (díky za odpověď Matta z 29.12.2010 5:23 v tomto článku), ale pozor na další bod
tento záznam se musí v registrech nacházet PŘED vytvořením DFS namespace

Bod 3 je zásadní problém, záznam v registrech jsme sice měli, ale asi jsme jej tam před x lety přidali pochopitelně až po vytvoření namespace. Ještě předtím ale dodatečná poznámka k bodu 2. Na AD musí záznam v registry být kvůli tomu, že SYSVOL adresář se chová jako DFS a poskytuje DFS klientovi odkaz na nejbližší SYSVOL právě podle toho, jak je nastaven ten záznam v registru.

Možnosti opravy jsou dvojí – horší a “ještě horší”. Ta “ještě horší” nastává v případě, kdy používáte tzv. domain-based DFS. Tam prostě nezbývá někdy (nespecifikováno, dle čeho se to řídí), než zahodit celou konfiguraci DFS, vytvořit záznam v registrech na všech příslušných serverech, restartovat na všech DFS službu (pokud tam existuje) a hezky si vše nakonfigurovat znovu. Tohle je pěkně blbé, pokud se používají replikace dat na vícero serverů, může totiž dojít k opětovné synchronizaci se všemi negativními dopady (čas, zatížení sítě, serveru atd.).

Pokud by někdo používal stand-alone DFS, tj. nepoužívá tvar \\domena.local\dfs, ale \\server.domena.local\dfs, tak to má krapet jednodušší – ale pozor – NESMÍ použít k opravě GUI nástroj! Pokud by tak totiž učinil, odebere jeden server z repliky a data z tohoto serveru zmizí.

Pro jednotlivé DFS linky se použije dvojice příkazů:

DFScmd /remove \\dfsname\dfsshare\path \\server\share\path

DFScmd /add \\dfsname\dfsshare\path \\server\share\path

Pokud je root DFS namespace umístěn na vícero serverech, použije se následující dvojice příkazů (ta se NESMÍ použít, pokud je DFS root jen jeden, došlo by ke smazání celého DFS namespace!):

DFSutil /remroot:DFSName /Server:rootSrv /Share:rootShare

DFSutil /addroot:DFSName /Server:rootSrv /Share:rootShare

Po restartu DFS služby (na všech DFS serverech) by mělo standalone DFS poskytovat výhradně FQDN názvy na odkazované servery.

Ověřil jsem si to tím, že jsem na jednom počítači pootvíral pár DFS zdrojů a pak v příkazové řádce napsal

dfsutil cache referral

Ve výstupu by měly být výhradně FQDN názvy.

dfsutil cache referral
4 entries...
Entry: \ad2.domena.local\dfs\asp
ShortEntry: \ad2.domena.local\dfs\asp
Expires in 0 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[\vs-data1.domena.local\asp] AccessStatus: 0 ( ACTIVE TARGETSET )

Entry: \domena.local\dfs
ShortEntry: \domena.local\dfs
Expires in 0 seconds
UseCount: 2 Type:0x81 ( REFERRAL_SVC DFS )
0:[\ad2.domena.local\dfs] AccessStatus: 0 ( ACTIVE TARGETSET )
1:[\ad1.domena.local\dfs]

Entry: \domena.local\SysVol
ShortEntry: \domena.local\SysVol
Expires in 517 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[\ad2.domena.local\SysVol] AccessStatus: 0 ( ACTIVE TARGETSET )
1:[\ad1.domena.local\SysVol]

Entry: \ad2.domena.local\dfs
ShortEntry: \ad2.domena.local\dfs
Expires in 0 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
0:[\ad2.domena.local\dfs] AccessStatus: 0 ( ACTIVE TARGETSET )
1:[\ad1.domena.local\dfs]

Další užitečné zdroje:
O’DFS Shares! Where art Thou?
Using the Windows Server 2008 DFSUTIL.EXE command line to manage DFS-Namespaces
What does DFSDiag do?