Building Our Company's AD Domain: From Workgroup to a Manageable Identity Base

We've got around thirty Windows machines at the company, and every one of them was sitting in a workgroup. Installing software meant passing around USB sticks, changing a password meant yelling across the office, and when someone left, their account just kind of lingered — "I think that machine still lets you log in." The boss wanted "all computers managed centrally, shared drives scoped by department," and I wanted to make damn sure I didn't join business PCs to the domain in week one and lock people out of their own desktops. This post follows the real rollout order — goals, skeleton, migration, rollback — not a screenshot tutorial on installing Windows Server.

Goals, boiled down to three lines

1. Identity: domain-account login, and one disable on departure takes effect everywhere;
2. Policy: screen lock, Windows Update source, mapped drives, and software distribution all have somewhere to land;
3. Resolution: stable internal hostnames — no machine keeping its own hand-typed list of IPs.

Deliberately not in phase one: complex federation, single sign-on across every SaaS in the building, and perfect zero trust. Get AD + DNS + baseline GPO standing first.

Architecture: two DCs beat one

A single DC runs fine — until patch Tuesday or a full disk makes every login queue up at once. Even on a tight budget, at least plan DC02's placement and replication instead of filing it under "later."

Hardware/VM: start at 4 cores / 8 GB (squeeze it lower if you're small), and keep the OS disk separate from the AD database disk if you can. Get your snapshot policy straight too — a DC is not a normal box you casually roll back. Rolling one back can trigger USN rollback; read Microsoft's guidance before you change anything.

Install day: DNS is deadlier than "installing the role"

When you promote the DC, its internal DNS must point at itself (or the planned DNS you stand up alongside), with external recursion going upstream. The classic failure modes:

• Clients still point at the router's 192.168.1.1, so domain join can't find the SRV records;
• The DC's own DNS points at public 8.8.8.8, and replication plus locator both go haywire;
• A name collision with the old internal net (someone already built a workgroup called "Fantasy Domain" with the same name).

I picked an internal name that hadn't been abused publicly — e.g. corp.example.local or a subdomain the company actually registers — and wrote it down plainly: email suffix ≠ domain suffix, and they're allowed to differ. Don't let the boss's casual "let's just call it xxx.com" turn into an incident.

# Post-promotion self-check (run on the DC)
dcdiag /v
repadmin /showrepl
Get-ADDomain
Get-ADDomainController -Filter *

OU and groups: tree first, policies second

Don't start with one OU per computer and micromanage yourself into madness. The skeleton I used:

corp
├── Users
│   ├── Dept-HR
│   ├── Dept-Fin
│   └── Dept-Ops
├── Computers
│   ├── Workstations
│   └── Servers
├── Groups
│   ├── G-HR-Share-RW
│   └── G-VPN-Users
└── ServiceAccounts

Permissions all follow AGDLP: accounts into global groups, global groups into domain local groups, domain local groups carry the NTFS/share rights. Avoid the "just ACE the user straight onto the disk" habit.

Group policy: phase one only ships policies nobody will riot over

Don't ship "disable USB, no exceptions" in week one — unless the boss signs a business-impact acknowledgment. Policy is politics, not just technology.

Migration window: join in batches

1. Join IT's own two machines first; verify login, policy, and printers;
2. Pilot with a volunteer department (10%);
3. Join the rest in batches during business lulls; get remote users' VPN and DNS suffix squared away first;
4. Local admin passwords go into LAPS, or at least a controlled ledger (if phase one skips LAPS, keep an inventory anyway).

The join command itself is no mystery:

Add-Computer -DomainName "corp.example.local" -Restart

The failure points are stale profiles, roaming, and users assuming their desktop files live in their domain profile. Back up desktops and browser bookmarks before the join — and get the talking points out before the command.

File server and shares

A dedicated member server carries the shares; share permissions go to Authenticated Users or department groups, and the fine-grained control lives in NTFS. DFS namespaces can wait for phase two — first make \\files\dept rock solid.

Backups: DC system state and share data on separate tracks. Back up only the data disks and skip the DC's system state, and the day ntds.dit goes bad you'll learn what "identity backbone" really means.

The 30-day post-launch watchlist

• Replication latency, DC disk usage, event logs;
• Whether join failures cluster around DNS suffixes and old antivirus;
• Whether offboarding really means "disable the account + remove it from groups";
• Whether any business software has local-user SIDs baked in (classic with old finance apps).

Wrapping up

AD isn't won the moment the role install finishes — it's identity, resolution, policy, and permissions closing in on the same day. When a network engineer does this work, the value lands in the boring parts: not tripping over DNS and Sites, sequencing the join batches and the rollback talking points, and not treating the DC like a file cabinet.

Later, HR told me the departed employee's drive was already unreachable on their last day. That's the real phase-one acceptance test — less romantic than an all-green dcdiag, but a hell of a lot more useful.