Popis DFS a migrace na Windows Server 2008 mode

Pozn.: Tento článek původně vznikl velmi dávno, ale v březnu 2021 jsem jej podstatně rozšířil. Jako hlavní jsem doplnil různé možnosti monitorování replikaci a řešení chyb. Údajně Microsoft již delší dobu DFSR nerozvíjí, protože má novější technologii Storage Replica, ta je ovšem dost odlišná.

Distributed File System

Distributed File System (DFS) je užitečná služba, které zařizuje několik funkcí. Principem je zjednodušení přístupu ke sdíleným adresářům a navíc zařizuje rozklad zátěže a vysokou dostupnost.

• DFS Namespaces
• DFS Replication

DFS zajišťuje konsolidaci různých síťových úložišť pod jednu adresu. Můžeme mít i více serverů, které hostují stejná data a DFS pak řeší load balancing a vysokou dostupnost. Další vlastností jsou replikace, které zajistí synchronizaci dat na více serverů a případně i na více lokalit. U replikací můžeme určovat šířku pásma, která se použije v různé denní době. DFS se stalo součástí Windows Serveru již ve verzi 2000. Na klientovi je také potřebná podpora DFS, která je součástí MS OS již od Windows NT 4.0.

DFS Namespaces

DFS se skládá ze dvou částí DFS Namespaces (DFSN) a DFS Replication (DFSR). Běžně používaná je verze domain-based namespace (druhá možnost je standalone namespace), kdy je konfigurace uložená v Active Directory a k sdíleným složkám se přistupuje pomocí \\jmeno.domeny\dfsroot\folder. Dále budeme mluvit o domain-based DFS na Windows Server 2008 R2 a novějším. Pro správu se používá snapin DFS Management nebo řádkový příkaz dfsutil nebo PowerShell DFSN module.

Konfigurace DFS se ukládá do Active Directory, dále potřebujeme jeden nebo více (pro vysokou dostupnost určitě) Namespace Server, které udržují informace o struktuře (sdílení). Automaticky se využívá informace o Site a podle toho se klient připojuje k serveru. Poslední částí jsou vlastní souborové servery (Target), kde jsou uložena data.

Struktura je taková, že vytvoříme Namespace (Root, identifikovaný pomocí jména = dfsroot), který se klientům tváří jako standardní sdílená složka, uvnitř vytváříme složky (Folders) a ty můžeme napojit na cílové servery jako Folder Target.

Údaje o DFS se ukládají na několik míst

• v Active Directory - konfigurace namespace (namespace servers, folder targets, konfigurace)
  • DFS Namespaces - CN=Dfs-Configuration,CN=System,DC=domena,DC=local
  • DFS Replication - CN=DFSR-GlobalSettings,CN=System,DC=domena,DC=local
• v registrech na Namespace serveru (členství namespace) - HKEY_LOCAL_MACHINE\Software\Microsoft\Dfs\Roots\domainV2
• na disku na Namespace serveru (spravuje shares) v defaultní cestě C:\DFSRoots

DFS Replication

DFS replikace je role Windows serveru, která umožňuje replikaci složek mezi více servery a Site, typu multiple-master. Můžeme použít pro replikaci DFS Namespaces a AD DS SYSVOL složky v doméně. DFSR nahradilo starčí FRS (File Replication Service). DFS replikace využívají kompresní algoritmus označovaný jako Remote Differential Compression (RDC). Umožňuje detekovat změny v datech a replikovat pouze změněné bloky souborů.

Vytváříme replikační skupiny - Replication Groups (RG), do kterých přidáváme jednu nebo více replikovaných složek - Replicated Folders (RF) a členské servery - Members. Jinak řečeno, RG je sada serverů (členů), kteří se účastní replikace jedné nebo více složek. Mezi členy vytváříme spojení - Connections, kde určíme odesílajícího a přijímajícího člena replikací a plán replikací (čas a pásmo). Spojení mezi všemi členy vytváří replikační topologii - Replication Topology. U replikovaných složek můžeme nastavit filtr na soubory a podsložky, které se mají replikovat.

DFSR má jednu velkou nevýhodu, že nepodporuje zamykání souborů. Takže je možné, aby dva uživatelé editovali stejný soubor na různých serverech. Konfliktní algoritmus využívá pravidlo Last Writer Wins, takže kdo později uloží změny, tak replikace přepíše ty předchozí. Také nepodporuje replikaci lokálně zamčených souborů, tedy pokud někdo edituje soubor, tak se po tu dobu nereplikují jeho změny. Understanding (the Lack of) Distributed File Locking in DFSR

Pro replikace je důležitý Staging Folder a jeho velikost, který slouží jako fronta pro změny, které se mají replikovat. Konfiguruje se pro každého člena Replicated Folder. How to determine the minimum staging area DFSR needs for a replicated folder

Převod DFS do nového módu

Spolu s Windows Server 2008 došlo k rozšíření a úpravě DFS. Předpokládal jsem, že se tyto nové funkce začnou automaticky používat, když bude DFS na novém serveru, ale bohužel to tak není. Je potřeba převést namespace do nového módu a to dost nepohodlným postupem. Největší problémy jsou s replikacemi.

Abychom mohli používat 2008kový mód, tak musí být splněny následující podmínky:

• funkční stupeň domény minimálně Windows Server 2008
• všechny namespace servery musí běžet alespoň na Windows Server 2008

Aktuální typ DFS zjistíme, když klikneme pravým tlačítkem na Namespace a zvolíme Properties, pak na záložce General vidíme položku Type, ta může být:

• Domain (Windows 2000 Server mode) – tak se dodatečně pojmenovala původní verze
• Domain (Windows Server 2008 mode) – nová verze

Bohužel nelze změnit pouze nějaké nastavení a dosáhnout tak nového módu (jako například u funkčního stupně domény). Ale musí se provést export, smazání, nové vytvoření (v novém módu) a import. Postup, jak přejít na 2008 mód je pospaný v MS článku Migrate a Domain-based Namespace to Windows Server 2008 Mode. Pro import a export musíme využít řádkový příkaz dfsutil. Ostatní operace můžeme provádět v grafickém DFS Management.

• z příkazové řádky (pod dostatečnými právy) provedeme export namespacu do soubor
  Dfsutil root export \\domain.local\namespace soubor.xml
• musíme si zapamatovat či zapsat Namespace Servers a jméno vlastního Namespace (dfsroot)
• v DFS Management smažeme Namespace, dostaneme dotaz, jestli chceme smazat replikace, to asi nechceme, více dále
• pomocí průvodce vytvoříme znovu Namespace, zadáváme první Namespace Server a jméno (dfsroot), musí být zatržené Enable Windows Server 2008 mode
• provedeme import pomocí příkazu
  Dfsutil root import merge soubor.xml \\domain.local\namespace
• přidáme další Namespace Server

Převod DFS a replikace

Pozn.: Vycházím z toho, že již používáme DFSR a ne FRS.

Když budeme po převodu kontrolovat stav DFS, tak zjistíme nepříjemnou věc. Které jsme si mohli všimnout již při exportu, pokud jsme otevřeli exportovaný XML soubor, ten totiž neobsahuje žádné informace o replikacích. Když se podíváme na nějaký adresář v Namespace, tak na záložce Replication není nic (Not configured). Stejně tak u Replication Group na záložce Replicated Folders je napsáno Not Published.

Když zkontrolujeme replikace, tak zjistíme, že fungují v pořádku. Ono totiž DFSN a DFSR může fungovat (a funguje) samostatně a nezávisle na sobě. Pokud u Namespace klikneme na Replicate Folder Wizard, tak dostaneme chybu, že replikační skupina již existuje.

Očividně chybí jen informace, že tento namespace patří k této replikační skupině. Prohledal jsem internet a našel jsem informaci, že u Replication Group v Active Directory je atribut, kde je uvedena cesta k namespace. Tam ji můžeme ručně zadat, například pomocí Active Directory Users and Computers se zapnutými Advanced Features (nebo ADSI Edit).

• proklikáme se skrze doménu, System, DFSR-GlobalSettings, naše replikační skupina, Content
• tam vidíme objekt naši skupinu, zvolíme Properties a záložku Attribute Editor
• nalezneme atribut msDFSR-DfsPath, kterému můžeme zadat cestu (\\domena\dfsroot\folder)

Když se nyní znovu podíváme do DFS Management (a případně dáme Refresh), tak již vidíme správně replikace u namespace i stav Published to namespace u Replication Group.

Zdálo by se tedy, že je vše v pořádku. Ale pokud u nějakého Namespacu zvolíme Delete na jednom Folder Target, tak se zobrazí pouze jeden potvrzující dialog a target je smazaný. Replikace se to přitom nedotkne a ta zůstane stále mezi všemi členy. Pokud chceme odstranit server i z Replication Group, tak to musíme udělat u replikací.

Pokud ale normálně vytvoříme namespace i s replikací, tak se při smazaní jednoho Folder Target zobrazí další dialog s dotazem, jestli chceme smazat i člena replikační skupiny. Očividně tedy chybí ještě nějaká vazba, ale o co jde, se mi nepodařilo nalézt. Vše ale vypadá funkčně, pouze musíme provádět samostatně některé úpravy členů pro DFSR a DFSN. Ale při přidání nového Folder Target se nabídne vytvoření replikací (a korektně provede) nebo při mazání celého Folder se správně nabídne i smazání replikační skupiny.

Přemýšlel jsem ještě o tom, když mám na dvou serverech replikovaná data a zruším replikační skupinu a znovu ji vytvořím, co se stane. V praxi to vypadá (podle logů), že se nějakým způsobem nastartuje kompletní replikace (na složce o pár desítkách gigabytů trvala několik hodin). Takže to není vhodné řešení.

DFS Replication

Kdy se projeví změny v replikacích a jak je vyvolat

Replikace DFS nezačne hned, členové si nejprve musí stáhnout novou konfiguraci z Active Directory. Prvně musí dojít k replikaci mezi jednotlivými doménovými kontrolery (DC) a pak si musí jednotlivé DFSR servery stáhnout konfiguraci z AD. Pokud provádíme některé změny v replikacích, tak můžeme potřebovat, aby se změny projevily hned, abychom mohli pokračovat dalším krokem (třeba při odstranění replikačního serveru, než na něm smažeme danou složku).

Replikaci AD můžeme vyvolat třeba pomocí Active Directory Sites and Services (na NTDS Settings u jednotlivých serverů v sites) nebo příkazu repadmin (voláme postupně pro všechny DC).

repadmin /syncall <jmeno-dc> /e /d /A /P /q

Jeden MS článek uvádí postup zjistit si DC a pouze z něj spustit synchronizaci.

WMIC /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig get LastChangeSource
repadmin /syncall /d /e /P <jmeno-dc> <Naming Context>

příklad:
repadmin /syncall /d /e /P dc.firma.local DC=firma,DC=local

Stažení konfigurace pro jednotlivé členy můžeme vyvolat příkazem dfsrdiag. Je potřeba spustit postupně pro všechny servery, které replikují data (členové replikační skupiny, tedy ti kdo hostují data). Pokud jsme přímo na serveru, tak jej nemusíme specifikovat.

dfsrdiag PollAD /Member:<jmeno-serveru>
dfsrdiag PollAD

Podobně můžeme využít PowerShell cmdlet.

Update-DfsrConfigurationFromAD -ComputerName "SERVER1","SERVER2" -Verbos

Když mluvíme o replikacích, tak jako další můžeme provést Migrace replikací SYSVOLu z FRS na DFSR.

Jednosměrná replikace

Pro různé praktické situace se může zdát výhodné vytvořit replikaci pouze jedním směrem. Konfigurace nás nechá vytvořit jednosměrné spojení (Connection), či druhé smazat nebo vypnout (Disable). Ale Microsoft uvádí, že to je nepodporované a nedoporučené řešení.

Na Windows Server 2008 R2 byla přidaná vlastnost Read-only Replicated Folders, kterou můžeme použít. Není podporováno řetězení členských serverů, které obsahují R/O replikované složky. Replikovat může pouze server s R/W replikovanou složkou.

Členský server přepneme do R/O módu pomocí DFS Management, kliknutím pravým tlačítkem na člena a volba Make read-only.

Více informací:

• Using One-Way Connections in DFS Replication
• Read-only replicated folders on Windows Server 2008 R2
• Configuring a read-only replicated folder on Windows Server 2008 R2
• Recovering from Unsupported One-Way Replication in DFSR Windows Server 2003 R2 and Windows Server 2008 (neřeší se zde možnost využít Read-only replicated folders, pokud přepneme na R/O, tak se patrně automaticky spustí Initial Synchronization and Initial Replication)

Jak monitorovat a kontrolovat DFS replikace

Myslím, že dost chybí nějaký nástroj, který by hromadně a přehledně ukázal, co se právě děje či kde je nějaký problém. Pro správu a dohled můžeme využít DFS Management, řádkové příkazy DfsrAdmin a Dfsrdiag, PowerShell DFSR modul nebo volání WMI.

Pro kontrolu stavu můžeme nechat vygenerovat Health Report pomocí DFS Management - Create Diagnostic Report. Ve výchozím nastavení je také zapnutý DFSR debug logging do složky %windir%\debug. Vhodné je kontrolovat logy událostí. Řádkové příkazy nám nabízí podobné možnosti jako PowerShell cmdlety.

Takový jednoduchý test může být skript, který vytvoří či modifikuje soubor na jednom členském serveru a kontroluje, zda se do určité doby vytvořil/modifikoval na ostatních.

Události v Event logu

Události o DFS replikacích se zapisují do samostatného logu DFS Replication (vyjímka jsou operace s DFSR databází, například oprava či defragmentace, které se zapisují do Application logu), který můžeme standardně otevřít v Event Viewer. Zde nalezneme mnoho důležitých informací i chybových stavů a je dobré log pravidelně kontrolovat. O některých událostech, a z toho vyplívajícím aktuálním stavu, se nedozvíme jinak než nelezením patřičného záznamu v logu.

Pár událostí, když hledáme začátek a konec (úvodní) replikace.

• Event ID 4104 na členském serveru
  The DFS Replication service successfully finished initial replication on the replicated folder at local path <…>.
• Event ID 4002 na členském serveru
  The DFS Replication service successfully initialized the replicated folder at local path <…>.
• Event ID 4102 na členském serveru
  The DFS Replication service initialized the replicated folder at local path <…> and is waiting to perform initial replication. The replicated folder will remain in this state until it has received replicated data, directly or indirectly, from the designated primary member.
• Event ID 4112 na primárním serveru
  The DFS Replication service initialized the replicated folder at local path <…>. This member is the designated primary member for this replicated folder.
• Event ID 2002
  The DFS Replication service successfully initialized replication on volume <…>.

Některé detekované chyby a případně jejich zotavení

• Event ID 5002
  The DFS Replication service encountered an error communicating with partner <…> for replication group <…>.
• Event ID 4412
  The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.
• Event ID 4304
  The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. The service failed to stage a file for replication due to a sharing violation.
• Event ID 4308
  The DFS Replication service has successfully recovered from sharing violations encountered on a file.
• Event ID 4202
  The DFS Replication service has detected that the staging space in use for the replicated folder at local path <…> is above the high watermark. The service will attempt to delete the oldest staging files. Performance may be affected.
• Event ID 4204
  The DFS Replication service has successfully deleted old staging files for the replicated folder at local path <…>. The staging space is now below the high watermark.
• Event ID 4208
  The DFS Replication service detected that the staging space usage is above the staging quota for the replicated folder at local path <…>. The service might fail to replicate some large files and the replicated folder might get out of sync. The service will attempt to clean up staging space automatically.
• Event ID 4210
  The DFS Replication service cleaned up the oldest staging files for the replicated folder at local path <…>, and the staging space is now below the configured staging quota.
• Event ID 4502
  The DFS Replication service encountered errors replicating one or more files because adequate free space was not available on volume <…>. This volume contains the replicated folder, the staging folder, or both. Please make sure that enough free space is available on this volume for replication to proceed. The service will retry replication periodically.
• Event ID 4504
  The DFS Replication service did not encounter replication failures caused by insufficient free space on volume <…> in the past 30 minutes.
• Event ID 2212
  The DFS Replication service has detected an unexpected shutdown on volume <…>. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. The service has automatically initiated a recovery process. The service will rebuild the database if it determines it cannot reliably recover. No user action is required.
• Event ID 2214
  The DFS Replication service successfully recovered from an unexpected shutdown on volume <…>. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. No user action is required.
• Event ID 2218
  The DFS Replication service is in the second step of replication database consistency checks after an unexpected shutdown. The database will be rebuilt if it cannot be recovered. No user action is required.

Kontrola Backlogs pomocí PowerShellu

Backlog jsou čekající aktualizace souborů na replikaci mezi dvěma partnery. Na mnoha místech se uvádí, že je důležité je sledovat, zda jsou soubory odbavovány. Můžeme použít cmdlet Get-DfsrBacklog nebo příkaz dfsrdiag backlog.

Příklady použití

Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName SERVER2 -Verbose |
 Select-Object FileName,FullPathName,CreateTime

Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName SERVER2 -Verbose |
 Select-Object * -First 1
 
PS C:\> Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName SERVER2 -FolderName "Privat" -Verbose |
 Select-Object FileName,FullPathName,CreateTime,UpdateTime 

VERBOSE: The replicated folder has a backlog of files. Replicated folder: "Privat". Count: 140

FileName                FullPathName                       CreateTime              UpdateTime  
--------                ------------                       ----------              ----------
Documents_20191011      D:\DFS\Privat\Documents_20191011   10/11/2019 3:27:47 PM   3/1/2021 11:56:16 AM

Patrně, pokud je změn velké množství, tak můžeme dostat následující chybu:

Get-DfsrBacklog : Could not retrieve the backlog information. Replication group: "*" Replicated folder: "*" Source computer:
 SERVER1 Destination computer: SERVER2 Confirm that you are running in an elevated Windows PowerShell session and are a
 member of the local  Administrators group on the destination computer. The destination computer must also be accessible
 over the network, and have the DFSR service running. This cmdlet does not support WMI calls for the following or earlier
 operating systems: Windows Server 2012. Details:  The WS-Management service cannot process the request.The computed
 response packet size (5047149) exceeds the maximum envelope size that is allowed (512000).
At line:1 char:1
+ Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo          : ProtocolError: (okdata2:String) [Get-DfsrBacklog], DfsrException
 + FullyQualifiedErrorId : Get-DfsrBacklog.CimException,Microsoft.DistributedFileSystemReplication.Commands.GetDfsrBacklogCom

Důležitá je informace, že velikost paketu překročila nastavenou maximální hodnotu. Podle řady informací na internetu můžeme hodnotu na cílovém serveru zvýšit, buď pomocí příkazu winrm nebo PowerShell cmdletu Set-WSManInstance. Příklad zjištění aktuální hodnoty a nastavení.

PS C:\> get-item -path WSMan:\localhost\MaxEnvelopeSizekb
 
 WSManConfig: Microsoft.WSMan.Management\WSMan::localhost

Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   MaxEnvelopeSizekb                              500

PS C:\> Set-WSManInstance -ValueSet @{MaxEnvelopeSizekb = "10240"} -ResourceURI winrm/config

Kontrola stavu replikací

Velmi důležitý je stav replikací (zjistíme například, že probíhá úvodní synchronizace, nebo nastala chyba), který můžeme zobrazit na členském serveru pomocí WMI (buď příkazem wmic nebo voláním z PowerShellu). Je to něco jiného, než nám zobrazí Get-DfsrState. Asi žádný cmdlet tento stav nezobrazuje, protože Get-DfsReplicatedFolder i Get-DfsReplicationGroup se dívají na logický objekt, který není vztažený k serveru, a vrací stav Normal i při chybě replikace na určitém serveru.

wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo get replicationgroupname,replicatedfoldername,state

Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo |
 Select-Object ReplicatedFolderName,ReplicationGroupName,state

Hodnota stavu (State) může být

• 0 - Uninitialized
• 1 - Initialized
• 2 - Initial Sync
• 3 - Auto Recovery
• 4 - Normal
• 5 - In Error

Stav DFS replikace pro člena z pohledu souborů

Pomocí cmdletu Get-DfsrState nebo příkazu dfsrdiag ReplicationState můžeme zjistit celkový stav replikace v rámci partnerů replikační skupiny. Zobrazuje informace o příchozích i odchozích replikacích souborů (třeba aktuálně replikované nebo ve frontě). Je to jiný pohled na Backlog. Dfsrdiag.exe ReplicationState: What’s DFSR up to?

PS C:\> Get-DfsrState -ComputerName SERVER1 | FT FileName,UpdateState,Inbound,SourceComputerName -AutoSize

FileName                 UpdateState Inbound SourceComputerName
--------                 ----------- ------- ------------------
dokument.pdf                 Waiting    True SERVER2 

PS C:\> dfsrdiag ReplicationState /member:SERVER1 /all
Summary

  Active inbound connections: 0
  Updates received: 0
  
  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

Zaseknuté Backlogs soubory ve Waiting stavu

Výše uvedené logy událostí, Backlogs, DfsrState a stav replikací, jsou hlavní věci, které bychom měli kontrolovat. Při kontrole jsem zjistil problém níže.

Při kontrole Backlogs z primárního serveru na Read Only Member jsem narazil na několik souborů, které zde zůstávají a jejich UpdateTime je již dlouho v minulosti. Fyzicky se soubory nachází pouze na primárním serveru a nejsou replikovány.

Příklad jednoho souboru:

PS C:\> Get-DfsrBacklog -SourceComputerName server1 -DestinationComputerName server2 -FolderName "Privat" -Verbose |
 select FileName,CreateTime,UpdateTime

FileName                        CreateTime             UpdateTime            
--------                        ----------             ----------            
OneNoteBackup_2018-10-15.zip    10/15/2018 9:00:00 AM  10/15/2018 9:00:07 AM

Ve výpisu Get-DfsrState jsou vidět v čekajícím stavu (soubory se zde zobrazují dvakrát).

PS C:\> Get-DfsrState -ComputerName server2 | FT  FileName,UpdateState,Inbound,SourceComputerName -AutoSize

FileName                        UpdateState Inbound SourceComputerName
--------                        ----------- ------- ------------------
OneNoteBackup_2018-10-15.zip        Waiting    True SERVER1           

Stav replikace, pro danou replikovanou složku (RF), ukazuje chybu.

PS C:\> Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo |
 Select-Object ReplicatedFolderName,state

ReplicatedFolderName state
-------------------- -----
Privat                   5

Zkusil jsem dané soubory přesunou mimo replikované složky. Tím se vyprázdnil Backlogs a stav replikací se zobrazil jako Normal (4).

V logu událostí (Event Log) jsem nalezl opakované Event ID 4502 a 4504. Nakonec jsem zjistil, že není problém s místem na disku. Ale tyto složky mají nastavenu kvótu (Storage Quota). Sice je stejná na zdrojovém i cílovém serveru, ale z nějakého důvodu se již do cíle soubory nevejdou. Po zrušení kvóty, a nahrání souborů zpět, se korektně replikovaly.

Po některých předchozích pokusech se stav replikace zobrazoval jako chyba (5). Vyřešilo se restartem služby DFS Replication.

Další kontroly a nastavení DFSR

Nastavení Primary Member

Nevím, zda to má nějaký význam. Jednoho člena skupiny můžeme nastavit jako primární. Když v průvodci vytváříme novou Replicated Group / Folder, tak volíme, který člen je primární (jeho obsah je autoritativní při úvodní replikaci). Přesto při výpisu, žádný člen jako primární nastaven není.

Pro zobrazení informací můžeme použít příkaz dfsradmin nebo cmdlet Get-DfsrMembership.

PS C:\> Dfsradmin Membership List /RGname:firma.local\dfs\projekty /attr:MemName,RFName,IsPrimary
MemName     RfName    IsPrimary
SERVER1     Projekty  No
SERVER2     Projekty  No

PS C:\> Get-DfsrMembership -GroupName "firma.local\dfs\Projekty" | FT ComputerName, FolderName, PrimaryMember

ComputerName FolderName PrimaryMember
------------ ---------- -------------
SERVER1      Projekty           False
SERVER2      Projekty           False

Get-DfsrMembership | FT ComputerName, GroupName, FolderName, PrimaryMember

Nastavit můžeme pro jednu replikovanou složku nebo rovnou pro všechny.

Set-DfsrMembership -GroupName firma.local\dfs\Projekty -FolderName Projekty -ComputerName SERVER1 -PrimaryMember $true

Get-DfsReplicatedFolder | Set-DfsrMembership -ComputerName SERVER1 -PrimaryMember $true -Force

dfsradmin Membership Set /RGName:<RG name> /RFName:<RF name> /MemName:<primary member> /IsPrimary:True

WMI - Windows Management Instrumentation

Různé informace můžeme zjistit pomocí WMI, kde je i možnost spustit speciální akce. DFSR WMI Classes

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig 
wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo
wmic /namespace:\\root\microsoftdfs path dfsrMachineConfig
wmic /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUID-NUMBER" call ResumeReplication
wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo where "replicatedfoldername='<RFname>'" call cleanupconflictdirectory

Porovnání souborů mezi dvěma servery

Můžeme získat hashe souborů (stejně je počítá DFSR služba) na jednom server a na druhém a pak je porovnat.

Get-DfsrFileHash e:\* | Out-File d:\Srv01.txt
Get-DfsrFileHash e:\* | Out-File d:\Srv02.txt
Compare-Object -ReferenceObject (Get-Content d:\Srv01.txt) -DifferenceObject (Get-Content d:\Srv02.txt) -IncludeEqual 

Kontrola parametrů spojení (Connections) mezi členy

Get-DfsrConnection | FT GroupName,SourceComputerName,DestinationComputerName,Enabled,RdcEnabled,CrossFileRdcEnabled,State -AutoSize 

Zobrazení informací v PowerShellu

Příklady zobrazení různých informací. Záleží, jaké hodnoty nás zajímají.

Get-DfsReplicationGroup | FT GroupName,State,Identifier
Get-DfsReplicatedFolder | FT GroupName,FolderName,Identifier,State,DfsnPath
Get-DfsrMember | FT GroupName,ComputerName,State
Get-DfsrMembership | FT ComputerName,GroupName,FolderName,PrimaryMember,ContentPath,ReadOnly,Enabled,State
Get-DfsrServiceConfiguration

Zobrazení souborů přesunutých do systémových složek ConflictAndDeleted a PreExisting

Příklad jednoduchého skriptu, který v zadané cestě projde její podsložky. Pokud v ní existuje složka DfsrPrivate a v ní XML soubor ConflictAndDeletedManifest.xml, tak z něj vypíše informace. Jednoduše můžeme zaměnit za soubor PreExistingManifest.xml. Pro jinou organizaci Replicated Folder je třeba upravit (například je možno hledat dané XML soubory na celém disku, to by ale trvalo podstatně déle).

$SourceFolder = "d:\dfs"
$Path = "\DfsrPrivate\ConflictAndDeletedManifest.xml"
Get-ChildItem $SourceFolder -Directory | Where-Object { Test-Path ($_.FullName + $Path) -PathType Leaf } | 
 ForEach-Object { Get-DfsrPreservedFiles -Path ($_.FullName + $Path) | FT Path,PreservedReason,FileSize,PreservedTime -AutoSize }

Unexpected (dirty) shutdown

Když se DFSR služba neukončí korektně, tak se označuje jako Unexpected Shutdown.

Zvýšení doby ukončení služby při restartu

Pokud se po restartu serveru v logu událostí (Event Log) objeví Event ID 2212, tak to může znamenat, že se server vypnul příliš rychle, aniž by se korektně ukončila služba DFSR. To může způsobit problémy. Oficiální řešení je zvednou čas ukončení služby You receive DFSR event ID 2212 after you restart the DFSR service in Windows Server 2008. Změníme (nebo vytvoříme) hodnotu v registrech

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WaitToKillServiceTimeout = 6000

Zastavení replikací při AutoRecovery

Pokud došlo k Unexpected shutdown a zalogovala se událost Event ID 2212. Tak Microsoft uvádí, že od určité verze OS je chování takové, že se zastaví replikace a nedojde k AutoRecovery. Má se zalogovat Event ID 2213. Popis DFSR event ID 2213 in Windows Server 2008 R2, Understanding DFSR Dirty (Unexpected) Shutdown Recovery.

Zjistit, zda je toto chování zapnuto (hodnota TRUE nebo 1), můžeme pomocí WMI nebo v registrech.

wmic /namespace:\\root\microsoftdfs path dfsrMachineConfig get StopReplicationOnAutoRecovery
StopReplicationOnAutoRecovery
FALSE

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery

Ověřoval jsem na OS Windows Server 2012 R2 a Windows Server 2016 a všude je vypnuté. Možná toto chování Microsoft opět změnil.

Obnovení replikací

Pokud by se replikace zastavila. Nikde jsem nenalezl, jak ověřit, že je zastavená (všude uvádí pouze hledat událost 2213). Tak musíme použít příkaz pro obnovení. Volume Guid se zobrazuje například v událostech 2212 a 2213.

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUID-NUMBER" call ResumeReplication

Pokud se Event ID 2213 nezaloguje, tak by měla automaticky proběhnout obnova a replikace by měly probíhat. Microsoft pouze uvádí, že po dobu obnovy databáze mohou být replikace zpomalené. Když je dokončeno (může to trvat mnoho hodin), tak se zaloguje Event ID 2214.

Dočasný problém - No Instance(s) Available

Narazil jsem na situaci, kdy se dělaly na serveru nějaké opravy. Po spuštění se mi zdálo, že replikace neprobíhají. Napovídaly tomu dvě informace. Stav replikací vracel, že neexistuje žádná instance.

PS C:\> wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo get replicationgroupname,replicatedfoldername,state
No Instance(s) Available.

Podobně vracel chybu příkaz Get-DfsrBacklog volaný pro cílový server.

Get-DfsrBacklog : No replicated folders were found on the member. Member name: server3 Replicated folder: "*" Replication group: "*"

V logu jsem objevil Event ID 2212, po několika hodinách se zalogovalo Event ID 2218 a chvíli na to Event ID 2002. Pak již stav replikací zobrazil seznam složek.

Systémové složky DFS replikací

Složka DfsrPrivate a její podsložky

V každé replikované složce (Replicated Folder) na každém členském serveru se v jejím kořeni (Root) nachází skrytá složka DfsrPrivate. Přesněji je to pouze odkaz - Directory Junction do složky \System Volume Information\DFSR\Private\<ReplicatedFolderGuid-MemberGuid> na stejném disku. Přímo ve složce mohou být XML soubory se seznamem položek dané podsložky.

Pod DfsrPrivate se mohou nacházet složky:

• ConflictAndDeleted - pokud je soubor (konfliktně) změněn na více serverech, tak je nezvolená verze uložena do této složky, v konfiguraci serveru určitého RF v RG se nastavuje kvóta na velikost této složky (záložka Advanced)
• Deleted - používá se pouze, pokud není zatrženo Move deleted files to Conflict and Deleted folder, při smazání se sem soubor na chvíli přesune, aktualizuje se DFSR databáze a pak se smaže
• Installing - zde se dočasně ukládá sestavený soubor se změnami přenesenými od replikačních partnerů
• PreExisting - pokud během úvodní synchronizace (Initial Synchronization) existovala nějaká data, která neodpovídají zdroji, tak se přesunou sem
• Staging - slouží jako fronta pro změny, které se mají replikovat, v konfiguraci serveru určitého RF v RG se nastavuje kvóta na velikost této složky (záložka Staging)

Nenalezl jsem žádný oficiální popis této oblasti od Microsoftu. Podle určitých informací probíhá replikace, pokud je zapnuto Remote Differential Compression (RDC), následně. Odesílající server vytvoří komprimovanou reprezentaci souboru ve složce Staging. Tento soubor, nebo pouze jeho část, se odešle příjemci, kde se také uloží do složky Staging. Soubor se dekomprimuje a sestaví ve složce Installing. Následně se aktualizuje cílový soubor v Replicated Folder. Pokud se detekuje konflikt v aktualizovaném souboru, tak se původní (přepisovaný) přesune do složky ConflictAndDeleted.

Složka PreExisting může v určité situaci obsahovat hodně dat. Pokud zjistíme, že je nepotřebujeme, tak snad můžeme vymazat. Diskuse často uvádí, že efektivnější než použít grafický nástroj, je využít příkaz robocopy. Vytvoříme prázdnou složku a obsah cílové složky smažeme následně.  

robocopy d:\empty d:\DFS\Administrativa\DfsrPrivate\PreExisting /MIR

Podobně můžeme chtít vymazat obsah složky ConflictAndDeleted nebo se může stát, že překročí svoji nastavenou velikost. K tomu má Microsoft oficiální postup The ConflictAndDeleted folder size may exceed its configured limitation, Manually Clearing the ConflictAndDeleted Folder in DFSR.

wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo where "replicatedfoldername='<ReplicatedFolderName>'" call cleanupconflictdirectory

Složky DFSR Config a Database

Výše jsme zmínili složku DfsrPrivate. V cestě \System Volume Information\DFSR\ se nachází další dvě důležité složky.

• Config - obsahuje konfigurační informace v XML stažené z AD DS, odpovídá aktuálně nastaveným Replication Group a Replicated Folder
• Database_* - zde se nachází Jet databáze, kterou používá DFSR služba, ukládá informace o verzích souborů a další metadata per Replicated Folder

DFS a Access-Based Enumeration

Jednou z novinek DFS ve Windows Server 2008 mode je Access-Based Enumeration pro DFS. Access-Based Enumeration je příjemná vlastnost, kterou můžeme doinstalovat do Windows Server 2003 a je součástí Windows Server 2008, pro sdílené složky (share). Zajišťuje, že uživatel nevidí složky, na které nemá oprávnění. U klasických sdílených složek se prostě zapne na daný share a pak se využívá Security oprávnění na složkách a podle toho se uživatelům zobrazují.

U DFS by Access-Based Enumeration mělo zajistit skrytí složek (Folders) na úrovni DFS. Myšlenka dobrá, ale připadá mi, že je to uděláno dost nepohodlně. Problém je, že v DFS vytváříme strukturu Namespace pomocí Folders, ta se uloží na Namespace serverech. Když zobrazíme DFSroot, tak se zobrazí tato struktura a v tuto chvíli se použijí práva, která jsou nastavena na složky na Namespace serveru (ne na fileserveru) v C:\DFSRoots, což jsou defaultně práva děděná z disku a tam je právo čtení pro Domain Users. Když otevíráme nějakou složku, na které je Folder Target, tak se provede přesměrování a nyní se vyhodnocují práva (security) nastavená již na skutečné složce na fileserveru.

Pokud na DFS Namespace zapneme Access-Based Enumeration, tak se běžně nic nestane, protože pro zobrazení se vyhodnocují práva ze struktury na Namespace serveru. Aby vše začalo fungovat, tak musíme projít jednotlivé Foldery a ručně nastavit práva. Práva, která zde nastavíme, se použijí pouze pro zobrazení, nikoliv pro řízení přístupu (takže i když takto zneviditelníme složku, tak pokud uživatel zná cestu a má tam oprávnění, tak ji otevře). Nastavení práv provedeme následovně:

• klikneme pravým tlačítkem na Folder, zvolíme Properties
• přepneme se na záložku Advanced a nastavíme přepínač na Set explicit view permissions on the DFS folder
• klineme na tlačítko Configure view permissions
• zde nastavíme práva skupině nebo osobám, které mají složku vidět

DFSUTIL na klientovi

Řádkový příkaz dfsutil můžeme použít nejen pro konfiguraci namespace či serveru, ale také pro operace na klientovi. Na Windows 7 příkaz doinstalujeme z feature RSAT (Remote Server Administration Tools) pod částí Distributed File System Tools.

Zobrazení informací v keši klienta (namespace, jména serverů, aktivní server):

dfsutil /pktinfo

Smazání lokální keše (odkazy na servery Folder Targets):

dfsutil /pktflush

Zobrazí informace o doménách a kontrolerech:

dfsutil /spcinfo

Donutí klienta aktualizovat informace o doménách:

dfsutil /spcflush