DFS namespace between SBS 2011 and Essentials 2012 R2
The main domain\server, SBS2011.local\server11 hosts all shares, users and security.
We have another domain\server, ESS2012R2.local\server12.
Both servers are on the same LAN, same IP subnet.
Can we use DFS namespace to allow users to read and write to a folder on ESS2012R2.local\server12?
If so, what AD trusts need to be created, if any?
On which server(s) do we create the DFS Namespace?
Do we use Domain or Stand-Alone namespaces?
How do you set user share permissions and security for the folder on server12?
Any other tips to make this work?
Thanks,
Jerry
We have another domain\server, ESS2012R2.local\server12.
Both servers are on the same LAN, same IP subnet.
Can we use DFS namespace to allow users to read and write to a folder on ESS2012R2.local\server12?
If so, what AD trusts need to be created, if any?
On which server(s) do we create the DFS Namespace?
Do we use Domain or Stand-Alone namespaces?
How do you set user share permissions and security for the folder on server12?
Any other tips to make this work?
Thanks,
Jerry
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
DFS is cool stuff.
The upside to AD DFS is redundancy and shared load. If you install stand-alone at the root there it is a single point of failure unless you have a failover cluster. DFS in standalone does support Microsoft failover cluster.
I use DFS to create a contiguous name space for shares. When you enable File Services role on AD controller you can choose an initial name but the default path is \\domain.myforest.com\YOUR
On standalone it would be \\SERVERNAME\MYNAME
If AD integrated and forest level it would be \\myforest.com\SOMENAME
Example:
DFS is a logical pointer. It uses NTFS file share permissions. If you have one forest then trust is transitional to all downlevel child domains.
If you have more than one forest or other domain trusts then those already exists or should.
You should not need to create new trusts or adjust NTFS permissions beyond what you have for Share to NTFS permission now.
All you are doing essentially is taking all those shares in Domain A and creating one DFS share for all those share - if you want.
This is how I use DFS.
This can spread across multiple sites.
If you have \\domainA\dfsshare1 the shares can be server1.domainA.com\share1
This would be \\domain\dfsshare1\share1 in Site A
Then \\domainA\dfsshare1\share2
You can replicate Site A to Site B and Site B to Site A for redundancy.
Having DFS in AD shares the load as well as redundancy.
Once you have the pointers behind DFS you can migrate servers or consolidate servers to larger file servers and simply change the pointer to the new file share but users never see a difference.
This is great for current and future migrations, server name changes, and so forth.
One such example might be:
\\FILESERVER1\HOMEDRIVES\
\\FILESERVER2\GROUPDRIVES\
\\FILESERVER3\PROFILES\
\\FILESERVER4\REPORTS\
\\FILESERVER5\PROJECTS\
Becomes
\\GLOBALFS\
HOMEDRIVES
GROUPDRIVES
PROFILES
REPORTS
PROJECTS
DFS is great for distributed applications or "network hosted" binary files aka apps.
Having your sites defined in Sites and Services, DFS in AD allows for "least expense" or what I call closest proximity share by physical site.
I prefer AD integrated DFS. To enable this requires AD installed, you want to install File Services > Next > Distributed File System
This is done on the domain / domains where your share resources are hosted.
NTFS permissions remain best practice.
Create Domain Local Groups in AD for local domain file resources and create Domain Global Groups in those child domains where users need access to another domain resource.
Add local users per domain to the DLG and remote users by way of Global Group.
Hope this helps
The upside to AD DFS is redundancy and shared load. If you install stand-alone at the root there it is a single point of failure unless you have a failover cluster. DFS in standalone does support Microsoft failover cluster.
I use DFS to create a contiguous name space for shares. When you enable File Services role on AD controller you can choose an initial name but the default path is \\domain.myforest.com\YOUR
On standalone it would be \\SERVERNAME\MYNAME
If AD integrated and forest level it would be \\myforest.com\SOMENAME
Example:
DFS is a logical pointer. It uses NTFS file share permissions. If you have one forest then trust is transitional to all downlevel child domains.
If you have more than one forest or other domain trusts then those already exists or should.
You should not need to create new trusts or adjust NTFS permissions beyond what you have for Share to NTFS permission now.
All you are doing essentially is taking all those shares in Domain A and creating one DFS share for all those share - if you want.
This is how I use DFS.
This can spread across multiple sites.
If you have \\domainA\dfsshare1 the shares can be server1.domainA.com\share1
This would be \\domain\dfsshare1\share1 in Site A
Then \\domainA\dfsshare1\share2
You can replicate Site A to Site B and Site B to Site A for redundancy.
Having DFS in AD shares the load as well as redundancy.
Once you have the pointers behind DFS you can migrate servers or consolidate servers to larger file servers and simply change the pointer to the new file share but users never see a difference.
This is great for current and future migrations, server name changes, and so forth.
One such example might be:
\\FILESERVER1\HOMEDRIVES\
\\FILESERVER2\GROUPDRIVES\
\\FILESERVER3\PROFILES\
\\FILESERVER4\REPORTS\
\\FILESERVER5\PROJECTS\
Becomes
\\GLOBALFS\
HOMEDRIVES
GROUPDRIVES
PROFILES
REPORTS
PROJECTS
DFS is great for distributed applications or "network hosted" binary files aka apps.
Having your sites defined in Sites and Services, DFS in AD allows for "least expense" or what I call closest proximity share by physical site.
I prefer AD integrated DFS. To enable this requires AD installed, you want to install File Services > Next > Distributed File System
This is done on the domain / domains where your share resources are hosted.
NTFS permissions remain best practice.
Create Domain Local Groups in AD for local domain file resources and create Domain Global Groups in those child domains where users need access to another domain resource.
Add local users per domain to the DLG and remote users by way of Global Group.
Hope this helps
You can't. Someone bought the wrong product in Essentials 2012. You cannot join an Essentials class system to an SBS class system - both systems insist upon being the FSMO master DC of the domain they are in. Both systems prohibit trusts. Domain based DFS cannot be used.
Thank you! Since my goal was to use DFS to represent a share that physically was on ESS2012R2.local\server12 to the users of SBS2011.local, I was not interested in failure protection or redundancy. It seems like this can't be done using SBS or Essentials versions of Windows server. I gave Lee points because that answered my question. I gave Brian the points because of the in-depth explanation of DFS.
Thank you both.
Jerry
Thank you both.
Jerry
The restrictions are having two "Small Business" class servers in the same domain - that cannot be done. Essentials and Small Business Server (and Foundation Edition) are all Small Business class with the FSMO role Master requirement.
Add any NON-Small Business Server to the network and you're fine - you can make them DCs, implement DFS, etc, etc.
So in short, Yes, DFS should work fine with SBS and a Standard 2012 R2 server.
Add any NON-Small Business Server to the network and you're fine - you can make them DCs, implement DFS, etc, etc.
So in short, Yes, DFS should work fine with SBS and a Standard 2012 R2 server.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial