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.

Offline domain join

Joins the deployed machine to Active Directory without it ever reaching a domain controller — the join happens offline during deploy, using a blob provisioned in advance. On any domain-joined machine with rights to create computer accounts:

djoin /provision /domain corp.example.com /machine ACCT-001 /savefile odj.bin

Base64-encode the file and paste it into the profile:

[Convert]::ToBase64String([IO.File]::ReadAllBytes("odj.bin"))

One blob, one machine — a djoin blob is bound to the exact machine name it was provisioned for. It must match the name your template will produce for that machine, which makes blobs a fit for one-off or small-batch deploys. For fleets, prefer a first-boot script that joins the domain, or provision one blob per machine.

First-boot script

Runs once, as SYSTEM, after Windows setup completes 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. Keep it idempotent; there is no retry UI on a machine that's already in a user's hands.

What applies when?

Setting	Mechanism	Works on
Computer name	Offline registry edit	Any image
Org, locale, time zone	unattend.xml	Generalized (sysprepped) images
Domain join	djoin /requestODJ offline	Any image
Local admin, first-boot	SetupComplete.cmd	Any image