Clean-up of a Orphaned Active Directory Server 2003R2 Namespace

In my previous post [here] I documented how to enable Access Based Enumeration on a 2003R2 DFS AD Namespace.  Since then several times in testing and now once in production or NameSpace has become orphaned from its NameSpace Server Host and I have had search how to clean-up an orphaned DFS Namspace.

Incase it every happens again… and so that I don’t have to search the web and try to figure out which random terms I used in the Google search I am documenting the process to fix an Orphaned Namespace here… for your use as well as mine. 

Since historically just pasting the links ends up burning me… I have included the step by step procedure, that was of course copied from several websites (Note: I am not claiming, any responsibility for, or noting the existence of, original content).

Your Mileage may very and no implied guarantees that the following steps will solve your issue… But the following did fix my issue with an Orphaned Namespace.

These steps have worked to delete the orphaned namespace because of server failure or loss of DFSRoots directory
(or migrating from one SAN to another and thinking that DFS replication will replicate your DFSRoots to a new volume on the new SAN… which by the way DFS replication doesn’t replicate DFSRoots)

The domain-based DFS configuration is stored in the AD database as well as some settings on the DFS Namespace Host server, so every time you launch the DFS management console, it will try to retrieve the DFS information from AD.

There are two nodes in AD which store the information of the DFS Namespace:

Node1. Store the DFS Namespace information which shows under the Namespaces node in DFS management console. CN=DFS-Configuration, CN=System, DC=Domainname, DC=domainsuffix

Node2. Store the DFS Replication group information which shows under the Replication node in DFS management console. CN=DFSR-GlobalSettings, CN= System, DC=Domainname, DC=domainsuffix

ON a DC use ADSIedit.msc to delete the orphaned namespace information \\domain.tld\DFS_Namespace under the node CN=DFS-Configuration.

1. Launch ADSIedit.msc

2. Connect to "Default naming context" (the domain partition)

3. Expand and locate to the following node:
CN=Dfs-Configuration, CN=System, DC=ourdomain, DC=tld

4. Check if the orphaned namespace CN=DFS_Test is under it, if so, you may delete this node CN=DFS_Test

5. Afterwards, please run "repadmin /syncall" if there are multiple domain controllers in the environment

6. Then run "dfsrdiag pollad" on all the DFS member servers to manually make them sync the information from AD database.

Then, you may launch the DFS management console and then right-click on the orphaned namespace, and then select Remove Namespace from Display… if needed.

After these steps you can proceed to re-create your DFS Namespace. When creating the Namespace you may receive the error: “ The Server you specified already hosts a namespace with this name. Please Select Another Namespace or another server to host the namespace.”

If that occurs:

1. Stop the DFS service by tying net stop dfs at a command prompt.

2. Delete the following three registry keys/values:
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain\YourOldNamespace
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\YourOldNamespaceShare
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\YourOldNamespaceShare

3. Reboot the server and restart DFS Service.

4. If it still appears, delete the Namespace from the Display.

5. Proceed to recreate a Namespace.

ACS (ChMS) and PCO integration … Dead for now

As I have discussed in previous posts  [1] , [2] and [3] we would love for synchronization or sharing of data between our ChMS and Planning Center Online.  My recent push has been to get the sync to work for ACS and PCO, obviously because that would impact us most because we use ACS. 

In our conversations with PCO Owner Jeff Berg we found out that PCO had plans to synchronize with multiple ChMS products not just ACS, which was great.  In that conversation multiple staff from ACS talked thru how to make the APIs work and for PCO to integrate. It looked like we finally had progress to an integrated solution not just for ACS but all Church Management systems.

Then turn the page a couple months later, and this week I was disappointed to receive the email below, which I totally can understand but disappointed none the less.

Hey Jason,

I just wanted to let you know that we have decided to kill our "SharpSync" project for now. We have been working on it for over a year and just have not seen any fruit from it. The complexities of working with different schemas & APIs are too big of a hurdle for our small team to attack…

 

We have had a long discussion this morning about integration and the difficulties in what we were trying to accomplish. We have found this too large of a task for us to accomplish.  This is not just with ACS but with all of the other ChMSs we were talking to. We have spent over a year and a lot of cash doing this and just haven’t found a reliable way to integrate with all of the ChMS systems out there.  Every time we thought we were clear we would run into a hurdle with an API or data consistency issue.

We have discussed this with some other ChMSs and some have decided to integrate from their end…

I’m really sorry for this, I was very excited for this project but it just didn’t work.

Thanks!

Jeff

So if you who have asked about such a tool, I encourage you to contact your ChMS and see if there is a way to make this project work.  If you are an ACS customer contact Sally Grantham and let her know your needs and interests.

I will stay to the PCO crew, thanks for the effort, and I still hope that we can see this product work.