The Cloned Lab Image That Forgets Its Own Identity
A high school has a 28-station Windows lab used for a digital design course. The technician deploys a single image to all 28 PCs by cloning a mastered workstation. The master was named LAB-PC, joined to the domain, and had a static IP of 10.10.4.20. After cloning, the technician renames each PC to LAB-01 through LAB-28 but does not run sysprep. Within a week: 11 PCs log in slowly, 7 report 'trust relationship between this workstation and the primary domain failed,' and 4 get an IP conflict warning; the file server shows several clients with the same machine identifier. The lab has a DHCP server, but the master's static IP was copied. Classes start in 3 days; reimaging all 28 PCs from scratch would take 6 hours, while a scripted fix might take 45 minutes but risks breaking domain accounts. The technician asks the teacher which approach to take.
1. Explain what cloning without sysprep did to the machines and how that produces the three symptoms.
Read the worked answer
Cloning copied the master's computer name, machine security identifier, domain membership, and static IP configuration. Renaming each PC after cloning changes the display name but does not generalize the image. The copied static IP 10.10.4.20 means multiple machines claim the same address, producing duplicate-address detection and the four IP conflict warnings. The duplicated machine identity and domain account data mean the domain controller sees several computers claiming the same underlying identity. When their machine account passwords diverge from the domain's record, the secure channel fails and users see the trust-relationship error on seven PCs. The slow logins on eleven PCs are consistent with name and account contention, stale DNS registrations, and Group Policy being applied to the wrong computer object. The root cause is a non-generalized image plus a copied static IP, not a failing switch or a bad DHCP server.
2. Recommend a recovery plan: reimage versus scripted fix. Include order of operations and what to verify.
Read the worked answer
Recommend reimaging from a properly generalized master. Six hours is available within three days, and the scripted fix leaves duplicate machine identifiers and hidden account problems that can reappear during testing. Order: back up any local student files; build a clean master; run sysprep /generalize /oobe /shutdown; capture the image; deploy to all 28 PCs; leave the NIC set to DHCP or use DHCP reservations; name each PC during first boot; join the domain; reboot; verify. Check ipconfig /all for unique addresses, nltest /sc_verify:DOMAIN for the secure channel, successful domain login for a test student, Group Policy application, and access to the file server.
If reimaging is impossible, the scripted triage is: disconnect from the network, switch to DHCP, rename, remove from the domain, delete the stale computer account, rejoin, reboot, and test. Treat that as temporary because the duplicate SID and image-level problems remain. In either path, fix one pilot machine and verify before touching all 28.
3. What should be changed in the lab's deployment process to prevent recurrence? Include both technical and documentation controls.
Read the worked answer
Technical controls: always generalize a master with sysprep before cloning; never include a static IP in a cloned image; use DHCP reservations by MAC address or a documented static-address table if reservations are not possible; use a naming convention applied at first boot; test one deployed machine for domain trust, IP uniqueness, and policy application before deploying the rest. Keep the master off the production domain or in a staging OU until generalization.
Documentation controls: write a deployment checklist with sign-off for sysprep, imaging, naming, IP method, and domain join; record the master image version and the date; keep a lab inventory mapping PC name to MAC address and assigned address; store the recovery steps for trust-relationship and IP conflicts; require a change ticket for image changes. These controls address the two failure modes seen here: copied identity and copied network configuration. The teacher should also confirm that student data is stored on the network, not on local disks, so future reimages are low-risk.