Discussion:
DFSR namespace nightmare
(too old to reply)
seanwish
2008-01-01 16:46:06 UTC
Permalink
We have Windows 2003 R2 DFSR implemented with member servers in VA, NC and GA.
All three DFS member servers are DCs in the same domain. We are using
namespace and replication technologies. A few weeks ago, one of our techs
accidentally deleted the primary namespace server (VA) using the DFSR manager
GUI. Replication was not impacted until the MPLS faltered last week. Users
local to the NC and GA servers were still able to access dfs shares mapped to
\\domainname.com\dfsdata (\shared and \users) but users local to the VA
server could not access the dfs shares until communication between sites was
back up, at which time replication was re-established.

Attempts to re-add the VA namespace server failed with "The server you
specified already hosts a namespace with this name" I contacted MS and was
asked to perform the following steps per KB 224384 @
http://support.microsoft.com/kb/224384/en-us


1. Stop the DFS service by tying net stop dfs at a command prompt.
2. Start Registry Editor and delete the following registry keys:a. Delete
the Volumes folder and any subfolders under HKLM\SOFTWARE\Microsoft\DfsHost.
b. Delete all subfolders under HKLM\SYSTEM\CurrentControlSet\Services\
DfsDriver\LocalVolumes, leaving LocalVolumes intact.
3. From the Active Directory Users and Computers snap-in, click Advanced
Features on the View menu. Open the DFS-Configuration container under the
System folder. Delete the DFS root in the right pane.
4. Restart the DFS service you stopped in step 1.


The registry key listed in 2b did not exist (KB article specific to Windows
2000?), and the fix did not permit re-adding the VA namespace server. I
followed up with MS support today and permitted remote control of the VA
server. After an hour of tinkering in the registry and adsiedit we can no
longer add the domain namspace to view from any server using DFSR manager.
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?

Regards,

Sean
Patrick Seeber
2008-01-02 18:09:46 UTC
Permalink
Hello Sean,

I appreciate your post. I have a similar issue, but I have not taken on MS
support yet. Your results are pretty much what my experiences have been in
2007. Not that *comforting*... Hence the presence in the newsgroups.

It does look like the information you were given is Server 2000 based.

You post has inspired me to get off my butt and start digging through the
registry. I may also end up re-building this namespace, but it looks like
there might be some discreat registry trimming prior to rebuild.

I did find, and I hope you also encountered, the namespace entry in the
registry. I think I will start there... and trim lightly.

Hope the rest of the New Year is Happy...

Patrick
Post by seanwish
We have Windows 2003 R2 DFSR implemented with member servers in VA, NC and GA.
All three DFS member servers are DCs in the same domain. We are using
namespace and replication technologies. A few weeks ago, one of our techs
accidentally deleted the primary namespace server (VA) using the DFSR manager
GUI. Replication was not impacted until the MPLS faltered last week.
Users
local to the NC and GA servers were still able to access dfs shares mapped to
\\domainname.com\dfsdata (\shared and \users) but users local to the VA
server could not access the dfs shares until communication between sites was
back up, at which time replication was re-established.
Attempts to re-add the VA namespace server failed with "The server you
specified already hosts a namespace with this name" I contacted MS and was
http://support.microsoft.com/kb/224384/en-us
1. Stop the DFS service by tying net stop dfs at a command prompt.
2. Start Registry Editor and delete the following registry keys:a. Delete
the Volumes folder and any subfolders under
HKLM\SOFTWARE\Microsoft\DfsHost.
b. Delete all subfolders under HKLM\SYSTEM\CurrentControlSet\Services\
DfsDriver\LocalVolumes, leaving LocalVolumes intact.
3. From the Active Directory Users and Computers snap-in, click Advanced
Features on the View menu. Open the DFS-Configuration container under the
System folder. Delete the DFS root in the right pane.
4. Restart the DFS service you stopped in step 1.
The registry key listed in 2b did not exist (KB article specific to Windows
2000?), and the fix did not permit re-adding the VA namespace server. I
followed up with MS support today and permitted remote control of the VA
server. After an hour of tinkering in the registry and adsiedit we can no
longer add the domain namspace to view from any server using DFSR manager.
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?
Regards,
Sean
Rudolf Meier
2008-01-03 10:34:41 UTC
Permalink
Hi
Post by seanwish
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?
Maybe it doesn't help a lot, but as far as I know the data will not be
replicated again. The servers will try to use the files available and if
they already are the same, they won't replicate them again...
... but to be honest, I'm not shure if it would work. I wanted to try this
out one day... but this day is still in the future :-)

Rudolf
seanwish via WinServerKB.com
2008-01-03 19:37:35 UTC
Permalink
I believe the existing files would be dumped into pre-existing following
namespace re-creation. I've encountered similar issues working with less
data in a different DFSR implementation. I don't know of a clean method of
transferring data from pre-existing back into the core dfs shares.
Post by Rudolf Meier
Hi
Post by seanwish
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?
Maybe it doesn't help a lot, but as far as I know the data will not be
replicated again. The servers will try to use the files available and if
they already are the same, they won't replicate them again...
... but to be honest, I'm not shure if it would work. I wanted to try this
out one day... but this day is still in the future :-)
Rudolf
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
Patrick Seeber
2008-01-03 21:58:59 UTC
Permalink
Hello Sean,

Need to check a couple of things with you before I can help you out. Please
let me know the following info if you are comfortable doing so...

In your original post, you say that the MPLS faltered. The users were then
unable to access the DFS SHARES mapped in NC and GA from VA. They SHOULD
have been able to access the DFS, but could not until MPLS proper function
was restored. Correct?

Have you checked Data sizes and file counts on all the DFS-R servers for
matching data? It sounds to me like ONLY your Namespace has been affected,
not the replication... Correct?

If this is the case, Replication Groups are unaffected and ONLY the
Namespace (s) are affected. These are 2 very different systems that are not
necessarily connected.

So you may wish to run some DFS Diagnostic reports and force the diagnostic
to "Count the replicated files and their sizes on each member" in the report
(Next to last page of the report setup, bottom 1/3rd of the dialog box) so
that you can see where your replication truly is.

You may not be facing the full replication unless you have Replication Group
errors and a huge disparity in that data.

Let me know how this shakes out for you. I am still mapping the Namespace
issue that I have - which is the identical error that you have.

I do not believe that you have a replication issue at all at this time.

HTH, and feed me some data back!

Patrick
Post by seanwish via WinServerKB.com
I believe the existing files would be dumped into pre-existing following
namespace re-creation. I've encountered similar issues working with less
data in a different DFSR implementation. I don't know of a clean method of
transferring data from pre-existing back into the core dfs shares.
Post by Rudolf Meier
Hi
Post by seanwish
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?
Maybe it doesn't help a lot, but as far as I know the data will not be
replicated again. The servers will try to use the files available and if
they already are the same, they won't replicate them again...
... but to be honest, I'm not shure if it would work. I wanted to try this
out one day... but this day is still in the future :-)
Rudolf
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
seanwish via WinServerKB.com
2008-01-04 05:46:15 UTC
Permalink
Patrick,

When the mpls went down only users local to the VA server were unable to
access dfs shares. This was because the users at all three locations were
mapped to \\domain.com\dfsdata\users and \\domain.com\dfsdata\shared etc. and
the VA namespace server had been deleted in DFSR Manager.

We do not currently have a replication issue, but recreating the namespace
will require using a different name, and associating the data with the new
namespace will restart replication and likely dump all that data from \\
domain.com\dfsdata\shared into \\domain.com\new_namespace_name\shared\
dfsrprivate\preexisting (dfsrprivate\preexisting are hidden protected
operating system files).

All data is still replicating, but if the mpls goes down again none of the
sites will be able to access \\domain.com\dfsdata shares, as the dfsdata
namespace no longer exists.

Thanks for any input you may have.
Post by Patrick Seeber
Hello Sean,
Need to check a couple of things with you before I can help you out. Please
let me know the following info if you are comfortable doing so...
In your original post, you say that the MPLS faltered. The users were then
unable to access the DFS SHARES mapped in NC and GA from VA. They SHOULD
have been able to access the DFS, but could not until MPLS proper function
was restored. Correct?
Have you checked Data sizes and file counts on all the DFS-R servers for
matching data? It sounds to me like ONLY your Namespace has been affected,
not the replication... Correct?
If this is the case, Replication Groups are unaffected and ONLY the
Namespace (s) are affected. These are 2 very different systems that are not
necessarily connected.
So you may wish to run some DFS Diagnostic reports and force the diagnostic
to "Count the replicated files and their sizes on each member" in the report
(Next to last page of the report setup, bottom 1/3rd of the dialog box) so
that you can see where your replication truly is.
You may not be facing the full replication unless you have Replication Group
errors and a huge disparity in that data.
Let me know how this shakes out for you. I am still mapping the Namespace
issue that I have - which is the identical error that you have.
I do not believe that you have a replication issue at all at this time.
HTH, and feed me some data back!
Patrick
Post by seanwish via WinServerKB.com
I believe the existing files would be dumped into pre-existing following
namespace re-creation. I've encountered similar issues working with less
[quoted text clipped - 17 lines]
Post by seanwish via WinServerKB.com
Post by Rudolf Meier
Rudolf
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
Patrick Seeber
2008-01-04 15:31:27 UTC
Permalink
Hello Sean,

Okay, good. so it's just the "mapping" within the namespace that you need
to resolve... just like me.

I have been rather surprised reviewing the information that MS gave you to
resolve this issue. They did not seem to be in sync with the server
revision that you / we are running.

If you search for DFS, you get lots of registry hits. If you search for
your namspace names you get more exact hits. My current plan is to deleted
the namespace in question from the server's registry every place it occurs.
Could it be that simple? I am thinking it is worth a shot. Got to be
better than rebuilding the entire name.

Rebuilding the namespace with a new name will mean that all my users will
have to re-aquire the new namespace somehow. That's my issue. So it would
be best if the removal of the "orphaned" namespace works.

The one place that hasn't been mentioned in the registry is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain\NAMESPACE_ENTRY

This looks like the one to remove to me... I will let you know. I am pretty
sure I have the *guts* (and backups) to give this a try... (grin)

Patrick
Post by seanwish via WinServerKB.com
Patrick,
When the mpls went down only users local to the VA server were unable to
access dfs shares. This was because the users at all three locations were
mapped to \\domain.com\dfsdata\users and \\domain.com\dfsdata\shared etc. and
the VA namespace server had been deleted in DFSR Manager.
We do not currently have a replication issue, but recreating the namespace
will require using a different name, and associating the data with the new
namespace will restart replication and likely dump all that data from \\
domain.com\dfsdata\shared into \\domain.com\new_namespace_name\shared\
dfsrprivate\preexisting (dfsrprivate\preexisting are hidden protected
operating system files).
All data is still replicating, but if the mpls goes down again none of the
sites will be able to access \\domain.com\dfsdata shares, as the dfsdata
namespace no longer exists.
Thanks for any input you may have.
Post by Patrick Seeber
Hello Sean,
Need to check a couple of things with you before I can help you out.
Please
let me know the following info if you are comfortable doing so...
In your original post, you say that the MPLS faltered. The users were then
unable to access the DFS SHARES mapped in NC and GA from VA. They SHOULD
have been able to access the DFS, but could not until MPLS proper function
was restored. Correct?
Have you checked Data sizes and file counts on all the DFS-R servers for
matching data? It sounds to me like ONLY your Namespace has been affected,
not the replication... Correct?
If this is the case, Replication Groups are unaffected and ONLY the
Namespace (s) are affected. These are 2 very different systems that are not
necessarily connected.
So you may wish to run some DFS Diagnostic reports and force the diagnostic
to "Count the replicated files and their sizes on each member" in the report
(Next to last page of the report setup, bottom 1/3rd of the dialog box) so
that you can see where your replication truly is.
You may not be facing the full replication unless you have Replication Group
errors and a huge disparity in that data.
Let me know how this shakes out for you. I am still mapping the Namespace
issue that I have - which is the identical error that you have.
I do not believe that you have a replication issue at all at this time.
HTH, and feed me some data back!
Patrick
Post by seanwish via WinServerKB.com
I believe the existing files would be dumped into pre-existing following
namespace re-creation. I've encountered similar issues working with less
[quoted text clipped - 17 lines]
Post by seanwish via WinServerKB.com
Post by Rudolf Meier
Rudolf
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
Patrick Seeber
2008-01-04 17:29:01 UTC
Permalink
Hey Sean,

Okay, I was definitely on the right track. There were some additional
deletes to be handled, along with the server restart. Once the server
restarted or reloaded the registry I was able to add the server to the
namespace as it used to be.

YOUR MILEAGE MAY VARY... but here is what I did...
Looked up and deleted these registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain\TARGET_NAMESPACE_ENTRY
(and it's sub keys)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares\TARGET_NAMESPACE_ENTRY

TARGET_NAMESPACE_ENTRY = the namespace that you are having issues with.

THERE ARE CAVEATS TO THIS, and perhaps yours will work differently.

My namespaces currently do not run multiple servers at all times. There
seems to be an issue with latency and the fall back to main site. So I run
one server per namespace. Not my decision, simply what I am told to do.

With these registry edits I am able to add the "backup" servers (now called
BC1 for this discussion) back into the namespace. When I do, I am unable to
right click on a folder in the "\\domain.com\target_namespace" and see the
DFS tab. Once i remove the BC1 server that I was having issues re-adding to
the Namespace then all of a sudden I see the properties info along with the
DFS tab for the "\\domain.com\target_namespace".

I just checked with another admin - as admins we don't have access rights to
this namespace - and the tab shows up on the end user (with access rights)
explorer/properties/DFS tab and shows the correct servers and correct active
server. This remains correct through out the transition of removing and
adding Namespace servers.

So you may want to approach this with caution. Because we don't have access
rights it may be causing some issues. In addition to this, I DID NOT follow
the instructions that you posted from MS. I did my own thing at this point.

If you are feeling brave, and have all the backups in place... you could go
for it.

If anyone has any insight into the "no display of properties" on the
Namspace, please share.

That is what I have for now, hope it helps.

Patrick
patricksATnavellier-DOT-com
Post by Patrick Seeber
Hello Sean,
Okay, good. so it's just the "mapping" within the namespace that you need
to resolve... just like me.
I have been rather surprised reviewing the information that MS gave you to
resolve this issue. They did not seem to be in sync with the server
revision that you / we are running.
If you search for DFS, you get lots of registry hits. If you search for
your namspace names you get more exact hits. My current plan is to
deleted the namespace in question from the server's registry every place
it occurs. Could it be that simple? I am thinking it is worth a shot.
Got to be better than rebuilding the entire name.
Rebuilding the namespace with a new name will mean that all my users will
have to re-aquire the new namespace somehow. That's my issue. So it
would be best if the removal of the "orphaned" namespace works.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain\NAMESPACE_ENTRY
This looks like the one to remove to me... I will let you know. I am
pretty sure I have the *guts* (and backups) to give this a try... (grin)
Patrick
Post by seanwish via WinServerKB.com
Patrick,
When the mpls went down only users local to the VA server were unable to
access dfs shares. This was because the users at all three locations were
mapped to \\domain.com\dfsdata\users and \\domain.com\dfsdata\shared etc. and
the VA namespace server had been deleted in DFSR Manager.
We do not currently have a replication issue, but recreating the namespace
will require using a different name, and associating the data with the new
namespace will restart replication and likely dump all that data from \\
domain.com\dfsdata\shared into \\domain.com\new_namespace_name\shared\
dfsrprivate\preexisting (dfsrprivate\preexisting are hidden protected
operating system files).
All data is still replicating, but if the mpls goes down again none of the
sites will be able to access \\domain.com\dfsdata shares, as the dfsdata
namespace no longer exists.
Thanks for any input you may have.
Post by Patrick Seeber
Hello Sean,
Need to check a couple of things with you before I can help you out.
Please
let me know the following info if you are comfortable doing so...
In your original post, you say that the MPLS faltered. The users were then
unable to access the DFS SHARES mapped in NC and GA from VA. They SHOULD
have been able to access the DFS, but could not until MPLS proper function
was restored. Correct?
Have you checked Data sizes and file counts on all the DFS-R servers for
matching data? It sounds to me like ONLY your Namespace has been affected,
not the replication... Correct?
If this is the case, Replication Groups are unaffected and ONLY the
Namespace (s) are affected. These are 2 very different systems that are not
necessarily connected.
So you may wish to run some DFS Diagnostic reports and force the diagnostic
to "Count the replicated files and their sizes on each member" in the report
(Next to last page of the report setup, bottom 1/3rd of the dialog box) so
that you can see where your replication truly is.
You may not be facing the full replication unless you have Replication Group
errors and a huge disparity in that data.
Let me know how this shakes out for you. I am still mapping the Namespace
issue that I have - which is the identical error that you have.
I do not believe that you have a replication issue at all at this time.
HTH, and feed me some data back!
Patrick
Post by seanwish via WinServerKB.com
I believe the existing files would be dumped into pre-existing following
namespace re-creation. I've encountered similar issues working with less
[quoted text clipped - 17 lines]
Post by seanwish via WinServerKB.com
Post by Rudolf Meier
Rudolf
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
seanwish via WinServerKB.com
2008-01-05 13:07:48 UTC
Permalink
Patrick,

Interesting findings on your part. Thanks for the post. I had some more
pressing matters to attend to at the end of this week so we are still
strategizing. We are trying to get some assurances from MS on replication
and pre-existing data before trying anything drastic. I'll let you know what
we find out.
Post by Patrick Seeber
Hey Sean,
Okay, I was definitely on the right track. There were some additional
deletes to be handled, along with the server restart. Once the server
restarted or reloaded the registry I was able to add the server to the
namespace as it used to be.
YOUR MILEAGE MAY VARY... but here is what I did...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain\TARGET_NAMESPACE_ENTRY
(and it's sub keys)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares\TARGET_NAMESPACE_ENTRY
TARGET_NAMESPACE_ENTRY = the namespace that you are having issues with.
THERE ARE CAVEATS TO THIS, and perhaps yours will work differently.
My namespaces currently do not run multiple servers at all times. There
seems to be an issue with latency and the fall back to main site. So I run
one server per namespace. Not my decision, simply what I am told to do.
With these registry edits I am able to add the "backup" servers (now called
BC1 for this discussion) back into the namespace. When I do, I am unable to
right click on a folder in the "\\domain.com\target_namespace" and see the
DFS tab. Once i remove the BC1 server that I was having issues re-adding to
the Namespace then all of a sudden I see the properties info along with the
DFS tab for the "\\domain.com\target_namespace".
I just checked with another admin - as admins we don't have access rights to
this namespace - and the tab shows up on the end user (with access rights)
explorer/properties/DFS tab and shows the correct servers and correct active
server. This remains correct through out the transition of removing and
adding Namespace servers.
So you may want to approach this with caution. Because we don't have access
rights it may be causing some issues. In addition to this, I DID NOT follow
the instructions that you posted from MS. I did my own thing at this point.
If you are feeling brave, and have all the backups in place... you could go
for it.
If anyone has any insight into the "no display of properties" on the
Namspace, please share.
That is what I have for now, hope it helps.
Patrick
patricksATnavellier-DOT-com
Post by Patrick Seeber
Hello Sean,
[quoted text clipped - 99 lines]
Post by Patrick Seeber
Post by Rudolf Meier
Rudolf
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
Jeffrey Randow
2008-01-03 02:35:06 UTC
Permalink
I saw this also at a site, but our solution was a bit draconian and I
did have to redo replication with that one server... I wiped and
rebuilt the box. However, the solution MS suggested seems easier than
this.
---
Jeffrey Randow
***@gmail.com
Windows Networking MVP 2001-2006
http://www.networkblog.net
Post by seanwish
We have Windows 2003 R2 DFSR implemented with member servers in VA, NC and GA.
All three DFS member servers are DCs in the same domain. We are using
namespace and replication technologies. A few weeks ago, one of our techs
accidentally deleted the primary namespace server (VA) using the DFSR manager
GUI. Replication was not impacted until the MPLS faltered last week. Users
local to the NC and GA servers were still able to access dfs shares mapped to
\\domainname.com\dfsdata (\shared and \users) but users local to the VA
server could not access the dfs shares until communication between sites was
back up, at which time replication was re-established.
Attempts to re-add the VA namespace server failed with "The server you
specified already hosts a namespace with this name" I contacted MS and was
http://support.microsoft.com/kb/224384/en-us
1. Stop the DFS service by tying net stop dfs at a command prompt.
2. Start Registry Editor and delete the following registry keys:a. Delete
the Volumes folder and any subfolders under HKLM\SOFTWARE\Microsoft\DfsHost.
b. Delete all subfolders under HKLM\SYSTEM\CurrentControlSet\Services\
DfsDriver\LocalVolumes, leaving LocalVolumes intact.
3. From the Active Directory Users and Computers snap-in, click Advanced
Features on the View menu. Open the DFS-Configuration container under the
System folder. Delete the DFS root in the right pane.
4. Restart the DFS service you stopped in step 1.
The registry key listed in 2b did not exist (KB article specific to Windows
2000?), and the fix did not permit re-adding the VA namespace server. I
followed up with MS support today and permitted remote control of the VA
server. After an hour of tinkering in the registry and adsiedit we can no
longer add the domain namspace to view from any server using DFSR manager.
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?
Regards,
Sean
J Ford
2008-01-03 16:25:05 UTC
Permalink
Is the 'primary' namespace server the first one setup when a given namespace
is created? Assuming so. In the gui, you can't tell which server's the
primary just by looking at the namespace tab and/or selecting any of the
servers hosting the namespace, viewing their properties.

Is that designation in the registry somewhere or...?

Also, accidents happen... but does the 'delete' action at least warn/prompt
you when deleting a namespace host server? Would hope so... if these are the
consequences that cannot easily be undone.
Post by Jeffrey Randow
I saw this also at a site, but our solution was a bit draconian and I
did have to redo replication with that one server... I wiped and
rebuilt the box. However, the solution MS suggested seems easier than
this.
---
Jeffrey Randow
Windows Networking MVP 2001-2006
http://www.networkblog.net
Post by seanwish
We have Windows 2003 R2 DFSR implemented with member servers in VA, NC and GA.
All three DFS member servers are DCs in the same domain. We are using
namespace and replication technologies. A few weeks ago, one of our techs
accidentally deleted the primary namespace server (VA) using the DFSR manager
GUI. Replication was not impacted until the MPLS faltered last week. Users
local to the NC and GA servers were still able to access dfs shares mapped to
\\domainname.com\dfsdata (\shared and \users) but users local to the VA
server could not access the dfs shares until communication between sites was
back up, at which time replication was re-established.
Attempts to re-add the VA namespace server failed with "The server you
specified already hosts a namespace with this name" I contacted MS and was
http://support.microsoft.com/kb/224384/en-us
1. Stop the DFS service by tying net stop dfs at a command prompt.
2. Start Registry Editor and delete the following registry keys:a. Delete
the Volumes folder and any subfolders under HKLM\SOFTWARE\Microsoft\DfsHost.
b. Delete all subfolders under HKLM\SYSTEM\CurrentControlSet\Services\
DfsDriver\LocalVolumes, leaving LocalVolumes intact.
3. From the Active Directory Users and Computers snap-in, click Advanced
Features on the View menu. Open the DFS-Configuration container under the
System folder. Delete the DFS root in the right pane.
4. Restart the DFS service you stopped in step 1.
The registry key listed in 2b did not exist (KB article specific to Windows
2000?), and the fix did not permit re-adding the VA namespace server. I
followed up with MS support today and permitted remote control of the VA
server. After an hour of tinkering in the registry and adsiedit we can no
longer add the domain namspace to view from any server using DFSR manager.
MS support now recommends recreating the namespace share, which will break
DFS and restart the replication of ~350GBs of data = 10 days. Does anyone
have a better solution?
Regards,
Sean
seanwish via WinServerKB.com
2008-01-03 19:30:24 UTC
Permalink
I don't recall if the "primary" server had a specific designation - I thought
it did but it may not have. I know that it was the first server added to the
newly created namespace.

I believe the tech that deleted the namespace server was prompted but there
was a time delay on the remote connection. Patience was the lesson learned.
Post by J Ford
Is the 'primary' namespace server the first one setup when a given namespace
is created? Assuming so. In the gui, you can't tell which server's the
primary just by looking at the namespace tab and/or selecting any of the
servers hosting the namespace, viewing their properties.
Is that designation in the registry somewhere or...?
Also, accidents happen... but does the 'delete' action at least warn/prompt
you when deleting a namespace host server? Would hope so... if these are the
consequences that cannot easily be undone.
Post by Jeffrey Randow
I saw this also at a site, but our solution was a bit draconian and I
did have to redo replication with that one server... I wiped and
[quoted text clipped - 43 lines]
Post by Jeffrey Randow
Sean
--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forums.aspx/windows-server-dfs-frs/200801/1
Loading...