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
jinfeldPresidentAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Brian MurphySenior Information Technology ConsultantCommented:
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\YOURNAME.

On standalone it would be \\SERVERNAME\MYNAME

If AD integrated and forest level it would be \\myforest.com\SOMENAME

Example:
dfs-name-space.png

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 in Site A

This would be \\domain\dfsshare1\share1 in Site A

Then \\domainA\dfsshare1\share2 in Site B

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
Lee W, MVPTechnology and Business Process AdvisorCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jinfeldPresidentAuthor Commented:
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
jinfeldPresidentAuthor Commented:
If we upgraded Essential 2012 R2 to Server 2012 R2, could this be done?
J
Lee W, MVPTechnology and Business Process AdvisorCommented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.