Exporteren (0) Afdrukken
Alles uitvouwen
Expand Minimize

DFS (Distributed File System) in Windows Server 2003 Service Pack 1

Wat doet DFS?

Met DFS (Distributed File System) kunnen beheerders gedeelde mappen op verschillende servers overzichtelijk groeperen door deze aan een of meer DFS-naamruimten te koppelen. Een DFS-naamruimte is een virtuele weergave van alle gedeelde mappen in een organisatie. Met de DFS-functies kan een beheerder bepalen welke gedeelde mappen onder welke naam in een naamruimte komen te staan. Verder kunnen deze mappen hiërarchisch geordend worden. Een gebruiker die de naamruimte bekijkt, ziet alle mappen alsof ze op één grote vaste schijf staan. Gebruikers kunnen vervolgens binnen de mappen in de naamruimte navigeren zonder dat zij de naam hoeven te weten van de server of gedeelde map waar de gegevens eigenlijk staan. DFS biedt ook andere voordelen, zoals fouttolerantie en belastingverdeling, en is hiermee ideaal voor alle typen organisaties.

Op wie is deze functie van toepassing?

Opslagbeheerders die verantwoordelijk zijn voor DFS-naamruimten of beheerders die DFS willen gaan gebruiken, moeten bekend zijn met de wijzigingen in SP1.

Welke nieuwe functionaliteit is aan deze functie toegevoegd in Windows Server 2003 Service Pack 1?

DFS-consolidatie van hoofdmappen

Gedetailleerde beschrijving

Voor alle nieuwe DFS-functies geldt dat het oorspronkelijke UNC-pad (Universal Naming Convention) van bestanden geldig blijft nadat deze naar een andere server zijn verplaatst. Zo blijven de gevolgen van consolidatie- en migratieprocessen van bestandsservers tot een minimum beperkt. De eindgebruikers hoeven niet op zoek naar hun bestanden en alle bedrijfstoepassingen blijven gewoon draaien.

Wat is het belang van deze wijziging?

Er zijn vele situaties denkbaar waarbij u wilt dat de UNC-paden (Universal Naming Convention) hetzelfde blijven wanneer de onderliggende bestanden naar een andere server of locatie worden verplaatst. Dit kan bijvoorbeeld het geval zijn wanneer u alle bestaande bestandsservers migreert naar of consolideert tot nieuwe computers met Microsoft Windows Server 2003. De UNC-paden kunnen immers in koppelingen of bedrijfstoepassingen zijn opgenomen, of op andere plaatsen staan waar ze moeilijk kunnen worden gewijzigd.

Wat werkt er anders?

U kunt de consolidatiefunctionaliteit voor hoofdmappen het beste configureren met de File Server Migration Toolkit. Deze vindt u op de website van Microsoft op http://go.microsoft.com/fwlink/LinkId=37029.

U kunt deze functionaliteit ook handmatig configureren door de sleutels in het Windows-register te wijzigen. Dit wordt beschreven in het artikel over het gebruik van de DFS-update (Distributed File System) voor ondersteuning van de consolidatie van hoofdmappen op de website van Microsoft op http://go.microsoft.com/fwlink/LindId=43006.

DFS-naamruimten verplaatsen of een andere naam geven

Gedetailleerde beschrijving

Beheerders kunnen de DFS-naamruimte wijzigen om fouten te verbeteren of om de hiërarchie aan te passen als de bedrijfsvoering daarom vraagt of als nieuwe mappen worden toegevoegd.

Wat is het belang van deze wijziging?

Vóór Windows Server 2003 Service Pack 1 konden beheerders naamruimte-elementen geen andere naam geven. Als zij een element boven in een naamruimte een andere naam wilden geven of wilden verplaatsen, moesten zij alle onderliggende elementen stuk voor stuk handmatig verwijderen en vervolgens weer opnieuw maken.

Wat werkt er anders?

Voortaan kunnen DFS-beheerders echter het opdrachtregelprogramma dfscmd gebruiken om koppelingen te verplaatsen of een andere naam te geven. Dit is de syntaxis van deze nieuwe opdracht:

dfscmd /move \\ DFS-naam \ DFS-sharenaam \ Pad \\ Servernaam \ Sharenaam \ Pad

In de volgende voorbeelden kunt u zien op welke manieren u deze opdracht kunt toepassen:

  • Als u een nieuwe map wilt maken, verplaatst u de inhoud van een bestaande map naar de nieuwe map. Vervolgens past u alle koppelingen onder deze map navenant aan:
    dfscmd /move \\domain\root\old_folder \\domain\root\new_folder
  • Van een bestaande map een submap van een nieuwe hoofdmap maken en alle koppelingen onder de map navenant aanpassen:
    dfscmd /move \\domain\root\old_folder \\domain\root\new_top_folder\old_folder
  • De inhoud van de ene naar de andere bestaande map verplaatsen
    dfscmd /move \\domain\root\folder \\domain\root\other-folder\

Clientfailback

Gedetailleerde beschrijving

Clientfailover in DFS-naamruimten is een proces waarbij clients proberen via een verwijzing toegang te krijgen tot een andere server als een van de servers niet goed werkt of uit de naamruimte is verwijderd. DFS-beheerders kunnen aangeven dat clients weer moeten terugvallen ("fail back") op de lokale voorkeursserver zodra de storing is verholpen. Het beleid voor de gewenste failback kan voor de gehele hoofdmap worden ingesteld of voor afzonderlijke koppelingen.

Wat is het belang van deze wijziging? Welke risico's worden op deze manier aangepakt?

Vóór Windows Server 2003 Service Pack 1 konden beheerders op geen enkele manier aangeven dat clients via failback weer op hun lokale server moesten terugvallen. Dit kan in een filiaalomgevingen problemen opleveren als clients steeds een beroep blijven doen op de hubserver terwijl de filiaalserver weer goed werkt.

Wat werkt er anders?

De failback-instellingen voor hoofdmappen en koppelingen kunnen met de optie /TargetFailback van dfsutil worden ingesteld. Bovendien moet de DFS-client-hotfix voor failback voor Windows XP en Windows Server 2003 worden geïnstalleerd om deze functionaliteit te implementeren.

Als de registersleutel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters\SysvolNetlogonTargetFailback is ingesteld en de DFS-service op de domeincontroller opnieuw is gestart, wordt de gewenste failback voor SYSVOL/NETLOGON-verwijzingsaanvragen voor die controller ingeschakeld.

Doelprioriteit

Gedetailleerde beschrijving

Met de functie voor doelprioriteit kunnen DFS-beheerders expliciet een prioriteit toewijzen aan een DFS-koppeling of hoofddoel.

Wat is het belang van deze wijziging? Welke risico's worden op deze manier aangepakt?

Vóór Windows Server 2003 Service Pack 1 konden beheerders op geen enkele manier een voorkeursserver instellen als dezelfde gegevens op meerdere servers in een naamruimte stonden. Dit probleem werd via een omweg opgelost; de beheerders maakten namelijk speciale subnetten voor deze servers, alsmede kunstmatige sites in Active Directory, met alle gevolgen van dien. Deze methode was complex, kostte veel tijd en bracht hogere ondersteuningskosten met zich mee.

Voortaan kunnen nieuwe API's voor DFS-beheer wordt gebruikt om aan te geven welke server als eerste/laatste in een verwijzing wordt vermeld, de lijst met servers die voor een gegeven map (koppeling) in de naamruimte naar een client wordt verzonden. Het toewijzen van een doelprioriteit kan vaak handig zijn, bijvoorbeeld wanneer een bepaalde server als laatste terugvalmogelijkheid is ingesteld. In dat geval zal een beheerder deze stand-by-server altijd als laatste in een verwijzing plaatsen. Clients maken dan alleen van deze server gebruik als alle andere servers niet werken of vanwege een netwerkstoring niet beschikbaar zijn.

Wat werkt er anders?

De doelen in een DFS-verwijzingsantwoord zijn op basis van de toegangskosten voor doelen vanuit een client gegroepeerd in sets. Binnen elke set worden de doelen willekeurig gerangschikt; deze sets worden op basis van de kosten voor de DFS-client in oplopende volgorde gerangschikt. Vóór Windows Server 2003 SP1 was het aantal sets in het verwijzingsantwoord afhankelijk van het feit of de kostenfunctie voor sites in Windows Server 2003 was ingeschakeld. Als de kostenfunctie voor sites was uitgeschakeld, waren er exact twee sets: een set met alle doelen op dezelfde site als de DFS-client en een set met alle overige doelen. Als de kostenfunctie voor sites was ingeschakeld, werden de sets gegroepeerd op basis van de werkelijke sitekosten van het doel vanaf de DFS-client. Op die manier kon er sprake zijn van veel meer sets. Verder is in de huidige DFS V1-, V2- of V3-verwijzingsantwoorden geen informatie beschikbaar aan de hand waarvan een DFS-client deze sets van elkaar kan onderscheiden.

Ook bij het gebruik van doelprioriteiten zijn deze sets nog steeds gebaseerd op de toegangskosten van doelen. De functie voor serverdoelprioriteit houdt simpelweg in dat de sorteercriteria voor kosten ook voor doelen gelden. De sets bestaan nu uit alle doelen die dezelfde sitekosten en serverdoelprioriteit hebben. Verder wordt in het nieuwe V4-protocol aangegeven waar de grenzen van de sets liggen in de lijst met doelen.

De serverdoelprioriteit bestaat uit twee waarden: een prioriteitsklasse en een prioriteitspositie. De prioriteitsklasse wordt op twee niveaus bepaald: lokaal, binnen de sets met doelen met dezelfde sitekosten, en globaal. Binnen deze klassen is er verder een grove indeling in doelen met een hoge, normale en lage prioriteit. Zo heeft u de beschikking over vijf prioriteitsklassen in deze volgorde:

N.B.: er is geen aparte categorie “globaal/normaal”. Als niet "globaal/hoog" of "globaal/laag" is opgegeven, wordt de verwijzing in de set "globaal/normaal" geplaatst. De prioriteitspositie wordt simpelweg door een nummer aangegeven: 0, 1, 2 enzovoort.

Het rangschikken van een verwijzing verloopt nu als volgt:

  • Er wordt vastgesteld welke sets globaal hoge en globaal lage doelen bevatten, alsmede welke set alle overige, globaal normale doelen bevat.
  • Deze drie sets worden in de volgorde globaal/hoog - normaal - laag gerangschikt.
  • Als INSITE is ingesteld, wordt deze toegepast op de normale set. Alle doelen buiten de clientsite worden verwijderd. Deze bewerking wordt niet toegepast op globaal/hoog en globaal/laag.
  • Binnen deze drie sets worden de doelen gerangschikt op de sitekosten (kosten van de lokale of van de volledige site). Zo ontstaan sets met doelen met dezelfde sitekosten.
  • Binnen de sets met globaal normale doelen met dezelfde sitekosten worden de doelen op prioriteitsklasse gerangschikt: hoge, normale en lage sitekosten.
  • Binnen de sets met doelen met dezelfde sitekosten en prioriteitsklasse worden de doelen vervolgens gerangschikt op prioriteitspositie (0 = de hoogste).
  • Tot slot worden de doelen binnen de sets met doelen met dezelfde sitekosten, prioriteitsklasse en prioriteitspositie willekeurig gerangschikt voor de taakverdeling.

De bovenstaande prioriteitsopties worden ingesteld met de optie /targetpriority van dfsutil.

Welke bestaande functionaliteit verandert in Windows Server 2003 Service Pack 1?

Betere overdracht

Gedetailleerde beschrijving

Vanaf Windows Server 2003 Service Pack 1 kunnen beheerders het recht om DFS-toegangspunten op domeinniveau te beheren aan anderen overdragen. Dit is mogelijk door de juiste rechten toe te wijzen aan het DFS-object in Active Directory. Verder mogen beheerders ook het recht om zelfstandige DFS-toegangspunten te beheren aan anderen overdragen. Dit is mogelijk door de juiste rechten toe te wijzen aan het DFS-object in het register. Dit is een uitbreiding van het bestaande overdrachtsmodel, waarbij DFS-beheerders kunnen worden toegevoegd aan de groep lokale Administrators op elke hostserver van de naamruimte.

Wat is het belang van deze wijziging?

In de vorige versies van Windows Server 2003 konden beheerders het beheer van een naamruimte alleen aan een andere gebruiker overdragen als zij deze persoon lid maakten van de lokale groep Administrators op elke hostserver van de naamruimte. Deze manier van werken kon leiden tot beheerconflicten als het lidmaatschap van de groepen niet goed was ingesteld. Bovendien had zo'n gebruiker hierdoor onbeperkt toegang tot het lokale bestandssysteem van elke naamruimteserver.

Wat werkt er anders?

Als gevolg van deze functionaliteitswijziging zijn de volgende procedures aangepast:

Een gebruiker alleen machtigen voor het beheer van een DFS-naamruimte op domeinniveau:
  1. Ga naar de MMC-module Active Directory: gebruikers en computers en klik in het menu Beeld op Geavanceerde kenmerken.

  2. Vouw in de consolestructuur de map Systeem uit door hierop te dubbelklikken.

  3. Klik op de map DFS-configuratie.

    Alle bestaande hoofdobjecten worden weergegeven in het detailvenster.

  4. Klik met de rechtermuisknop op het hoofdobject waarvoor u de gebruiker beheerrechten wilt geven. Klik vervolgens op Eigenschappen.

  5. Klik op het tabblad Beveiliging op Toevoegen.

  6. Typ de naam van de gebruiker en klik op OK.

  7. Controleer of de gebruiker het recht Volledig beheer heeft en klik vervolgens op OK.

noteOpmerking
De rechten van de gebruiker, zoals die zijn vastgelegd in de toegangsbeheerlijst (ACL) die van toepassing is op het DFS-object in Active Directory, worden vastgesteld op het niveau van de afzonderlijke hoofddoelen. Hierdoor worden de rechten die aan bekende gebruikers en groepen zijn toegekend, genegeerd vanwege het mogelijke verschil tussen het lidmaatschap van de bekende groepen in Active Directory en in elk hoofddoel. Als hoofdgebruikers bijvoorbeeld beschikken over het volledige beheer van het DFS-hoofdobject in Active Directory, betekent dit niet dat de hoofdgebruikers in de afzonderlijke hoofddoelen het bijbehorende DFS-toegangspunt mogen beheren. As een bekende gebruiker of groep rechten heeft voor een hoofddoel, maar geen toegang krijgt tot het DFS-hoofdobject in Active Directory, geldt bovendien dat deze weigering wordt genegeerd in de DFS-hoofddoelen.
Een gebruiker machtigen voor het beheer van een zelfstandige DFS-naamruimte
  1. Gebruik regedit om de volgende sleutel op te zoeken:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Standalone

  2. Klik met de rechtermuisknop op het hoofdobject waarvoor u de gebruiker beheerrechten wilt geven. Klik vervolgens op Machtigingen....

  3. Klik op het tabblad Beveiliging op Toevoegen.

  4. Typ de naam van de gebruiker en klik op OK.

  5. Controleer of de gebruiker het recht Volledig beheer heeft en klik vervolgens op OK.

TTL-waarden (Time To Live) voor verwijzingen worden niet vernieuwd voor DFS-clients

Gedetailleerde beschrijving:

Voor DFS-clients die niet op Windows XP met SP2 of Windows Server 2003 met SP1 worden uitgevoerd, bepaalt de TTL-waarde (Time To Live) van een verwijzing het tijdstip waarop een client op zijn vroegst een nieuwe verwijzing aanvraagt. Dit geldt echter alleen als de bestaande verwijzing is verlopen voordat deze opnieuw is benaderd. Voor clients die werken met een verwijzing in cache, geldt dat de TTL-waarde van de verwijzing wordt vernieuwd. Zo wordt de verwijzing steeds opnieuw gebruikt totdat de cache met de verwijzingen wordt gewist of de client opnieuw wordt gestart.

Dit gedrag is gewijzigd voor clients die op Windows XP met SP2 en Windows Server 2003 met SP1 worden uitgevoerd. De TTL-waarde wordt namelijk niet meer steeds vernieuwd op het moment dat een client een doel benadert via een verwijzing in de cache. In plaats daarvan vervalt de verwijzing zodra de TTL-waarde is bereikt.

Wat is het belang van deze wijziging?

Door deze wijziging kunnen DFS-clients die op Windows XP met SP2 of Windows Server 2003 met SP1 worden uitgevoerd, de werkelijke TTL-waarde van een verwijzing aanhouden. Een groot voordeel is dat DFS-clients die van deze servicepacks zijn voorzien, wijzigingen in koppelingen en hoofdmappen sneller doorvoeren. Als bijvoorbeeld de doelen van een koppeling met de naam Huidig elke dag worden gewijzigd, wordt de TTL-waarde in een DFS-client zonder deze servicepacks steeds vernieuwd zodra de koppeling Huidig wordt benaderd. Dit betekent dat de verwijzing naar verouderde doelen blijft bestaan terwijl de TTL-waarde voor de oorspronkelijke verwijzingsaanvraag al lang is bereikt.

Wat werkt er anders?

Deze wijziging heeft verschillende gevolgen:

  • Clients die op Windows XP met SP2 of Windows Server 2003 met SP1 worden uitgevoerd, vragen vaker een verwijzing aan dan andere DFS-clients. Hierdoor wordt de belasting op DFS-basisservers op domeinniveau, zelfstandige basisservers en domeincontrollers enigszins groter.
  • Omdat clients die op Windows XP met SP2 of Windows Server 2003 met SP1 worden uitgevoerd, vaker verwijzingen aanvragen, worden wijzigingen van naamruimten sneller opgepikt dan in andere DFS-clients.
  • Wat de DFS-failover betreft betekent dit nieuwe gedrag dat er in een DFS-client een failover plaatsvindt naar een nieuw doel als het vorige actieve doel niet voorkomt in de nieuwe verwijzing. Dit is bijvoorbeeld het geval wanneer het doel dat de client had benaderd uit de naamruimte is verwijderd.

Service standaard uitgeschakeld

Gedetailleerde beschrijving

De DFS-service is in Windows Server 2003 Service Pack 1 standaard uitgeschakeld.

Wat is het belang van deze wijziging?

In Windows Server 2003 SP1 zijn onnodige services standaard uitgeschakeld om de kwetsbaarheid van de server tot een minimum te beperken.

Wat werkt er anders?

Voor computers waarop Windows Server 2003 met Service Pack 1 voor het eerst wordt geïnstalleerd, geldt dat de DFS-service standaard is uitgeschakeld.

Als Service Pack 1 wordt geïnstalleerd op een computer met Windows Server 2003, wordt de DFS-service ook uitgeschakeld, behalve wanneer de server een domeincontroller is of al als hostserver voor een bestaand DFS-toegangspunt fungeert.

Zodra een server met Windows Server 2003 Service Pack 1 tot domeincontroller wordt gepromoveerd, wordt de DFS-service ingeschakeld.

Welke instellingen zijn toegevoegd of gewijzigd in Windows Server 2003 Service Pack 1?

 

Naam van instelling Locatie Vorige standaardwaarde Standaardwaarde Mogelijke waarden

Nieuwe poging van serverconsolidatie

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services\Dfs \Parameters\Replicated

N.v.t.

0

0,1

Consolidatie aanmeldingsserver

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services\Dfs \Parameters\Replicated

N.v.t.

0

0,1

Gewenste failback voor Sysvol/Netlogon

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services\Dfs \Parameters

N.v.t.

0

0,1

Vindt u dit nuttig?
(1500 tekens resterend)
Bedankt voor uw feedback

Community-inhoud

Toevoegen
Weergeven:
© 2014 Microsoft