DFS Namespace sometimes takes time to register a new root target successfully

Question

I have a domain-based DFS Namespace with 3 root targets. They're all configured identically but exist in different Active Directory sites.

My company has a requirement to replace these servers regularly, so I've written automation that will launch a new Namespace server, and on startup it runs a powershell script which adds this server as a new root target to the same Namespace.

This all works correctly - it joins the Namespace as a new root target, and starts accepting client queries. DFS then works fine for a month until I then replace the servers. I replace them one-at-a-time, so that when a new replacement spins up, it connects to the domain controller and the other 2 DFS root targets to receive its configuration. Whilst I am in the middle of deploying my new Namespace servers, the script automatically sets the ones they are replacing as "Offline" in the DFS config, and a week later, all the "Offline" ones are then removed as root targets from the DFS config, which keeps the Namespace config tidy and only containing valid, Online root targets.

The issue I am having is that, with some servers, I get the error "SYSTEM ERROR - The object identifier does not represent a valid object." when I run the command to add this server as a root target using the command:

dfsutil target add "\\hostname.mydomain.com\my_namespace"

My script retries every 30 seconds until it is successful. And it is always eventually successful. But, sometimes it succeeds instantly (no retries), and sometimes it succeeds only after a number of minutes (the most I've recorded so far is 22 minutes of retrying before it succeeds). As an example, in a deployment of 3 servers I may see: 1) instant success, 2) success after 18 minutes, 3) success after 4.5 minutes.

Before I run the "dfsutil target add" command, I do two things:

1. verify that the domain controller hosting the PDCe role is responding and accessible from this server
2. run the command 'dfsutil root "\\hostname.mydomain.com\my_namespace"' to validate that the Namespace is accessible and responding

and these are always successful.

I've done web searches and can't find anyone else getting the error "SYSTEM ERROR - The object identifier does not represent a valid object." in relation to DFS Namespace.

I think the object it is referring to is the computer record or the DNS record maybe of the new Namespace server? I'm trying to add a new root target but maybe dfsutil doesn't recognise the target as being valid because it's trying to look it up somewhere but failing? Then it retries a number of times, and after a while it does look it up successfully.

These are Windows 2019 Namespace servers. The domain controllers are set to use "notify" so that any changes are replicated instantly to the other domain controllers - so I am assuming, since this Namespace server joined the domain 10 minutes prior, the computer record and DNS record should already have replicated to the PDCe (dfsutil always acts against the PDCe according to the documentation). The domain controllers are also the DNS servers, and it is Active Directory-Integrated DNS. My script runs maybe 3 minutes or so after domain-join, and 2 of my new servers will likely do the domain-join against the domain controllers which are not the PDCe (i.e. I imagine they will register against the domain controller in the same AD site).

My script runs under an account from domain A, and the Namespace servers are joined to domain B, where there is a one-way trust from B to A. Port 389 is disallowed traffic outbound on my Namespace server towards domain A, so I see blocked network traffic on 389 to domain A...but since the root target add sometimes works instantly and always succeeds eventually, I don't think that would be a cause of the delay (otherwise it would always fail). Port 389 outbound is allowed towards domain B, and I see network traffic flowing to and from the domain controllers successfully in domain B. The only network traffic that gets rejected is some (but not all) outbound on 139, 389, 445 - the vast majority is 389 to domain A, and no traffic is rejected to the other Namespace servers or the domain B domain controllers. I mention it in case it is relevant.

Finally: I also have a non-production environment which joins to the same domain, and uses the same machine image to launch the Namespace servers from, where the only difference is that there are no network restrictions for inbound or outbound network traffic for my Namespace servers...and they all succeed instantly in adding themselves as root targets. I can't reproduce the error there as they all always succeed first time. I can replace all my Namespace servers here 6 times in a single day and every single one of them successfully adds as a target on the first attempt. This implies it's maybe a connectivity issue...but the fact that the "target add" process always ends up eventually succeeding means that if it is caused by a critical network call on some port to some destination, it does get through at some point.

The question I have is: what actually is causing the "SYSTEM ERROR - The object identifier does not represent a valid object." error, and what do I need to investigate in order to fix it?

Thanks.

Answer 1

Hello there,

This error message might be due to multiple reason and might be difficult to find the exact reason without checking your automation script

If you see the DFS root that you are trying to create under Dfs-Configuration, delete it and replicate your domain controllers. Close ADSIEdit.

Now, add the DFS Root using the DFS Management utility. When you point it at your DFS root share, it will say "the folder already exists, do you want to keep the existing permissions?" Go ahead and keep the permissions of the existing folder.

After the DFS creation wizard has finished, you should see a healthy DFS root. Now you can use DFSUtil to import merge the DFS xml file that you exported earlier. Don't forget to manually add your other DFS namespace servers. Again, you'll get the same message about the DFS root folder already existing for each server you add..

Hope this resolves your Query !!

--If the reply is helpful, please Upvote and Accept it as an answer--