Microsoft Azure — Azure CLI¶

Deploy the RTA with the az CLI. This is the fastest path: azcopy copies our published VHD server-side straight into a managed disk on Azure's backbone (minutes, not a full download/re-upload), and you never need a storage account of your own.

Before you start

Review the Microsoft Azure overview. You'll need the VHD read SAS URL from your engagement lead, the Azure CLI, azcopy, and your SSH public key.

Method A — direct server-side copy into a managed disk (recommended)¶

Gen2 / UEFI required — Secure Boot off

The disk and the image must be created as Gen2 / UEFI (--hyper-v-generation V2, below). A Gen1 disk boots to a black screen. Do not enable Trusted Launch / Secure Boot — leave the security type default.

RG=rg-rta                 # your resource group
LOC=eastus                # your region
VNET=your-vnet            # existing VNet for the appliance
SUBNET=your-subnet        # subnet in that VNet
SAS='<SAS_URL>'           # the read SAS we provided (quote it)

az group create -n "$RG" -l "$LOC"

# 1. Create an empty Gen2 "upload" disk sized to the exact VHD byte length
az disk create -g "$RG" -n rta-disk -l "$LOC" \
  --os-type Linux --hyper-v-generation V2 \
  --upload-type Upload --upload-size-bytes 42949673472 --sku Standard_LRS

# 2. 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 "$RG" -n rta-disk \
  --access-level Write --duration-in-seconds 86400 -o json | grep -o 'https[^"]*')

# 3. Server-side copy our VHD straight into your disk
azcopy copy "$SAS" "$DISK_SAS" --blob-type PageBlob

# 4. Revoke the disk write SAS
az disk revoke-access -g "$RG" -n rta-disk

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

# 6. Create the VM (admin user 'swag'; supply YOUR public key).
#    No public IP and no inbound rule — the appliance only needs outbound.
az vm create -g "$RG" -n rta-vm \
  --image "$(az image show -g "$RG" -n rta-image --query id -o tsv)" \
  --size Standard_D2s_v3 \
  --admin-username swag \
  --ssh-key-values ~/.ssh/your_key.pub \
  --vnet-name "$VNET" --subnet "$SUBNET" \
  --public-ip-address "" --nsg ""

--upload-size-bytes must be exact

Use 42949673472 (the exact byte length of the 40 GiB VHD). An upload disk must be created at the precise source size or the copy fails.

Don't force a Standard security type

Do not pass --security-type Standard unless the Microsoft.Compute/UseStandardSecurityType feature is registered on the subscription. For a legacy managed image the default is already a non-Trusted-Launch Gen2 VM, which is what you want.

Method B — via your own storage account¶

If you want to keep a copy of the VHD in your own storage account:

# Copy our VHD into your storage account (server-side)
azcopy copy "$SAS" \
  "https://<youracct>.blob.core.windows.net/<container>/rta-generic-latest.vhd?<your-write-sas>"

# Create the image from YOUR blob, then create the VM exactly as in Method A step 6.
az image create -g "$RG" -n rta-image --os-type linux --hyper-v-generation V2 \
  --source "https://<youracct>.blob.core.windows.net/<container>/rta-generic-latest.vhd"

az image create cannot read a SAS URI

--source must be a plain blob URL, so your storage account has to allow the platform to read it (shared-key access enabled — the default). If your account has shared key disabled, use Method A instead.

Verify¶

# The VM lands on your VNet with a private IP only. SSH from inside your network:
az vm show -g "$RG" -n rta-vm -d --query privateIps -o tsv
ssh swag@<private-ip>

The VHD is generic, so on first boot the appliance comes up in activation mode and shows an Appliance Registration screen with a one-time activation code — you normally don't need to log in at all. Read the code from the boot-diagnostics screenshot (az vm boot-diagnostics get-boot-log / portal Screenshot) and give it to your Sophos engagement lead to activate. See the overview troubleshooting for the benign cloud-init status warning.

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 Microsoft Azure troubleshooting for the most common issues on this platform and how to fix them.