Hello. I am hoping that someone more experienced with these services can provide some feedback on the following comments. We are a large UK based Secondary school occupying two sites. The sites are linked using Gigabit Fibre and all our servers run Windows Server 2003 Enterprise edition and our clients XP PRO with a mix of SP1 & SP2. Our school consists of around 1700 students, 120 staff and 700 pc's, we have around 10 servers running Exchange, SMS, ISA, Linux, Print Server etc. We have a general network resource drive with about 10GB of data which is replicated using DFR-RFS between sites. This resource drive is 95% read only with a very low churn rate of not more than a couple of MB a day. FRS seems to be working very well for this drive. We would like to use DFS / RFS for our student & staff home folders to provide load balancing and fault tolerance. Our user data is currently just over 100GB in size and we estimate that we have a churn rate of not more than 7GB spread across the day. I have the choice of a new Server 2003 or Storage Server 2003 system to configure as our first replication partner but on checking out the Microsoft recommendations I am concerned that we have considerably more than the 64GB data limit Microsoft specify. My questions:- Is this limit per site, domain or replica set? Can one pair of servers host more than one replica sets to get around this limit? If not how come the jet database and staging areas can be terabytes in size? Is the DFS/replication supported by Storage Server 2003 more robust and scalable? IE will it support replicating our 100GB of data? What about Server 2003 R2, Is this a better bet than Storage Server 2003 for our requirements? Please understand that I have researched these questions and I have vague answers to most of these questions but I am looking for feedback from someone who has been at the sharp end of implementing something along the lines of my proposed solution. In fact any insight at all is very much appreciated. Thank you for taking time to read this. Andy.