Distributed Management of Multiple DFS roots

Hello all

Background:
In my organization we have many sites spread throughout the world. A
significant portion of these sites has their own IT staff and they manage
services that are specific to their site. Each site is a member of the same
AD domain but is given it's own OU within that domain to contain it's
objects, permissions are set on this OU so that the site's IT department can
manage their own objects. Each site has it's own DFS root within the domain
(i.e. if our domain name is ExampleDomain and we have two sites ExampleSite1
and ExampleSite2, our DFS roots would be as follows
\\ExampleDomain\ExampleSite1\ and \\ExampleDomain\ExampleSite2\. we create
links in these locations to point to the file shares hosted at each site.)

Issue:
We have begun utilizing DFS shares more heavily recently and would like to
allow each site's IT department to manage their own DFS root. Our senior AD
administrator is under the impression that this must be done by a domain
admin but with as granular as AD allows you to be, it seems that this should
not be the case.

Please reply and let me know if I need to clarify anything further or if you
have encountered similar issues. Any and all links and comments will be
appreciated.

Thank you!

I suspect your AD admin remembers how it used to work.

Namespace administration can be delegated. This is a change as of Windows
2003 SP1 and requires the DFSMGMT.MSC management console, first available in
Windows 2003 R2, for ease of access. In that console, you should see a
"Delegate Management Permissions" as you navigate to a given namespace.

However, if you are comfortable in ADSIEDIT, you can modify the permissions
on the metadata directly and it will have effect.

"BrianB" wrote:
> Issue:
> We have begun utilizing DFS shares more heavily recently and would like to
> allow each site's IT department to manage their own DFS root. Our senior AD
> administrator is under the impression that this must be done by a domain
> admin but with as granular as AD allows you to be, it seems that this should
> not be the case.