Those resources are really helpful, thanks. I was wondering if anyone can make recommendations on implementing this in an existing production environment. I had two main concerns/ideas:
Creating DFS root shares at each site and then synchronize them with the branch sites. This way each main hub would be the primary for their users' location and then failover to the branch in the case of an outage or if the user logs on to the branch network physically.
Thinking about building these DFS shares little by little. Since it may be really difficult or impossible to take down their production network to ship servers for all of these inital syncs.., perhaps populate the DFS shares little by little so that the synchronization can complete before adding new data.
Thoughts?
Main Topics
Browse All Topics
by: CynepMeHPosted on 2009-01-16 at 14:36:17ID: 23398128
Since you're talking about a mesh, I'm assuming you're talking about Windows 2003 R2, as DFS differences between "original" and R2 are VERY drastic.
Your bandwidth challenges and concerns are certainly valid. Depending on the scenario, you may have several options. I usually have a very strict set of standards for roaming users for these exact reasons.
1. No saving to the desktop
2. Folder re-direction to DFS share (which itself is replicated)
3. Internet Explorer cache - 10MB or less, cleaned up on logon/logoff
4. No iTunes if possible or iTunes modified to save locally, not to network
5. Any apps that attempt to cache or write to the network have to be reviewed
6. Recycle bin set to 1%, NOT synch'd to the network, automatically cleaned up on logon/logoff
7. User Temp folder cleaned up on logon/logoff
8. No bitmap caching for RDP client (if in use, etc).
There could be other concerns but basically, go through your average user's profile folder and identify your large folders/files. Determine why they are large and what can be done to shrink them. Some may require hacking of registry and/or custom GPO.
Once you've slimmed down your profile size, you can now at least have some sort of baseline to go off of.
Now, here's a wonderful part - DFS-R in R2 does differential updates - so, only files that have changed are updated. To speed up this process, I'd recommend having your replica servers connected on a LAN - this way you can do an initial sync and then ship them out in the field. This way, you'll be only pushing delta updates across the WAN.
As far as supportability goes, this is a very common scenario and even included in GPO extensively. Take a look at some policies to see what I mean. This is a 100% supported (and often recommended) solution.
2003 R2 and 2008 can be DFS-R partners without any issues. Even "original" DFS can be used, albeit with number of limitations and careful planning. I'd recommend sticking with R2 and 2008, if possible.
This is a pretty good MS blog on DFS - take a look. Also contains number of useful links:
http://blogs.technet.com/a
Also, take a look here if you haven't already:
http://technet.microsoft.c