username/password move from the sealed image to makeConfigMedium, so two
VMs get distinct logins (and, as before, distinct SIDs). The sealed
image bakes only a generic bootstrap account ("vmixsetup") whose sole job
is to carry OOBE to a logon; post-oobe then creates the real account from
the config CD, switches autologon to it, and reboots so it builds its own
SID-bound profile on D:\Users\<username>. A one-shot cleanup (RunOnce,
first logon of the real account) retires the bootstrap and its profile
and applies the per-user tint. So nothing about the account is shared or
baked, and the on-disk profile folder matches the real username.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117qMyjpuXsjpVAcpJbFD8g
A sealed image bakes no per-VM data. generalize.nix gains a gated
configMedium flag (false path byte-identical, so the shared macOS
generalize path is untouched): the baked answer file stays generic and
the target's first boot reads hostname/static-IP/timezone/tint off a
small removable CD via a finder (vmix-load-config.cmd) + applier
(vmix-apply-config.ps1), with the static-IP script dot-sourcing the same
config. templates.seal is a thin preset (delayOobeRun + configMedium +
D:\Users profiles + a data disk); images gain a .seal leaf next to
.generalize; makeConfigMedium renders the per-VM ISO.
So one sealed store path is shared by every VM, each mints its own SID
on first boot and builds the whole profile on D:, and only a cheap ISO
is per-VM. Also folds in the delayOobeRun reconcile: extraDisk (and the
audit-mode data-disk init) are gated off under deferral, so a sealed
image ships with no throwaway `data` output -- the target's specialize
formats the host zvol instead.
vms: disks.config.file attaches the config medium as a second CD-ROM.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0117qMyjpuXsjpVAcpJbFD8g
