DFS Structure help "Barkley Bees" <barkbees[ at ]nomail.com> 12/3/2008 10:08:34 AM I am setting up DFS (R2) right now with namespaces and replication. I think I may be making a fundamental mistake though with the structure. I will only be using it for user folders at this time so I: - created my namespace server: Server_A - Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the Users folder Everything is great up to this point as I can now see "\\domain\users". When I go to the Namespaces folder on the DFS Management conosle and drill down to \\domain\users I don't see anything in the "Namespace" tab on the right. I can of course add folders from but the existing subfolders under "USERS" don't appear here. Have I made "USERS" the DFS Root in this case? Should I be instead be structuring it so that "USERS" is a namespace folder? I'm a little lost now..ugh! Thanks.

Re: DFS Structure help "Marcin" <marcin[ at ]community.nospam> 12/3/2008 7:33:33 PM Barkley, DFS is commonly used to minimize number of drive mappings/providing a single point of entry to mulitple network shares. If this is your longer term goal (obviously this does not apply at this point), you might want to change your approach (and create a generic top level namespace with Users as its folder). Otherwise, you will need to create another namespace (which, btw. is certainly a possibility) if you decide to add another set of shared folders to your DFS hierarchy at some point in the future... hth Marcin "Barkley Bees" <barkbees[ at ]nomail.com> wrote in message news:uu5jc8SVJHA.4384[ at ]TK2MSFTNGP06.phx.gbl... [Quoted Text] >I am setting up DFS (R2) right now with namespaces and replication. I think >I may be making a fundamental mistake though with the structure. I will >only be using it for user folders at this time so I: > > - created my namespace server: Server_A > - Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the > Users folder > > > Everything is great up to this point as I can now see "\\domain\users". > When I go to the Namespaces folder on the DFS Management conosle and drill > down to \\domain\users I don't see anything in the "Namespace" tab on the > right. I can of course add folders from but the existing subfolders under > "USERS" don't appear here. > > Have I made "USERS" the DFS Root in this case? Should I be instead be > structuring it so that "USERS" is a namespace folder? I'm a little lost > now..ugh! Thanks. > > > >

Re: DFS Structure help DaveMills <DaveMills[ at ]newsgroup.nospam> 12/4/2008 7:29:36 AM What I have done is a) Create a DFS root like you. I called mine Storage so I have \\domain\storage b) Added various folders to storage e.g. Users, Public, Confidential c) Added links in these above folders the point to the physical data location via it \\server\share reference. e.g. \\domain\storage\public ---> \\server\public$ For home folders I added another layer so I can have home folders on the department own servers \\domain\storage\users\legal ---> \\legalserver\users$ \\domain\storage\users\engineers ---> \\engineersserver\users$ No data is ever stored directly in the DFS folder only Links are put there. On Wed, 3 Dec 2008 19:08:34 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> wrote: [Quoted Text] >I am setting up DFS (R2) right now with namespaces and replication. I think >I may be making a fundamental mistake though with the structure. I will only >be using it for user folders at this time so I: > >- created my namespace server: Server_A >- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the >Users folder > > >Everything is great up to this point as I can now see "\\domain\users". When >I go to the Namespaces folder on the DFS Management conosle and drill down >to \\domain\users I don't see anything in the "Namespace" tab on the right. >I can of course add folders from but the existing subfolders under "USERS" >don't appear here. > >Have I made "USERS" the DFS Root in this case? Should I be instead be >structuring it so that "USERS" is a namespace folder? I'm a little lost >now..ugh! Thanks. > > > -- Dave Mills There are 10 types of people, those that understand binary and those that don't.

Re: DFS Structure help "Barkley Bees" <barkbees[ at ]nomail.com> 12/4/2008 9:41:12 AM Thanks for the answers. As mentioned before, mine is setup as \\domain\users\ with the user folders in that directory. When I create the actual user folders via AD Users & Computers (multiselecting a batch of test user accounts - home folder: \\domain\users\%username%) the folders are of course created but I notice they do not appear in the DFS Management console namespace tab. Of course I can create a folder on the Namespace tab and it appears in the users directory but I am left to wonder what the difference is between the two ways of creating folders? If may ask, why did you create them as hidden shares ($)? * that said, I am considering going with the route you suggested David (\\domain\dfs\users or similar). Not sure what the 'best practice' would be in this case though. "DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message news:u71fj45fv6vvkikaok95qgb335m1i5e6ml[ at ]4ax.com... [Quoted Text] > What I have done is > a) Create a DFS root like you. I called mine Storage so I have > \\domain\storage > b) Added various folders to storage e.g. Users, Public, Confidential > c) Added links in these above folders the point to the physical data > location > via it \\server\share reference. e.g. > \\domain\storage\public ---> \\server\public$ > For home folders I added another layer so I can have home folders on the > department own servers > \\domain\storage\users\legal ---> \\legalserver\users$ > \\domain\storage\users\engineers ---> \\engineersserver\users$ > > No data is ever stored directly in the DFS folder only Links are put > there. > > > > > On Wed, 3 Dec 2008 19:08:34 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> > wrote: > >>I am setting up DFS (R2) right now with namespaces and replication. I >>think >>I may be making a fundamental mistake though with the structure. I will >>only >>be using it for user folders at this time so I: >> >>- created my namespace server: Server_A >>- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the >>Users folder >> >> >>Everything is great up to this point as I can now see "\\domain\users". >>When >>I go to the Namespaces folder on the DFS Management conosle and drill down >>to \\domain\users I don't see anything in the "Namespace" tab on the >>right. >>I can of course add folders from but the existing subfolders under "USERS" >>don't appear here. >> >>Have I made "USERS" the DFS Root in this case? Should I be instead be >>structuring it so that "USERS" is a namespace folder? I'm a little lost >>now..ugh! Thanks. >> >> >> > -- > Dave Mills > There are 10 types of people, those that understand binary and those that > don't.

Re: DFS Structure help DaveMills <DaveMills[ at ]newsgroup.nospam> 12/5/2008 6:36:23 AM On Thu, 4 Dec 2008 18:41:12 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> wrote: [Quoted Text] >Thanks for the answers. As mentioned before, mine is setup as >\\domain\users\ with the user folders in that directory. When I create the >actual user folders via AD Users & Computers (multiselecting a batch of test >user accounts - home folder: \\domain\users\%username%) the folders are of >course created but I notice they do not appear in the DFS Management console >namespace tab. Of course I can create a folder on the Namespace tab and it >appears in the users directory but I am left to wonder what the difference >is between the two ways of creating folders? I do not know why the folders do not display in the DFS Management console, I have never tried to have non DFS managed folders within the DFS root. In my opinion this is a poor design because you have no control over the replication. All DFS root servers get a replicated copy of the content of the DFS root and you cannot change that. This means that many GB of data will be moved between the root servers when they synchronize. There is no interface for managing the schedule or any other parameters. You may be able to via DFSUTIL or registry changes but the system is not designed to be used in this way so I would not be surprised to find a future update changing things in a way the will break your system. You should change the design to have \\Domain\DFSRoot\Users where Users is a link to a \\server\users($) share where the actual %username% folders are stored. If you want replication of the Users folders then simply set it up when you add a second link to another server share. This will be far more flexible. You may have 2 replicated copies of the "Users" folder, no replication on the "Public" link or any other combination you desire. The way you have things will not allow you to expand the system for future needs, to change target servers etc. (A side note: Be careful with the NTFS permissions in the physical DFSRoot folders, these are not replicated but inherited from the parent folder when the root server is set up. I had one copy with Admin=F/C + Everyone=R and the other as Everyone=F/C. It took me some time to figure out how people were able to add files to the root because when I looked I saw the more restricted permission set) If you have not yet read "How DFS works" on http://technet.microsoft.com/en-us/library/cc782417.aspx You may find it very useful. I can't say I remember it all but it sure helped me understand why I needed to be careful with the design. > >If may ask, why did you create them as hidden shares ($)? So users will connect to the DFS paths and not the server UNC path (I know this is not enforced). If users connect to the UNC name directly I loose to ability to move the share to a new server and simply change the link in the DFS console to point to the new location. Instead I have to get all clients to change their configuration. > >* that said, I am considering going with the route you suggested David >(\\domain\dfs\users or similar). Not sure what the 'best practice' would be >in this case though. > > > >"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message >news:u71fj45fv6vvkikaok95qgb335m1i5e6ml[ at ]4ax.com... >> What I have done is >> a) Create a DFS root like you. I called mine Storage so I have >> \\domain\storage >> b) Added various folders to storage e.g. Users, Public, Confidential >> c) Added links in these above folders the point to the physical data >> location >> via it \\server\share reference. e.g. >> \\domain\storage\public ---> \\server\public$ >> For home folders I added another layer so I can have home folders on the >> department own servers >> \\domain\storage\users\legal ---> \\legalserver\users$ >> \\domain\storage\users\engineers ---> \\engineersserver\users$ >> >> No data is ever stored directly in the DFS folder only Links are put >> there. >> >> >> >> >> On Wed, 3 Dec 2008 19:08:34 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> >> wrote: >> >>>I am setting up DFS (R2) right now with namespaces and replication. I >>>think >>>I may be making a fundamental mistake though with the structure. I will >>>only >>>be using it for user folders at this time so I: >>> >>>- created my namespace server: Server_A >>>- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the >>>Users folder >>> >>> >>>Everything is great up to this point as I can now see "\\domain\users". >>>When >>>I go to the Namespaces folder on the DFS Management conosle and drill down >>>to \\domain\users I don't see anything in the "Namespace" tab on the >>>right. >>>I can of course add folders from but the existing subfolders under "USERS" >>>don't appear here. >>> >>>Have I made "USERS" the DFS Root in this case? Should I be instead be >>>structuring it so that "USERS" is a namespace folder? I'm a little lost >>>now..ugh! Thanks. >>> >>> >>> >> -- >> Dave Mills >> There are 10 types of people, those that understand binary and those that >> don't. > -- Dave Mills There are 10 types of people, those that understand binary and those that don't.

Re: DFS Structure help "Barkley Bees" <barkbees[ at ]nomail.com> 12/8/2008 9:14:43 AM 1. Thanks for the advice, I have got my Namespace and Replication in place as follows: Server_A E:\Users$ Server_B E:\Users$ Namespace: \\domain\DFS\ Namespace folder: USERS (I will be configuring the users' home path in AD as follows - \\domain\dfs\users\%username%) We are attempting to have Server_A be the main server with Server_B as a "hot stand-by" so to speak. So, I have configured Server_A to be "first among all targets" and Server_B to be "last among all targets in Namespaces. I have done the same for the Folder "Users" in Namespaces. Does this appear to be correct? 3. I have set up a replication group for these folders to sync. We will be replicating ~2TB of data between severs. What would be the recommended quota sizes for: -Staging folder (4096MB default) -Conflict and Deleted folder (660MB default) 4. To facilitate our "hot stand-by" goal, we would like to implement one-way replication but I am beginning to wonder if there is any merit to this. I had planned to simply disable (not delete) the replication connection from Server_B -> Server_A to prevent it replicating back to the primary. The in the event of a failure on the primary server I would enable this connection after recovery so Server_B could replicate back to Server_A. Can anyone advise on this, should I abandon 1-way replication? 5. How does VSS work with DFS? Do I simply enable VSS on both servers' volumes that host the shared folder in the replication group and restore from the active server when required? Or is the VSS restore done from the \\domain\dfs\share ? 6. I have asked this before but didn't get a clear response, does anyone know about SiS (single instance storage) and getting it to work correctly in a DFS scenario? I am a little bit wary of enabling this service as I don't know how it would be have with the Common store folder not being replicated (and also how it would function with VSS). 7. Do most of you using DFS deploy the Client failback patch (kb898900)? Appreciate any feedback as always. Thanks. "DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message news:t5hhj4lfurm17cn5gsis2mrndre6cp009h[ at ]4ax.com... [Quoted Text] > On Thu, 4 Dec 2008 18:41:12 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> > wrote: > >>Thanks for the answers. As mentioned before, mine is setup as >>\\domain\users\ with the user folders in that directory. When I create the >>actual user folders via AD Users & Computers (multiselecting a batch of >>test >>user accounts - home folder: \\domain\users\%username%) the folders are of >>course created but I notice they do not appear in the DFS Management >>console >>namespace tab. Of course I can create a folder on the Namespace tab and it >>appears in the users directory but I am left to wonder what the difference >>is between the two ways of creating folders? > I do not know why the folders do not display in the DFS Management > console, I > have never tried to have non DFS managed folders within the DFS root. > > In my opinion this is a poor design because you have no control over the > replication. All DFS root servers get a replicated copy of the content of > the > DFS root and you cannot change that. This means that many GB of data will > be > moved between the root servers when they synchronize. There is no > interface for > managing the schedule or any other parameters. You may be able to via > DFSUTIL or > registry changes but the system is not designed to be used in this way so > I > would not be surprised to find a future update changing things in a way > the will > break your system. You should change the design to have > \\Domain\DFSRoot\Users > where Users is a link to a \\server\users($) share where the actual > %username% > folders are stored. If you want replication of the Users folders then > simply set > it up when you add a second link to another server share. This will be far > more > flexible. You may have 2 replicated copies of the "Users" folder, no > replication > on the "Public" link or any other combination you desire. The way you have > things will not allow you to expand the system for future needs, to change > target servers etc. > > (A side note: Be careful with the NTFS permissions in the physical DFSRoot > folders, these are not replicated but inherited from the parent folder > when the > root server is set up. I had one copy with Admin=F/C + Everyone=R and the > other > as Everyone=F/C. It took me some time to figure out how people were able > to add > files to the root because when I looked I saw the more restricted > permission > set) > > > If you have not yet read "How DFS works" on > http://technet.microsoft.com/en-us/library/cc782417.aspx > You may find it very useful. I can't say I remember it all but it sure > helped me > understand why I needed to be careful with the design. > > >> >>If may ask, why did you create them as hidden shares ($)? > So users will connect to the DFS paths and not the server UNC path (I know > this > is not enforced). If users connect to the UNC name directly I loose to > ability > to move the share to a new server and simply change the link in the DFS > console > to point to the new location. Instead I have to get all clients to change > their > configuration. >> >>* that said, I am considering going with the route you suggested David >>(\\domain\dfs\users or similar). Not sure what the 'best practice' would >>be >>in this case though. >> >> >> >>"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message >>news:u71fj45fv6vvkikaok95qgb335m1i5e6ml[ at ]4ax.com... >>> What I have done is >>> a) Create a DFS root like you. I called mine Storage so I have >>> \\domain\storage >>> b) Added various folders to storage e.g. Users, Public, Confidential >>> c) Added links in these above folders the point to the physical data >>> location >>> via it \\server\share reference. e.g. >>> \\domain\storage\public ---> \\server\public$ >>> For home folders I added another layer so I can have home folders on the >>> department own servers >>> \\domain\storage\users\legal ---> \\legalserver\users$ >>> \\domain\storage\users\engineers ---> \\engineersserver\users$ >>> >>> No data is ever stored directly in the DFS folder only Links are put >>> there. >>> >>> >>> >>> >>> On Wed, 3 Dec 2008 19:08:34 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> >>> wrote: >>> >>>>I am setting up DFS (R2) right now with namespaces and replication. I >>>>think >>>>I may be making a fundamental mistake though with the structure. I will >>>>only >>>>be using it for user folders at this time so I: >>>> >>>>- created my namespace server: Server_A >>>>- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the >>>>Users folder >>>> >>>> >>>>Everything is great up to this point as I can now see "\\domain\users". >>>>When >>>>I go to the Namespaces folder on the DFS Management conosle and drill >>>>down >>>>to \\domain\users I don't see anything in the "Namespace" tab on the >>>>right. >>>>I can of course add folders from but the existing subfolders under >>>>"USERS" >>>>don't appear here. >>>> >>>>Have I made "USERS" the DFS Root in this case? Should I be instead be >>>>structuring it so that "USERS" is a namespace folder? I'm a little lost >>>>now..ugh! Thanks. >>>> >>>> >>>> >>> -- >>> Dave Mills >>> There are 10 types of people, those that understand binary and those >>> that >>> don't. >> > -- > Dave Mills > There are 10 types of people, those that understand binary and those that > don't.

Re: DFS Structure help DaveMills <DaveMills[ at ]newsgroup.nospam> 12/8/2008 6:51:58 PM On Mon, 8 Dec 2008 18:14:43 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> wrote: [Quoted Text] >1. Thanks for the advice, I have got my Namespace and Replication in place >as follows: > >Server_A E:\Users$ >Server_B E:\Users$ I assume you means E:\Folder shared as Server_X\Users$ in both cases. > >Namespace: \\domain\DFS\ >Namespace folder: USERS Created using the DFS Management console I assume. > >(I will be configuring the users' home path in AD as follows - >\\domain\dfs\users\%username%) Fine > >We are attempting to have Server_A be the main server with Server_B as a >"hot stand-by" so to speak. So, I have configured Server_A to be "first >among all targets" and Server_B to be "last among all targets in Namespaces. That is what I did but I often found Server_B was the active target even though Server_A was operating normally. >I have done the same for the Folder "Users" in Namespaces. Does this appear >to be correct? You cannot configure the target for a folder in the root only a link or the DFS root itself, unless I have missed something somewhere. > >3. I have set up a replication group for these folders to sync. We will be >replicating ~2TB of data between severs. What would be the recommended quota >sizes for: Notice that the replication group will be replicating the physical folders not via the shares. i.e. E:\Users$ on each server. I think you can even remove the shares and DFS namespace and replication will continue (pointlessly) > >-Staging folder (4096MB default) >-Conflict and Deleted folder (660MB default) I am not sure > >4. To facilitate our "hot stand-by" goal, we would like to implement one-way >replication but I am beginning to wonder if there is any merit to this. I >had planned to simply disable (not delete) the replication connection from >Server_B -> Server_A to prevent it replicating back to the primary. The in >the event of a failure on the primary server I would enable this connection >after recovery so Server_B could replicate back to Server_A. Um, you will need to be absolutely certain that the clients cannot connect to Server_B and as I noted above they sometimes will. This would mead actually disabling the referrals to server B and manually enabling they in a failure. This is what I am thinking of doing but not for several months. > >Can anyone advise on this, should I abandon 1-way replication? > >5. How does VSS work with DFS? Do I simply enable VSS on both servers' >volumes that host the shared folder in the replication group and restore >from the active server when required? Or is the VSS restore done from the >\\domain\dfs\share ? This was answered in another thread as the VSS runs independently on each server. I have not looks and as yet do not have the resources to set up the replication. > > >6. I have asked this before but didn't get a clear response, does anyone >know about SiS (single instance storage) and getting it to work correctly in >a DFS scenario? I am a little bit wary of enabling this service as I don't >know how it would be have with the Common store folder not being replicated >(and also how it would function with VSS). > >7. Do most of you using DFS deploy the Client failback patch (kb898900)? > >Appreciate any feedback as always. Thanks. > >"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message >news:t5hhj4lfurm17cn5gsis2mrndre6cp009h[ at ]4ax.com... >> On Thu, 4 Dec 2008 18:41:12 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> >> wrote: >> >>>Thanks for the answers. As mentioned before, mine is setup as >>>\\domain\users\ with the user folders in that directory. When I create the >>>actual user folders via AD Users & Computers (multiselecting a batch of >>>test >>>user accounts - home folder: \\domain\users\%username%) the folders are of >>>course created but I notice they do not appear in the DFS Management >>>console >>>namespace tab. Of course I can create a folder on the Namespace tab and it >>>appears in the users directory but I am left to wonder what the difference >>>is between the two ways of creating folders? >> I do not know why the folders do not display in the DFS Management >> console, I >> have never tried to have non DFS managed folders within the DFS root. >> >> In my opinion this is a poor design because you have no control over the >> replication. All DFS root servers get a replicated copy of the content of >> the >> DFS root and you cannot change that. This means that many GB of data will >> be >> moved between the root servers when they synchronize. There is no >> interface for >> managing the schedule or any other parameters. You may be able to via >> DFSUTIL or >> registry changes but the system is not designed to be used in this way so >> I >> would not be surprised to find a future update changing things in a way >> the will >> break your system. You should change the design to have >> \\Domain\DFSRoot\Users >> where Users is a link to a \\server\users($) share where the actual >> %username% >> folders are stored. If you want replication of the Users folders then >> simply set >> it up when you add a second link to another server share. This will be far >> more >> flexible. You may have 2 replicated copies of the "Users" folder, no >> replication >> on the "Public" link or any other combination you desire. The way you have >> things will not allow you to expand the system for future needs, to change >> target servers etc. >> >> (A side note: Be careful with the NTFS permissions in the physical DFSRoot >> folders, these are not replicated but inherited from the parent folder >> when the >> root server is set up. I had one copy with Admin=F/C + Everyone=R and the >> other >> as Everyone=F/C. It took me some time to figure out how people were able >> to add >> files to the root because when I looked I saw the more restricted >> permission >> set) >> >> >> If you have not yet read "How DFS works" on >> http://technet.microsoft.com/en-us/library/cc782417.aspx >> You may find it very useful. I can't say I remember it all but it sure >> helped me >> understand why I needed to be careful with the design. >> >> >>> >>>If may ask, why did you create them as hidden shares ($)? >> So users will connect to the DFS paths and not the server UNC path (I know >> this >> is not enforced). If users connect to the UNC name directly I loose to >> ability >> to move the share to a new server and simply change the link in the DFS >> console >> to point to the new location. Instead I have to get all clients to change >> their >> configuration. >>> >>>* that said, I am considering going with the route you suggested David >>>(\\domain\dfs\users or similar). Not sure what the 'best practice' would >>>be >>>in this case though. >>> >>> >>> >>>"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message >>>news:u71fj45fv6vvkikaok95qgb335m1i5e6ml[ at ]4ax.com... >>>> What I have done is >>>> a) Create a DFS root like you. I called mine Storage so I have >>>> \\domain\storage >>>> b) Added various folders to storage e.g. Users, Public, Confidential >>>> c) Added links in these above folders the point to the physical data >>>> location >>>> via it \\server\share reference. e.g. >>>> \\domain\storage\public ---> \\server\public$ >>>> For home folders I added another layer so I can have home folders on the >>>> department own servers >>>> \\domain\storage\users\legal ---> \\legalserver\users$ >>>> \\domain\storage\users\engineers ---> \\engineersserver\users$ >>>> >>>> No data is ever stored directly in the DFS folder only Links are put >>>> there. >>>> >>>> >>>> >>>> >>>> On Wed, 3 Dec 2008 19:08:34 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> >>>> wrote: >>>> >>>>>I am setting up DFS (R2) right now with namespaces and replication. I >>>>>think >>>>>I may be making a fundamental mistake though with the structure. I will >>>>>only >>>>>be using it for user folders at this time so I: >>>>> >>>>>- created my namespace server: Server_A >>>>>- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the >>>>>Users folder >>>>> >>>>> >>>>>Everything is great up to this point as I can now see "\\domain\users". >>>>>When >>>>>I go to the Namespaces folder on the DFS Management conosle and drill >>>>>down >>>>>to \\domain\users I don't see anything in the "Namespace" tab on the >>>>>right. >>>>>I can of course add folders from but the existing subfolders under >>>>>"USERS" >>>>>don't appear here. >>>>> >>>>>Have I made "USERS" the DFS Root in this case? Should I be instead be >>>>>structuring it so that "USERS" is a namespace folder? I'm a little lost >>>>>now..ugh! Thanks. >>>>> >>>>> >>>>> >>>> -- >>>> Dave Mills >>>> There are 10 types of people, those that understand binary and those >>>> that >>>> don't. >>> >> -- >> Dave Mills >> There are 10 types of people, those that understand binary and those that >> don't. > -- Dave Mills There are 10 types of people, those that understand binary and those that don't.

Re: DFS Structure help "Barkley Bees" <barkbees[ at ]nomail.com> 12/12/2008 1:48:56 AM "DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message news:i3qqj4d7p1m196p6ll8niq5s7svqj11m0h[ at ]4ax.com... [Quoted Text] > On Mon, 8 Dec 2008 18:14:43 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> > wrote: > >> >>3. I have set up a replication group for these folders to sync. We will be >>replicating ~2TB of data between severs. What would be the recommended >>quota >>sizes for: > Notice that the replication group will be replicating the physical folders > not > via the shares. i.e. E:\Users$ on each server. I think you can even remove > the > shares and DFS namespace and replication will continue (pointlessly) > >> >>-Staging folder (4096MB default) >>-Conflict and Deleted folder (660MB default) > I am not sure >> Thanks for the advice DaveMills. Btw, I have found a good article on Staging folder configuration which I will follow: http://blogs.technet.com/filecab/archive/2006/03/20/422544.aspx There are several factors that affect the size of staging. Without going into theories, here are some rules of thumb: 1.. It is desirable to set the staging folder to be as large as possible (as available space) and comparable to the size of the replicated folder. Hence if the size of the replicated folder is 24.5 GB, then ideally a staging folder of comparable size is desirable. Note that this amortizes the cost of staging and hash calculation over all connections. It is also a best practice to locate the staging folder on a different spindle to prevent disk contention. 2.. If staging cannot be set comparable to the size of the replicated folder, then reduce the size by 20%. Depending on how well the data compresses, staging files will be 30-50% of the original file size. 3.. Note recommendations (1) and (2) are particularly important if all the data is preexisting and DFS Replication must process all content at the same time during initial replication. On the other hand, if the replicated folder is relatively empty and gradually grows over time, the recommendation is to determine the projected size of the replicated folder and size the staging appropriately. 4.. If the size of the staging folder cannot be set proportional to the size of the replicated folder, then increase the size of the staging folder to be equal to the five largest files in the replicated folder. 5.. Also monitor for staging clean up events in the DFS Replication event log (for example, event 4208 followed by 4206, which means that it was not possible to stage a file due to lack of space and no further clean up was possible), or frequent clean-up events (4202 followed by 4204). If more than a few such event-pair occurs every hour, then increase the size of staging by 50%.

Re: DFS Structure help DaveMills <DaveMills[ at ]newsgroup.nospam> 12/12/2008 4:45:11 AM On Fri, 12 Dec 2008 10:48:56 +0900, "Barkley Bees" <barkbees[ at ]nomail.com> wrote: [Quoted Text] > >"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message >news:i3qqj4d7p1m196p6ll8niq5s7svqj11m0h[ at ]4ax.com... Thanks, I have sent that to my hint and tip folder. >Thanks for the advice DaveMills. Btw, I have found a good article on Staging >folder configuration which I will follow: > >http://blogs.technet.com/filecab/archive/2006/03/20/422544.aspx > >There are several factors that affect the size of staging. Without going >into theories, here are some rules of thumb: > 1.. It is desirable to set the staging folder to be as large as possible >(as available space) and comparable to the size of the replicated folder. >Hence if the size of the replicated folder is 24.5 GB, then ideally a >staging folder of comparable size is desirable. Note that this amortizes the >cost of staging and hash calculation over all connections. It is also a best >practice to locate the staging folder on a different spindle to prevent disk >contention. > 2.. If staging cannot be set comparable to the size of the replicated >folder, then reduce the size by 20%. Depending on how well the data >compresses, staging files will be 30-50% of the original file size. > 3.. Note recommendations (1) and (2) are particularly important if all the >data is preexisting and DFS Replication must process all content at the same >time during initial replication. On the other hand, if the replicated folder >is relatively empty and gradually grows over time, the recommendation is to >determine the projected size of the replicated folder and size the staging >appropriately. > 4.. If the size of the staging folder cannot be set proportional to the >size of the replicated folder, then increase the size of the staging folder >to be equal to the five largest files in the replicated folder. > 5.. Also monitor for staging clean up events in the DFS Replication event >log (for example, event 4208 followed by 4206, which means that it was not >possible to stage a file due to lack of space and no further clean up was >possible), or frequent clean-up events (4202 followed by 4204). If more than >a few such event-pair occurs every hour, then increase the size of staging >by 50%. > -- Dave Mills There are 10 types of people, those that understand binary and those that don't.