Multi-site and AD Sites

The lab grew from one location into the real Bingham footprint: eight towns, each an Active Directory Site. This is not cosmetic. Sites are how AD localizes clients to nearby domain controllers and how it schedules replication, so modeling them makes the RODC behave the way a real branch DC does.

What an AD Site actually buys you

A Site is a named collection of IP Subnets. When a client authenticates, AD maps its source IP to a subnet, the subnet to a site, and hands the client the DC-locator records for that site. So a workstation in Pocatello prefers the Pocatello DC, not one across the state. The lab encodes this directly: eight sites, one /24 subnet each, listed in the sites reference.

This is also why the RODC story gets richer. rodc1 now lives in the Pocatello site, so a Pocatello client uses it for reads and chains to the writable dc1 in Blackfoot-HQ only for writes and uncached credentials. That read-local, write-referred behaviour is exactly what a branch RODC is for, and now the site topology makes it realistic instead of incidental.

The safe way to create the primary site

There was a sharp edge in setting this up. The goal was to put dc1 in a Blackfoot-HQ site, but dc1 is the only writable DC and it is live. Moving a running DC’s server object between sites is the kind of operation that can disturb replication metadata.

The safer move is a rename. The domain ships with one site, Default-First-Site-Name, and dc1 already lives in it. Renaming that site to Blackfoot-HQ relocates the whole subtree (the server object and its NTDS settings) in one atomic operation, so dc1’s position relative to its parent never changes. Only rodc1, the lower-stakes branch DC, is actually moved into its new site.

flowchart TB
  subgraph before["Before"]
    d0["Default-First-Site-Name<br/>(dc1 + rodc1)"]
  end
  subgraph after["After"]
    bh["Blackfoot-HQ<br/>(dc1)"]
    po["Pocatello<br/>(rodc1)"]
  end
  d0 ==>|"RENAME site<br/>(dc1 rides along, untouched)"| bh
  d0 -->|"MOVE rodc1 server object<br/>(branch DC, low stakes)"| po

The lab backs up the domain first regardless, because the change touches the configuration partition.

Geography in two partitions

The towns appear in two different places, and it is worth keeping them straight:

• Sites and Subnets live in the configuration partition (CN=Sites, CN=Configuration,...). They drive DC-locator and replication.
• Facility OUs live in the domain partition (OU=Locations,...). They organize people and assets, and they are where the cast is seeded.

A real deployment has both: the network topology that AD uses internally, and the administrative OU structure that humans navigate. The lab models both so the two views line up with the same eight towns.

The payoff: policy scales with structure

Because access is gated by group nesting rather than per-share lists, growing to this scale cost almost nothing in policy. Fifty-seven specialties, sixteen departments, eight sites, and a few dozen new staff were added without editing a single share’s access rules. When gregory.house joined the new Nephrology group, he could reach patient records immediately, because the policy lives in the shape of the group tree, not in the shares. That is the whole design paying off at scale. See the HIPAA boundary.