Thanks Steve, We don't really have a branch office scenario here, so the only reason I might use data replication is to help with the initial migration of data from old servers to new servers. After that, my hope is that we can use SAN mirror copies to achieve the data replication.
I think the best way to view this design is that we want the logical layer to be as abstracted as possible from the physical data as possible. Even setting up a replication schedule will have some ties to the physical data. The domain based DFS is to provide high availability and failover for file services to MSFT clients. Layering it into a standalone DFS, is to allow MSFT clients to access that data using a Mac or Unix host. Basically the Standalone DFS is a service layer network interface for Macs and Unix. Yes the path will change slightly. But it is forgivable. Also my hope is that this also gives me flexibility to disable SMB signing if needed, etc. And not require the UNIX or AD host to bind to the AD. On the issue of last write, we plan to use Sharepoint in the future for collaborative services. We would love to be able to tie in home directories, and department shares into this as well... but it might be better to have a separation of these functions too. More to come... Todd Myrick -----Original Message----- From: Molkentin, Steve [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 6:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Domain Based DFS Todd, It really comes down to what you want to achieve with your Domain-based DFS root and standalone DFS root. Now that I've stated the obvious - organising your data in a logical fashion can have far reaching implications (good and bad) for your staff, but I'm all for making it easier for them (starts to save on seven copies of the same file!). We recently implemented a company wide domain-based DFS root, which we map as Z:\ drive. All teams have their folders in this, located local to the team but available company wide, and replicated where the team is physically distributed. Their home folders are a part of their team structure, and are replicated (if the team folder is replicated) as that is a part of the team access to data. I would think that the only reason you'd "normally" replicated the home folder would be for offsite (or even onsite) backup purposes. Profiles could be replicated, and would be helpful if you have a lot of staff moving about sites and you use roaming profiles. I could foresee problems with replicating profiles, but I am confident they'd be no-brainers to solve. Including UNIX and Mac clients in accessing a DFS root (standalone or otherwise)... I would have thought is simply a DNS and installing the relevant access to services issue. Sadly, as with DFS (in both versions), it is pretty intrinsically AD linked, so there is no way around (that I can see) NOT getting these other clients to bind to the AD for access or authentication... For a domain-based root. A stand-alone root is obviously a little bit of a different beast, but it takes away the benefit of the DFS root being "server independent", if you catch my meaning. Everything is possible - not everything is permissible. What you've suggested will *probably* work, but what sort of administrative overhead do you want to bring down on yourself and your team? As always, the KISS principle applies, even with Mac and UNIX clients, but it sounds like your requirements and rationale for the replication aren't a simple "main-site-to-branch-office" situation. Obviously be aware of the "last person that saves wins" issue with multi access to replicated files, although in DFSR if there is a conflict like this at least it now has the smarts to store the file that "lost" in a folder for recovery on the server that resolve the conflict. Lots to look at and consider when planning a good DFS structure. It's one of those things that is nasty to recover from AFTER the fact if it went in dodgy. My $0.02 inc GST, FWIW... Thanks! :) themolk. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Myrick, Todd (NIH/CC/DCRI) [E] > Sent: Thursday, 14 December 2006 1:06 AM > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] Domain Based DFS > > I am working on a Domain DFS Namespace plan and was wondering how some > of you all organize your information in it. > > Specifically I was wonder do you publish Home Directories, Profile > Directories and Department File shares in it. > > Out goal is to develop a Unified Data Access Service for PC, but to > provide accommodations for UNIX, Mac, and FTP / Web access. I don't > necessarily want to make it so Macs and Unix have to bind to our AD to > get access to these services. > > I am also wondering if any of you provide access to no > Microsoft clients > via the Domain DFS or do you stand up a stand alone DFS and > install NFS > services on it? > > Is it feasible to mix Domain DFS links with standalone DFS. > > Here something as an example. > > Logical > > company.lan > -Domain-DFS > Users > Org > Software > Pub > > > - Standalone DFS - (Clustered) Mapped to Users (Needs High > Availability) > - Profiles > - Home (Needs MSFT, Mac, Unix access) Possibly URL as well. > > - Standalone DFS - (Clustered) Mapped to Org > - Each Department (MSFT, Mac, Unix, maybe URL) > > - Standalone DFS - (Clustered) Mapped to Software > - Each Application Type (Might go away with Softricity > - Public (MSFT, Mac, UNIX, FTP and URL) > > - Standalone DFS - (Clustered) Mapped to Pub > - Outgoing (MSFT, Mac, UNIX, FTP and URL) > - Incoming (Accessable via FTP and URL) > > > Physical > > AD Domain > Stand-Alone DFS Server Clusters. > > Main Site DR Site > Servers Servers > -FS1 -DRFS1 > -FS2 -DRFS2 > -FS3 -DRFS3 > -FS4 -DRFS4 > > Probably use some type of SAN storage and Mirroring to host > actual data. > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir@mail.activedir.org/ > This email (including any attachments) contains confidential information and is intended only for the named addressee. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. Email transmission cannot be guaranteed to be secure or error-free and emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. The sender does not give any warranties nor accepts any liability in relation to any of these matters. If you have any doubt about the authenticity of an email purportedly sent by us, please contact us immediately. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
