AzureStack.NYC · Live Deployment Console
● connecting…
livedeployment.azurestack.nyc

An Empire State of deployment.

Six stages, watched live — from collecting parameters to a running cluster and day-2 workloads. Status auto-refreshes from the deployer.

Data center infrastructure · one-stop control center
Loading inventory…

Every cluster, server, hypervisor and core across the estate — to see and control resources. Gated; shows real iDRAC IPs for operations.

Azure Local clusters
Servers & hypervisors
Infrastructure services · AD DS · DHCP · Hyper-V · Azure Local
  • Run recover.sh services-inventory on a host with line-of-sight to populate AD DS / DHCP / Hyper-V / cluster service health.
IP map · /24 purpose & heartbeat
Run recover.sh ip-inventory from a host on the subnet…
Recycle & maintain · stale VMs / hosts
  • Run recover.sh lifecycle to surface expired / disconnected / unused machines.
Stage 0 · scan the environment

What the scan does

Enter read-only credentials for your Azure subscription / Entra ID, Active Directory, and the node iDRACs. The scan probes each target the same way an engineer would — Azure resources & RP registration, the AD OU + LCM account, and iDRAC inventory — then recommends Greenfield, Brownfield, or Redeploy, and pre-fills the Settings tab.

🔒 Credentials are processed in your browser only and embedded into a command you run on the deployer host. They are never sent to this site and never published. Only a redacted result (no IPs, no secrets, no hostnames) appears below.

Azure & Entra ID

Active Directory

iDRAC (per node)

Scan result & recommendation
awaiting scan
  • Run the scan on the deployer (it publishes a redacted scan.json here) to see findings and a Greenfield / Brownfield / Redeploy recommendation.
Hardware inventory · all nodes · Microsoft requirements
hardware check awaiting scan

Run recover.sh hw-validate --publish on the deployer — it inventories every node (CPU · RAM · SSD · HDD · NICs · TPM · SecureBoot · UEFI · virtualization · SR-IOV) and marks ✓ / ✗ against Microsoft's Azure Local requirements + cross-node symmetry. Runs before firmware in the workflow.

Checks — ✓ pass · ✗ fail · ⚠ warning
  • Awaiting hardware validation…
Stage 1 · collect deployment settings

Cluster & Azure

Active Directory

Nodes

Network & Time

Witness · Key Vault · AKS / GPU

Stage 2 · node preparation — firmware · drivers · time
Awaiting node-prep status…

Per node: iDRAC reachability, NIC / Mellanox / iDRAC firmware (vs baseline), vendor drivers (Broadcom/Mellanox/chipset), time sync, single mgmt IP. Self-healing: recover.sh fw-flash-nic · ref-drivers · stage-drivers · net-enforce.

Stage 3 · Azure Arc registration & extensions
Awaiting Arc status…

Per node: Arc connected state + the 4 mandatory AzureEdge extensions at the deployment's required versions (a moving target — discovered, not hardcoded). recover.sh arc-onboard · ext-sync · deploy-perms.

Stage 4 · validate the system
state
  • Awaiting validation…
Stage 5 · cloud deployment (~2.5–3 h)
state
  • Deployment starts after validation passes.
Stage 6 · day-2 — workloads & operations

AKS-Arc

cluster
statepending deploy
GPU (T4 DDA)

Arc VMs / AVD

Provision Arc VMs & Azure Virtual Desktop session hosts on the custom location once the cluster is live.

Workload mobility

Replicate-then-cut-over moves between this cluster and Azure (and back). Tracked here per job.

Day-2 surfaces once Stage 5 completes: AKS workloads, Arc VM / AVD provisioning, and cross-environment workload migrations.

End-to-end · every little thing, tracked live
build progress
Run recover.sh preflight --publish on the deployer to populate the end-to-end checklist — every step of the build workflow (iDRAC → firmware → drivers → network → time → AD/DNS/KV → Arc → extensions → RBAC → validate → deploy → day-2). The autopilot keeps it live.

This mirrors the deployer's workflow (deploy-autopilot.sh phases) at the finest grain — each item shows pass / running / to-do / fail as the build advances.