Target not eligible for replication?

[David Neil Smith]

Hi, we have a simple scenario - two offices (750kbs link between them), 2
Windows 2003 R2 servers, and I want to have a folder with the same contents
on both servers in a domain based DFS namespace. Set it up on one system and
stupidly waited for replication of 20Gb over the ADSL link. Removed the 2nd
target and physically brought the server back to the main office. Recreated
the 2nd target again and tried to set up replication but the main/1st server
(the one with the currently working and published DFS domain root on it now
states and I quote
"This target is not eligible because the folder overlaps an existing
replicated folder on that computer"
I am at a loss as to what to do now and any help would be very much
appreciated.
Many thanks in anticipation of some kind person replying

David Smith
MCP MCDBA MCSE (<---- and none of it much good obviously!!)

[Ned Pyle [MSFT]]

You have both DFSR and FRS configured to replicate the same exact folders.
Need to choose one and stick with it - I recommend DFSR. :-)

[David Neil Smith]

Ned, OK - I can understand what you are saying however:

a. I have never as far as I am aware (and these are new servers only a few
dasy old) have I specifically configured FRS and
b. How do I stop the FRS and stick with DFSr?

Many thanks

David

Post by Ned Pyle [MSFT]
You have both DFSR and FRS configured to replicate the same exact folders.
Need to choose one and stick with it - I recommend DFSR. :-)
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.

[Ned Pyle [MSFT]]

It's possible that DFSR is overlapping with DFSR as well, I suppose. Never
actually seen that, but would certainly be possible (it's almost always
FRS).

Look through the DFSMGMT.MSC at all of your replicated folders and ensure
they are not overlapping.

[David Neil Smith]

Ned, many thanks once again. I must be being stupid but by 'DFSMGMT.MSC' do
you mean the normal DFS Management MMC tool - i.e. the one you set up DFS
with? We only have the one root that points to just one top level folder; the
message about 'overlapped folders' almost looks as though it refers to the
staging folder - I have seen other articles on the web (and you never know
how accurate these articles are of course) describing using various tools to
remove and reset this staging folder. Do you think this is something I should
look at/ Your help is very much appreciated.

Kind regard

David

Post by Ned Pyle [MSFT]
It's possible that DFSR is overlapping with DFSR as well, I suppose. Never
actually seen that, but would certainly be possible (it's almost always
FRS).
Look through the DFSMGMT.MSC at all of your replicated folders and ensure
they are not overlapping.
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.

[Ned Pyle [MSFT]]

No worries - yes, that is the one.

The area in that tool you want to look at is the 'Replication' node (the
counterpart to the Namespaces node). Do you have more than one Replication
group in there? If you look at each one of them, do any of their replicated
folders ever cross each other, for "local path"?

[David Neil Smith]

Sorry I haven't got back before now but we have had a holiday here in the UK.
Ned, as I said I must be being even more stupid as the tool that I assume you
meant doesn't seem to have anything like 'replication' nodes etc. I was
meaning the menu option on a standard W2003 Server that's called 'Distributed
File System' and the one that shows items like the Root Target, DSR Referral
and Status. Is this the one you mean and if so, how can I see the items you
mentioned there?

Sorry about this but I'm getting desperate to solve this basic 2 server DFS
situation.

Also, as a test - some weeks ago now before trying to go 'live' - I had set
created another root target on a local server and proved the replication to
work, stopped the replication, removed the root but now the 'FRS-Staging'
folder (on the test target server) is still stuck there and will not let me
remove it. How can I remove this folder please?

Many thanks in anticipation of your continued help.

kind regards

David

Post by Ned Pyle [MSFT]
No worries - yes, that is the one.
The area in that tool you want to look at is the 'Replication' node (the
counterpart to the Namespaces node). Do you have more than one Replication
group in there? If you look at each one of them, do any of their replicated
folders ever cross each other, for "local path"?
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.

[Ned Pyle [MSFT]]

You would want to be loading DFSMGMT.MSC if you wanted to configure DFSR
replication. It sort of sounds like you are describing DFSGUI.MSC, the
legacy tool that was used pre-R2/DFSR.

Since you have DFSR, I would highly recommend using it now instead of FRS.
It's many many times better for a variety of reasons. Using DFSMGMT to
configure replication uses DFSR. Using DFSGUI to configure replication uses
FRS.

I hope I've made more sense... I think I may still being more confusing than
helpful. :-(

[David Neil Smith]

Ned, I finally understand - must be my age. I didn't realise that the DFS
Management Tool was not loaded by default into Windows 2003 R2 and that I
have been using the old DFS tool which does use FRS of course. Having
installed the new tool on both servers, I added the second server as a
namespace server and started the replciation wizard which allowed me to
select the relevant folder that I need replicating - in fact, now much of
what you said makes sense (sorry about the delay in understanding you) about
what folders to replicate etc. I actually only want replicating one folder
(and all relevant sub-folders) so setting up the replication group was easy!
However, when I completed it, having set the schedule to 24hr full bandwith
(both machines are local now with 1Gb connections between each other), first
of all my users mentioned that suddenly the published share which in our case
is \\bam\data (that's the namespace) didn't have any data in it (the IT
person's nightmare) and on the first server the event viewer reported a 6402
error regarding FRS replication. So I had to quickly remove the replication
group, remove the secondary namespace server and breath again - users OK.
So trying to move forward, how do I get rid of any old FRS replication
information please - using the old DFS tool there is nothing set to replicate
so it must be registry thing. Any ideas and AS ALWAYS many, many thanks for
your help. I do feel I am getting closer but a long weekend looks inevitable
at the moment.

Kind regards

David Smith

Post by Ned Pyle [MSFT]
You would want to be loading DFSMGMT.MSC if you wanted to configure DFSR
replication. It sort of sounds like you are describing DFSGUI.MSC, the
legacy tool that was used pre-R2/DFSR.
Since you have DFSR, I would highly recommend using it now instead of FRS.
It's many many times better for a variety of reasons. Using DFSMGMT to
configure replication uses DFSR. Using DFSGUI to configure replication uses
FRS.
I hope I've made more sense... I think I may still being more confusing than
helpful. :-(
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.

[Ned Pyle [MSFT]]

If the old FRs info is gone from DFSGUI.MSC, it may still be in registry and
possibly AD. Another customer here had the same issue, trying to find the
post I gave him which ended up solving it...

[Ned Pyle [MSFT]]

Here we go. /SNIP:

STOP FRS ON THE REPLICAS BEFORE DOING ANY OF THIS

1. Examine the registry at
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs
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
in a domain called Contoso.com with a server called NED01):

cn=YOUR REPLICA,cn=7613dd47-bfbe-407f-a8dc-43cc00c878ca,cn=dfs
volumes,cn=ntfrs subscriptions,cn=NED01-2,cn=computers,dc=contoso,dc=com

(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
service,cn=system,dc=contoso,dc=com
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
deleted.

[David Neil Smith]

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
week.
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
going.
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
\\JEEVES\DATA.
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?

Kind regards

David

Post by Ned Pyle [MSFT]
STOP FRS ON THE REPLICAS BEFORE DOING ANY OF THIS
1. Examine the registry at
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs
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
cn=YOUR REPLICA,cn=7613dd47-bfbe-407f-a8dc-43cc00c878ca,cn=dfs
volumes,cn=ntfrs subscriptions,cn=NED01-2,cn=computers,dc=contoso,dc=com
(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
service,cn=system,dc=contoso,dc=com
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
deleted.
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.

[Ned Pyle [MSFT]]

Whew! :)

Shoot me the JPG in an email with my address I post with here, removing the
.online part.

[Ned Pyle [MSFT]]

Got your JPEG's.

I *think* I understand this now... it looks like the structure is a bit
interwoven, in a way that we don't want to do.

The 'Data' root name space share should not contain any data - it is simply
used as a reparse point for DFS to create the namespace.
The Folder targets should be *separate shares* (not the root Data shares).
Those folder targets can then be replicated.

Everything should just work then. Does this make sense? I am on 4 hours
sleep and can't self evaluate... :-)

[David Neil Smith]

Ned, sorry about your lack of sleep. However, any wild thoughts on the
simplest way of getting myself out of the mess?

Cheers

David

Post by Ned Pyle [MSFT]
Got your JPEG's.
I *think* I understand this now... it looks like the structure is a bit
interwoven, in a way that we don't want to do.
The 'Data' root name space share should not contain any data - it is simply
used as a reparse point for DFS to create the namespace.
The Folder targets should be *separate shares* (not the root Data shares).
Those folder targets can then be replicated.
Everything should just work then. Does this make sense? I am on 4 hours
sleep and can't self evaluate... :-)
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.

[Ned Pyle [MSFT]]

Oh! Well yes, I do: don't put any data in Data. Data should be used only as
an empty DFS root share. Put data in shares on servers, then make those
shares into folder targets and replicate *those* guys.

[David Neil Smith]

Ned, once again, many thanks for this.

Can I now announce that everything is working wonderfull - I was brave
enough at the weekend to pull the plug on all the old DFS stuff and re-create
it from new with the new DFS Management consolde - so easy and more
importantly - it works!

You are a star - even with only 4 hrs sleep.

Cheers

David

Post by David Neil Smith
Ned, sorry about your lack of sleep. However, any wild thoughts on the
simplest way of getting myself out of the mess?
Cheers
David

Post by Ned Pyle [MSFT]
Got your JPEG's.
I *think* I understand this now... it looks like the structure is a bit
interwoven, in a way that we don't want to do.
The 'Data' root name space share should not contain any data - it is simply
used as a reparse point for DFS to create the namespace.
The Folder targets should be *separate shares* (not the root Data shares).
Those folder targets can then be replicated.
Everything should just work then. Does this make sense? I am on 4 hours
sleep and can't self evaluate... :-)
--
Ned Pyle
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
http://www.microsoft.com/info/cpyright.mspx to find terms of use.