DFS Best practice

I am looking to set up DFS between two servers in two locations.  Each location has a file server used primarily by that office.  Lets call "Office A" (2008R2) the HQ and "Office B" (2012) the remote office.  I'd like to get copies of the shared folders on Office B's server on a share on Office A's server, mostly for backup purposes, but also to give personnel in Office A access.  Office B doesn't need access to A's files.  Looks like DFS will be the easiest way.  My questions:

Do I need namespace servers on both locations, and do the users in Office B (the source) need to use the namespace or can they write directly to the local server shares? ie \\server\folder vs. \\namespace\share

Thanks
mchad65Asked:
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.

ChrisCommented:
I wouldn't recommend using DFS Replication if the files are likely to change in both locations. That being said, if your users are only accessing location specific folders this shouldn't be a problem. Just be aware that there will be a certain lag before files are current on both ends.

With regards to the namespace. I would usually ensure that any domain controllers are also namespace servers. When it comes to accessing the folders, it's perfectly fine to access the direct share on an individual server as DFS Namespace and DFS Replication are really two different technologies that have just been unified under one management console. What you need to remember when mapping to an individual server's share however, is that if the user goes to work at the other site, they won't benefit from DFS's ability to connect them to the local share and will instead have to work over the WAN.
0

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
mchad65Author Commented:
My plan is mostly for read-only purposes in the main site (A) - (B) users will access the shares directly on (B) and I will run my nightly differential backups on the replicated folder on (A) - with the very occasional (A) user doing a search for something.  (B) users don't access much on (A) anyway, so its really a one-way copy.  That being said, if namespaces and replication are two different technologies, do you need the namespace to have the replication?  Meaning if I only wanted to copy changes from B to A and not have a domain available share exposed, do I need to create the namespace, or can I simply set up replication?  Thanks
0
ChrisCommented:
Yeah, that implementation should be fine. I've done similar myself a number of times with no issue.

You can indeed replicate without the namespace, the folders don't even need to be shared. Open the DFS console, right click Replication and click New Replication Group. From there you add the servers, then add a local folder from the master server and in the next step add the corresponding local folder on the other server.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

mchad65Author Commented:
Cool.  So I just set up replication from the source server (B) to the destination (A) and got my first error:

The DFS Replication service encountered an error communicating with partner MFS for replication group <RepGroupName>.
 
Partner DNS address: A.domain.com
 
Optional data if available:
Partner WINS Address: A
Partner IP Address: <A's Internal IP>
 
The service will retry the connection periodically.
 
Additional Information:
Error: 1753 (There are no more endpoints available from the endpoint mapper.)
Connection ID: 22C9F8B2-FD89-4049-B3B0-CD1B8126FAB6
Replication Group ID: E6F8862F-1144-4B32-A99C-8A6275421AA4
0
mchad65Author Commented:
Hmm, looks like TCP135 may be blocked by the L2L VPN.  Let me check that.
0
mchad65Author Commented:
Ok.  Got port 135 open and no longer getting replication errors.  However I saw no replicated folders in the destination folder on the "A" server.  I put some stuff on the "B" server and still nothing.  Then I was poking around, and found the fully replicated folders - marked as hidden.  Once I showed hidden files, voila, there they are.  Why would they be hidden, and any idea how I can fix that?  Obviously I know how to change the flag, but I expect Windows made them hidden for a reason?
0
ChrisCommented:
Hmm, never seen that happen before. Usually all security/time stamps/attributes etc are replicated along with the data.

Perhaps it's hidden the files until initial replication has completed, though I've never noticed this behaviour before.

When you setup the initial replication group, there should have been an event logged in event viewer on the secondary server saying that it was waiting to perform initial replication. Once initial replication has completed you'll see another event logged saying that the server has completed initial replication on the folder. It might be worth looked for these events to get a better idea whether it's still at the initial replication stage.

Another useful tool to find out what's going on is dfsrdig. Running the following command will give you an idea what the replication queue is like:

Dfsrdig backlog /smem:server1 /rmem:server2 /rgname:ReplicationGroupName /rfname:ReplicatedFolderName

Obviously, you need to change the command to work with your setup. You can also switch round the sending member and receiving member server names to see replication in both directions.
0
mchad65Author Commented:
Here's come clarification:  The root folder (to where the replicated folders are written) is what is read only when browsed to on the serve itself.  Once in the folder, all the shares are there and replicating correctly (yay!) - you can map drives to them from domain workstations.  So not a big deal.  What is a problem, is the inherited, or replicated - permissions.  I need the replicated folders on (A) to be read only for the masses, yet r/w for admins - as I want to run backups and the app needs to change the attrib flag.  Is that possible?  It looks like the replicated folders are indeed collecting the share permissions from the source.  I see in the rep console I can change the target to read only, but it looks like that's for everyone - including domain admins (which is the account which backup runs on).  Anything I can do, other then full backups daily?  Or am I asking too much.  Thanks
0
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
Windows Server 2012

From novice to tech pro — start learning today.

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.