01Executive summary

When an office closes, the servers in its closet do not get to close with it. Domain controllers, DNS, DHCP, file shares and print queues still have users who depend on them, and every one of those services carries assumptions about the network it lives on.

This case study covers continuity planning for relocating a Hyper-V host and its virtual machines from a closing site into another office. It is written as a consolidation and continuity plan. Milestones are only shown as complete where completion has been verified.

02Disciplines & technologies

03The problem

The VMs could be moved. The hard part was everything that assumed they would stay where they were: static addresses on the old subnet, DNS records pointing at those addresses, a DHCP scope that only made sense at the old site, mapped drives and printer paths on every workstation, and a domain controller whose replication and site configuration reflected the old layout.

Get any of it wrong and users see the same symptom: logons slow down, drives go missing, printing breaks, and nobody can tell which change caused it.

04Environment & complexity

05My contributions

• Inventoried the services on the Hyper-V host and the dependencies on each one
• Planned readdressing for VMs moving to the receiving subnet
• Worked through the domain controller IP change: DNS records, client resolvers, replication health
• Evaluated whether the closing site’s DHCP role was still needed and where scope conflicts could occur
• Reviewed subnetting and routing so both offices could reach the services during the transition
• Planned file and print access continuity: share paths, mapped drives, printer deployment
• Defined post-relocation verification checks

06Relocation plan

1. Map dependenciesList every service on the host and who or what talks to it, including devices that do not show up in AD.
2. Decide addressingReaddress into the receiving subnet, or keep the old subnet and route it. Readdressing is cleaner long-term; routing is faster short-term.
3. Prepare DNSLower TTLs ahead of the move, plan record updates for every static host, and plan client DNS server changes via DHCP options and static configs.
4. Domain controllerConfirm replication is healthy before the move, change the IP deliberately, re-register DNS records, then confirm replication again.
5. DHCPDecide whether the role is still needed. If two servers could answer on one segment, disable or remove one scope before cutover.
6. File & printKeep share and queue names stable where possible so drive mappings and printer paths survive the move.
7. VerifyRun the checks below before calling any milestone done.

# domain controller health and replication
› dcdiag /v
› repadmin /replsummary
› repadmin /showrepl
# DC registered its records at the new address
› ipconfig /registerdns
› nltest /dsgetdc:<domain>
› nslookup <dc-hostname>
# DHCP: who is answering on this segment
› Get-DhcpServerv4Scope
› Get-DhcpServerInDC
# file and print
› Get-SmbShare
› Get-Printer -ComputerName <print-server>

07Challenges & decisions

08Outcomes

• Design / evaluation

  Relocation plan, dependency map and verification checklist prepared.

• Pending verification

  VM relocation, readdressing and DC DNS/replication status after the move: pending confirmation.

• Pending verification

  DHCP role decision and final file and print access validation: pending confirmation.

• Not documented

  No downtime or cost figures are claimed.

09Lessons & capabilities

• Move the dependencies, not just the VMs
• A domain controller IP change is a DNS project with a server attached
• Never let two DHCP services find out about each other in production
• Verification is part of the change, not something that happens afterwards

Capabilities demonstrated

• Hyper-V operations
• AD DS & DNS
• DHCP design
• IP planning
• Change planning
• Service verification

10Related work