The CyberLab uses two domain controllers in a single-domain model for the acs-p01.local forest (NetBIOS ACS-P01).
Current state (September 5, 2026): DC01 and DC02 remain domain controllers for
acs-p01.local— they are not being demoted or converted. What is changing is their role as session hosts: every student now has their own pod member server and connects there instead. Student RDP on DC01 is still technically enabled and is removed as the final cutover step, after the Pod01/Pod03 pilots pass. Student accounts do not move —student01–student20stay domain accounts held here.
| Property | Value |
|---|---|
| VM ID | 200 |
| Hostname | DC01-P01 |
| IP Address | 10.50.1.10 |
| OS | Windows Server 2022 Datacenter (retail, activated 2026-10-01) |
| Domain | acs-p01.local |
| FSMO Roles | All 5 roles |
| vCPU | 12 |
| RAM | 32 GB |
| Bridge | pod01net (pods reach it through their pod gateway) |
| RD Session Host | Installed |
| Autostart | onboot=1 |
acs-p01.local zone)Without the RD Session Host role, Windows Server allows only 2 concurrent RDP sessions (administrative remote access). With all 20 pods pointed at DC01 that meant the third student was blocked, which is exactly the failure students hit on August 17.
Applied on DC01:
| Setting | Value | Effect |
|---|---|---|
RDS-RD-Server feature |
Installed | Lifts the 2-session cap |
LicensingMode |
4 (Per User) | No license server configured — runs on the RDS grace period |
MaxInstanceCount |
999999 | No artificial session cap |
MaxDisconnectionTime |
3600000 ms (1 h) | Disconnected sessions end and free resources |
MaxIdleTime |
7200000 ms (2 h) | Idle sessions are disconnected |
fSingleSessionPerUser |
1 | One session per student account |
Windows Search (WSearch) |
Disabled | Removes per-session indexing overhead |
| Defender exclusion | C:\CyberLab |
Keeps evidence writes off the scanner |
Validated, not just configured: 12 real student logons were driven through guacd simultaneously and all 12 were logged on at once (confirmed with quser) at roughly 2% CPU with ~27 GB RAM free. Sizing guidance from that test: 12 vCPU / 32 GB for 12 concurrent students, 12 vCPU / 48 GB if all 20 are on DC01.
Configuration and the load-test harness are codified in the crc-awx-labops repository (playbooks/configure-dc-session-host.yml, docs/runbooks/SHARED-DC-CAPACITY.md).
There is no RD licensing server and no RDS CALs, so DC01's session host runs on the RDS grace period. Windows Server 2022 Datacenter product keys license the operating system — they are not RDS CALs. The pod member server model removes this exposure: one student per server needs no CALs, and the RD Session Host role comes off DC01 when student logon is retired.
| Property | Value |
|---|---|
| VM ID | 221 |
| Hostname | DC02-P01 |
| IP Address | 10.50.1.11 |
| OS | Windows Server 2022 Datacenter (retail, activated 2026-09-29) |
| Domain | acs-p01.local |
| vCPU | 4 |
| RAM | 16 GB |
| Bridge | pod01net |
| RD Session Host | Not installed (2-session admin limit) |
| License Expiry | None — permanently licensed |
DC02 is a replica for authentication resilience only. No student sessions run on DC02: its RDS logon right is restricted to Administrators, no Guacamole connection points at it, and it holds no pod evidence trees. There has never been a "students 01–10 on DC01 / 11–20 on DC02" split. Students are now issued PODXX-SRV tiles at 10.50.XX.20, and seed/verify/reset run against crc_pod_servers; the legacy PODXX-DC tiles at 10.50.1.10 and the crc_shared_dcs path are retained only for rollback.
DC02 was converted off the Evaluation build before the 2 October expiry, which would have started hourly auto-shutdowns. Microsoft does not allow an evaluation-to-retail conversion while a machine holds AD DS, so the sequence was: demote DC02 (no FSMO roles, replication clean), DISM /Online /Set-Edition:ServerDatacenter with the retail key, reboot, slmgr /ato, then re-promote as a replica domain controller and global catalog.
Verified afterwards: edition is Datacenter (non-evaluation), LicenseStatus 1, retail channel; DC02 is a global catalog with no operation-master roles; replication succeeds in both directions on all five naming contexts with zero failures; dcdiag connectivity, advertising and services pass. The dcdiag Replications sub-test reports DsBindWithSpnEx() failed with error 5 on both DCs — that is the remote WinRM credential context, not replication, and predates this work.
Two notes for whoever touches DC02 next: activation needs public DNS on the Ethernet 2 (192.168.1.221) interface, because the internal resolver does not serve external names — set it temporarily, activate, then return the interface to 10.50.1.10; and the local administrator and DSRM passwords were reset during the maintenance, so the current values are the ones held in the operator's private state file, not the pre-September credentials.
DC01 was already full Datacenter but carried a duplicate of the POD01 key and sat in Notification. A fresh retail key was installed with slmgr /ipk and activated; no reboot and no role change. Verified afterwards: Datacenter, retail channel, LicenseStatus 1; dcdiag connectivity, advertising, services and DNS all pass and replication with DC02 is current.
DC01 has a single NIC on pod01net with no default gateway, so activation needed temporary internet: a second e1000 NIC on vmbr0 was hot-added to VM 200, given public DNS with RegisterThisConnectionsAddress off, used to activate, then deleted. Hot-add and hot-remove both worked without a reboot. Anyone repeating this must turn off DNS registration on the temporary NIC first, or the 192.168.1.x address lands in acs-p01.local and clients start resolving the domain to an unroutable address.
While checking that, two stale 192.168.1.221 A records from DC02's second NIC were found at the acs-p01.local zone root and removed, and registration was disabled on that interface so they do not come back.
Known oddity, not yet explained: every PODXX-SRV address (10.50.X.20) is registered as an A record at the acs-p01.local zone root alongside the two DCs. Member servers should not register there. It is harmless for SRV-based domain location but means a bare acs-p01.local lookup can return a pod server.
Still outstanding: POD07-SRV and POD11-SRV remain in Notification, with the supplier keys rejected for activation-count exhaustion (0xC004C008); both pods are held back.
Compare keys character for character, not by their last group. Get-CimInstance SoftwareLicensingProduct only exposes PartialProductKey, which is the final five characters, and that group is not unique to a key — two unrelated Datacenter keys in this estate (POD20's and DC01's) both end F9FRV. A suffix match is a prompt to check the full key list, not proof of reuse.
Students now sign in to their own PODXX-SRV, not to a DC. What the DCs still provide to a student session is directory service only: DNS, Kerberos logon, LDAP/LDAPS for ADUC and AD PowerShell, Global Catalog, and SYSVOL/NETLOGON for the logon script.
Directory-side rights are unchanged by the migration:
studentXX is delegated GenericAll on its own OU=PodXX,OU=Students,DC=acs-p01,DC=local — nothing else.studentXX@acs-p01.local (or ACS-P01\studentXX). ACS\studentXX is invalid — the NetBIOS name is ACS-P01.Still to remove at final cutover: studentXX membership in DC01's Remote Desktop Users, the RDS logon right for students, and their grants on the PODXX-DC Guacamole connections. DNS, LDAP/LDAPS, Kerberos, Global Catalog, SYSVOL/NETLOGON and replication are re-tested after that change.
AD replication between DC01 and DC02 uses standard intra-site replication over the shared 10.50.1.0/24 network. Both DCs are in Default-First-Site-Name.
| Page | Purpose |
|---|---|
| Pod Member Servers | The student session hosts (PODXX-SRV) |
| Pod Infrastructure | Pod networks, OUs, gateways |
| Student Quick Start | Student-facing login instructions |