Sean Martin <[email protected]> wrote on 08/28/2009 03:35:50 PM:
> > AH! DFS moved back into the realm of possible (for us). Without > > replication, I don't need as the full amount of storage at each site, > > enough to support *all* users; I'd really only need enough storage to > > support the number of users who can physically fit into the site ... (plus > > some as overflow, of course). > > That is correct. W00t! One in a row, for me. LOL > > So I would need to make sure all my site info is correct and up-to-date > > That would definitely help. Two! A streak ... > > So what happens in this case: > > > User at Server_A/Site_A moves to Site_B. I don't know about this move. > > When the user logs in, DFS tries to map his profile to a server in his > > site. But there is no server in Site_B with a copy of his files (yet). > > Does he get an error? > > You keep using the term "profile" but since you stated you don't use > roaming profiles, I'm assuming this is just a personal directory (my > documents, etc.). Right. Sorry; I mean "home folder", as specified on the "Profile" tab of the properties of a user. We connect this to drive "Z:" in AD. > If that's the case, I would imagine some type of > error would be presented during login indicating the target wasn't > accessible. > > > Does he just (transparently) connect long-distance back to his files at > > Site_A? > > No, I believe that mapping would simply not exist during the session. That would need testing; I seem to recall that if Windows can't find it's "My Documents" (which we re-direct to the user's home folder), it can just sort of hang and never log in. And if there's no home folder to find "My Documents" ... But I'm old; it's Friday; and I might be mis-remembering ... > > When I do the backup/restore of his files to Site_B, he should Just Work. > > (He'd have to be logged out while I did the backup/restore, right?) > > Yes it would require he logoff/logon after the data has been restored. OK! Definitely ammunition for a pilot project, after we finally get 2003 AD in place. Thanks everybody. That was a whole lotta signal for a Friday. LOL > > - Sean > On Fri, Aug 28, 2009 at 11:03 AM, <[email protected]> wrote: > Sean Martin <[email protected]> wrote on 08/28/2009 02:31:17 PM: > > > You can certainly implement DFS without replication. You would > > simply need to follow your same procedures of backup/restore, > > copying, etc. when a user moves from one site to another. It would > > just eliminate the need for modifying the user's profile path. Keep > > in mind that you'll need to modify your folder redirection GPO with > > the DFS path as well. > AH! DFS moved back into the realm of possible (for us). Without > replication, I don't need as the full amount of storage at each site, > enough to support *all* users; I'd really only need enough storage to > support the number of users who can physically fit into the site ... (plus > some as overflow, of course). > > > When a user accesses a DFS Namespace, DFS will determine which > > member of that namespace to direct the connection to based on the > > site they're logging in from. > So I would need to make sure all my site info is correct and up-to-date > ... > > So what happens in this case: > > User at Server_A/Site_A moves to Site_B. I don't know about this move. > When the user logs in, DFS tries to map his profile to a server in his > site. But there is no server in Site_B with a copy of his files (yet). > > Does he get an error? > Does he just (transparently) connect long-distance back to his files at > Site_A? > When I do the backup/restore of his files to Site_B, he should Just Work. > (He'd have to be logged out while I did the backup/restore, right?) > > > If you decided to use replication, DFS-R in Windows 2003 has pretty > > good compression capabilities, as well as the ability to only > > replicate changes to files. I had 600GB of user profiles/home > > directories replicating between 4 servers and I routinely had > > a reduction rate of 97% or greater. Example: If over a certain > > period of time, 1TB of data was modified and needed to replicate, > > DFS-R's compression and replication would only transfer 31GB. > Good to know. Thanks! > > > > > Sean > > > On Fri, Aug 28, 2009 at 8:43 AM, <[email protected]> wrote: > > Jon Harris <[email protected]> wrote on 08/28/2009 12:29:07 PM: > > > > > I don't know but I think DFS in 2000 was pretty poorly done, 2003 > > > was better and I hear the 2008 fixed a lot of things so he may have > > > issues with DFS. That is assuming he is still running all of his > > > file servers on 2000, he does not say. > > > > 4 file servers are Win2003; one is still Win2000. That one is scheduled > to > > be upgraded to Win2003 in a couple months. > > > > We are also going to be going to 2003 AD later this year. (and 2008 AD > > next year) > > > > So at some soon-to-be furute point, I will have 5 file servers, all at > > 2003 AD, scattered about, all in a 2003 AD. If I do implement DFS, it > > would be after all that. > > > > I guess I'm still unclear about the replication aspects of DFS. I get > the > > idea that I wouldn't need (num of servers x amount of each server > storage) > > at each site, but I am struggling to understand then how I am cutting > out > > bandwidth. I can see where I might be reducing it, but: > > > > If a person moves from Server #1 to Server #2, and I am using DFS, how > > (what method occurs) does that user not be accessing his/her files over > > the WAN link, if I am not replicating all their files to Server #2? I > > suppose that is my fundamental knowledge block, at the moment. > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
