Replication across a sit with a separate domain

creamy_stew

Let's say I have SiteA and Site B. The DCs in those sites belong to the same domain "AB".

Let's also say that the only way for those sites to communicate is through SiteC which only has DCs in domain "C".

Bookstudy gives that this should work (since site links are bridged by default). I just now realized I'm not at all sure HOW this works. Does the replication traffic now cross a DC in domain "C", which then forwards the traffic to domain "AB", or does the replication traffic somhow get directly from SiteA to SiteB? (DCx.domainAB <--> DCy.domainAB) using only IP.

If the first case is the correct one, would the domains have to be members of the same forest?

SiteA SiteC SiteB

---

---

---

DCx.domainAB

---

DCx.domainC

---

DCy.domainAB


I tried to be clear, but after previewing, I realize I might have failed

ltgenspecific

Just trying to understand what you're stating...

If the "only" way for them to communicate is through Site C then I believe, yes, necissarily the replication traffic will flow through a DC in Site C. However, this is a little ambiguous. Are you suggesting that DCx.domainAB and DCy.domainAB have an established cross-forest trust with DCx.DomainC? If so, it's an inefficient model in my newbie opinion. It's simpler (and I think automatic at first due to KCC) to have replication between x and y in domainAB and then include DCx.DomainC in some sort of (one-way, external, etc.) trust with DomainAB... but this will depend on what and why you need replicated to or through DCx.DomainC...

I hope that helps as a starting point but from what I am reading you are talking about a replication question between sites and the water is muddied with the domain/forest configuration. Is there a business-relevant context to this?

(take it with a grain of salt, I am an aspiring techie as much as the next guy... I'd love to hear that i read this totally wrong, always willing to learn something new)

Claymoore

All sites are subnets, but not all subnets are sites. In a fully routed topology, all DCs will be able to replicate without proper definition of sites - it just won't be optimal. Sites and site links don't have to match the network topology, but sites should at least have the proper subnets defined. I have seen large enterprises with multiple locations run with just the Default-First-Site-Name, which means we have to fix AD before we can deploy Exchange 2007 or 2010. Sometimes its surprising to see how well AD works despite what the admins have done (or in this case, not done) to it. Keep the concept of Site A separate from Subnet A and we'll see how things work in your example.

Let's start with Subnet C not being defined in AD as Site C. Because the network is fully routed, DC A and DC B can talk so they can replicate. Now a client from Domain AB sits down with his laptop in Site C and tries to log on. Because Site C isn't defined, the PC starts searching for any available domain controller and could connect to DC Z in Site Z on the other side of the world. Slow logon times and client complaints result.

Now you define Site C as containing Subnet C. Still no DC from Domain AB in the site, but now the PC knows where it is and will be redirected to a more optimal domain controller after it contacts the first DC. DC A and B can still talk so they can still replicate. What this does change is whether A and B will choose to replicate through C. With sites come site links which have a cost associated with them. Everyone is a member of the default site link which has a cost of 100, giving the A-C-B path a total cost of 200. If Site D has a is a member of a different site link with sites A&B and that site link costs 50, replication traffic will travel that path instead. Oh, the joys of waiting for Exchange AD attributes to replicate or schema extensions to spread throughout a network of multiple site links with different costs and replication schedules.

Add a DC from Domain C to Site C. Domain AB and Domain C are members of the same forest. Now all the DCs share some replicated information, such as schema updates or global catalog updates, but ignore the domain partition replication traffic for the other domain in which they are not a DC. This makes more sense if the site is a spoke instead of a hub, because the DC will only replicate its domain partition data.

Back in the early days of the design of Active Directory (or the theft of NDS if you want to be bitter), a T1 at the headquaters was a luxury and a 56k frame relay connection to a different office was screaming fast. Admins needed to tune replication traffic to protect the network. We can tune 'How' replication occurs with site links, 'When' replication occurs with replication schedules on those site links, and 'What' is replicated by separating domains and thus only replicate certain domain partitions. It was acceptable at one time to create separate domains just to segregate replication traffic. Now with faster networks and better understanding of the true costs of maintaining separate domains, the only good reason for having multiple domains in a forest is if those domains have a disjointed DNS namespace.

Got off track a bit there, but I hope I answered your question. If you really want to learn more about replication, check out this Technet article or pick up the Server 2008 AD Resource Kit. It has about 100 pages on replication so you can learn about the KCC, ISTG, timestamps, change DSNs and how a multi-master model keeps from tripping all over itself.