Ned, many many thanks for that. I am sorry I haven't got back to you before
now but I had to try this out at the weekend rather than during the working
In fact, from my 'tests', there were several replica set defintions in the
FRS location you mention but none (apart from the SYSVOL one) at the location
using ADSIEdit. So, trying to be brave, I deleted the FRS replicas from the
registry of both systems and then went to work using the new DFS Management
tool (and what a better tool it looks!).
Just a quick background: I want a very simple scenario of just one parent
folder that all staff in two sites point to, that I intended to call data (Ok
- highly original I know). I'm not sure whether this is my current problem
but I created a share on our first server called DATA and this, in effect,
was the top most folder with staff accessing relevant sub-folders.
So my dfsnamespace was going to be called \\BAM\DATA (where BAM.LOCAL is our
internal domain name).
I had created a share on the first server, JEEVES, called DATA and because
the DFS information had come through from the old DFS setup, my first
namespace server was already defined as \\JEEVES\DATA.
I can created another namespace server using a server called HATTY and share
DATA as \\HATTY\DATA.
I then set up replication between these 2 servers and as both are in our
local network currently (HATTY will eventually end up in Harrogate (hence the
name!)), replication of the 20Gb of current data (all held in sub-folders of
that data folder) was very rapid and breather a big sigh of relief thinking
all my troubles were over.
When I tried to access this from a workstation I couldn't see any
sub-folders what so ever and then I discovered that you have to publish the
replication which I did. HOWEVER, for a reason I am not sure about, I then
had to create a name for the publication - and of course I couldn't really
use data again - so I called it ROOT and had to specificy a new folder
location for this on the second server which I called SYNCDATA just to get it
Monday am comes and things generally are OK - however, JEEVES is confused
with an inability to locate \\BAM\DATA\ROOT directly and seems to have the
situation of ROOT within ROOT etc. Workstations generally can access
\\BAM\DATA\ROOT - but can still access \\BAM\DATA and see the contents not
just as ROOT but as ROOT plus all the sub-folders of the actual share
Wow, sorry that was so complicated - I have a jpeg of what the DFS
Management util shows but cannot add it here for some reason.
Any thoughts on what I have done wrong please?
Post by Ned Pyle [MSFT]
STOP FRS ON THE REPLICAS BEFORE DOING ANY OF THIS
1. Examine the registry at
2. Under there, look at Replica Sets
3. Under there, you should have a series of GUID's
4. Under the GUID's, look for the replica set that matches the one you are
attempting to remove ( Replica Set Name should ID it)
5. Load ADSIEDIT.MSC from the support tools, then navigate to (for example
(Note that 7613dd47-bfbe-407f-a8dc-43cc00c878ca is a random GUID - it will
be different for you.)
6. You can then delete object that matches your Replica Set Name. If that
was the *only* NTFRS replica under the computer, you can delete the ntfrs
subscriptions object (if it's a DC it will NOT be the only one, as SYSVOL is
an NTFRS replica).
7. Then you will want to use ADSIEDIT to go into cn=SOME GUID's,cn=YOUR DFS
LINK,cn=YOUR DFS NAMESPACE,cn=dfs volumes,cn=file replication
8. Those GUID's will all have an attribute named FrsMemberReference - if
that matches this server you are trying to repair, the object should be
Microsoft Enterprise Platforms Support
All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit