+1 to the namespace usage. I did this ages ago on Server 2003 and it makes life much easier.
-Jeff On Mon, Apr 29, 2013 at 5:19 PM, Tim Evans <tev...@sparling.com> wrote: > 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. I can plug in > \\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:david....@nwea.org] > *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 J). 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 listmana...@lyris.sunbeltsoftware.com > 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 listmana...@lyris.sunbeltsoftware.com > 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 listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
