DFS: Properties cannot be set on the namespace server - Access is denied

I ran across a strange problem the other day with DFS. I needed to override the referral ordering for a namespace server, but the change wouldn’t take. I got a status of Error during the Commit changes task. In the detail, it showed Properties cannot be set on the namespace server \\SERVER.domain.local\Share. Access is denied.

This error must be uncommon, because all of the search results are for a similar but differently worded error about changing the properties of a folder and that issue’s resolutions don’t apply here.

I finally figured out the problem, and thought I’d share!

The Root of the Problem

If you looked at the other search results and forum postings and Microsoft KB articles, you probably went around and checked permissions on the target folders. If you’re here by now, then you know that it wasn’t the problem.

Actually, this issue doesn’t live on any of the individual namespace servers. Instead it’s a permissions problem in the Active Directory objects used to store information about the DFS shares. The computer object for each namespace server in a namespace will have some permissions granted on that namespace’s object in AD.

In my case, one of the computers was missing (I suspect that this was a side-effect of a swing migration, as the missing computer was a secondary domain controller that was demoted and then re-promoted after the migration, but that’s another story).

It’s worth noting that this prevented me from changing the referral ordering of another namespace server as well, so even if the ACL looks to be in order for the one you’re trying to change, it’s important to check the ACLs for every namespace server.

The Easy Fix?

You could blow away the whole DFS share and start fresh. That should fix the problem. Of course, if you run into errors deleting it, you might have to forcefully delete it, then use dfsutil.exe to clean up the left over registry entries.

Plus, in my case at least, the DFS share worked just fine. I really didn’t want to bring the share down, or worry about cleaning up leftovers.

The Easy Enough Fix

Since the problem lives in Active Directory, you’ll be making changes to AD itself. We’ll be using ADSI Edit, so hop onto a Domain Controller or a machine with the ADSI Edit RSAT. There’s no need to make this change from a namespace server on the DFS share.

You should also have a complete list of the namespace servers for the share.

Use ADSI Edit to view the DFS configuration

1. In ADSI Edit, connect to Default naming context.

2. Browse to DC=ABCD,DC=local > CN=System > CN=Dfs-Configuration

3. Here, you’ll see a list of your DFS shares: CN=ShareName
   
   

4. Open the Properties of the affected share. In the first tab (Attribute Editor), look for the remoteServerName field.
   
   
   
   This contains the list of all the namespace servers that AD has listed. Make sure this matches what is shown in the DFS management console. If it doesn’t, you might have bigger problems, and you may need to resort to the “easy” fix.

5. Now you can switch over to the Security tab. Click the Advanced button so that you see all the entries and the special permissions.
   
   
   
   Looking at the entries for the computer objects (the ones with the $ at the end), we can see that they all have the Read/write all properties access. In this example, you’ll also see a missing object, listed as Account Unknown(S-ID-xxx) with the same access as the other computers, so it’s a good bet that this is the missing one.

Please note that I took these screenshots after I fixed the issue. In the above, STORAGE01$ is not missing, but in the subsequent screens, I use it as the example machine I am adding. I hope it’s not confusing!

Find the missing namespace server and add it back

1. In the Advanced Security dialog above, click the Add button.

2. In the Select… dialog, click Object Types… and make sure that Computers is selected. Click OK.

3. Now choose the computer that was missing from the list, and click OK.
   
   \

4. Next, you want to give the computer object the  Read all properties and Write all properties Permissions. You can leave the Properties alone or clear them all in advance, as I did. By default, other Permissions may be granted, but only the two listed should be kept.

   Server 2012 Dialog:
   

   Server 2008 R2 (and earlier) Dialog:
   

Wait, Then Test

Once the changes are made, wait until they have had time to replicate to all DCs. It can be difficult to tell which DC you’re hitting when you try to make administrative changes with DFS, so best to wait until all of them have the same information. You could force replication if you prefer.

When you’re sure it’s all synchronized, test it out. I didn’t run into any issues after this.

Unsolved Mysteries

I still don’t know exactly how that computer went missing. As I said, there was some turmoil due to a previous swing migration, but the share was working fine. Stranger still, other DFS shares had the same namespace server missing in the ACLs, yet they had no problem making changes to their properties (like the referral ordering). Seems like they should be broken.

Please let me know if you had success (or not) with this procedure!