Excellent article on this!
Source link
"
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, the issue here 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
Look ma!
No downtime! 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
- In ADSI Edit, connect to Default naming context.
- Browse to DC=ABCD,DC=local > CN=System > CN=Dfs‑Configuration
- Here, you’ll see a list of your DFS shares: CN=ShareName
- 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.
- 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(SID)” 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
- In the Advanced Security dialog above, click the Add button.
- In the “Select…” dialog, click “Object Types…” and make sure that Computers is selected. Click OK.
- Now choose the computer that was missing from the list, and click OK.
- 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.
"
