Windows Server 2025 / How to Plan a Virtual Lab and Network
Plan a Windows Server 2025 lab by placing servers and clients on a virtual network isolated from your production network, then deciding their names, IP addresses, and DNS roles. Start with DC1 and CLIENT1, and add FS1 and DC2 when you reach file sharing and replication exercises.
Distinguish the host from the guests
The host is the physical computer running the virtual machines; a guest is an operating system installed inside a VM. Establish which one an instruction applies to before changing settings. Changing the host's real network adapter when you meant to change a guest's IP address can disrupt connections outside the lab.
Check that your chosen virtualization product, such as Hyper-V or VMware, supports the host operating system and hardware. Hyper-V also has Windows edition and hardware virtualization requirements. Following a VM creation wizard does not make an unsupported host suitable for the lab.
Create the isolated virtual network first
Keep an initial Active Directory or DHCP lab off the office network rather than immediately connecting it through an external or bridged adapter. If the host needs access to the lab, choose a configuration that permits host-to-VM communication. If only guests need to communicate, a VM-only network may be sufficient. Networking terms and defaults vary between virtualization products, so check the actual connection scope.
This course uses 172.24.50.0/24 as an example subnet. Before proceeding, check for overlap with the host network, a virtual private network (VPN), or another virtual network. If necessary, choose a different private subnet and apply the replacement consistently throughout the exercises.
A fully isolated network has no route to the internet. For updates, plan a controlled connection or separate routing and Network Address Translation (NAT). Entering the address of a router that is not connected to the lab does not create an internet connection.
Plan names, addresses, and DNS
| Machine | Purpose | Example addressing | DNS plan |
|---|---|---|---|
| DC1 | First domain controller and DNS server | 172.24.50.10/24, static | Use domain DNS after the service is configured |
| DC2 | Additional domain controller and DNS server | 172.24.50.11/24, static | Use DC1 for name resolution before promotion |
| FS1 | Domain member file server | 172.24.50.20/24, static | Use domain DNS |
| CLIENT1 | Check domain joining, policies, and share access | Static initially; DHCP during later exercises | Use domain DNS when joining the domain |
The table is an address plan, not a claim that DNS is already working. A new server before DNS installation and a server in a configured domain require different checks. Once the domain exists, domain members must be able to query the domain's DNS records rather than relying only on external public DNS servers.
An example lab domain name is ad.example.test. Do not arbitrarily use a real domain belonging to another organization. A production namespace requires separate planning around names your organization controls and its other services.
Budget resources beyond installation minimums
Minimum installation requirements differ from resources that make several lab roles comfortable to use. Microsoft's Windows Server hardware requirements describe product requirements; capacity for the services you combine must be planned separately.
For a small learning VM, an example starting allocation is two virtual CPUs, 4 GB of memory, and a dynamically expanding 60 GB system disk, followed by observation of actual usage. These are lab planning examples, not a universal Microsoft recommendation or a guarantee for a business workload. Budget separately for file server data disks and backup storage.
Add the memory of guests that will run simultaneously and leave capacity for the host operating system. If memory is tight, start only the machines needed for the current exercise. Dynamically expanding disks still require enough real host storage for growing files, updates, and checkpoints.
Record the configuration and recovery plan
- Record each virtual network's name, communication scope, and whether it connects to a real network.
- Record VM names, editions, installation options, IP addresses, DNS settings, and administrator account names. Keep passwords out of public documentation.
- Identify useful restart points, such as just after installation or before adding a role, and prepare the necessary backups or installation media.
- Verify that clients and servers use the intended lab network, then check for address conflicts and name resolution problems.
- If an exercise temporarily permitted external access, restore the intended isolation afterward and verify the result.
Recovering a domain controller is not the same as copying a file or arbitrarily reverting a VM. Rebuilding an empty learning VM differs from restoring Active Directory with real accounts and replication data. As the lab develops, record both the data and the roles that a recovery must preserve.








