In case you find this blog and have read through...

Discussion in 'File Systems' started by Rob Ness, Jan 27, 2010.

  1. Rob Ness

    Rob Ness Guest

    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.



    Previous Posts In This Thread:

    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.

    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.



    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.

    :

    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.



    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.


    :

    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.



    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?

    Re: Remove DFS replication member & namespace target problem
    Sure thing. Use (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.



    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.



    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.

    :

    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.



    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?

    :

    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.



    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




    :

    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.




    Submitted via EggHeadCafe - Software Developer Portal of Choice
    Java link favorites
    http://www.eggheadcafe.com/tutorial...ef-b0db-5368e3f8f689/java-link-favorites.aspx
     
    Rob Ness, Jan 27, 2010
    #1
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.