Microsoft Azure: AI assistant (LLM)

If you are deploying with an AI coding assistant (Claude, Codex, and similar), copy the prompt below and paste it into your assistant. It drives the same az CLI flow as the CLI (az) guide, but written for the assistant to follow step by step, pausing for your confirmation and for the values only you can supply.

Before you paste

Give the assistant a session that already has the Azure CLI (az) logged in (an agentic tool with shell access, or paste the commands it returns into your own terminal), with azcopy installed. Have your engagement lead's values ready: the VHD read SAS URL (the shared image reference), a target resource group and region, your VNet/subnet (the full subnet resource ID), an admin username you choose (azureuser works), and your SSH public key. The assistant will ask for anything it is missing.

Deployment prompt

You are helping me deploy the Sophos Remote Testing Appliance (RTA) as a virtual
machine in my Microsoft Azure subscription, using the Azure CLI (az). Work through
the steps below in order. Before any command that changes state, tell me what it
will do and wait for my confirmation.

CONTEXT:
- The appliance is a prebuilt image my engagement lead shared with me as a
  time-limited, read-only SAS URL. It is a Gen2 / UEFI Linux VHD with no engagement
  identity baked in, so on first boot it shows an "Appliance Registration" screen
  with a one-time activation code that I send back to Sophos. There is no software
  to install and no inbound access.

WHAT I WILL PROVIDE (ask me for any you do not have; never guess these):
- <SAS_URL>: the VHD read SAS URL my engagement lead sent (quote it). It is
  time-limited; if it has expired I will request a fresh one.
- <RESOURCE_GROUP>: the resource group to create or use for these resources.
- <LOCATION>: the Azure region for the resources (for example eastus). Use the same
  region as my subnet's VNet.
- <SUBNET_ID>: the FULL subnet resource ID (starts /subscriptions/...). Get it with:
  az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query id -o tsv
- <SSH_KEY_PATH>: the path to my SSH PUBLIC key (for example ~/.ssh/id_rsa.pub).
- <ADMIN_USERNAME> (optional): an admin username I choose. Azure requires one, but it
  is arbitrary and only for break-glass SSH. If I do not give one, use azureuser.

STEPS:
1. Confirm the CLI is logged in to the right subscription:
   az account show --query '[name,id]' --output tsv
   If this errors, stop and tell me to run "az login".

2. Create the resource group (skip if <RESOURCE_GROUP> already exists):
   az group create -n <RESOURCE_GROUP> -l <LOCATION>

3. Create an empty Gen2 "upload" disk sized to the exact VHD byte length. The disk
   MUST be Gen2 (--hyper-v-generation V2); a Gen1 disk boots to a black screen. Do
   NOT enable Trusted Launch / Secure Boot; leave the security type default.
   az disk create -g <RESOURCE_GROUP> -n rta-disk -l <LOCATION> \
     --os-type Linux --hyper-v-generation V2 \
     --upload-type Upload --upload-size-bytes 42949673472 --sku Standard_LRS
   The value 42949673472 is the exact byte length of the 40 GiB VHD and must be used
   verbatim; an upload disk created at the wrong size makes the copy fail.

4. Get a temporary WRITE SAS for the disk (grep pulls the URL out of the JSON, which
   avoids the accessSAS/accessSas field-name difference between az versions):
   DISK_SAS=$(az disk grant-access -g <RESOURCE_GROUP> -n rta-disk \
     --access-level Write --duration-in-seconds 86400 -o json | grep -o 'https[^"]*')

5. Server-side copy our VHD straight into the disk (minutes, not a full download):
   azcopy copy "<SAS_URL>" "$DISK_SAS" --blob-type PageBlob

6. Revoke the disk write SAS:
   az disk revoke-access -g <RESOURCE_GROUP> -n rta-disk

7. Create a generalized Gen2 managed image from the disk:
   az image create -g <RESOURCE_GROUP> -n rta-image --os-type linux --hyper-v-generation V2 \
     --source "$(az disk show -g <RESOURCE_GROUP> -n rta-disk --query id -o tsv)"

8. Create the VM. Standard_D2s_v3 is the recommended size (Gen2-capable). Supply MY
   public key. No public IP and no network security group; the appliance only needs
   outbound access. Pass the FULL subnet ID with --subnet and do NOT also pass
   --vnet-name.
   az vm create -g <RESOURCE_GROUP> -n Sophos-RTA \
     --image "$(az image show -g <RESOURCE_GROUP> -n rta-image --query id -o tsv)" \
     --size Standard_D2s_v3 \
     --admin-username <ADMIN_USERNAME> \
     --ssh-key-values <SSH_KEY_PATH> \
     --subnet <SUBNET_ID> \
     --public-ip-address "" --nsg ""

VERIFY:
9. Confirm the VM is running with a private IP and no public IP:
   az vm show -g <RESOURCE_GROUP> -n Sophos-RTA -d \
     --query '[powerState, privateIps, publicIps]' --output tsv
   Expect "VM running", a private IP populated, and an empty public IP.

10. A minute or two after the VM starts, read the one-time activation code off the
    console. Azure renders the "Appliance Registration" screen on the boot-diagnostics
    screenshot: open the VM in the portal and use Help > Boot diagnostics > Screenshot
    (or Serial console), or from the CLI read the serial log with:
    az vm boot-diagnostics get-boot-log -g <RESOURCE_GROUP> -n Sophos-RTA
    The screen shows a short code (for example "4 5 D C V Y"). Read that code back to
    me exactly. Do NOT send it anywhere yourself: I give it to my Sophos engagement
    lead, who activates the appliance. After activation the console switches to a live
    status dashboard. (Azure downscales the screenshot, so the text can look blurry;
    that is cosmetic.)

RULES YOU MUST FOLLOW:
- These steps are authoritative. If a command fails, returns something unexpected,
  or reality does not match what is written here, STOP and show me the exact output.
  Do not improvise, invent flags, or try alternative commands on your own.
- The appliance needs exactly ONE connection: an outbound tunnel on TCP/443 to
  connect.remotetesting.secureworks.com. Never open, forward, or allow any INBOUND
  port to it. If connectivity fails, the problem is on the outbound path, never a
  missing inbound rule.
- Never enable Secure Boot and never change the firmware or boot type away from what
  these steps specify (UEFI / Generation 2). The appliance will not boot otherwise.
- Do not SSH into, log in to, or reconfigure the appliance. Once it boots it
  provisions itself; there is nothing to set up inside it.
- Every value in angle brackets (<LIKE_THIS>) must come from me. Never guess, invent,
  or reuse one. Ask me for any you do not have before running the step that needs it.
- Do not weaken security to force the connection (do not disable TLS inspection, and
  do not turn off a firewall). If something is blocked, tell me what and let me decide.
- Do only what these steps describe: deploy this one appliance. Do not create extra
  resources, install extra software, or take any action beyond that.

Network access

The appliance makes one connection to do its job: an outbound tunnel to the Sophos headend. Nothing inbound is ever required: you never open or forward any ports to the appliance.

Allow this outbound destination

Destination	connect.remotetesting.secureworks.com
IP addresses	3.33.194.251 and 15.197.255.2 (static; these do not change)
Port / protocol	TCP 443, carrying OpenVPN (not HTTPS)
Direction	Outbound only

Allow egress on TCP/443 to that destination from the appliance's network. On a next-generation firewall or NAC-controlled network, an L3 "allow 443" rule is often not enough: Layer-7 application control, TLS/SSL decryption, or NAC can still drop the tunnel even when the port is open. See Connectivity troubleshooting for the exact firewall and NAC exceptions to request.

Troubleshooting

Deployed but something isn't right?

See this platform's troubleshooting guide for the most common issues here and how to fix them.