In case you find this blog and have read through to this point and still have a problem, try looking at AD.
I had a similar issue and followed the same steps with no resolution. Found that AD still thinks that the old server is part of the DFS namespace. Still working on the full solution, but at least now I know what the cause is.
In short, AD is the cause, and the ongoing DFS replication is just the symptom.
Regards,
Ned Pyle [MSFT] wrote:
Are there any folders under your root namespace share/ the reparse point
12-Mar-07
Are there any folders under your root namespace share/ the reparse point
should be in there... somewhere.
LOL@ the namespace gods. :-)
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:DEA44DAC-A1CD-47E8-9255-***@microsoft.com...
Previous Posts In This Thread:
On Friday, March 02, 2007 12:06 PM
StuJackso wrote:
Remove DFS replication member & namespace target problem
Here is my problem:
I have removed a server we are decomissioning from a replcation group as
well as removed it from being a namespace target using the DFS Management
console. I have also removed the file shares from the server and shut down
the disk array that housed the data in the replication group. As part of my
testing I went to verify that there was no way my user community could access
the data since it was no longer live. Much to my dismay I found that when I
entered the UNC pathing to test access to the retired data (which I do not
want) somehow a namespace target is still recognized for the server and
redirected my query to the live data on another server. I have tried
removing the old namespace target using the dfsutil method laid out in
http://support.microsoft.com/default.aspx?scid=kb;en-us;842218 and the share
continues to exist. I would like to get this old target removed but have
been completely unable to eradicate it.
I'll take any suggestions.
On Wednesday, March 07, 2007 6:39 PM
Ned Pyle [MSFT] wrote:
From one of the clients that can still see the data, copy the DFSUTIL.
From one of the clients that can still see the data, copy the DFSUTIL.EXE
from the Windows Server 2003 SP1 support tools. Connect to the undesired
share through DFS. Then execute:
DFSUTIL /PKTINFO
DFSUTIL/SPCINFO
and paste the results here. I'm looking for which machines are still
advertising the root and which DC's you were talking to at the time to get
it.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:820A3FCF-64ED-4F59-8D46-***@microsoft.com...
On Thursday, March 08, 2007 10:24 AM
StuJackso wrote:
Here are the results of the DFSUTIL as your requested.
Here are the results of the DFSUTIL as your requested. The mapping that I
have been trying to remove is the first two in the pktinfo results (assuming
that once the first goes away the second will as well). The susd4sw20101
server is currently a domain controller but I am working on replacing that
server and hence the reason that I would like to get rid of the mapping.
C:\Temp>dfsutil /pktinfo
Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.
--mup.sys--
4 entries...
Entry: \susd4sw20101\libae
ShortEntry: \susd4sw20101\libae
Expires in 300 seconds
UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS )
0:[\SUSD4SW20125\LibAE] State:0x19 ( ACTIVE )
Entry: \susd4sw20101\libae\Florida
ShortEntry: \susd4sw20101\libae\Florida
Expires in 1800 seconds
UseCount: 1 Type:0x1 ( DFS )
0:[\susd4sw20125.susd4.swisslog.com\Florida] State:0x31 ( ACTIVE )
1:[\susd4s1103.susd4.swisslog.com\Florida] State:0x21 ( )
2:[\SUSD4S0201\Florida] State:0x21 ( )
Entry: \susd4.swisslog.com\Denver
ShortEntry: \susd4.swisslog.com\Denver
Expires in 300 seconds
UseCount: 1 Type:0x81 ( REFERRAL_SVC DFS )
0:[\SUSD4S0126\Denver] State:0x19 ( ACTIVE )
Entry: \susd4.swisslog.com\Denver\users
ShortEntry: \susd4.swisslog.com\Denver\users
Expires in 1800 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[\susd4sw20102.susd4.swisslog.com\Users] State:0x31 ( ACTIVE )
1:[\susd4s0126.susd4.swisslog.com\Users] State:0x21 ( )
DfsUtil command completed successfully.
C:\Temp>dfsutil /spcinfo
Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.
[*][susd4sw20102.susd4.swisslog.com]
[*][SUSD4]
[*][susd4.swisslog.com]
[+][susd4.swisslog.com]
[+susd4sw20102.susd4.swisslog.com]
[-SUSD4SW20101.susd4.swisslog.com]
[-susd4sw20302.susd4.swisslog.com]
[-susd4s1101.susd4.swisslog.com]
[-SUSD4SW20501.susd4.swisslog.com]
[-][SUSD4]
DfsUtil command completed successfully.
"Ned Pyle [MSFT]" wrote:
On Thursday, March 08, 2007 10:36 AM
Ned Pyle [MSFT] wrote:
So that's a standalone DFS root?
So that's a standalone DFS root? Having removed everything gracefully, has
the DFS service on that machine been restarted, and after it has, does it
still have DFS registry entries for the namespace?
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:ADBEC163-26D1-4FC3-8557-***@microsoft.com...
On Thursday, March 08, 2007 2:44 PM
StuJackso wrote:
That share (DFS root?
That share (DFS root?) is the remants of what was created when that server
was a namespace target.
Here's what I done/found on that server(0101) as I have removed it from my
DFS Replication and Namespace. I have added server identifiers in
parenthesis to try and make this all a little less confusing.
- Disabled connections settings in DFS Management snap-in
- Deleted Member and selected the option to Delete the member from DFS and
remove it as a target in the namespace. After removal I watched for the
correct eventlog messages to come through regarding the removal of the server
from DFS replication and namespace. Once those event logs appeared I
rebooted the server(0101). I also rebooted my namespace server(0125)
Several days later I was in the process of following my checklist to
decommision the server(0101) and went to verify that the shares on the
server(0101) were all removed to insure that no one in the company was
writing data to it since it was not longer replicating ot the other partners.
That's when I found that I could still address the share. I then
uninstalled DFS R2 from the server(0101) and rebooted again. During the
reboot I disconnected the Disk Array that housed the data. When the
server(0101) came back up I was still able to map to that share and access
data. At that point I shut down the server(0101) to try and determine if the
share was coming from something locally I missed or possibly the namespace.
While the server(0101) was off I again attempted to map to that share and it
again came up and I was able to access data. The only possible explanation I
could find for this was that the share has somehow survived as a target in my
namespace. The namespace that this server(0101) was a target in is still
available with other servers acting as targets.
I have looked in the registry on the server(0101) and do not see anything
related to the share.
In desparation I have also tried the Modlink.exe code that was posted on the
DFS TEchblog. That didn't remove the share either.
I'm not sure where else to look.
"Ned Pyle [MSFT]" wrote:
On Thursday, March 08, 2007 7:35 PM
Ned Pyle [MSFT] wrote:
Okedoke, I think I have better handle on this now.
Okedoke, I think I have better handle on this now. A couple more pieces of
legwork to request:
On 0101, in registry under:
HKey_Local_Machine\software\microsoft\dfs\standalone
... you see no entries, correct?
Also, if you run "DFSUTIL /root:\\susd4sw20101\libae /view /verbose >>
somefile.txt" and post the results here, that would be useful. It seems like
either we still have information cached on the clients and the server, or
possibly there's an interlinked DFS configuration here that still gets us
back to this machine.
If you see entries in that registry key, stop the DFS service on that
machine, export the entries, then delete them from the registry, and start
the service.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:4CBC99DC-B0E8-410F-A690-***@microsoft.com...
On Friday, March 09, 2007 10:27 AM
StuJackso wrote:
You are correct that there is nothing in the registry at that location.
You are correct that there is nothing in the registry at that location.
I created the verbose listing as you requested but it is too long to post
here. Can I send it to you offline for you to take a look at?
On Friday, March 09, 2007 10:50 AM
Ned Pyle [MSFT] wrote:
Re: Remove DFS replication member & namespace target problem
Sure thing. Use ***@microsoft.com (remove the REMOVE)
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:713BDD17-A4A4-4966-AD9E-***@microsoft.com...
On Friday, March 09, 2007 3:00 PM
Ned Pyle [MSFT] wrote:
Well.... hmmm.
Well.... hmmm. This data indicates that susd4sw20101 definitely does *not*
think it's a namespace (root) target for the domain namespace \\SUSD4\Libmae
.. It believes that:
Root Name="\\SUSD4\LibAE" State="1" Timeout="300"
Target Server="SUSD4SW20125" Folder="LibAE" State="2" [Site: Denver]
.... aka SUSD4SW20125 is still a namespace (root) target, and that the
namespace still exists. It sounds like 20101 was once a standalone DFS root
for interlinking to your domain-based namespace. With the registry cleaned
and the service (and server) restarted, there's simply no way that that
server's standalone namespace should still be working.
Is 20125 also supposed to be up and hosting this whole namespace still?
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Ned Pyle [MSFT]" <***@online.microsoft.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
On Friday, March 09, 2007 3:08 PM
StuJackso wrote:
Yes, the namespace that 20101 was part of is still active and being hosted by
Yes, the namespace that 20101 was part of is still active and being hosted by
20125.
"Ned Pyle [MSFT]" wrote:
On Friday, March 09, 2007 3:43 PM
Ned Pyle [MSFT] wrote:
Ok. So is there a problem here?
Ok. So is there a problem here? :-)
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:894EAC55-756C-488E-A284-***@microsoft.com...
On Friday, March 09, 2007 4:25 PM
StuJackso wrote:
Just the one where that 20101 share still survives and I don't want any chance
Just the one where that 20101 share still survives and I don't want any
chance of people accessing it!!
I'm just trying to eliminate that chance of users doing something that might
cause them confusion. Oh wait, is that possible?
"Ned Pyle [MSFT]" wrote:
On Friday, March 09, 2007 6:15 PM
Ned Pyle [MSFT] wrote:
Oh my gosh - is what your concerned about that the share actually still exists
Oh my gosh - is what your concerned about that the share actually still
exists on the server and can't be deleted? Dang, yeah Stu, we can do that.
To do this, find the folder in question on 0101. You can then run FSUTIL
(included with 2003):
FSUTIL reparsepoint delete %path%
Usage : fsutil reparsepoint delete <path to a folder>
ex : fsutil reparsepoint delete C:\ServerShare1
After this completes you will be able to delete the actual directories.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:76630500-A66F-4691-9ACE-***@microsoft.com...
On Monday, March 12, 2007 2:52 PM
StuJackso wrote:
Alas, that didn't work either.
Alas, that didn't work either. FSUTIL doesn't see any reparse point at the
location where the share used to exist.
I've decided the Namespace gods hate me and are torturing us so that they
can all have a good laugh. I'm heading to the bar to a meeting of the local
network admin support group and intend on making sure my sorrows are complete
drown.
Let me know if you have any other suggestions. I'm about ready to resign
myself to the fact that this share will always be a part of the namespace
whether the server actually exists or not.
stu
"Ned Pyle [MSFT]" wrote:
On Monday, March 12, 2007 5:47 PM
Ned Pyle [MSFT] wrote:
Are there any folders under your root namespace share/ the reparse point
Are there any folders under your root namespace share/ the reparse point
should be in there... somewhere.
LOL@ the namespace gods. :-)
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
"Stu Jackson" <***@discussions.microsoft.com> wrote in message news:DEA44DAC-A1CD-47E8-9255-***@microsoft.com...
Submitted via EggHeadCafe - Software Developer Portal of Choice
Java link favorites
http://www.eggheadcafe.com/tutorials/aspnet/54fe40d3-e474-44ef-b0db-5368e3f8f689/java-link-favorites.aspx