Quantcast
Channel: File Services and Storage forum
Viewing all articles
Browse latest Browse all 16038

Removing domain DFS namespaces from AD following upgrade from Windows 2000 Server to Windows Server 2008 R2

$
0
0

Hi,

Following the introduction of a number of new Windows Server 2008 R2 domain controllers during a functional level increase (from 2000 to 2003) we have demoted all of our Windows 2000 Servers to become member servers of the domain. They are mostly still present, but the plan was to migrate off any remaining information before decommissioning them permanently. The domain has been functioning as part of a Windows Server 2003 forest and domain functional level hierarchy without any obvious issues following this work, however we have just run into a problem with introducing Windows Server 2008 R2 DCs into the existing Windows 2000 DFS root. Whenever we attempt to add a server as an additional namespace the DFS Management tool in 2008 just hangs whenever trying to enumerate the existing DFS root folder or namespaces. In fact I left this running overnight and the user interface did not return back with any useable information. In contrast however the previous domain controllers which were demoted (and metadata cleanup carried out) still can be used to interrogate the original DFS root with their Windows 2000 Server Distributed File System plugin, and to this end we started to remove namespaces from the existing root in order to attempt to clean out the old servers. In all but one case the process of removal of a DFS namespace hung indefinitely, but querying the namespaces from another (ex-DC) machine showed that the namespaces were being removed anyhow. After continuing to remove the old servers we now have a situation where we now have no listed namespaces visible within the old Windows 2000 based DFS management tool, but we cannot add/query/delete this DFS root from Windows Server 2008 R2 domain controllers. We would like to completely decommission this DFS and recreate it using the previous naming convention e.g. \\domain.rootdomain\DFSdata.

NB after I had removed all of the previous namespaces using the Windows 2000 DFS tool I followed the advice of http://support.microsoft.com/kb/969382 to delete the previous fTDfs object from AD under the System, DFS-Configuration - this finally removed the entry from the Windows 2000 servers. We have then been systematically going through the legacy (ex-DCs) to removed any DFS shares and registry entries as per the article for fault tolerant roots here http://support.microsoft.com/?id=224384.

Where we are now, is that following a night's worth of replication of the deleted fTDfs object we still cannot use any of the Windows Server 2008 R2 domain controllers to query or delete the old name space using DFS Management. Even commands such as

dfsutil /root:\\domainname.rootdomain\dfsdata /export:C:\DATA-dfs-Root.txt

seem to hang indefinitely and I cannot use any of the other commands such as

Dfsutil root remove \\domain\namespace

to attempt to remove the namespaces as they also hang without output.

An inspection of the domain in AD Users & Computers with Advanced mode turned on shows that we have a folder tree called 'DFSData' containing replication objects relating to the old decommissioned domain controllers in the following location:

System, File Replication Service, DFS Volumes - which shows a GUID for each of the replication partners and then the other parties to which it replicates.

Is this information within AD messing around with the Windows Server 2008 R2 version of DFS Management? Can it safely be deleted if these servers are no longer domain controllers / DFS namespace holders?

We are loathed to leave any extinct information in place because ideally we would like to recreate the namespace using the same name so that some of our software delivery packages will work without modification.

Can anyone please provide assistance to point us in the right direction, we have done as much research as possible - but this needs a pointer from Microsoft or someone who has experienced the same problem to prevent us from going too far down the wrong route.

Many thanks -


Viewing all articles
Browse latest Browse all 16038

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>