Distributed File System, or DFS.
The business problem that DFS aims to solve is something like our users can't
get to their work because we have a mess of shared folders.
Does that sound at all familiar to you?
I've been a Windows Server specialist for over 20 years now,
since the Windows NT days,
and having a shared folder web across your infrastructure and then
mapping drive letters and the ensuing chaos,
not just for your users, but for your IT staff to get to their work,
is certainly a significant problem.
DFS is a solution to that problem.
We need to understand, first of all, DFS architecture.
Now this is a Windows Server feature that's been in the product for many years,
and what we're doing here is creating what's called a DFS namespace,
and these namespaces can exist in one of two modes,
domain or standalone.
Standalone,
the namespace metadata is kept in the registry of that
local Windows Server file server.
I would recommend that you use the domain model in which the
namespace configuration travels with Active Directory,
and you also can use DFS replication for your SYSVOL in
your Active Directory replication.
Much more efficient way to go.
With that namespace, which, again, is simply a logical share point,
and I don't mean Microsoft SharePoint Server by the way,
you can have multiple servers hosting that root namespace for high availability.
Within that single namespace in this example,
\\Contoso\Public, you can create folders,
which are essentially virtual directories that refer to targets,
and these folder targets are distinct and discrete file shares that
can exist on any file server in your infrastructure.
So at the end of the day,
what you have is a single universal naming convention path that you
can point your users to in their drive mappings,
whatever, in this example, \\Contoso\Public,
and then they can browse a hierarchy that you design,
that's the folders, that directs the users to the appropriate folder targets.
So everybody wins with DFS.
And the fact that you can have multiple namespace servers means
you have some redundancy and high availability if you need to
take the primary server offline.
Now, of course, there's the question, well,
if I take one of my file servers offline,
doesn't that mean that the shared folders on that box go bye‑bye?
Well, no,
because with DFS you can actually replicate your targets as well
so that multiple DFS namespace servers actually have that target
content on their file system as well.
That is what we mean by DFS replication.
And again, DFS Replication, or DFSR,
is an excellent way to do high availability here for your file data,
and you should also know that when you're using DFS in a
domain context and you're using DFSR, you've got Active Directory site awareness.
Earlier in the AZ‑800 learning path we reviewed Active Directory sites
and services and subnets and connection objects,
so you know that one of the key points of Active Directory is that your users,
when they sign into their domain‑joined workstations,
they're going to be directed to their closest lowest latency domain controller.
Well, that same rule applies when your users are browsing your DFS tree.
When they hit a folder, a replicated folder,
they're going to be redirected to the instance,
that is the member that holds that data within their site,
so it's nicely architected for sure.
But I also want to say before we move on to BranchCache that recall what
we did earlier in the course with Azure File Sync.
You may be using DFS and DFSR now, but as a hybrid cloud administrator,
you want to start to realize some of the cloud high
availability and cloud backup, etc.
So I'm just framing this in the context of the
Hybrid Windows Server Administrator.
It's not an either or proposition.
You know that.
The standard consultant answer is it depends. It depends on your needs, your requirements, and your context.