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.

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@nomail.com> wrote in message
news:uu5jc8SVJHA.4384@TK2MSFTNGP06.phx.gbl...

Quote:

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.

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@nomail.com> wrote:

Quote:

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.

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@newsgroup.nospam> wrote in message
news:u71fj45fv6vvkikaok95qgb335m1i5e6ml@4ax.com...

Quote:

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@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.

On Thu, 4 Dec 2008 18:41:12 +0900, "Barkley Bees" <barkbees@nomail.com> wrote:

Quote:

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.

Quote:

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.

Quote:

* 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@newsgroup.nospam> wrote in message news:u71fj45fv6vvkikaok95qgb335m1i5e6ml@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@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.

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@newsgroup.nospam> wrote in message
news:t5hhj4lfurm17cn5gsis2mrndre6cp009h@4ax.com...

Quote:

On Thu, 4 Dec 2008 18:41:12 +0900, "Barkley Bees" <barkbees@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@newsgroup.nospam> wrote in message news:u71fj45fv6vvkikaok95qgb335m1i5e6ml@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@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.

On Mon, 8 Dec 2008 18:14:43 +0900, "Barkley Bees" <barkbees@nomail.com> wrote:

Quote:

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.

Quote:

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.

Quote:

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)

Quote:

-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.

Quote:

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.

Quote:

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@newsgroup.nospam> wrote in message news:t5hhj4lfurm17cn5gsis2mrndre6cp009h@4ax.com... On Thu, 4 Dec 2008 18:41:12 +0900, "Barkley Bees" <barkbees@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@newsgroup.nospam> wrote in message news:u71fj45fv6vvkikaok95qgb335m1i5e6ml@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@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.

"DaveMills" <DaveMills@newsgroup.nospam> wrote in message
news:i3qqj4d7p1m196p6ll8niq5s7svqj11m0h@4ax.com...

Quote:

On Mon, 8 Dec 2008 18:14:43 +0900, "Barkley Bees" <barkbees@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%.

On Fri, 12 Dec 2008 10:48:56 +0900, "Barkley Bees" <barkbees@nomail.com> wrote:

Quote:

"DaveMills" <DaveMills@newsgroup.nospam> wrote in message news:i3qqj4d7p1m196p6ll8niq5s7svqj11m0h@4ax.com...

Thanks, I have sent that to my hint and tip folder.

Quote:

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.