Is it Possible to Promote DC on a Subnet With Connectivity to a Site DC But Not DC with FSMO Roles???

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 Matthew,
Unfortunately a lot of the intricacies of DFS leave my head as soon as I’m done with a particular design or troubleshooting situation but from memory, having direct connectivity to the PDC emulator for a particular domain is the key to managing domain based
DFS.
Have a read of this article for the differences between “Optimize for consistency” vs “Optimize for scalability”:
http://technet.microsoft.com/en-us/library/cc737400(v=ws.10).aspx
In brief, I’d say they mean:
In consistency mode the namespace servers always poll the PDCe for the latest and greatest information on the namespaces they are hosting.
In scalability mode the namespace servers should poll the closest DC for information on the namespaces they are hosting.
The key piece of information in that article about scalability mode is: “Updates are still made to the namespace object in Active Directory on the PDC emulator, but namespace servers do not discover those changes until the updated namespace object replicates
(using Active Directory replication) to the closest domain controller for each namespace server.”
I read that as saying you can have a server running DFS-N as long as it has connectivity to a DC but if you want to make changes, do them from a box that has direct connectivity to the PDCe. Then let AD replication float those changes out to your other DCs
where the remote DFS-N server will eventually pick them up. Give it a try and see how you get on.
That being said, you may want to double check that you have configured the most appropriate FSMO role placement in your environment's AD design:
http://technet.microsoft.com/en-us/library/cc754889(v=ws.10).aspx
And a DFS response probably wouldn’t be complete without an AskDS link:
http://blogs.technet.com/b/askds/archive/2012/07/24/common-dfsn-configuration-mistakes-and-oversights.aspx
These links may also help:
http://blogs.technet.com/b/filecab/archive/2012/08/26/dfs-namespace-scalability-considerations.aspx
http://blogs.technet.com/b/josebda/archive/2009/12/30/windows-server-dfs-namespaces-reference.aspx
http://blogs.technet.com/b/josebda/archive/2009/06/26/how-many-dfs-n-namespaces-servers-do-you-need.aspx
I hope this helps,
Mark