• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 557
  • Last Modified:

Moving Domain Based DFS from member server to DC's

We currently have a domain based DFS namespace hosted on our file server. We want to move it to our DC's instead. Now the actual Namespace root is called \\domain\public and there are no links listed under it as the namespace was created using an existing share. I want to try to avoid having to create a new link called Public under that one and have it shown as \\slgreen.prv\Public\Public. Will I have to delete and recreate the link?
Damon Rodriguez
Damon Rodriguez
  • 5
  • 3
  • 2
1 Solution
What version of DFS are you running?  Is it 2000, 2003 or 2008?  It will make a difference on how you will go about moving it.
Damon RodriguezDirector of Business TechnologyAuthor Commented:
It is on a 2003 R2 server and I'm moving it to a 2008 R2 server.
Add the new server to the DFS replication group to get the data replicated.
one you have that done, you would alter the DFS management and add the new server as a target while removing the other server.

i.e. \domain\public you have a list of targets. or alias links?

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Damon RodriguezDirector of Business TechnologyAuthor Commented:
The problem is that i want keep the data where it is. I just want the DC's to hold the Namespace links. There are no links as the Root was created on the member server using the existing share Public. So we map the the users to that DFS share.
Are the files going to stay at their current location or are you going to move them to the DC's?

You can see from our DFS implementation that we have a Domain DFS.  I renamed ours to "\\dfs.com\group"  I created links to all the folders on the 3 file servers we have, but yours can be different.

You would add the DC's as namespace servers to the existing DFS.
Damon RodriguezDirector of Business TechnologyAuthor Commented:
We currently have our Main file shares done that way. This was created before anyone knew what they were doing. So that under the Namespace tab there are NO folders. See attached.
What do you mean?

You can define multiple root shares i.e.
It all depends on your setup.
Some prefer to have
and then have each share defined individually.

I do not get the significance you are trying to address.  Do you want all the domain shares listed under a single \\domain\listofallshares\ setup?

Just to be clear the DFS is controlled by the DC's and is then redirected to the servers holding the shares.  you can confirm this by running \\dcserver1\share and you will end up on the same share you would if you were using \\domain\share.

Damon RodriguezDirector of Business TechnologyAuthor Commented:
I apologize for the long break.
Yes. We want to have \\domain\Public hosted on our DC's. SO, if I add the DC's to available Namespace servers the folder Public will be created under c:\dfsroots\public right? But if people get redirected to that server they will see nothing in it because the original DFS root was set on the File server that hosted the shared folder. I can add a folder that points to the Public folder but then the share would be \\domain\Public\Public. I wanted to see if i could avoid that.
Yes, If you want a central location that lists all the available shares within a single root DFS share, you would end up with \\domain\public and then subfolders for each alias share
\\domain\public is the root
Within it:
public1 -> servera,serverb
public2 -> serverc,serverd

The problem you may face in this type of setup is when you map \\domain\public as a drive, you may get space notification even though no data is actually stored in \\domain\public if the servers where \\domain\public is stored (c:\dfsroot\public) is low on space.

You can create the DFS shared folder anywhere you want on the server.
you can have F:\somefolder have the same data and this folder will be shared as \\domain\public
c:\dfsroot is a default location MS uses as a starting point but is not required to work.
I personally would not put shares on the C drive if another drive letter is available.
Prior to adding the target for the share, make sure to configure the replication first this way the files will be copied and once that is complete, you add the target for the share.

usually for ease of reference the same names are used on the folders and the shares, but you can have:
servera e:\someshare
serverb F:\newshare
serverc c:\thisshare

all members of the same replication group. and shared as \\domain\public which depending on your DFS configuration load balance, preference, etc. will hit a specific server.

\\serverc\public will end up on the respective shared folder on each server.

The confusion is what the end result of what you are trying to do is.

Do you want a single DFS root where all other DFS based shares are seen, or do you actually want to have your DC also function as a fileserver for this DFS share.

An alternative is you can create a new dfsroot \\domain\allshares that will be hosted on the DC's.  Then within each configure \\domain\allshares\public and reference the existing servers as targets.
And repeat as needed.
Do not reuse the existing \\domain\public as it will cause problems.
Damon RodriguezDirector of Business TechnologyAuthor Commented:
We are not replicating data yet. We don't want our DC's hosting data either. With that said, you have confirmed my route. I will be setting up a new DFS namespace called All Public with links to different Public folders (we currently have 2 subsidiary companies with their own public folders). Thank you for all the help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 5
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now