GPO, DHCP, and DFS: the unglamorous plumbing of AD consolidation

Last summer we published the design notes from a multi-forest Active Directory consolidation: one target forest, SID history, ADMT phases, the political fights about child domains. That was the architecture everyone wanted to talk about. This post is the work that actually ate the calendar once design was signed — GPO rationalization, DHCP failover migration, and DFS namespace redesign. The unglamorous plumbing between the org charts.

If you have ever finished an ADMT user wave and still watched helpdesk tickets spike for printers, drives, and "my desktop looks wrong," you already know: identity cutover without GPO and file namespace discipline is half a project.

The GPO estate nobody wanted to own

Discovery on the source forests turned up roughly nine hundred Group Policy Objects that had ever been linked, including orphans, "Test_v3_FINAL_use_this," and policies whose only purpose was a single registry preference someone set in 2009 and forgot. Linked-and-enforced count was lower — around two hundred forty — but still far past what anyone could reason about.

GPO cleanup consolidation is not a cleanup sprint. It is a reverse-engineering project with change control.

We started with inventory that tools alone do not give you:

Link map. Every GPO to every OU and site, with enforced and block inheritance flags. PowerShell against Get-GPO and Get-GPInheritance across domains, merged into one spreadsheet the agency security team could argue over.
Settings export. Get-GPOReport -ReportType Xml for every linked policy. Diffing XML is miserable; it is also the only way to find two policies that set the same IE zone and fight each other.
Security filtering and WMI filters. Half the "why does this PC get policy X" mysteries live here. We found WMI filters testing for Windows XP long after XP was gone from the estate.
Preference item-level targeting. Printers, drive maps, and shortcuts that only apply to certain groups — gold when intentional, landmines when the group was emptied two reorganizations ago.

The reduction target was not "delete everything." It was a rational set: baseline security (password, audit, firewall), baseline desktop (Office defaults, OneDrive if in use, browser), department overlays for the few that truly needed them, and temporary policies with expiry dates written into the description field. We landed near two hundred linked policies — not because two hundred is magic, but because that was the count we could name an owner for.

Order of operations mattered. We never deleted a GPO the week of a user migration wave. Instead: create target-forest baselines first, link them to the new OU structure, pilot with a ring of IT machines, then cut user OUs over and only then unlink source policies as those OUs emptied. SID history does not save you from a drive map that points at a server name that dies next month.

DHCP: failover that actually fails over

DHCP looks simple until you migrate it under production load. The source forests ran a mix of standalone DHCP servers, some split-scope "high availability" from the 2000s, and one pair already on Windows Server 2012 R2 failover. The target design was 2012 R2 failover relationships — hot standby for smaller sites, load balance for the two big campuses — with scopes rebuilt cleanly rather than exported and hoped.

What broke when people treat DHCP as a copy-paste:

Reservations and options. Vendor classes, PXE options for SCCM, custom options for VoIP phones. Miss one and a floor of polycoms reboots into misery.
Lease time and conflict detection. Shortening leases before cutover helps reclaim addresses; too short and you create renewal storms.
DNS dynamic update credentials. The account that registers PTR records is often wrong after a forest migration if nobody updates the credentials on the DHCP server properties.
Relay agents. Every subnet's helper-address still pointed at the old DHCP IPs. We maintained a dual-listen window where old and new servers both answered, then flipped helpers in controlled batches per building.

The cutover runbook for each site was deliberately boring: export scopes with Export-DhcpServer, import to the failover pair, validate a test client on a spare VLAN, schedule the helper-address change with network, watch lease assignment for an hour, decommission the old server only after a full lease-time cycle with no critical clients left. "We migrated DHCP last night" with no dual-run period is how you get a Monday where half the campus has no IP.

DFS namespaces: the map users actually live on

Users do not navigate by server name. They navigate by \\contoso\shares\Finance and muscle memory. DFS namespace redesign and replication cutover is therefore a user-experience project disguised as storage.

Across the consolidating agencies we found:

Domain-based namespaces with roots in dying domains
Standalone DFS still hanging off single file servers
Folder targets pointing at clusters that no longer existed
ABE (access-based enumeration) on for some roots and off for others, with no documented reason
DFS-R replication groups that had been "paused for maintenance" since 2015

The target design: one domain-based namespace in the new forest, structured by business function not by agency archaeology, with folder targets on the surviving file clusters and clear ownership. We did not try to merge every share in one weekend. We built the new namespace empty, migrated high-traffic folders first (home drives and departmental shares), left archival data on old servers with temporary folder targets, and published a "path translation" sheet for helpdesk for ninety days.

Replication cutover discipline:

Add new servers as targets with override referral priority low so clients still prefer old servers.
Complete initial DFS-R sync; verify with dfsrdiag and sample hash checks on critical trees.
Flip referral priority so new servers are preferred.
After a quiet period, remove old targets and old replication membership.

Skipping step 2 is how you get silent incomplete copies and finance discovering missing prior-year folders at audit time. Zero data loss is a process, not a slogan.

The thread that ties them together

GPO, DHCP, and DFS fail independently and recover slowly. Our rule on this program: no ADMT user wave into an OU until that OU's GPO baseline is live, its subnets' DHCP is on the target pair, and its primary DFS paths resolve in the new namespace. Identity without plumbing is a green dashboard with red phones.

We staffed a "plumbing desk" for the duration of the consolidation — two seniors who owned the three services end-to-end, sat in the same bridge as the ADMT operators, and had veto power on wave readiness. That sounds bureaucratic. It prevented three near-misses we could name.

Printers: the fourth service nobody budgets

We almost titled this post with printers in the list. Network printers are GPO preferences, DHCP options for some multi-function devices, and DFS-adjacent when scan-to-folder paths move. On this program we:

Rebuilt print GPO preferences against print servers in the target forest only
Retired direct-IP TCP/IP printers that bypassed the print server (security and driver chaos)
Kept a two-week dual-publish window where old and new queues both existed for critical floors
Gave helpdesk a "queue name translation" sheet — same pattern as DFS path maps

If you ignore printers until after user migration, you will spend the next month on the phone with finance who cannot print checks. Put printers on the plumbing desk's checklist.

Monitoring and rollback

SCOM (and later, whatever you use) needs packs and overrides updated for new DHCP servers, new DFS namespaces, and new domain controllers. We added:

DHCP failover relationship health and lease denial spikes
DFS namespace root and folder target availability
GPO processing errors in event logs on pilot OUs during the first week of each wave

Rollback for GPO is usually "relink the old policy and unlink the new." Rollback for DHCP is keeping the old server powered for one full lease cycle. Rollback for DFS is reordering folder target priority. Write those three sentences into the wave plan so nobody invents them at 1 a.m.

Staffing the boring work

Architecture partners love the forest diagram. The plumbing desk is two seniors for the life of the program, not a rotating junior. Continuity matters: the person who designed boundary groups should still be there when wave seven fails in a building nobody mapped. We also put a weekly "ugly services" status in the steering pack — GPO count, DHCP scopes cut over, DFS folders migrated — so executives see progress that is not just "users moved."

What we would refuse next time

Big-bang GPO deletion without a settings inventory and owner map
DHCP export/import with no dual-run and no relay agent plan
DFS redesign driven only by storage admin convenience, without helpdesk path maps
Treating any of the three as "week zero" tasks after users already moved
Printer cutover left to "the desktop team will handle it" with no wave gate
No monitoring for lease failures and namespace target health

A short war story

Mid-program, a business unit reported that "the network is down" every morning for twenty minutes. Network was fine. DHCP lease time had been shortened aggressively before cutover and a misconfigured relay was sending half the building to a decommissioned server that still answered with bad options. Clients that got the wrong DNS could not find the new DFS namespace. The plumbing desk found it in an hour because lease assignment and namespace resolution were on the same dashboard. Without that, it would have been three teams arguing about wireless controllers.

That is why we treat GPO, DHCP, and DFS as one program thread. Users experience them as one system: "I log on, I get an address, I get my drives, I get my printers."

If you're facing this

If your forest consolidation plan has a beautiful target diagram and a one-line bullet for "migrate GPOs and file shares," the plan is not done. Inventory links, options, and namespace paths the way you inventory users — then sequence waves so plumbing lands first. We still take these programs; bring the ugly spreadsheets, not the marketing slides.