Is It Possible to Add a Fileserver to a DFS Replication Group Without Connectivity to FSMO Roles Holder DC But Connectivity to Site DC???

Question

I apologize in advance for the rambling novella, but I tried to include as many details ahead of time as I could.
I guess like most issues, this one's been evolving for a while, it started out with us trying to add a new member 
to a replication group that's on a subnet without connectivity to the FSMO roles holder. I'll try to describe the 
layout as best as I can up front.
The AD only has one domain & both the forest & domain are at 2008R2 function level. We've got two sites defined in 
Sites & Services, Site A is an off-site datacenter with one associated subnet & Site B with 6 associated subnets, A-F. 
The two sites are connected by a WAN link from a cable provider. Subnets E & F at Site B have no connectivity to Site A 
across that WAN, only what's available through the front side of the datacenter through the public Internet. The network 
engineering group involved refuses to route that WAN traffic to those two subnets & we've got no recourse against that 
decision; so I'm trying to find a way to accomplish this without that if possible.
The FSMO roles holder is located at Site A. I know that I can define a Site C, add Subnets E & F to that site, & then 
configure an SMTP site link between Sites A & C, but that only handles AD replication, correct? That still wouldn't allow me, for example, 
to enumerate DFS namespaces from subnets E & F, or to add a fileserver on either of those subnets as a member to an existing
DFS replication group, right? Also, root scalability is enabled on all the namespace shares.
Is there a way to accomplish both of these things without transferring the FSMO roles from the original DC at Site A to, say, 
the bridgehead DC at Site B? 
When the infrastructure was originally setup by a former analyst, the topology was much more simple & everything was left
under the Default First Site & no sites/subnets were setup until fairly recently to resolve authentication issues on 
Subnets E & F... I bring this up just to say, the FSMO roles holder has held them throughout the build out & addition of 
all sorts of systems & I'm honestly not sure what, if anything, the transfer of those roles will break. 
I definitely don't claim to be an expert in any of this, I'll be the first to say that I'm a work-in-progress on this AD design stuff, 
I'm all for R'ing the FM, but frankly I'm dragging bottom at this point in finding the right FM. I've been digging around
on Google, forums, & TechNet for the past week or so as this has evolved, but no resolution yet. 
On VMs & machines on subnets E & F when I go to DFS Management -> Namespace -> Add Namespaces to Display..., none show up 
automatically & when I click Show Namespaces, after a few seconds I get "The namespaces on DOMAIN cannot be enumerated. The 
specified domain either does not exist or could not be contacted". If I run a dfsutil /pktinfo, nothing shows except \sysvol 
but I can access the domain-based DFS shares through Windows Explorer with the UNC path \\DOMAIN-FQDN\Share-Name then when 
I run a dfsutil /pktinfo it shows all the shares that I've accessed so far.
So either I'm doing something wrong, or, for some random large, multinational company, every sunbet & fileserver one wants 
to add to a DFS Namespace has to be able to contact the FSMO roles holder? Or, are those ADs broken down with a child domain 
for each Site & a FSMO roles holder for that child domain is located in each site?

Answer 1

Hi,
A DC in siteB should helpful. I still not see any article mentioned that a DFS client have to connect to PDC every time trying to access a DFS domain based namespace.
Please see following article. I pasted a part of it below:
http://technet.microsoft.com/en-us/library/cc782417(v=ws.10).aspx
Domain controllers play numerous roles in DFS:
Domain controllers store DFS metadata in Active Directory about domain-based namespaces. DFS metadata consists of information about entire namespace, including the root, root targets, links, link targets, and settings. By default,root servers
that host domain-based namespaces periodically poll the domain controller acting as the primary domain controller (PDC) emulator master to obtain an updated version of the DFS metadata and store this metadata in memory.
So Other DC needs to connect PDC for an updated metadata.
Whenever an administrator makes a change to a domain-based namespace, the
change is made on the domain controller acting as the PDC emulator master and is then replicated (via Active Directory replication) to other domain controllers in the domain.
Domain Name Referral Cache
A domain name referral contains the NetBIOS and DNS names of the local domain, all trusted domains in the forest, and domains in trusted forests. A
DFS client requests a domain name referral from a domain controller to determine the domains in which the clients can access domain-based namespaces.
Domain Controller Referral Cache
A domain controller referral contains the NetBIOS and DNS names of the domain controllers for the list of domains it has cached. A DFS client requests a domain controller referral from a domain controller (in the client’s domain)
to determine which domain controllers can provide a referral for a domain-based namespace.
Domain-based Root Referral Cache
The domain-based root referrals in this memory cache do not store targets in any particular order. The targets are sorted according to the target selection method only when requested from the client. Also, these referrals are based on DFS metadata stored
on the local domain controller, not the PDC emulator master.
Thus it seems to be acceptable to have a disconnect between sites shortly when cache is still working on siteB.
If you have any feedback on our support, please send to [email protected].