2012 server - orphaned DFS share can't be deleted

I need to manually delete, remove, clean up an orphaned DFS name.

I have a folder shared as \\server\data
At one time, it was also a DFS share called \\mydomain.com\data

I cannot delete/remove the share name.  I get:

“An error occurred while trying to delete the share %sharename%. The share must be removed from the Distributed File System before it can be deleted.”

The problem is - it *doesn't* exist in DFS.  
I've checked ADSIEDIT, as mentioned in countless articles.  The namespace DOES NOT EXIST in this location.

I can remove it from "display" in DFS Management, but if I go to add a namespace to display, it shows me "\\mydomain.com\data" as a valid name to add.

I can't re-add the namespace because it says it already exists.  I can't delete it because it says it doesn't exist!!

HELP!
snowdog_2112Asked:
Who is Participating?
 
snowdog_2112Connect With a Mentor Author Commented:
Abandoning this - no solutions found.

I've created a new folder and new share and migrated all mappings to the new share.

The orphaned DFS sapce will forever remain in this network apparently.
0
 
becraigCommented:
Have you tried checking the registry to see if the namespace is persisting there :
http://cscmblog.blogspot.com/2012/06/distributed-file-system-error-share.html



This might be your issue since you indicate you cannot find the namespace in AD

Please check the registry value at:
HKLM\Software\Microsoft\Dfs\Roots\Domain
0
 
MaheshArchitectCommented:
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
snowdog_2112Author Commented:
I see an entry in the registry - waiting for after-hours window to attempt whacking it.

Will report back.  Thanks.
0
 
becraigCommented:
Did you have any luck with this ?
0
 
snowdog_2112Author Commented:
No luck.  The registry setting was there, and we removed it, rebooted and still can't delete the share tied to the phantom DFS namespace.

Still, if a user saves to a *SUB-FOLDER* of the drive letter mapped to the \\SERVER\share (note: not the DFS sharename \\domain\share), the file is saved to the root of the drive letter with now indication to the user - no error, no warning.  Even more strange...only Office applications exhibit this behavior, not something like Notepad.

Any other thoughts?

Meantime, I've created a new share to the same folder and have users mapped to the new share name via GPO.  File saving to the new share name via mapped drive letter works as expected.
0
 
MaheshArchitectCommented:
Are you able to view DFS object under \\domain.com\system\dfs-global-configuration folder or any other DFS folders under system container ?
If you found one just delete it
Also try to find share under below registry key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares]
If  Under shares you find share pointing to your DFS root share, just delete that one.
Now restart server service on server and force AD replication

Now try to create DFS name space again
 
Mahesh
0
 
snowdog_2112Author Commented:
I will give that a try at the next maintenance window opportunity and report back.
0
 
snowdog_2112Author Commented:
I've deleted the registry key and every place I can find the name, but it still will not let me remove the share name due to a non-existent DFS name.

Are there any other options I have?  Spin up a new DC, attach the disk from this busted DC and create the shares on a new DC?  At the same time, create a "dummy" disk for the busted DC with the same folder?
0
 
snowdog_2112Author Commented:
No solution - had to workaround/replace the share name.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.