Skip to main content

Which Provisioning Method, Then OS Configuration

Runbook Azure

DOCUMENT CATEGORY: Runbook SCOPE: How the OS install method decides what OS configuration does PURPOSE: Know which path your machines take from the OS install to ARM Deploy, and which method you used MASTER REFERENCE: Phase 03: OS Configuration

Status: Active

Overview​

There are two ways the OS gets onto a machine, and OS configuration always starts after the OS install:

MethodWho installs the OSWhat exists when OS configuration starts
Simplified provisioning (azurelocal-ztp, or the portal tasks)Azure, after the machine is claimed with its ownership voucherAn Arc-connected, Provisioned machine named <device-id>-1. With ZTP, also a handoff file
Manual ISO install (Phase 02, manual)A person, at the BMC console, on every machineAn installed OS with no Arc machine yet
There is no unattended ISO install for Azure Local

Microsoft's installer for Azure Local is interactive. Nothing in this repository or in azurelocal-ztp installs the OS from an ISO without a person. If you want no one in the rack, use simplified provisioning with azurelocal-ztp. OS configuration then starts from the ZTP Handoff.

The flow​

Decision flow from the OS install method to OS configuration. After Phase 01 the OS is installed either by a manual ISO install or by simplified provisioning with azurelocal-ztp, which ends at the Handoff. Method detection per node checks scenario.os_install against the evidence: the ZTP handoff file, the Arc machine and whether the node answers. The simplified path runs over Azure Arc Run Command and first verifies what ZTP did; the ISO path runs over WinRM with the vault local administrator, sets the computer name and the static management address by MAC and registers the node with Arc. Both then do the remaining steps, and a converge check follows. A converged cluster goes to ARM Validate and then ARM Deploy; anything else ends with a non-zero exit code.

Select the diagram to open it full screen and zoom. Source: provisioning-to-os-configuration.drawio.

The two paths share most of their work. They differ in how they reach the node, and in what has to happen first:

Simplified pathISO path
Reaches the node byAzure Arc Run Command: the script goes through Azure to the Connected Machine agent. HTTPS to Azure onlyWinRM, from a host that reaches the nodes' management subnet (TCP 5985), signed in with the local administrator from Key Vault
FirstVerify what ZTP did: Provisioned, Arc Connected, the management address result for its mode, BIOS restoredPrepare the node: computer name, static management address by MAC, WinRM, RDP and ICMP; register it with Arc
Management addressMode A: verified. Modes B and C: set by MAC (the OS install reset it)Set by MAC
Then, only where the node differs from the fileDHCP and extra gateways off, unused ports disabled, OEM drivers and SBE, DNS, time, local administrator, MPIO and SAN checks, optional storage wipeThe same
Arc machineExists, named <device-id>-1; the run finds it from the handoffCreated by the registration step

Method detection​

At the start of the automated run, each node's method is declared in the master file and checked against evidence. Nothing is guessed from the file alone.

DeclaredEvidence the run looks for
scenario.os_install: simplifiedthe ZTP handoff file is present and lists the node; the node's Arc machine exists and is Connected; the node answers
scenario.os_install: isono Arc machine for the node yet; the node answers on its management address over WinRM
  • They agree: the node takes its path.
  • They disagree (for example the file says iso but the Arc machine is already Connected): the run reports the mismatch for that node, with what it found, and does not carry on for it. Correct scenario.os_install or the node's state, then run again.
Check the shipped behaviour

Method detection is part of the wrapper in the azurelocal-toolkit. The wording above follows its design. If the shipped wrapper words a rule differently, the wrapper's Get-Help is the reference.

Which method did I use?​

If you are not sure how the machines in front of you were installed, check these in order:

QuestionSimplified (ZTP)Simplified (portal)ISO
Did you run Invoke-ZtpEnvironment.ps1?YesNoNo
Is there a <run>.ztp-handoff.json in the ztp-state folder under the media folder?YesNoNo
In the Azure portal, under Azure Arc > Operations > Provisioning (preview) > Provisioned machines, is the machine listed as Ready to cluster?YesYesNo
Is the Arc machine named <device-id>-1 and Connected?YesYesNo Arc machine until Phase 04
Did anyone use the install wizard at the BMC console?NoNoYes
Does the computer name look like WIN-... until you set it?No: provisioning set itNoYes

Still unsure: run the plan. It changes nothing, and for every node it prints the method it detected and the evidence behind it. Then set scenario.os_install to match.

A portal-provisioned machine has no handoff file

That is fine. Set scenario.os_install: simplified, give each node's arc_machine_name (the <device-id>-1 name from the portal), and leave the handoff out. The run finds the Arc machine by name in azure.resource_group.

After OS configuration​

When every node matches the file, the run ends with a report and a zero exit code. Then:

  1. Prepare Active Directory (or choose local identity) and confirm the Azure resource providers are registered.
  2. Phase 05: ARM Validate, which reads the OS configuration report for the adapter names by MAC and the SAN disks. Validate never deploys.
  3. Phase 05: ARM Deploy, a separate run that needs a successful Validate.

On the ISO route, if you registered the nodes by hand, continue with Phase 04: Arc registration first. The simplified route skips Phase 04.

← Phase 03: OS Configuration↑ Part 4: Cluster DeploymentAutomated OS configuration →

References​

VersionDateAuthorChanges
1.02026-11-07Azure Local CloudInitial release