need not in depth guide to DFS

Have you seen the step by step from Microsoft?

http://technet.microsoft.com/en-us/library/cc732863%28WS.10%29.aspx

very easy to follow

Sorry, I now notice that you did read it

however the link i sent you has this line "you need a minimum of two servers configured in the test lab as follows"

http://blogs.technet.com/b/josebda/archive/2009/03/09/the-basics-of-the-windows-server-2008-distributed-file-system-dfs.aspx

explains on how to set it up with pictures :)

I'll assume that you want to use Windows 2008 DFS-R to replicate two folders on different servers.


Try these out.  They were written for Windows 2003 R2, but it's pretty much the same in Windows 2008.  There are more articles linked to the end of these that might be of further help.

Step 1: Setting up a DFS namespace
http://www.windowsnetworking.com/articles_tutorials/Implementing-DFS-Namespaces.html

Step 2: Setting up replication
http://www.windowsnetworking.com/articles_tutorials/Implementing-DFS-Replication.html

Hi,

do you have any older DFSes based on 2000 or 2003 in your network? Would yu like to use domain based DFS or standalone DFS? What is your domain functional level (2000 native, 2003, 2008)?

Thank you in advance

Regards,
Krzysztof

A simpler approach is to download and use RichCopy from Microsoft. RichCopy replaced RoboCopy for this kind of functionality.

An example command line might be as follows:
 "\\server1\share1\folderpath"  "\\server2\share1\folderpath" /FSD /NE /P /QA /QP "driveletter:\someserver\someshare\RichCopyLog.log" /UE /US /UD /UC /UPF /UFC /UCS /UET

This compares the two folders, copies/replicates what is different and log the process.

You can get all the help from the command line while you test how it works for you.

You can enter something similar to the example as the command line to run in a Scheduled Task on one of the servers in question.

 - Tom

@jakethecatuk

Wow, that was super simple. How come not a single guide showed me this option? So what have I done by not setting up replication folders and all that other stuff in all the other guides? I mean your approach worked in a complet;y different folder than all the guides show?!?!?

Feels like i cheated and did something wrong?

ok, i see what happens, I just set up 2 folders and they are synchronizing. Nothing more nothing less...

So i guess the easy way out of this would be to now share the 'replication folder' on the new server and connect users to that share instead of the one here in the main office?

Replication is taken care of by DFS and the sharing is just plain old sharing. Is this right thinking?

You haven't done anything wrong.

DFS comes in two parts: -

Part 1 - the distributed file system which is what is set up above
Part 2 - the namespace in AD.  What this does is update AD with a new folder share that points to both servers.  This allows you to map to one share only but you can connect to either server (in your case, but as many servers as you want).

If you want users to connect to a common share for both servers - you need to setup a namespace.

I was just thinking about how that works.

So explain the theory:
1 - I create a "name space" which is a sort of alias for my virtual file library host.
2 - now i attach a folder to this name space. lets call it "data" folder (c:\data) on the main server
3 - i now create another folder on my second server and call that "data' and sync it with the main server
4 - in the main office people can now either connect to the original "\\server\share_name" or the new "\\server.local\dfs-share-name"
5 - in the second office, people should now connect to?
A - the DFS share name on the local server (\\new_server.local\dfs-share-name)
B - The DS name on the main server (\\server.local\dfs-share-name)

??

two questions for the price of one is cheating :P

1. From Server Manager, expand Roles and then File Services - you should see DFS Management listed
2. Right click on Namespaces and choose New Namespace
3. On the Namespace Server screen, type in the name of the primary server and click on Next
4. On the Namespace Name and Settings screen, give it a share name - i.e. Data
5. Click on Edit Settings.  Leave the local path of the shared folder as set.  Make sure you choose All users have read and write permissions and click on OK
6. On the Namespace Type screen, this is how you share the namespace.  If you have a domain, leave it as Domain-based namespace and you will see in the preview of domain based namespace, how you connect to the share \\domain.loca\data.  Click on Next
7. Click on Create to create the namespace.

You will now have a namespace - you can now add your second server to the namespace.

1. Right click on your new namespace and choose Add Namespace Server
2. On the Add Namespace Server screen, type in the name of your second server.
3. Click on Edit Settings.  Leave the local path of the shared folder as set.  Make sure you choose All users have read and write permissions and click on OK
4. Click on OK to add the server.

You now have your two servers offering the namespace which is good for redundancy.  You can now add a folder: -

1. Right click on your new namespace and choose New Folder
2. On the New Folder screen, type in the folder name.
3. Click on Add and on the Add Folder Target screen, enter the full path to the shared folder and click on OK
4. Click on OK again to create the folder.  You will be prompted to create a replication group - click on No

I would suggest that when you create the shared folder on each server that you make it a hidden share by putting a $ on the end of the share name.

BTW - clicking on Yes to create the replication group will do what was in my previous post - but you won't understand how it's setup if you do that :)

your answers are awesome, thank you so much or helping...

So this is where you loose me:

1 - i create the 'name-space', I now have an AD FDQN to use (\\server.local)
2 - I create a new folder inside the DFS manager and give it a name (data for example)
3 - I now associate my original share with this folder inside the DFS as you say in step 3 in your last guide (the old share "\\server\share_name' can now be accessed through "\\server.local\dfs-share-name")
4 - I now also add a folder on the new server to this, so that the original share copies all it's content to the new folder on the new server. This folder i can access via "\\new_server.local\dfs-share-name

so here i am lost. I create a folder in DFS (step 1) to create a new "virtual folder". I then link the existing share to this virtual folder. Yet on the new server i need to create a new folder to physically copy the data to, but i also have to create a virtual older on the new server? So i now have this mess of 2 shared folders, 2 virtual dfs folders, and to reach any of them i need to put in the DFS name instead of simply sharing it.

I guess what I don;t understand is why would i not just simply set up the original copy scheme you taught me first, so that the folders are synced, then i just share the new folder on the new server and leave the original share alone.

WHat is the gain in using the DFS name space thingimajing?

DFS namespaces are great if you have a lot of servers providing the same data - you have one common share name to connect to regardless of location.

If you have two servers - DFS namespaces can be a bit of overkill as you have worked out.

There would be nothing wrong with just setting up the replication and attaching to the share on each server.  DFS will keep the folders in sync and all will be good - I simply gave you the option of using namespaces.  If it's too complicated - don't do it.

dude, you rocked my world with this. i wish people would be more like this when they answer instead of just sending links to other sites.

I am clear on all except:
" you have one common share name to connect to regardless of location"

I don't get that, what is the difference between using '\\servername\sharename' versus "\\servername.local\dfs-share-name". I mean if i have 2 servers, on 2 different locations, the data would still be accessed via \\server.local\dfsname on one side and \\server2.local\dfsname on the other side. I don;t get the "great" part.

OK...imagine this scenario.

You have ten servers sharing files in different locations and you have users in those ten locations.

As part of the login process, you map a drive to the users which is their S:\ drive for example.  If users don't move around, then they can be set to map to their local server for their share.

Now imagine you have users moving around - how will you map the roaming user to the local server?  User1 who is normally in office1 will always try and map to \\server1\data and if the links between offices aren't that fast, your users will complain about slow speeds.  Or, you write a very complicated login script that can work out where they are and map the network drive accordingly.  

Or, the easy way is to use DFS Namespace.  Instead of using \\{local server}\data or complicated scriting to map to the correct server, you use \\domain\data for every user and whereever your user is based, they always attach to the local share on the local server.  Even if they change office, they will still map to the server in the local office.

Does it make a bit more sense now?

that was how i was hoping it would work. But how does the client know which is the "closest" share?

i create a namespace server on the main server
i do the same on the new server
i now map the original share on the main server "\\server\data\" and create a DFS share called "datax"
I create a folder on the new server, and set up a synch between the new folder and the original share
I now have a perfectly synched folder in two locations.

Now one of my users goes to the other office with his laptop
when he fires up the computer, his "X:" looks for "\\server.local\datax"
How will the local server know and divert his request to the local folder instead of going accross the VPN?

I mean, how does the server know which of the 2 synched folders is the local one?

and again, I can't thank you enough for taking the time...

I'm guessing that your two locations are part of the same domain.

If you configure your users to connect to \\domain\data instead of \\server\data, the domain handles the mapping request.  When you try and connect to \\domain\data, the PC will look at the local DC for this and it knows what the local DC is because of the IP address.  

Site 1:
DC - 192.168.1.1

Site 2:
DC - 192.168.2.1

When your PC has an IP address of 192.168.1.10, when it logs in, it will know that the DC is 192.168.1.1.  Similarly, when your PC has an IP address of 192.168.2.10, when it logs in, it will know that the DC is 192.168.2.1.

In simple terms, the namespace resolution will work in a similar way.

Whatever you do...don't map directly to the server share or you will have problems.  If you using namespaces, always ALWAYS map to the domain share.

Hit post too soon...

So the local DC will know which file server is local and will always try and connect to that share over the remote share.

Make sure that you also set up your sites in Active Directory Sites and Services - define your subnets and assign them to the appropriate site.  This helps DFS and other services figure out where the "closest" appropriate server is.  If done properly, DFS will pick the closest available server when you use the DFS namespace to access shares.

ooooohhhh, I see, i don't do
"\\servername.local\dfs-share"

I do "\\domainname.local\dfs-share"

that makes allot more sense.

what if i had 2 servers in the same room, same subnet, which one would be used first (if they were both replicating and sharing the same folder)

I though you said earlier that I could synch 2 folders and share them just fine. Is that not true? or is this only when you are dealing with folders active with DFS?

Yeah, I need to set up an additional site for the server in AD. Gonna look in to that tomorrow.

speaking of which. a different site is still the same domain, right? so if I set this server up on the DFS system it won;t matter that i move this server to another office, change the IP and make it the controller for this "new AD site". because it will find it through DNS, right?