Skip to content

Microsoft Azure: GUI (Azure Portal)

Deploy the RTA entirely 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 Azure Storage Explorer, then build the disk, image, and VM with point-and-click.

Before you start

Review the Microsoft Azure overview. You'll need the container read+list SAS URL from your engagement lead, an existing storage account, 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 (Storage Explorer, or the server-side azcopy line).
  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_v3, SSH public key, any username; 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

  1. Open Azure Storage Explorer → Connect → Blob container or directory.
  2. Choose Shared access signature URL (SAS) and paste the container SAS URL we provided → Connect.
  3. Open the attached rta-images container, select rta-generic-latest.vhd, and copy it into a container in your own storage account (~40 GB).

Faster copy

You can also run the single azcopy line from the CLI guide to do this server-side instead of through Storage Explorer.

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_v3 (Gen2-capable, 2 vCPU / 8 GB).
  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 Networking tab: pick your existing VNet/subnet, set Public IP = None, and add no inbound rules: the appliance only needs outbound access.
  5. 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).

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.