I have another question, how do you prevent the situation where a user at one site opens a document and a user at the remote site opens and starts editing the same document? What happens then? How do you prevent that?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of E Brown Sent: Wednesday, April 14, 2004 3:12 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DFS use question If you decide to use dfs\frs do the following as tuning guide... 1. Create as many separate trees as opposed to one large one. 2. Use latest frs hotfix 3. Have each partner have only one upstream & downstream partner 4. Do a backup so that recovery is easier. 5. Connect server to switch and use full-duplex 6. Change the change order maximum from 8 to 100 changes- will cause additional load on the upstream partner 7. Take a look at Q329491 8. Take a look at the recovery scripts that make recovery faster. Restore from backup even old is better than replicating in all data. 9. Remove large files that don't change much and replicate them via robocopy if they are static. 10. Refer to the 2003 BODG for newest functionality. 11. Use proper monitoring tools and stability will be excellent. 12. Don't virus scan ntfrs.jdb file. Let me know how this goes. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 6:16 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DFS use question I concur... especially considering the restore time in the event that replication screws up and critical information is pushed off to a Staging area, inaccessible to the user. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Monday, April 12, 2004 11:30 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DFS use question With all due respect to those that absolutely think that FRS v1 is hot, I'm quite pleased that there has been this level of success with it. However, even Microsoft admits that FRS is....well, broken. It gets better with each QFE, Service Pack and HotFix, but the basics are just flat broken. I'm not sure that I'd recommend it for anything remotely critical. But, to each his own. Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E Brown Sent: Monday, April 12, 2004 2:51 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DFS use question This is not out of the realm of FRS. I work with some folks that sync 240+GB between 12 servers using T-1 as well.. There are some tuning factors that should be followed: What is DFS topology? Make sure you using dfs & frs tuning docs. Setup Ultrasound to monitor... Let me know if you need more details. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Sunday, April 11, 2004 7:06 PM To: '[EMAIL PROTECTED]' Subject: [ActiveDir] DFS use question We have one of our largest sites in England and another large site in the US, with at least a full T-1 between the two sites. We have a share with about 70GB of data in it, that both sites regularly need to access. Would this be something we could use DFS for with automatic replication, or is this way out of DFS's range? And if it's out of the range of DFS, how are others solving this issue? A program like Veritas Storage Replicator, or NSI DoubleTake? Or will DFS suffice? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/