Kapothi Scroll: Rebooting Domain Controllers and FSMO Roles

Kapothi — Sinhala slang for “getting into a big problem” — is our reminder that even in IT, what looks like disaster can be turned into wisdom. Today’s scroll: Do you need to transfer FSMO roles before rebooting a domain controller?

🏛 The Setup

• Two domain controllers: Server1 and Server2.
• All FSMO roles (Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master) are on Server1.
• Question: If you reboot Server1, must you transfer all roles to Server2 first?

🔎 The Truth

No, you don’t need to transfer FSMO roles for a short reboot. Server2 will continue authenticating users, handling DNS, and keeping AD alive. FSMO roles are only required for specific operations (schema changes, RID allocation, time sync from PDC). These can pause briefly without breaking daily logons.

✅ Pre‑Reboot Checklist

Before rebooting Server1, confirm Server2 is healthy:

# Replication health
repadmin /replsummary

# DNS resolution
nslookup yourdomain.local Server2_IP

# Time sync status
w32tm /query /status

# FSMO role holders
netdom query fsmo

• Ensure Server2 is a Global Catalog (check in Active Directory Sites and Services).
• Verify clients have Server2’s IP in their DNS list (ipconfig /all).

⚖️ When to Transfer FSMO Roles

• If Server1 will be offline for days or weeks.
• If you plan to decommission Server1.
• If you need high availability for RID allocation or schema changes.

In those cases, transfer FSMO roles to Server2. Otherwise, a simple reboot is safe.

🌌 Kapothi Takeaway

• Short reboot? No FSMO transfer needed.
• Long absence or decommission? Transfer roles.
• Always check replication, DNS, and Global Catalog before reboot.

Kapothi reminds us: what looks like a big problem is often just a small ritual, if you know the scrolls.