It depends. There are 2 parts to DFS- the DFS namespace and DHS Replication. You can use the namespace without doing replication, but you can do replication without the namespace.
I use the DFS namespace on all shares so that when I replace a file server, all of the links to it will still work. I.e. DFS namespace domain.com\dfs\share points to \\server\myshare<file:///\\server\myshare>. I can plug in \\newserver\newshare<file:///\\newserver\newshare> and people can till access it using the same DFS path. DFS replication doesn't do you any good unless you have multiple locations involved, so I don't use it there. The other thing to keep in mind with DFSR is that it doesn't do distributed file locking, so even though you have the data in multiple locations, you can't let people edit the same files from different locations. I use it mainly for backup and RO data for my users. ...Tim From: David Lum [mailto:[email protected]] Sent: Monday, April 29, 2013 2:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
