asked on

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

ASKER CERTIFIED SOLUTION

Chris

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

mchad65

ASKER

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

Chris

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.

mchad65

ASKER

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

mchad65

ASKER

Hmm, looks like TCP135 may be blocked by the L2L VPN. Let me check that.

mchad65

ASKER

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?

Chris

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.

mchad65

ASKER

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