Deployment profiles

A machine that comes out of the oven finished: named, localized, joined.

A profile is a bundle of identity settings the technician picks at deploy time. The same golden image plus a different profile produces an accounting workstation, a lab machine, or a kiosk — no per-machine fiddling afterward.

Computer name preview

Try a template before putting it in a profile. The preview applies the same 15-character NetBIOS cleanup rule.

Template Sequence Serial Asset tag Model

Computer name templates

The template builds each machine's name at deploy time. Plain text passes through; tokens are replaced per machine:

Token	Becomes
`{SEQ}`	A per-profile counter the Forge increments on every deploy: 1, 2, 3… Two technicians deploying at once can't collide — the Forge hands out the numbers.
`{SEQ:03}`	The same counter zero-padded to the given width: 001, 002… (any width works: `{SEQ:05}` → 00001).
`{SERIAL}`	The machine's SMBIOS serial number / service tag — a name that survives reimaging and matches the sticker on the case.
`{ASSET}`	The SMBIOS asset tag, if your fleet sets one.
`{MODEL}`	The hardware model string.

Examples: ACCT-{SEQ:03} → ACCT-001, ACCT-002, … | LAB-{SERIAL} → LAB-9XJ4L83.

Names are sanitized to NetBIOS rules: uppercased, letters/digits/hyphens only, trimmed to 15 characters. The rename is applied offline to the deployed image's registry, so it works on any image — sysprepped or not.

Locale and time zone

Locales are BCP-47 codes (en-US, de-DE, pt-BR…). Time zones are Windows time-zone names — run tzutil /l on any Windows machine for the full list (Eastern Standard Time, W. Europe Standard Time, UTC…). The console suggests common values as you type; anything valid is accepted. Both apply via unattend answers, which fire on generalized (sysprepped) images.

Local admin account

When set, the deploy ensures a local administrator with that name and password exists on the machine at first boot — your bench/support account, present everywhere.

The password (and the domain-join account password below) are encrypted at rest on the Forge with a key that lives only on that machine's local disk — not in the image store, so a store relocated to a NAS/UNC share never carries the key with it. A disaster-recovery backup includes the key (so a restore onto a replacement Forge still works); anyone with filesystem access to just the store, without the Forge box itself, sees ciphertext.

Skipping the out-of-box experience

A generalized (Sysprep) image normally comes up in Windows Setup's out-of-box experience, and recent Windows builds push hard for a Microsoft account there — on a machine with a network connection there may be no visible way past it. Deploying a deployment image now answers those screens automatically, so the PC reaches a desktop without a technician clicking through setup.

Set a local admin account and a locale on the profile to skip OOBE entirely. The deploy screen tells you which of the two is missing:

Profile has	What the deployed PC does
Local admin + locale	Boots straight to the sign-in screen for that account. No setup prompts at all.
Local admin only	Skips the account, network, EULA and privacy screens. Still asks for region and keyboard layout.
Neither	Skips the Microsoft-account, EULA and privacy screens, but still asks for region, keyboard, and a local account name.

The account you set becomes a local administrator on the deployed machine, and it is the same account described under local admin account above — one setting, not two.

Replacement clones are unaffected. A clone keeps the source machine's existing accounts and never runs the out-of-box experience, so there is nothing to skip. ImageForge deliberately does not write the account details to a clone.

Where the password sits, briefly. Windows accepts a first-boot account password in its answer file only in plain form, so between the deployment finishing and Windows completing setup, that password is readable on the deployed machine's disk at C:\Windows\Panther\unattend.xml. Windows removes it when setup completes. Anyone who can boot that machine from other media during that window can read it — use a bench account password you rotate, not a domain administrator's.

Domain identity

Whenever a profile is applied, the deployed machine's first-boot script checks whether it's carrying an inherited domain identity and removes that identity before any new join. This matters because a captured golden image is very often domain-joined itself: cloning it duplicates the source machine's Active Directory computer-account identity onto every deployment, which shows up later as "the trust relationship between this workstation and the primary domain failed" and used to mean unjoining and rejoining by hand on every deployed machine. ImageForge performs that sequence in explicit phases: authenticated domain leave, restart into WORKGROUP, activate the selected computer name, restart if required, join with the active name, then restart once more before running the profile's custom first-boot script.

Field	Required?
Join domain	Leave blank to deploy as a workgroup machine. If the captured source was domain-joined, use a domain profile with valid credentials so ImageForge can authenticate the required leave before joining the target identity.
Organizational unit	Optional — defaults to the domain's default computer container when blank.
Domain join account / password	Required when a domain is set and also used to remove inherited domain membership. It needs rights to unjoin the captured identity and create or reuse the target computer object in the selected OU.

Test against a non-production domain first — this runs as SYSTEM at first boot and needs the target machine to actually reach a domain controller to complete a new join (the leave step alone does not). ImageForge waits up to 60 seconds for domain discovery and allows up to three actual identity failures; required restarts do not consume that limit. If the expected restart does not occur, inspect C:\Windows\Setup\Scripts\ImageForge-firstboot.log and C:\Windows\debug\NetSetup.log.

Check the requested name in Active Directory before deploying. A computer object with that name must either be absent or reusable by the join account. Microsoft domain-join hardening can block reuse of an object owned by another account. Also remove stale duplicate HOST/NAME and RestrictedKrbHost/NAME SPNs anywhere in the forest. ImageForge now explains these cases, along with DNS, OU, credential, and domain-controller failures, in ImageForge-firstboot.log.

Windows activation

ImageForge copies Windows exactly as it was captured, including its license state. Each profile chooses what the deployed PC does about its Windows license at first boot:

Setting	What happens	Use it when
Leave as captured (default)	Nothing changes. A clone starts with the source PC's key and Windows re-checks activation on the new hardware; a Sysprep-generalized image normally picks up the key stored in the PC's firmware during setup.	Volume-licensed Enterprise or Education images that activate against your own KMS or Active Directory activation, or when you handle activation another way.
Use each PC's own license	The deployed Windows reads the key the manufacturer stored in that PC's firmware, installs it, and activates. The key never leaves the PC and never passes through ImageForge.	PCs that came with Windows, deployed with a matching edition — for example Pro PCs deployed with a Pro image. This fixes clones that show Windows isn't activated after moving to new hardware.
Install a product key	The key you enter is installed and activated on each PC.	A MAK or retail key you are licensed to use on those PCs. Stored encrypted on the Forge, like the profile's passwords.

The deploy screen's plan shows which one will happen, and whether the PC in front of the technician has a license in its firmware. Activation needs the deployed PC to reach Microsoft (or your KMS server): if it is offline at first boot the key is still installed, and Windows keeps trying. The result is written to C:\Windows\Setup\Scripts\ImageForge-firstboot.log. On a clone, like the domain settings, this runs at the first administrator sign-in.

ImageForge does not supply Windows licenses. Every PC you deploy needs its own valid license for the Windows edition you install. The right to re-image PCs with one image comes from your agreement with Microsoft (typically Volume Licensing), not from ImageForge. A key whose edition doesn't match the image is rejected by Windows and logged; nothing else changes.

Which technicians can use a profile

A profile that holds a local-admin password, a domain-join password, a Windows product key, or a first-boot script can only be used with a technician code that has sensitive profile access. On the boot USB, such profiles are marked locked for other codes instead of being refused after they are chosen. The profiles table in the console shows which profiles need such a code, and warns when no current code can use one.

After deployment

Each profile chooses what happens when the image is down: restart into Windows (the default), shut down for machines being prepared to ship or store, or stay in ImageForge. Restart and shut down wait 60 seconds first; pressing Enter at the PC cancels and offers the choice again.

First-boot script

Runs once, as SYSTEM, after Windows setup and managed identity work complete on the deployed machine (SetupComplete.cmd). Use it for agent installs, config pulls, domain joins at scale — anything you'd otherwise do by hand on first login. ImageForge's local-admin and domain work runs before this custom command. The custom command runs in an isolated child process and its start and exit code are written to ImageForge-firstboot.log, so an exit or restart inside it cannot skip or repeat managed identity setup. Keep custom work idempotent.

What applies when?

Setting	Applied	Works on
Computer name	During deploy, offline	Any image
Org, locale, time zone	During Windows setup (unattend.xml)	Generalized (Sysprep) images only
Out-of-box experience skip	During Windows setup (unattend.xml)	Deployment images only
Domain leave/name activation/join	During Windows setup or the first local-administrator sign-in, with automatic restarts between required phases	Any image
Local admin	During the first managed phase	Any image
Windows activation	After the requested name and domain membership are active	Any image
Custom first-boot script	After the requested name and domain membership are active	Any image

Keep Ethernet connected through the automatic restarts. Managed identity phases continue at startup as SYSTEM. If the first phase has not begun by the time Windows reaches sign-in, signing in once as a local administrator triggers the RunOnce fallback. The deploy screen lists exactly which settings are deferred, so a technician knows what is still outstanding when they hand the machine over.

On generalized images the same work may run slightly earlier, during Windows setup. It is guarded so it only ever runs once, whichever path fires.