15
Frage zu domänenbasierten DFS Namespaces
Hallo zusammen,
ich erstelle gerade ein Konzept für eine neue File-Service-Infrastruktur und hänge an einer vermeintlich simplen Stelle gedanklich fest. Ich habe bisher nur Erfahrung mit Stand-Alone Namespaces, möchte nun aber Domain-Based Namespaces verwenden. Soweit alles kein Problem.
Mir ist nun jedoch nicht klar, ob ich bei Domain-Based Namespaces noch immer dedizierte Namespace-Server benötige. Der Sinn hinter Domain-Based Namespaces ist ja eigentlich, dass die DFS-Funktionalität vom Active Directory bereitgestellt wird und von den Domänen-Controllern gemanaged wird. Nach dem Lesen der Microsoft-Dokumentation klingt es nun jedoch manchmal so, dass dedizierte Namespace-Server benötigt werden, manchmal aber auch so, dass diese Rolle von den Domänen-Controllern übernommen wird.
Was ist denn nun korrekt? Sind dedizierte Namespace-Server ggf. optional, aber nicht mandatorisch? Ich behaupte, dass Domänen-Controller diese Rolle übernehmen, aber ergänzend oder auch stattdessen dedizierte Namespace-Server zum Einsatz kommen können, um bspw. eine DFS-Root in einem Branch Office abzubilden, an dem kein Domänen-Controller vorhanden ist. Was ja aber auch blödsinnig wäre, denn der Einstiegspunkt, um den Root-Server zu finden, wäre ja trotzdem das Active Directory...
Dementsprechend braucht es meiner Meinung nach bei Domain-Based Namespaces in erster Linie nur die Domänen-Controller. Richtig?
Danke für eure Unterstützung.
Viele Grüße.
ich erstelle gerade ein Konzept für eine neue File-Service-Infrastruktur und hänge an einer vermeintlich simplen Stelle gedanklich fest. Ich habe bisher nur Erfahrung mit Stand-Alone Namespaces, möchte nun aber Domain-Based Namespaces verwenden. Soweit alles kein Problem.
Mir ist nun jedoch nicht klar, ob ich bei Domain-Based Namespaces noch immer dedizierte Namespace-Server benötige. Der Sinn hinter Domain-Based Namespaces ist ja eigentlich, dass die DFS-Funktionalität vom Active Directory bereitgestellt wird und von den Domänen-Controllern gemanaged wird. Nach dem Lesen der Microsoft-Dokumentation klingt es nun jedoch manchmal so, dass dedizierte Namespace-Server benötigt werden, manchmal aber auch so, dass diese Rolle von den Domänen-Controllern übernommen wird.
Was ist denn nun korrekt? Sind dedizierte Namespace-Server ggf. optional, aber nicht mandatorisch? Ich behaupte, dass Domänen-Controller diese Rolle übernehmen, aber ergänzend oder auch stattdessen dedizierte Namespace-Server zum Einsatz kommen können, um bspw. eine DFS-Root in einem Branch Office abzubilden, an dem kein Domänen-Controller vorhanden ist. Was ja aber auch blödsinnig wäre, denn der Einstiegspunkt, um den Root-Server zu finden, wäre ja trotzdem das Active Directory...
Dementsprechend braucht es meiner Meinung nach bei Domain-Based Namespaces in erster Linie nur die Domänen-Controller. Richtig?
Danke für eure Unterstützung.
Viele Grüße.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 625246
Url: https://administrator.de/contentid/625246
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
15 Kommentare
Neuester Kommentar
Es werden Server benötigt auf denen man die DFS Rolle aktiviert, diese Rolle hat ein paar Features, und das wars. Es sei denn wir sprechen hier von Museumsinfrastukturen im Windows 2000-Bereich. Man kann sich im Server 2008R2 und höher entschenden, ob der Server eben nur DFS Management macht (Dann verwaltet der tatsächlichnur noch den Namespace) oder auch einen Fileshare beherbergt u.s.w.
Dann sprichst du von Branch offices, das wäre schon ein Beispiel für DFSR / RDC. Gibt nen Artikel wie man das einrichtet - hat mir am Ende sehr geholfen.
https://www.mcseboard.de/topic/190738-einrichtung-dfs-replikation-mit-df ...
Der Rest funktioniert tatsächlich autonom im AD über ein paar Properties bzw. Objekte anhand denen der Fileshare-Client in Windows auch DFS Pfade auswerten kann. Im Branch office hat man typsicherweise einen Server stehen, der zumindestens mal als AD Replica funktioniert, damit Anmeldeprozesse nicht quer durchs Netz laufen, und auf dem kann man die DFS Rolle natürlich ncoh mit dazukonfigurieren.
Letztenendlich ist nur die Dateireplikation etwas worüber man nachdenken sollte... denn die verschlingt Bandbreiten und CPU-Cores wenn sie was zu tun kriegt. Das über WAN Anbindungen dann so zu konfigurieren daß die Leitung hinterher noch gut funktioniert ist dann die Kunst.
Dann sprichst du von Branch offices, das wäre schon ein Beispiel für DFSR / RDC. Gibt nen Artikel wie man das einrichtet - hat mir am Ende sehr geholfen.
https://www.mcseboard.de/topic/190738-einrichtung-dfs-replikation-mit-df ...
Der Rest funktioniert tatsächlich autonom im AD über ein paar Properties bzw. Objekte anhand denen der Fileshare-Client in Windows auch DFS Pfade auswerten kann. Im Branch office hat man typsicherweise einen Server stehen, der zumindestens mal als AD Replica funktioniert, damit Anmeldeprozesse nicht quer durchs Netz laufen, und auf dem kann man die DFS Rolle natürlich ncoh mit dazukonfigurieren.
Letztenendlich ist nur die Dateireplikation etwas worüber man nachdenken sollte... denn die verschlingt Bandbreiten und CPU-Cores wenn sie was zu tun kriegt. Das über WAN Anbindungen dann so zu konfigurieren daß die Leitung hinterher noch gut funktioniert ist dann die Kunst.
hi
du brauchst einen Server der die DFS Rolle hat.
Dieser übermittelt den Clients am Ende nur die Info wo sie ihre Daten finden können.
Aus diesem Grund solltest du, falls das eine Anforderung für dich ist, mind. 2 DFS Server haben, die den Namespace bedienen, da sonst beim Ausfall oder Reboot des einen die Clients nicht mehr auf das DFS zugreifen können.
Und nein, man macht das nicht auf dem DC. Denn ein DC ist ein DC ist ein DC und nur ein DC.
Von daher: Eine eigene VM macht schon Sinn, wenn die Lizenzen das hergeben. Ansonsten kann das natürlich auch auf einem sonstigen Server laufen.
du brauchst einen Server der die DFS Rolle hat.
Dieser übermittelt den Clients am Ende nur die Info wo sie ihre Daten finden können.
Aus diesem Grund solltest du, falls das eine Anforderung für dich ist, mind. 2 DFS Server haben, die den Namespace bedienen, da sonst beim Ausfall oder Reboot des einen die Clients nicht mehr auf das DFS zugreifen können.
Und nein, man macht das nicht auf dem DC. Denn ein DC ist ein DC ist ein DC und nur ein DC.
Von daher: Eine eigene VM macht schon Sinn, wenn die Lizenzen das hergeben. Ansonsten kann das natürlich auch auf einem sonstigen Server laufen.
N'Abend.
Cheers,
jsysde
Zitat von @SeaStorm:
[...]Und nein, man macht das nicht auf dem DC. Denn ein DC ist ein DC ist ein DC und nur ein DC.
Jein - DC ist DC, da bin ich bei dir. Aber die Rolle des DFS-Namespace-Servers kann durchaus und problemlos auf einem DC betrieben werden. Wichtig ist eben, dass die Foldertargets dabei _nicht!_ auf dem DC liegen, sondern auf einem dedizierten Fileserver. Entsprechend findet dann auch die DFS-Replikation (sofern man mehrere Foldertargets hat) dann auch nicht auf dem DC statt, sondern auf dem Fileserver.[...]Und nein, man macht das nicht auf dem DC. Denn ein DC ist ein DC ist ein DC und nur ein DC.
Cheers,
jsysde
Guten Morgen zusammen,
schon mal danke für eure Rückmeldungen.
@GrueneSosseMitSpeck: Um die File Shares geht es ja noch gar nicht. Ich bin erst mal nur bei den Namespaces. Die Frage ist einfach nur, ob die DCs den Namespace hosten oder nicht. DFS Replication ist ja auch schon wieder ein anderes Thema.
@SeaStorm:
Da bin ich vollkommen bei dir, und so wird es auch gehandhabt, aber die DFS-Daten liegen ja nativ im AD und so gesehen nicht zusätzlich auf den DCs. Das ist ja so gewollt. Aber auch hier: Warum ein eigener Server, wenn alle Daten (Namespace und Links) aus dem AD kommen? Was würde der Namespace Server denn dann konkret tun, denn es gibt ja nichts, was das AD nicht schon weiß.
@jsysde: Natürlich liegen die Shares auf einem eigenen File Server und nicht auf DCs. Aber muss ich auf dem DC, wenn er den Namespace hosten soll, wirklich extra die Namespace-Rolle installieren? Die hätte ja gar nichts zu tun, weil die Daten ja alle in der AD-Datenbank liegen.
Versteht ihr, was ich nicht meine?
Danke und viele Grüße.
schon mal danke für eure Rückmeldungen.
@GrueneSosseMitSpeck: Um die File Shares geht es ja noch gar nicht. Ich bin erst mal nur bei den Namespaces. Die Frage ist einfach nur, ob die DCs den Namespace hosten oder nicht. DFS Replication ist ja auch schon wieder ein anderes Thema.
@SeaStorm:
Denn ein DC ist ein DC ist ein DC und nur ein DC.
Da bin ich vollkommen bei dir, und so wird es auch gehandhabt, aber die DFS-Daten liegen ja nativ im AD und so gesehen nicht zusätzlich auf den DCs. Das ist ja so gewollt. Aber auch hier: Warum ein eigener Server, wenn alle Daten (Namespace und Links) aus dem AD kommen? Was würde der Namespace Server denn dann konkret tun, denn es gibt ja nichts, was das AD nicht schon weiß.
@jsysde: Natürlich liegen die Shares auf einem eigenen File Server und nicht auf DCs. Aber muss ich auf dem DC, wenn er den Namespace hosten soll, wirklich extra die Namespace-Rolle installieren? Die hätte ja gar nichts zu tun, weil die Daten ja alle in der AD-Datenbank liegen.
Versteht ihr, was ich nicht meine?
Danke und viele Grüße.
AFAIK kommen die Daten nicht aus dem AD. Nicht für den Client. Der bekommt die Info über den DFS Service, der diese Info aus dem AD hat. Man kann ja einstellen welcher DFS Server welchen Namespace bedient
Hier mal eine technische Darstellung, wie DFS funktioniert:
(Quelle: How DFS Works | Microsoft Docs)
Hier ist von CIFS die Rede, da die Grafik aus 2003er-Zeiten stammt, aber das Prinzip ist bei SMBv2/SMBv3 dasselbe. Ich verstehe das so, dass die Daten am Ende von beiden Servern zugeliefert werden können. Zunächst wird der Cache befragt oder eben das Active Directory. Daher vermute ich, dass der Namespace nicht zusätzlich auf dedizierten Servern gehostet werden muss, da er immer auf den Domänen-Controllern vorgehalten wird.
Dazu sagt Microsoft ja auch:
Das widerspricht auch nicht deinem korrekten Prinzip
Danke.
Hier ist von CIFS die Rede, da die Grafik aus 2003er-Zeiten stammt, aber das Prinzip ist bei SMBv2/SMBv3 dasselbe. Ich verstehe das so, dass die Daten am Ende von beiden Servern zugeliefert werden können. Zunächst wird der Cache befragt oder eben das Active Directory. Daher vermute ich, dass der Namespace nicht zusätzlich auf dedizierten Servern gehostet werden muss, da er immer auf den Domänen-Controllern vorgehalten wird.
Dazu sagt Microsoft ja auch:
Root servers (also called root targets) are the servers on which administrators create stand-alone and domain-based namespaces. A root server can be a member server or a domain controller.
Das widerspricht auch nicht deinem korrekten Prinzip
Denn ein DC ist ein DC ist ein DC und nur ein DC.
denn es wird ja keine zusätzliche Rolle installiert. Ich bin nur irritiert, weil ich noch kein Beispiel gefunden habe, in denen keine zusätzlichen Namespace-Server verwendet wurden und suche nun halt den Grund, was das für einen Vorteil bieten soll.Danke.
@Festus94
Das ist eigentlich ganz einfach:
AD speichert und stellt die Informationen über domänenbasierte DFS-Namespaces bereit. Der DFS-Dienst stellt die DFS-Namespaces bereit. Man braucht also immer beides. Und für AD braucht man dann auch noch einen DNS-Server.
Ich bin auch dafür, dass man DC und FS trennen sollte, wenn möglich. Aber ich sehe kein Problem darin, einen DC nebenbei auch als Server für die Bereitstellung weiterer DFS-Namespace zu verwenden. Er stellt ja sowieso schon einen DFS-Namespace bereit: SYSVOL.
Wir halten das bei uns jedenfalls so:
Auf den DC's (nicht allen, min. 2, ggf. auch DC's an den Standorten) von Domänen, in welchen es Namespaces gibt, hosten die Root-Freigaben für diese Namespaces. Dafür benötigen die DC's nur ein paar Byte Festplatte. Jede Root mit min. 2 Zielen (ganz ohne Replikation).
Die Freigabe der DFS-Ordner werden von dedizierten File- und/oder Applikationsservern gehostet.
Die Idee dahinter ist die:
Der DFS-Client benötigt sowieso einen DC, um auf einen DFS-Namespace zugreifen zu können. Er benötigt aber auch die DFS-Namespace-Root. Um nicht unnötig zwei Abhängigkeiten zu haben, haben wir die DFS-Roots auch auf die DC's gelegt. Die DC's sind auch DNS-Sever.
Man muss dann nur aufpassen, wenn man mal die DC's durch neue ersetzt (neue OS-Versionen), dass man dann die diversen DFS-Roots nicht vergisst. Und, dass man - natürlich! - in den Roots niemanden(!) Schreibrechte erteilt, auch den Admins nicht, weil sonst auf den Root-Freigaben der DC's ungewollt Daten landen.
Die Mehrbelastung der DC's dadurch ist unerheblich. Nur Sitzungen, welche immer wieder in der Root eines Namespace browsen, z.B. weil sie einen Explorer mit der DFS-Root als Pfad offen haben, halten permanent SMB-Sitzungen am DC offen. Alle anderen werden wieder geschlossen, weil der Client dann ja nur in den einmal ermittelten Freigaben der DFS-Ordner arbeitet.
Beachte auch, dass bei über mehrere Standorte verteilte und replizierte DFS-Namespaces die Standort-Informationen im AD abgebildet sind, da sonst die Clients u.U. unnötig über WAN arbeiten.
E.
Das ist eigentlich ganz einfach:
AD speichert und stellt die Informationen über domänenbasierte DFS-Namespaces bereit. Der DFS-Dienst stellt die DFS-Namespaces bereit. Man braucht also immer beides. Und für AD braucht man dann auch noch einen DNS-Server.
Ich bin auch dafür, dass man DC und FS trennen sollte, wenn möglich. Aber ich sehe kein Problem darin, einen DC nebenbei auch als Server für die Bereitstellung weiterer DFS-Namespace zu verwenden. Er stellt ja sowieso schon einen DFS-Namespace bereit: SYSVOL.
Wir halten das bei uns jedenfalls so:
Auf den DC's (nicht allen, min. 2, ggf. auch DC's an den Standorten) von Domänen, in welchen es Namespaces gibt, hosten die Root-Freigaben für diese Namespaces. Dafür benötigen die DC's nur ein paar Byte Festplatte. Jede Root mit min. 2 Zielen (ganz ohne Replikation).
Die Freigabe der DFS-Ordner werden von dedizierten File- und/oder Applikationsservern gehostet.
Die Idee dahinter ist die:
Der DFS-Client benötigt sowieso einen DC, um auf einen DFS-Namespace zugreifen zu können. Er benötigt aber auch die DFS-Namespace-Root. Um nicht unnötig zwei Abhängigkeiten zu haben, haben wir die DFS-Roots auch auf die DC's gelegt. Die DC's sind auch DNS-Sever.
Man muss dann nur aufpassen, wenn man mal die DC's durch neue ersetzt (neue OS-Versionen), dass man dann die diversen DFS-Roots nicht vergisst. Und, dass man - natürlich! - in den Roots niemanden(!) Schreibrechte erteilt, auch den Admins nicht, weil sonst auf den Root-Freigaben der DC's ungewollt Daten landen.
Die Mehrbelastung der DC's dadurch ist unerheblich. Nur Sitzungen, welche immer wieder in der Root eines Namespace browsen, z.B. weil sie einen Explorer mit der DFS-Root als Pfad offen haben, halten permanent SMB-Sitzungen am DC offen. Alle anderen werden wieder geschlossen, weil der Client dann ja nur in den einmal ermittelten Freigaben der DFS-Ordner arbeitet.
Beachte auch, dass bei über mehrere Standorte verteilte und replizierte DFS-Namespaces die Standort-Informationen im AD abgebildet sind, da sonst die Clients u.U. unnötig über WAN arbeiten.
E.
2
Hi @emeriks,
danke für deine ausführliche Antwort. Ganz genau so sehe ich das auch.
Muss ich dann eine DFS-Rolle auf den DCs installieren? Da die ja sowieso schon einen DFS-Based Namespace hosten (SYSVOL) müsste das ja eigentlich überflüssig sein. Von daher...
Mich interessiert nur ein technisches Detail. Du schreibst:
Wo ist der Unterschied? Alle Informationen liegen in der Active-Directory-Datenbank, und die Domänen-Controller stellen diese Informationen bereit. Was genau (technisch) macht der Namespace-Server denn anderes, was der DC nicht schon macht?
Microsoft hat die Technik hinter DFS ja sehr schön ausführlich dokumentiert, aber der Unterschied wird daraus leider nicht klar ersichtlich. Oder anders gefragt: Wenn ich die Namespaces nicht auf DCs hosten würde, kämen die Infos ja weiterhin aus dem AD. Was genau tut der Namespace-Server bzw. welche technische Operation funktioniert nicht mehr, wenn der Server nicht erreichbar wäre. Ich frage, weil aus dem großen Bild oben für mich hervorgeht, dass es keine Info gibt, die der DC nicht kennt.
Aber es wird dann wohl auf die Variante ohne dedizierte Namespace-Server hinauslaufen. Mich interessiert trotzdem die Technik im Detail dahinter.
Danke.
danke für deine ausführliche Antwort. Ganz genau so sehe ich das auch.
Muss ich dann eine DFS-Rolle auf den DCs installieren? Da die ja sowieso schon einen DFS-Based Namespace hosten (SYSVOL) müsste das ja eigentlich überflüssig sein. Von daher...
Mich interessiert nur ein technisches Detail. Du schreibst:
AD speichert und stellt die Informationen über domänenbasierte DFS-Namespaces bereit. Der DFS-Dienst stellt die DFS-Namespaces bereit. Man braucht also immer beides.
Wo ist der Unterschied? Alle Informationen liegen in der Active-Directory-Datenbank, und die Domänen-Controller stellen diese Informationen bereit. Was genau (technisch) macht der Namespace-Server denn anderes, was der DC nicht schon macht?
Microsoft hat die Technik hinter DFS ja sehr schön ausführlich dokumentiert, aber der Unterschied wird daraus leider nicht klar ersichtlich. Oder anders gefragt: Wenn ich die Namespaces nicht auf DCs hosten würde, kämen die Infos ja weiterhin aus dem AD. Was genau tut der Namespace-Server bzw. welche technische Operation funktioniert nicht mehr, wenn der Server nicht erreichbar wäre. Ich frage, weil aus dem großen Bild oben für mich hervorgeht, dass es keine Info gibt, die der DC nicht kennt.
Aber es wird dann wohl auf die Variante ohne dedizierte Namespace-Server hinauslaufen. Mich interessiert trotzdem die Technik im Detail dahinter.
Danke.
Zitat von @Festus94:
Wo ist der Unterschied? Alle Informationen liegen in der Active-Directory-Datenbank, und die Domänen-Controller stellen diese Informationen bereit. Was genau (technisch) macht der Namespace-Server denn anderes, was der DC nicht schon macht?
Das AD ist das Kochbuch. Der DFS-Server der Koch, der die Speise bereitstellt.Wo ist der Unterschied? Alle Informationen liegen in der Active-Directory-Datenbank, und die Domänen-Controller stellen diese Informationen bereit. Was genau (technisch) macht der Namespace-Server denn anderes, was der DC nicht schon macht?
Muss ich dann eine DFS-Rolle auf den DCs installieren?
Ja, das muss man extra tun.Was genau tut der Namespace-Server
Den Namespace bereitstellen.bzw. welche technische Operation funktioniert nicht mehr, wenn der Server nicht erreichbar wäre.
Der Namespace wäre nicht mehr verfügbar.Es sei denn, man hat mehrere Root-Server eingerichtet.
Sicherlich könnte man orakeln, warum der extra DFS-Server notwendig ist, warum das DFS nicht einfach von jedem DFS-Client allein berechnet wird. Keine Ahnung. Ich schätze, das ist historisch bedingt. Man darf nicht vergessen, wo diese Technik ihre Wurzeln hat: Windows 2000 (meines Wissens sogar noch WinNT4.0) und die damals verfügbaren Rechenleistungen und Arbeitsspeicher an den Clients sowie die dünnen WAN-Verbindungen (64 Kbit/s war da keine Seltenheit).
Das würde ja Sinn machen, aber laut Microsoft Docs sieht der Prozess grob so aus:
Das heißt, der Client läuft immer erstmal zum DC. Und mein gedankliches Problem ist: Der DC weiß schon alles. Warum dann noch den Umweg über einen dedizierten Namespace Server gehen? Der kann dem Client nix erzählen, was der DC nicht auch wüsste.
Gut, dann werde ich das mal so fertig konzeptionieren und bauen.
Danke.
Das heißt, der Client läuft immer erstmal zum DC. Und mein gedankliches Problem ist: Der DC weiß schon alles. Warum dann noch den Umweg über einen dedizierten Namespace Server gehen? Der kann dem Client nix erzählen, was der DC nicht auch wüsste.
Gut, dann werde ich das mal so fertig konzeptionieren und bauen.
Danke.
Ja der Client meldet sich bei der Domäne und frägt wo er den Namespace findet. Dann wird er an den verwaltenden Namespace-Server verwiesen, der ihm dann die Info gibt wo der Share zu finden ist.
Na gut, diese Info steht aber auch im AD.
Genau, der Namespace-Server würde ja nur genau das Gleiche, das auch in der AD-Datenbank steht, bereitstellen. Änderungen finden auch im AD statt. Der dedizierte Namesapce-Server scheint daher irgendwie das fünfte Rad am Wagen zu sein.
Und um die Bilderorgie zu komplettieren, hier noch eine Übersicht, was genau wo gespeichert wird:
Oben rechts ist zu sehen, was genau vorgehalten wird. Und der Ursprung der Daten ist halt das Active Directory.
Schönen Feierabend.
Zitat von @Festus94:
Der dedizierte Namespace-Server scheint daher irgendwie das fünfte Rad am Wagen zu sein.
Ich verstehe nicht, warum Du Dich da jetzt so einschießt und da immer wieder drauf rumreitest.Der dedizierte Namespace-Server scheint daher irgendwie das fünfte Rad am Wagen zu sein.
Der DFS-Client muss auch mit standalone DFS-Namespaces zurechtkommen, ganz ohne Domäne. Für solch einen Namespace benötigt man dann in jedem Fall einen DFS-Root-Server. Es ist doch nachvollziehbar, dass Microsoft da jetzt nicht zwei verschiedene Techniken programmiert.
Richtig, aber das sind halt zwei Paar Schuhe. Ist ja nur eine Verständnisfrage für die Technik dahinter, aber die will ich halt im Detail verstanden haben. Und da die Doku hier nicht eindeutig ist, habe ich hier gefragt.
Aus Clientsicht ist das Vorgehen ja identisch. Ich werde es jetzt so implementieren und schauen, ob es sich verhält wie erwartet.
Danke noch mal.
Aus Clientsicht ist das Vorgehen ja identisch. Ich werde es jetzt so implementieren und schauen, ob es sich verhält wie erwartet.
Danke noch mal.
