DFS namespace empty after reboot

One of our sites had the following issue. It has a Server 2008 R2 DC which was also hosts DFS and whenever the server is rebooted, sometimes the DFS namespace appears empty until the DFS Namespace service is restarted.

I tracked it down to a timing issue.

The DFS namespace was a domain based one. Which means even though the server hosts the namespace root, it doesn’t have any information on the root until AD is up and running. This is because domain based DFS information is stored in AD (unlike stand-alone DFS where the information is stored in the server registry) and so the DFS Namespace service looks to AD for details. Had the DFS server been a separate one it would have contacted the local DC and got this, but in this case the DC and DFS Namespace are on the same server and so it all came down to which service was up first. If AD initialized before DFS, when the Namespace service runs it is able to contact AD and get the info. But if the Namespace initializes before AD, when it contacts AD for info it gets nothing and so assumes there’s no namespaces present. The result is an empty namespace, and the c:\DFSRoots folder (or whatever you have chosen) is empty. If you restart the DFS Namespace service a while later, it is able to contact AD and present the namespace.

The easiest way to see if AD is initialized is via Event Viewer. Go to Custom Views > Server Roles > Active Directory Domain Service. When AD is ready an event ID 1000 is generated from source ActiveDirectory_DomainService that tells you AD startup is complete.

AD initialized

Similarly, to check when DFS initialized go to the Event View, Windows Logs > System. Check for events from source DfsSvc – when DFS has completed initializing an event with ID 14531 is generated.

DFS initialized
When the namespace is empty you’ll see that the time-stamp of the DFS event is before the AD event. In my testing as long as DFS initializes a second before AD is ready the namespaces are fine, but anything longer than that and the namespaces are empty.

There doesn’t seem to be any other fix for this than delay the startup of the DFS Namespace service. Again, only the DFS Namespace service is what matters. Not the DFS Replication service. There are two parts to DFS – one if the namespace, which provides the unified namespace and folders beneath that; other is the replication bit which ensures that if a target points to multiple servers each of these servers are kept in sync. You don’t necessarily have to use the DFS Replication service to keep these replicated – use whatever tool you prefer, DFS Replication is what’s provided in the box for you. If your namespace is missing the DFS Replication service has nothing to do with it. (On the other hand, if your namespace was fine but some of the targets had incorrect data then DFS Replication is what you should focus troubleshooting on).

What I did in this case was set the startup type of DFS Namespace to “Automatic (Delayed Start)”. In my testing, on this particular server, this delayed the startup of the DFS Namespace service by about 3 minutes. AD initializes in about 50-90 seconds so there’s ample time after AD is ready and for other services to launch, before DFS Namespace runs. There is no impact for users too as there are multiple namespace servers – all of them being in different sites in this situation – and so if users were to connect to DFS in the 3 minute period after a server reboot they would connect to one of these different namespace servers. Yes, there will be a bit of a delay as they are connecting to an off-site server, but when they access any target after that they will be sent back to the local site (provided there are target servers there) and so there’s no performance impact.

If the 3 minute window too is unacceptable I suppose one could set the DFS Namespace service to manual start and use the Task Scheduler to start it manually after a few seconds after reboot.

Hope this helps anyone else.