Hello! In this second installment of the series, we walk through building a domain environment — the steps for setting up a test lab.

Series Overview

Chapter 1: Understanding the Basics - Fundamentals of Active Directory and Kerberos/NTLM authentication

[★This installment★] Chapter 2: Building the Domain Environment - Steps for building a test environment

Chapter 3: Joining Clients and Servers to the Domain - Detailed domain-join procedures

Chapter 4: Proxy Servers and Integrated Windows Authentication

Chapter 5: Browser Configuration and Authentication - Configuration steps for each browser

Chapter 6: Troubleshooting - Common problems and solutions

Chapter 7: Security and Best Practices - Considerations for production environments

Chapter 8: Practical Configuration Examples - Integration examples with AI security tools

Chapter 2: Building the Domain Environment

2.1 Designing the Domain Name

2.1.1 Domain Naming Rules

When you build Active Directory, the first important element you must decide on is the domain name. This decision is as important as choosing a company name when founding a company. Once chosen, it is very difficult to change later, so it deserves careful consideration.

[Domain-name decision meeting]
CEO: "I'd like to decide on a domain name for the new AD system."
IT admin: "Yes — this needs to be decided carefully."
General Affairs manager: "Why not just use the company name? We're 'Tanaka Trading,' so tanaka-shoji?"
IT admin: "Hold on. There are rules a domain name has to follow."

To understand the basic rules for domain names, let's first look at the structure of DNS (Domain Name System). Domain names are hierarchical, becoming more specific as you read from right to left.

[Structure of a domain name]
IT admin: "Suppose we have a name like server.tokyo.jp.qualiteg.com."

Breakdown:
- com: top-level domain (TLD)
- qualiteg: second-level domain (organization name)
- jp: subdomain (country/region)
- tokyo: subdomain (site)
- server: host name (an individual computer)

Sales manager: "So it's like a postal address."
IT admin: "Exactly! Like Japan > Tokyo > Minato Ward > Tanaka Building."

There are restrictions on the characters a domain name may contain.

[Allowed and disallowed characters]
New hire: "I want a cool name! Like qualiteg☆japan."
IT admin: "Unfortunately, special characters are not allowed."

Allowed characters:
- Letters (a-z, A-Z) *case-insensitive
- Digits (0-9)
- Hyphen (-) *except at the beginning or end

Disallowed characters:
- Underscore (_)
- Spaces
- Japanese characters
- Special characters (@, #, $, ☆, etc.)

New hire: "So qualiteg_japan is out too?"
IT admin: "Right, underscores aren't allowed. qualiteg-japan would be fine."

There are length limits as well.

[Domain-name length]
General Affairs manager: "How about qualiteg-information-technology-corporation-limited-japan.com?"
IT admin: "Too long! Each label (each dot-separated part) must be 63 characters or fewer."

General Affairs manager: "And the whole thing?"
IT admin: "255 characters total, but in practice shorter is better."

Employee A: "Why is shorter better?"
IT admin: "Imagine typing it every day."
Employee A: "Fair point... I don't want to type qualiteg-information-technology-corporation-limited-japan\yamada."

2.1.2 The Problems with .local Domains

Many organizations have used the ".local" top-level domain, but it actually has problems.

[History of the .local domain]
Veteran admin: "In the 2000s, everyone used .local."
Rookie: "Why?"
Veteran: "Old Microsoft documentation recommended it, and it was an easy way to mark something as internal."

Rookie: "Then qualiteg.local is fine for us too, right?"
Veteran: "Wait! We now know it causes problems."

The biggest problem with .local domains is the conflict with mDNS (Multicast DNS).

[Conflict with mDNS]
(In the meeting room)
Sales: "I can't reach the internal server from my MacBook!"
IT admin: "The .local problem again..."

Explanation:
Mac and iPhone: ".local is a special name reserved for mDNS (Bonjour)."
Windows AD: ".local is my domain name."
Mac: "Let me look up printer.local... wait, do I use mDNS? Or ask the DNS server?"

Result: confusion, and name resolution fails

IT admin: "Problems arise easily when Apple devices and a Windows environment are mixed."

Let's look at a real-world trouble sequence.

[.local domain troubles]
Monday
Tanaka: "I can reach file-server.qualiteg.local from my Windows PC."
IT: "Good."

Tuesday  
Yamada: "I can't reach it from my Mac!"
IT: "That's the .local problem... I'll adjust the DNS settings."

Wednesday
Suzuki: "I can't open the internal wiki from my iPhone."
IT: ".local again..."

Thursday
Sato: "Name resolution from the Linux server is unstable."
IT: "I wish we had never used .local..."

There are also problems down the road.

[Future extensibility problems]
CEO: "I want to integrate with cloud services."
IT admin: "The .local domain is a problem there."

CEO: "How so?"
IT admin: "For example, when integrating with Office 365 or Azure AD..."
- You cannot obtain SSL certificates (.local is not an official TLD)
- External services do not recognize .local
- Hybrid configurations become complicated

CEO: "So we should have avoided .local from the start."
IT admin: "Yes. For a new build today, I recommend other options."

2.1.3 Recommended Domain-Name Formats

Let's look at the recommended domain-name formats based on current best practices.

[Recommended pattern 1: subdomain approach]
IT admin: "The most recommended approach is to use a subdomain of a public domain the company owns."

CEO: "We own qualiteg.com, don't we?"
IT admin: "Then ad.qualiteg.com or corp.qualiteg.com would be good choices."
IT admin: "For this example, let's use jp.qualiteg.com."

Benefits:
- It is an official domain name, so SSL certificates can be obtained
- Easy integration with external services
- Clear DNS management

Sales manager: "But won't it be visible from outside?"
IT admin: "Good question. We solve that with 'split DNS.'"

Let's look at how split DNS works.

[How split DNS works]
IT admin: "We return different DNS answers internally and externally."

Access from outside:
Visitor: "What's the IP address of qualiteg.com?"
External DNS: "133.167.109.189 (the public web server)."
Visitor: "And jp.qualiteg.com?"
External DNS: "No such record." (internal information stays private)

Access from inside:
Employee: "What's the IP address of qualiteg.com?"
Internal DNS: "192.168.1.100 (the internal web server)."
Employee: "And jp.qualiteg.com?"
Internal DNS: "192.168.1.10 (the domain controller)."

Let's also look at recommended pattern 2: using a reserved TLD.

[Using the .internal domain]
IT admin: "Another option is to use .internal, a reserved TLD."

Rookie: "So, qualiteg.internal?"
IT admin: "Yes. It is reserved exclusively for internal use, so it is safe."

Benefits:
- No conflicts with the outside world
- Clearly marks internal use
- Safe going forward

Drawbacks:
- SSL certificates cannot be obtained from public certificate authorities
- Relatively new, so older systems may have issues

Let's look at an actual selection process.

[Domain-name decision checklist]
Discussion in the meeting room:
IT admin: "Let's run through the checklist."

1. Do we own an external domain?
   CEO: "We own qualiteg.com." → Yes

2. Any plans for cloud integration in the future?
   CEO: "We're considering adopting Office 365." → Yes

3. Do we need SSL certificates?
   IT admin: "Needed for Exchange Server and VPN." → Yes

4. Do we use Apple products?
   Sales: "The sales team uses iPads." → Yes

IT admin: "All Yes — so I recommend jp.qualiteg.com."

2.1.4 Designing the Domain with the Future in Mind

Because a domain name is hard to change once chosen, designing with future expansion in mind is important.

[Imagining 10 years from now]
Corporate planning: "We're thinking about overseas expansion in five years."
IT admin: "Then we should consider per-region subdomains."

Today:
- jp.qualiteg.com (single domain)

Future expansion plan:
- jp.qualiteg.com (Japan)
- us.qualiteg.com (United States)
- eu.qualiteg.com (Europe)

Corporate planning: "I see — plan the hierarchy from the start."

Let's also consider M&A (mergers and acquisitions).

[Acquisition scenario]
2024: Qualiteg starts
- jp.qualiteg.com

2026: Acquires Yamada Industries
CEO: "We acquired Yamada Industries — what do we do about AD?"

Option 1: Consolidation
- Migrate Yamada Industries users into jp.qualiteg.com
- Benefit: unified management
- Drawback: heavy migration work

Option 2: Trust relationship
- Trust between jp.qualiteg.com and jp.yamada-kogyo.com
- Benefit: minimal migration work
- Drawback: more complex management

Option 3: Parent-company structure from the start
- group.qualiteg.com (parent)
- jp.group.qualiteg.com (child)
- yamada.group.qualiteg.com (child)

The cloud era also deserves consideration.

[Supporting hybrid environments]
IT admin: "These days, combining on-premises and cloud is the norm."

Traditional design:
- On-premises AD: qualiteg.local (problematic)
- Cloud: qualiteg.onmicrosoft.com
→ Different names make integration complicated

Recommended design:
- On-premises AD: jp.qualiteg.com
- Azure AD: qualiteg.com
→ Same domain name makes integration easy

Rookie: "So we choose a name with integration in mind from the beginning."
IT admin: "Exactly. Changing it later is sheer misery."

Don't forget the importance of a naming-convention document.

[Documenting the naming conventions]
IT admin: "Always document the rules you decide on."

Qualiteg AD Naming Conventions v1.0
========================
1. Domain names
   - Production: jp.qualiteg.com
   - Development: dev.jp.qualiteg.com
   - Disaster recovery: dr.jp.qualiteg.com

2. Site names
   - Tokyo HQ: TOKYO-HQ
   - Osaka branch: OSAKA-BR
   - Nagoya sales office: NAGOYA-SO

3. Server naming
   - DC: DC01-TKY, DC02-TKY
   - File: FS01-TKY
   - Mail: EX01-TKY

4. OU structure
   - Level 1: region (Tokyo, Osaka)
   - Level 2: department (Sales, Admin, IT)
   - Level 3: purpose (Users, Computers, Groups)

Rookie: "With this, everyone's work stays consistent no matter who does it."
IT admin: "Yes — it's also important for avoiding dependence on any one person."

2.2 Windows Server Roles and Features

2.2.1 What Is the AD DS (Active Directory Domain Services) Role?

Windows Server is built so that various capabilities can be added as "roles." It is a bit like installing apps on a smartphone.

[The Windows Server mindset]
Rookie: "If we buy Windows Server, we can use AD right away, right?"
Senior: "No, that's not how it works."

(Smartphone analogy)
Rookie: "If I buy a phone, I can use LINE right away, right?"
Senior: "You can't use LINE without installing the app, can you?"
Rookie: "Oh, right."
Senior: "Windows Server is the same. You need to install the AD DS role."

Let's understand the difference between roles and features.

[Restaurant analogy]
Owner: "I want to open a new restaurant."

Roles (primary capabilities):
- Chef (cooks the food) → AD DS (authentication service)
- Waiter (serves guests) → Web Server (IIS)
- Cashier (handles payment) → DHCP Server
- Manager (oversees everything) → DNS Server

Features (supporting capabilities):
- Kitchen knife (cooking tool) → .NET Framework
- Order slips (for records) → management tools
- Apron (presentation) → Windows Backup

Owner: "So I only hire the roles I need."

Let's look inside the AD DS role.

[What installing the AD DS role gives you]
IT admin: "The AD DS role includes a number of components."

What gets installed:
1. The Active Directory database (NTDS.dit)
   → Stores all user/computer information
   
2. Authentication services
   - Kerberos authentication (KDC = Key Distribution Center)
   - NTLM authentication
   - LDAP (Lightweight Directory Access Protocol) service

3. Replication service
   → Synchronizes data across multiple DCs

4. Group Policy processing engine
   → Creates and distributes policies

5. Management tools
   - Active Directory Users and Computers
   - Active Directory Sites and Services
   - Group Policy Management

Rookie: "That's quite a lot."
IT admin: "All of this together is the 'AD DS' role."

Let's look at the installation flow.

[The actual installation]
IT admin: "Now, let's install the AD DS role."

Step 1: Open Server Manager
Screen: "Welcome"
IT admin: "Manage → Add Roles and Features"

Step 2: Installation type
Choices:
- Role-based or feature-based installation ← choose this
- Remote Desktop Services installation

Step 3: Select roles
□ Active Directory Domain Services ← check
□ Active Directory Rights Management Services
□ DHCP Server
□ DNS Server ← usually checked together
□ File and Storage Services
...

Rookie: "We need DNS too?"
IT admin: "Yes — as explained in Chapter 1, AD requires DNS."

2.2.2 Installing the Role vs. Promotion

A point that confuses many beginners is the difference between "installing the role" and "promoting the server to a domain controller."

[A common misconception]
Rookie: "AD DS role installation complete! So this is a domain controller now!"
Senior: "Hold on — you're only halfway there."
Rookie: "What? But the installation finished!"

(Analogy)
Rookie: "I graduated from medical school! So I'm a doctor now!"
Senior: "No — you're not a doctor until you get your medical license."
Rookie: "Oh, right..."

Let's check the state right after role installation.

[Immediately after installation]
Server: "The AD DS role has been installed."
Server: "But I am still just a member server."
Server: "To become a domain controller, I need to be 'promoted.'"

How to check:
IT admin: "Let's look at the System Properties."
- Computer name: SERVER01
- Domain: WORKGROUP ← still a workgroup!

Rookie: "You're right — it's not a domain yet."

Let's look at the promotion process.

[DC promotion wizard]
IT admin: "Now, let's start the promotion."

Server Manager notification:
"Configuration required for AD DS" ← click

Deployment configuration options:
○ Add a new forest ← choose this for the first DC
○ Add a domain controller to an existing domain
○ Add a new domain to an existing forest

Rookie: "What's a forest?"
IT admin: "The topmost administrative unit of AD. Think of it as the whole company."

Let's look in detail at what happens during promotion.

[Behind the scenes of promotion]
Wizard: "Enter the domain name."
IT admin: "jp.qualiteg.com"

Wizard: "The following will be performed:"

1. Create the AD database
   Location: C:\Windows\NTDS\ntds.dit
   
2. Create the SYSVOL folder
   Location: C:\Windows\SYSVOL
   Purpose: storing Group Policy

3. Create DNS zones
   - Forward lookup zone for jp.qualiteg.com
   - Registration of the required SRV records

4. Convert the Administrator account
   Local administrator → domain administrator

5. Start the services
   - Kerberos Key Distribution Center
   - Intersite Messaging
   - DFS Replication

Progress:
[■■■■■□□□□□] 50% complete
"Creating the AD database..."

Let's verify after promotion completes.

[Verification after reboot]
(Automatic reboot)
IT admin: "Promotion is complete. Let's verify."

System Properties:
- Computer name: DC01
- Domain: jp.qualiteg.com ← now a domain!

Service check:
- Active Directory Domain Services: Running
- DNS Server: Running
- Kerberos Key Distribution Center: Running

Rookie: "Wow, it really became a domain controller!"
IT admin: "Now we can start registering users."

2.2.3 Combining the Necessary Roles

In an AD-centered environment, it is common to combine multiple roles. Let's look at the typical combinations.

[Small environment (up to ~50 users)]
CEO: "We're a small company — I'd like one server to do everything."
IT admin: "Then an all-in-one configuration it is."

Roles to install on SERVER01:
□ AD DS (required)
□ DNS Server (required)
□ DHCP Server (strongly recommended)
□ File Services (recommended)
□ Print and Document Services (as needed)

CEO: "Will one server be enough?"
IT admin: "For around 50 people, no problem. But backups are a must."

Let's look at a mid-size configuration too.

[Mid-size environment (50–500 users)]
IT director: "For availability, I'd like a multi-server configuration."
IT admin: "Let's distribute the roles."

Recommended configuration:
DC01 (primary):
- AD DS
- DNS Server
- DHCP Server (primary)

DC02 (secondary):
- AD DS
- DNS Server  
- DHCP Server (secondary)

FS01 (file server):
- File Services
- DFS (Distributed File System)

APP01 (application):
- Web Server (IIS)
- Application server

IT director: "Why two DCs?"
IT admin: "If one fails, the other can still handle authentication."

Configuring DHCP failover is also important.

[DHCP redundancy conversation]
Network engineer: "If the DHCP server goes down, new PCs can't get an IP."
IT admin: "That's why we configure DHCP failover."

Configuration:
DC01 DHCP: 192.168.1.100–192.168.1.199 (50%)
DC02 DHCP: 192.168.1.200–192.168.1.254 (50%)

Or

Failover modes:
- Load balance (normally split 50:50)
- Hot standby (DC02 waits; takes over if DC01 fails)

Network engineer: "Now I can relax."

Let's look at role design for large environments.

[Large environment (500+ users)]
CTO: "We have sites across the country — design for that."
IT admin: "We place DCs per site and split roles onto dedicated servers."

Tokyo HQ:
- DC-TKY-01, DC-TKY-02 (AD DS + DNS)
- DHCP-TKY-01, DHCP-TKY-02 (dedicated DHCP)
- FS-TKY-01, FS-TKY-02 (file servers)
- PRINT-TKY-01 (print server)

Osaka branch:
- DC-OSA-01 (AD DS + DNS)
- Uses Tokyo's DHCP servers via DHCP relay

Nagoya sales office:
- RODC-NGY-01 (read-only DC)

Let's explain RODC (Read-Only Domain Controller).

[RODC for small sites]
Office manager: "Nagoya only has five people — do we still need a DC?"
IT admin: "There's an option called RODC."

RODC characteristics:
- User information is read-only (cannot be modified)
- Passwords are cached only (not stored for everyone)
- Suited to sites with weaker physical security

Office manager: "So even if it's stolen, the damage is limited?"
IT admin: "Exactly. Authentication gets faster, while the risk of information leakage stays minimal."

Let's also understand role dependencies.

[Dependencies between roles]
Rookie: "Can we put any role on any server we like?"
IT admin: "No — there are dependencies."

Required combination:
AD DS → DNS Server (required)
Reason: AD cannot function without DNS

Recommended combination:
AD DS + DNS + DHCP
Reason: keeping the authentication infrastructure together simplifies management

Combination to avoid:
AD DS + Exchange Server + SQL Server + file server
Reason: too much load concentrated in one place

Rookie: "So balance is what matters."

Virtualization considerations are important too.

[Role placement in virtual environments]
Virtualization engineer: "We can just make everything a virtual machine (VM), right?"
IT admin: "Basically yes, but with caveats."

Recommendations:
1. Keep at least one physical DC
   Reason: recovery when the virtualization platform fails

2. Place virtual DCs on different physical hosts
   Reason: limit the impact of a physical host failure

3. Be careful with time synchronization
   VM: "I'll sync my clock with the host."
   IT admin: "No — DCs should sync time on their own."
   Reason: Kerberos authentication is sensitive to clock skew

4. Do not use snapshots
   Virtualization engineer: "We'll back up with snapshots."
   IT admin: "Snapshots are not recommended for DCs."
   Reason: they cause USN (Update Sequence Number) rollback

2.3 The DHCP Role and Its Configuration

2.3.1 What DHCP Hands Out

DHCP (Dynamic Host Configuration Protocol) is a service that automatically distributes the settings that devices on the network need.

[A world without DHCP]
Monday morning
New hire A: "I'd like to connect my PC to the network."
IT staff: "Sure, apply these settings:"
- IP address: 192.168.1.101
- Subnet mask: 255.255.255.0
- Default gateway: 192.168.1.1
- DNS server: 192.168.1.10

New hire A: "Um, what is all this..."

That afternoon
New hire B: "My PC too, please..."
IT staff: "Let's see, 192.168.1.102..." (same explanation all over again)

New hire C: "Me too..."
IT staff: "I can't take this anymore!"

Let's look at the basic information DHCP hands out.

[After introducing DHCP]
New hire: "I plugged my PC into the LAN cable."
PC: "DHCP server, settings please!" (DHCP Discover)
DHCP server: "Here you go." (DHCP Offer)

Information handed out:
1. IP address: 192.168.1.150
2. Subnet mask: 255.255.255.0
3. Default gateway: 192.168.1.1
4. Lease duration: 8 hours

PC: "These settings work for me." (DHCP Request)
DHCP server: "Confirmed. Go ahead." (DHCP Ack)

New hire: "I'm already online! So easy!"
IT staff: "What a relief..."

Let's understand why the DNS-server information matters.

[Distributing DNS-server settings]
Sales rep: "Why is it so important that DHCP hands out the DNS server?"
IT admin: "Let me show you with an example."

If DHCP does not hand out the DNS server:
PC: "Got my IP address! 192.168.1.150"
PC: "I want to access file-server.jp.qualiteg.com"
PC: "But I don't know the DNS server... can't resolve the name"
User: "I can't reach the file server!"

If DHCP hands out the DNS server:
PC: "Along with my IP, I got the DNS server (192.168.1.10)"
PC: "file-server.jp.qualiteg.com... let me ask DNS"
DNS: "That's 192.168.1.20"
PC: "Access succeeded!"

Distributing option information is important too.

[DHCP options]
IT admin: "Beyond the basics, DHCP can hand out various optional settings."

Commonly used options:
Option 003: Router (gateway)
Option 006: DNS server
Option 015: DNS domain name
Option 066: TFTP server (for PXE boot)
Option 067: Boot file name

Configuration example:
IT admin: "Let's distribute the domain name with Option 015."
DHCP server setting:
- Option 015: jp.qualiteg.com

Result:
PC: "ping file-server" (short name)
PC: "Automatically appends the DNS suffix jp.qualiteg.com"
PC: "Resolves it as ping file-server.jp.qualiteg.com"

2.3.2 How to Configure the DNS-Server Information

Correctly distributing DNS-server information via DHCP is critically important in an AD environment.

[Example of a wrong configuration]
Rookie admin: "DHCP configuration complete!"
Senior: "What did you set as the DNS server?"
Rookie: "The router's address (192.168.1.1)."
Senior: "That won't work!"

Result:
PC: "I want to log in to the domain"
PC → router: "Where is the DC for jp.qualiteg.com?"
Router: "No idea. Let me try the internet."
Internet DNS: "Never heard of that domain."
PC: "Can't log in..."

Let's look at the correct configuration.

[Configuration in Windows Server DHCP]
IT admin: "Open DHCP Manager and configure it."

Steps:
1. Launch DHCP Manager
2. Server → IPv4 → Scope → Scope Options

Settings:
006 DNS Servers:
  - 192.168.1.10 (DC01)
  - 192.168.1.11 (DC02) ← specify more than one for redundancy

015 DNS Domain Name:
  - jp.qualiteg.com

IT admin: "Always specify the DCs' IP addresses."

Let's also look at configuration when using a router's DHCP feature.

[Configuration on a consumer router]
Small-business owner: "Can't we use the router's DHCP instead of buying an expensive server?"
IT admin: "You can, but the configuration needs care."

Yamaha router example:
dhcp scope 1 192.168.1.2-192.168.1.254/24
dhcp scope option 1 dns=192.168.1.10 192.168.1.11
dhcp scope option 1 domain=jp.qualiteg.com

Buffalo router example (GUI):
Advanced Settings → LAN → DHCP Server
- DNS server advertisement: manual
- Primary DNS: 192.168.1.10
- Secondary DNS: 192.168.1.11

Important: choose "manual configuration," not "advertise the router's IP"!

Let's also understand why priority matters.

[Impact of DNS priority]
IT admin: "The priority order of DNS servers matters too."

Good example:
Primary DNS: 192.168.1.10 (DC01)
Secondary DNS: 192.168.1.11 (DC02)

Bad example:
Primary DNS: 8.8.8.8 (Google)
Secondary DNS: 192.168.1.10 (DC01)

Sales: "Isn't Google DNS faster?"
IT admin: "Then internal names can't be resolved."

Example:
PC: "Where is file-server.jp.qualiteg.com?"
PC → Google DNS: "No idea."
PC: "Then it must not exist." (does not ask the secondary)
Result: access fails

2.3.3 Where to Place the DHCP Server (On the DC vs. Dedicated Server vs. Router)

Where to place the DHCP server depends on network size and management policy.

[Comparing placement patterns]
Management: "Where should the DHCP server go?"
IT admin: "Each option has pros and cons."

Pattern 1: Same server as the DC (for small environments)
Pros:
- Fewer servers needed (cost savings)
- Management in one place
- Easy to use AD-integration features

Cons:
- Adds load to the DC
- DHCP also stops if the DC has trouble

Pattern 2: Dedicated server (mid-size to large)
Pros:
- Load distribution
- Independent management
- Unaffected by DC trouble

Cons:
- More servers (higher cost)
- More places to manage

Pattern 3: The router's DHCP feature (small environments)
Pros:
- No extra cost
- Stable hardware
- Simple configuration

Cons:
- No advanced features
- No AD-integration features
- No detailed logging

Let's look at a real selection example.

[Choice for a small company (20 people)]
CEO: "We're a 20-person company — which is best?"
IT admin: "The router's DHCP is plenty."

Configuration:
- DC01: AD DS + DNS
- Router: DHCP feature (with DNS pointing to DC01)

CEO: "Why is the router enough?"
IT admin: "With around 20 machines, IP management is simple, and routers run stably around the clock."

Let's look at the mid-size choice as well.

[Choice for a mid-size company (200 people)]
IT director: "At 200 people, what should we do?"
IT admin: "Host DHCP on the DC servers and make it redundant."

Configuration:
- DC01: AD DS + DNS + DHCP (active)
- DC02: AD DS + DNS + DHCP (standby)

DHCP failover settings:
- Mode: hot standby
- DC01: handles everything normally
- DC02: takes over automatically if DC01 fails

IT director: "No need for a dedicated server?"
IT admin: "For about 200 people, modern servers handle it with ease."

Let's look at large-environment considerations too.

[Choice for a large company (2,000 people)]
CTO: "What about 10 sites nationwide and 2,000 people?"
IT admin: "Place dedicated DHCP servers per region."

Tokyo HQ (800 people):
- DC-TKY-01, DC-TKY-02: AD DS + DNS
- DHCP-TKY-01, DHCP-TKY-02: dedicated DHCP (redundant)

Osaka branch (400 people):
- DC-OSA-01: AD DS + DNS
- DHCP-OSA-01: dedicated DHCP

Other sites (100 people or fewer each):
- Each site's router: uses Tokyo/Osaka DHCP via DHCP relay

CTO: "Why dedicated servers?"
IT admin: "At this scale, DHCP load is significant and detailed log analysis becomes necessary."

Let's explain DHCP relay.

[What is DHCP relay?]
Regional office manager: "Our office has only five people — do we need a DHCP server?"
IT admin: "With DHCP relay, you can use headquarters' DHCP server."

Normal DHCP (same network):
PC: "Settings please!" (broadcast)
DHCP server: "Here you go."

The problem:
PC (branch office): "Settings please!" (broadcast)
Router: "Broadcasts don't get forwarded to other networks."
DHCP server (HQ): "I can't hear anything..."

With DHCP relay:
PC (branch office): "Settings please!" (broadcast)
Router: "Forwarding to HQ's DHCP server via the DHCP relay feature."
DHCP server (HQ): "A PC from the branch office. Here you go."
Router: "Relaying back to the PC."

Office manager: "I see — no server needed at the branch office."

Let's also look at the benefits of AD-integrated DHCP.

[Benefits of using Windows Server DHCP]
Developer: "Isn't the router's DHCP good enough?"
IT admin: "Windows Server DHCP has advanced features."

1. Dynamic DNS update integration
PC: "I received IP 192.168.1.150"
DHCP: "I'll register it in DNS."
DHCP → DNS: "Register PC-001 = 192.168.1.150"
DNS: "Registered."

2. MAC address reservations
IT admin: "I want the CEO's PC to always get the same IP."
DHCP settings:
- MAC address: AA:BB:CC:DD:EE:FF
- Reserved IP: 192.168.1.100
Result: the CEO's PC is always .100

3. User classes / vendor classes
IT admin: "I want different settings for laptops and desktops."
- Desktops: lease duration 8 days
- Laptops: lease duration 8 hours

4. Detailed audit logs
Auditor: "We need records of who used which IP and when."
DHCP log:
2024-01-15 09:00:00, PC-001, 192.168.1.150, AA:BB:CC:DD:EE:FF

Finally, let's summarize the decision guidelines.

[DHCP server placement decision flow]
IT admin: "Use these questions to pick the best placement."

Q1: How many users?
- 50 or fewer → go to Q2
- 50–500 → hosting on the DC recommended
- 500 or more → dedicated server recommended

Q2: (If 50 or fewer) Do you need AD-integration features?
- No → router DHCP
- Yes → host on the DC

Q3: How many sites?
- One site → follow the recommendation above
- Multiple sites → DHCP at major sites, relay elsewhere

Q4: Availability requirements?
- Normal → single DHCP
- High → DHCP redundancy (failover)

Rookie: "Now we can choose the right placement."
IT admin: "Yes — but factor in future growth as well."

Summary

In this installment, we covered building the domain environment — the first step in constructing an Active Directory environment.

In domain-name design, we learned that the once-recommended ".local" domain suffers from problems such as conflicts with mDNS and the inability to obtain SSL certificates. Today's best practice is to use a subdomain of a public domain you own (for example, jp.qualiteg.com) and separate internal from external with split DNS. It is also important to document proper naming conventions from the start, with future growth in mind.

We also saw that installing the AD DS role on Windows Server and promoting the server to a domain controller are separate processes. Just as graduating from medical school does not make you a doctor without a license, installing the role alone does not make a DC — the "promotion" step is required.

As for DHCP server placement, the best choice depends on company size: the router's DHCP feature for small environments, co-hosting on the DC for mid-size ones, and dedicated servers for large ones. What matters most is that the DNS-server information distributed by DHCP always points to the DCs' IP addresses.

Coming up next

In Chapter 3, we finally walk through joining client PCs and servers to the domain in detail.

You might think it is just clicking the "join domain" button — but a surprisingly complex sequence runs behind the scenes. Do computer accounts need to be pre-created? What naming conventions apply at join time? How should OUs be designed? How do the join procedures differ between Windows 10 and 11?

We will also cover troubleshooting for "I can't join the domain!" with real examples — DNS name resolution, time synchronization, firewalls, and other common stumbling blocks, explained in an easy-to-follow conversational format.

Next time, staying true to our motto of "clear enough for both the CEO and the new hire," we will bring you more practical content. Stay tuned!