Skip to content

Microsoft Azure: GUI (Azure Portal)

Deploy the RTA from the Azure Portal. The portal can't pull a VHD across tenants, so you first copy our published VHD into your own storage account with one azcopy command, then build the disk, image, and VM with point-and-click.

Before you start

Review the Microsoft Azure overview. You'll need the VHD read SAS URL from your engagement lead, azcopy, an existing storage account with a container to copy into, and your SSH public key.

Quick deploy

Experienced operators can work straight from this outline; the detailed walkthrough follows below.

  1. Copy rta-generic-latest.vhd into a container in your own storage account with the single server-side azcopy line below.
  2. Disks → Create: source Storage blob (the copied VHD), OS Linux, VM generation Gen2 (Gen1 boots to a black screen), security type Standard.
  3. Open the disk → Create image (Linux, Gen2).
  4. Open the image → Create VM: size e.g. Standard_D2s_v5 (v5 or older, but not the NVMe-only families such as Lsv4; not Arm64 p, Generation 1-only, or confidential sizes), SSH public key, any username; Disks = OS disk type Standard SSD; Networking = your VNet/subnet, Public IP None, no inbound rules.
  5. Boot diagnostics → Screenshot to read the one-time activation code, then send it to your engagement lead.

1. Copy the VHD into your storage account

The link we send is a single-blob SAS, so it cannot be attached as a container in Azure Storage Explorer. Copy it server-side instead; the bytes never leave Azure and the copy takes minutes, not a 40 GB download.

  1. In the portal, open your storage account → Containers → your container → Shared access tokens. Grant Write and Create permissions, set an expiry of a few hours, and Generate SAS token and URL. Copy the Blob SAS URL field (it ends in ?sv=...).

  2. Run the copy, pasting our read SAS as the source and your container SAS as the destination. The destination needs the blob name inserted before the ?:

    azcopy copy '<OUR_VHD_READ_SAS_URL>' \
  'https://<youracct>.blob.core.windows.net/<container>/rta-generic-latest.vhd?<your-write-sas>' \
  --blob-type PageBlob

  3. Confirm rta-generic-latest.vhd (~40 GB) now shows in your container.

Prefer no storage account at all?

The CLI (az) page copies straight into a managed disk, so you never need a storage account of your own.

2. Create the disk

  1. Disks → Create.
  2. Source type: Storage blob → Browse to the VHD you just copied.
  3. OS type: Linux.
  4. VM generation: Gen2. (This is the step people miss; Gen1 boots to a black screen.)
  5. Security type: Standard → Create.

3. Create an image from the disk

  1. Open the disk you just created → Create image.
  2. OS type: Linux, VM generation: Gen2 → Create.

4. Create the VM

  1. Open the image → Create VM.
  2. Size: e.g. Standard_D2s_v5 (Gen2-capable, 2 vCPU / 8 GB). Pick a v5 or older size outside the NVMe-only families: v6 and newer sizes (e.g. Standard_D2s_v6) and a few older families such as Lsv4 (full list in the overview) use NVMe disks only, and the portal cannot create one from this image (use the CLI or PowerShell guide for those). Not supported at all: Arm64 sizes (e.g. Standard_D2ps_v5; the image is x86_64), Generation 1-only sizes (e.g. Standard_D2_v3), and confidential sizes (e.g. Standard_DC2as_v5).
  3. Authentication type: SSH public key; Username: any value you choose (e.g. azureuser, Azure requires one; it's only for break-glass SSH); paste your public key.
  4. On the Disks tab: set OS disk type to Standard SSD (it works on every VM size).
  5. On the Networking tab: pick your existing VNet/subnet, set Public IP = None, and add no inbound rules: the appliance only needs outbound access.
  6. Review + create.

Verify

The VM has a private IP only. Confirm it shows as Running in the portal.

Send us the activation code

The VHD is generic, so the appliance comes up in activation mode on first boot. Read the code from the console: open the VM in the portal and use Help → Boot diagnostics → Screenshot (or Serial console).

You can also copy it as text from the Serial log tab on the same page: find the last line containing RTA-ACTIVATION-CODE; the code is the word right after it (the same code the screenshot shows, without the spaces). activated there means there is nothing to send; none, or an expires= time in the past, means that code is no longer valid (a new appliance can also show none if its first registration attempt failed); wait a minute and look again. If there is no usable line, your image predates this feature or the log has not caught up yet; use the Screenshot.

The console shows the Appliance Registration screen: a one-time activation code (for example 4 5 D C V Y) under the prompt "Provide this code to your Sophos staging team." You do not log in to the appliance to read it.

Send that activation code to your Sophos engagement lead so they can activate the appliance on the Sophos side. Once activated, the console switches from the registration screen to the appliance's live status dashboard, and no further action is needed on your end.

Registration needs outbound 443 to get.remotetesting.secureworks.com

Registration and activation use outbound TCP/443 (HTTPS) to get.remotetesting.secureworks.com, in addition to the OpenVPN tunnel to connect.remotetesting.secureworks.com covered under Network access below. Its IP addresses are not guaranteed to stay constant, so allowlist get.* by FQDN (not by IP). If that egress is blocked, the console shows a registration error ("ensure outbound HTTPS to get.remotetesting.secureworks.com") instead of an activation code.

The boot-diagnostics screenshot is plain text

The appliance renders the Appliance Registration screen as text on the boot-diagnostics screenshot. 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 this platform's troubleshooting guide for the most common issues here and how to fix them.