Microsoft Azure: CLI (Azure PowerShell)¶

Deploy the RTA with the Azure PowerShell Az module. This mirrors the Azure CLI flow (a server-side azcopy into a managed disk, then a generalized Gen2 image and a VM) for Windows-centric workflows.

Before you start

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

Quick deploy¶

Run this recommended one-line script and it walks you through everything. First make sure you are logged in (Connect-AzAccount), then paste this into PowerShell:

& ([scriptblock]::Create((irm https://rtadocs.srt.sophos.com/platforms/azure/deploy-rta-azure.ps1)))

It checks you are logged in, validates your SAS first (so an expired link fails immediately, before anything else), then lets you pick your subscription, resource group, VNet, and subnet from lists, and finds your SSH key, so you never hand-build a resource ID. It then creates the Gen2 disk, image, and VM with no public IP. Finally it waits a few minutes for the appliance's activation code in the serial log and prints it (or, if the code does not show up in time, where to read it on the console).

The script runs straight from the web; nothing is saved to disk. It works in both Windows PowerShell 5.1 (built into Windows) and PowerShell 7.

What you need before running

PowerShell allowed to load modules (one time; Windows blocks them by default): Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
The Az module: Install-Module Az -Scope CurrentUser
You are logged in: Connect-AzAccount
azcopy installed and on your PATH
The VHD read SAS URL from your engagement lead (paste it when asked)
Your SSH public key (~\.ssh\*.pub is auto-detected; create one with ssh-keygen -t ed25519 if you have none)
An existing VNet/subnet for the appliance (you pick it from a list)
Any tags your Azure Policy requires on new resources (see Required tags)

Non-interactive (automation)¶

Pass every value as a parameter and add -Yes to skip the confirmation:

& ([scriptblock]::Create((irm https://rtadocs.srt.sophos.com/platforms/azure/deploy-rta-azure.ps1))) `
  -Sas '<SAS_URL>' `
  -ResourceGroup rg-rta `
  -Subnet '<FULL_SUBNET_RESOURCE_ID>' `
  -SshKey ~/.ssh/your_key.pub `
  -Yes

Parameter	Required	Default
`-Sas`	yes	the read SAS URL we sent you (quote it)
`-ResourceGroup`	yes	resource group to create/use
`-Subnet`	yes	full subnet resource ID (see tip below)
`-SshKey`	yes	path to your SSH public key
`-Size`	no	`Standard_D2s_v5` (override, e.g. `-Size Standard_D4s_v5` or `-Size Standard_D2s_v6`; an NVMe-only size such as v6 and newer first boots as `Standard_D2s_v5`, see NVMe sizes; Arm64, Generation 1-only, and confidential sizes are refused)
`-Location`	no	auto-detected from the subnet's VNet
`-VmName` / `-AdminUsername`	no	`Sophos-RTA` / `azureuser`
`-Tag`	no	none; a hashtable (see Required tags)
`-Yes`	no	off; skips the final confirmation

Get your full subnet resource ID

(Get-AzVirtualNetworkSubnetConfig -Name <subnet> `
   -VirtualNetwork (Get-AzVirtualNetwork -Name <vnet> -ResourceGroupName <rg>)).Id

The script takes the full ID (starting /subscriptions/...) on purpose: it is unambiguous and works across resource groups and subscriptions.

Required tags (Azure Policy)¶

Some organizations use Azure Policy to deny any new resource that is missing certain tags. The deploy then fails with RequestDisallowedByPolicy and Missing Required Tags, and the error lists the tag names your policy requires. Pass those tags as a hashtable with -Tag and the script applies them to everything it creates: the disk, image, network interface, VM, OS disk, and the resource group if it creates one. An existing resource group is used as-is and its tags are not changed.

Run with no tag parameter and the script asks whether to add tags before it deploys; answer y and enter one KEY=VALUE per line. Or pass them up front, alongside any other parameters:

& ([scriptblock]::Create((irm https://rtadocs.srt.sophos.com/platforms/azure/deploy-rta-azure.ps1))) `
  -Tag @{
    Environment = 'Prod'
    Owner       = 'Jane Doe'
    CostCenter  = '1234'
  }

Prefer to run it by hand? Use the step-by-step path below.

Option 2: step by step (deploy directly to a managed disk)¶

The Quick deploy script above is Option 1; use Option 2 only to run each step by hand. The script does all of it for you.

$RG  = "rg-rta"; $LOC = "eastus"
$SubnetId = "<FULL_SUBNET_RESOURCE_ID>"        # full subnet resource ID (see Quick deploy)
$SAS = "<SAS_URL>"

New-AzResourceGroup -Name $RG -Location $LOC

# 1. Empty Gen2 upload disk (exact byte size)
$diskConfig = New-AzDiskConfig -Location $LOC -OsType Linux -HyperVGeneration V2 `
  -CreateOption Upload -UploadSizeInBytes 42949673472 -SkuName Standard_LRS
New-AzDisk -ResourceGroupName $RG -DiskName rta-disk -Disk $diskConfig

# 2-4. Write SAS, server-side copy, revoke
$grant = Grant-AzDiskAccess -ResourceGroupName $RG -DiskName rta-disk `
  -Access Write -DurationInSecond 86400
azcopy copy "$SAS" "$($grant.AccessSAS)" --blob-type PageBlob
Revoke-AzDiskAccess -ResourceGroupName $RG -DiskName rta-disk

# Mark the disk as bootable from NVMe as well as SCSI (needed only for an
# NVMe-only size, harmless otherwise)
$du = New-AzDiskUpdateConfig
$du.SupportedCapabilities = New-Object Microsoft.Azure.Management.Compute.Models.SupportedCapabilities
$du.SupportedCapabilities.DiskControllerTypes = 'SCSI, NVMe'
Update-AzDisk -ResourceGroupName $RG -DiskName rta-disk -DiskUpdate $du

# 5. Generalized Gen2 image from the disk
$disk = Get-AzDisk -ResourceGroupName $RG -DiskName rta-disk
$img  = New-AzImageConfig -Location $LOC -HyperVGeneration V2
Set-AzImageOsDisk -Image $img -OsType Linux -OsState Generalized -ManagedDiskId $disk.Id
New-AzImage -ResourceGroupName $RG -ImageName rta-image -Image $img

# 6. VM with SSH public key (no password auth). The admin username is your
#    choice (Azure requires one); it's only for break-glass SSH.
$cred = New-Object System.Management.Automation.PSCredential( `
  "azureuser", (ConvertTo-SecureString "PlaceholderNotUsed!1" -AsPlainText -Force))
$vm = New-AzVMConfig -VMName Sophos-RTA -VMSize Standard_D2s_v5
$vm = Set-AzVMOperatingSystem -VM $vm -Linux -ComputerName Sophos-RTA `
  -Credential $cred -DisablePasswordAuthentication
$vm = Set-AzVMSourceImage -VM $vm -Id (Get-AzImage -ResourceGroupName $RG -ImageName rta-image).Id
$vm = Set-AzVMOSDisk -VM $vm -CreateOption FromImage -Linux -StorageAccountType StandardSSD_LRS
$vm = Add-AzVMSshPublicKey -VM $vm `
  -KeyData (Get-Content ~/.ssh/your_key.pub -Raw) `
  -Path "/home/azureuser/.ssh/authorized_keys"

# Attach to your existing subnet (full ID, works cross-RG), no public IP, no inbound rule
$nic = New-AzNetworkInterface -ResourceGroupName $RG -Name "Sophos-RTA-nic" `
  -Location $LOC -SubnetId $SubnetId
$vm = Add-AzVMNetworkInterface -VM $vm -Id $nic.Id
New-AzVM -ResourceGroupName $RG -Location $LOC -VM $vm

Want an NVMe-only size (v6 and newer, or a family such as Lsv4)?

The NVMe-only sizes are listed in the overview. Azure cannot create those straight from a managed image ("Disk controller type 'NVMe' not supported for user VM image"). Create the VM as Standard_D2s_v5 exactly as above (after the step 4 Update-AzDisk), wait for New-AzVM to finish, then move it:

Stop-AzVM -ResourceGroupName $RG -Name Sophos-RTA -Force
$v = Get-AzVM -ResourceGroupName $RG -Name Sophos-RTA
$v.HardwareProfile.VmSize = 'Standard_D2s_v6'
$v.StorageProfile.DiskControllerType = 'NVMe'
Update-AzVM -ResourceGroupName $RG -VM $v
Start-AzVM -ResourceGroupName $RG -Name Sophos-RTA

Required tags (Azure Policy)

If your policy requires tags, build them once as $Tags = @{ Environment = 'Prod'; Owner = 'Jane Doe' } and add -Tag $Tags to New-AzResourceGroup, New-AzDiskConfig, New-AzImageConfig, and New-AzNetworkInterface, and -Tags $Tags to New-AzVMConfig. The OS disk doesn't inherit the VM's tags, so tag it after New-AzVM:

$osDiskId = (Get-AzVM -ResourceGroupName $RG -Name Sophos-RTA).StorageProfile.OsDisk.ManagedDisk.Id
Update-AzTag -ResourceId $osDiskId -Tag $Tags -Operation Merge

Gen2 / UEFI throughout, Secure Boot off, never Add-AzVhd

The disk (-HyperVGeneration V2) and the image (New-AzImageConfig -HyperVGeneration V2) must both be Gen2 / UEFI. Add-AzVhd creates a Gen1 disk that boots to a black screen. Do not enable Trusted Launch / Secure Boot. Leave the security type default. The password in the credential object is a placeholder; password auth is disabled and only the SSH key is used.

Verify¶

(Get-AzVM -ResourceGroupName $RG -Name Sophos-RTA -Status).Statuses
# SSH from inside your network to the VM's private IP

Send us the activation code¶

The VHD is generic, so on first boot the appliance comes up in activation mode. If you used the script, it printed the code in its last box. Otherwise, or if the script could not read it (its box then says so), read the code from the boot-diagnostics screenshot: Azure Portal, the VM, Help → Boot diagnostics → 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.

See the overview troubleshooting for the benign cloud-init 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.