DFS to dobra rzecz. I choć stwierdzenie to pasuje również do DFS rozumianego jako mechanizm replikacji, to tym razem mam na myśli zintegrowaną z domeną AD przestrzeń nazw. Dla nieświadomych szybkie przybliżenie tematu:

Tradycyjny dostęp do sieciowych zasobów plikowych realizowany jest w taki sposób, że są serwery, na serwerach udziały a klient sięga do konkretnego udziału na konkretnym serwerze. Czy sięgnie przez ścieżkę UNC (po nazwie albo IP) czy zamapuje dysk, to już nie ma większego znaczenia. W przypadku DFS, na serwerze publikowana jest przestrzeń nazw zintegrowana z domeną i udziały plikowe na poszczególnych serwerach podłączane są do "wirtualnej" ścieżki \\nazwa.domeny\nazwa_DFS\nazwa_udziału. Piękno tego rozwiązania polega między innymi na tym, że jeżeli podłączymy klienta do takiego udziału DFS, to możemy "pod spodem" dowolnie żonglować serwerami, udziałami i ścieżkami a klient zostanie automatycznie przekierowany we właściwe miejscie i nie zauważy żadnych zmian. Czyli na przykład łatwo wyobrazić sobie, że mając serwer z dziesięcioma udziałami sieciowymi, w miarę rozwoju firmy podzielimy go na dwa albo więcej serwerów, a klienci nic w codziennej pracy nie odczują. Oczywiście to samo możnaby uzyskać przemapowując wszystkie dyski na stacjach roboczych, ale przecież IT jest po to, żeby administratorzy nie musieli robić rzeczy żmudnych i nieciekawych.

W mojej prywatnej ocenie, mając DFS do dyspozycji (a jest on wspierany przez każdy współczesny system Windows) nie wypada z niego nie skorzystać. Kłopot jednak w tym, że w żywych środowiskach, tradycyjne sposoby dostępu do plików są tak rozpowszechnione, że tytułowa przesiadka na DFS wymaga "wyłapania" wszystkich sięgających przez \\serwer\udział i poprawienia ich konfiguracji. Wbrew pozorom może tego być sporo. Skrypty, polisy, mapowane dyski, skróty, odwołania w dokumentach... Tak więc zdecydowanie skuteczniejsze jest wykrywanie takiego dostępu po stronie serwera niż po stronie klientów. Oczywiście można wyłączyć tradycyjny udział i zobaczyć u kogo przestało działać, ale chyba nie jest to moja ulubiona metoda.

W efekcie, administrator chcący poważnie użyć DFSa w swoim środowisku musi sprawdzić, kto do jego serwera plików przychodzi przez DFS a kto bezpośrednio. Przyznaję się bez bicia, że zidentyfikowanie tego trochę mnie przerosło. Żadna znana mi metoda pozyskania informacji o nawiązanych połączeniach nie pozwala na rozróżnienie sposobu dostępu. Być może przegapiłem jakąś oczywistość (za wskazanie której będę oczywiście wdzięczny), ale nawet dłubiąc po API nie byłem w stanie odróżnić klienta przychodzącego do udziału X przez DFS od tych, którzy podłączyli się do niego "na skróty".

Poszedłem więc trochę inną drogą. Każdy udział serwera udostępniłem jeszcze raz, z sufiksem _dfs$. Czyli mając na początku \\serwer\home, \\serwer\biuro i \\serwer\magazyn zrobiłem dodatkowo \\serwer\home_dfs$, \\serwer\biuro_dfs$ i \\serwer\magazyn_dfs$. W konsolce zarządzającej DFS wyłączyłem odwołania do oryginalnych udziałów i dodałem te nowe. Można to zrobić "w locie" ponieważ operacja w żaden sposób nie jest zauważalna dla użytkowników. Teraz wystarczy "wmic /node:serwer path Win32_ServerConnection get ComputerName, ShareName, UserName" i już widzę z którego komputera jaki użytkownik sięga bez użycia DFS. Pozostaje tylko dojść, z czego taki dostęp wynika, poprawić i polować na kolejne.

Na końcu dostanę środowisko, w którym dostęp będzie opierać się w całości na DFS, co znacząco ułatwi mi kolejne zmiany. Choćby takie jak wyłączenie mocno wiekowego serwera plików.

Autor: Grzegorz Tworek [MVP]