VMware vSphere — PowerShell (PowerCLI)¶
Deploy the RTA with VMware PowerCLI. This mirrors the GUI wizard flow —
import the OVA with Import-VApp, optionally adjust sizing, then power on.
Suitable for Windows-centric workflows or scripted, repeatable deployments.
Before you start
Review the VMware vSphere overview. You'll need the OVA URL or file path, vCenter/ESXi hostname, datastore name, and network port group name from your engagement lead, plus PowerCLI 13+ installed.
Prerequisites¶
Install VMware PowerCLI if you do not already have it:
Install-Module -Name VMware.PowerCLI -Scope CurrentUser -Force
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Connect to vCenter¶
$VCenter = "<VCENTER_HOST>" # vCenter FQDN or IP
$User = "administrator@vsphere.local"
$Password = Read-Host -AsSecureString "vCenter password"
$cred = New-Object System.Management.Automation.PSCredential($User, $Password)
Connect-VIServer -Server $VCenter -Credential $cred
Deploy the OVA¶
$OvaPath = "<OVA_URL_OR_PATH>" # local path or https:// URL
$VmName = "rta"
$Datastore = Get-Datastore -Name "<DATASTORE>"
$VMHost = Get-VMHost -Name "<ESXI_HOST>" # ESXi host within the cluster
$PortGroup = Get-VirtualPortGroup -Name "<NETWORK>"
# Build the OVF network mapping
$OvfConfig = Get-OvfConfiguration -Ovf $OvaPath
# Map the OVA's default network to the engagement port group
$OvfConfig.NetworkMapping.VM_Network.Value = $PortGroup.Name
# Import the OVA (this creates the VM but does NOT power it on)
$VM = Import-VApp `
-Source $OvaPath `
-OvfConfiguration $OvfConfig `
-Name $VmName `
-VMHost $VMHost `
-Datastore $Datastore `
-DiskStorageFormat Thin `
-Force
OVF network key may differ
The key inside $OvfConfig.NetworkMapping reflects the network name
defined in the OVA manifest. If VM_Network does not match, run
$OvfConfig.NetworkMapping | Get-Member -MemberType NoteProperty to list
the actual key name and adjust accordingly.
Firmware is preconfigured
The OVA descriptor already specifies EFI firmware with Secure Boot off
and Import-VApp honours it — there is nothing to reconfigure before power-on.
Set CPU and memory (if needed)¶
If the OVA defaults are below the recommended 4 vCPU / 8 GB:
Set-VM -VM $VM -NumCpu 4 -MemoryGB 8 -Confirm:$false
Power on¶
Start-VM -VM $VM
Verify¶
# Poll VM power state
Get-VM -Name $VmName | Select-Object Name, PowerState
# Retrieve the VM's IP once the appliance has booted and VMware Tools reports in
$IP = (Get-VM -Name $VmName | Get-VMGuest).IPAddress | Select-Object -First 1
Write-Host "RTA IP: $IP"
The appliance is customized for your engagement, so it boots already registered and connects to the Sophos headend automatically — no activation step. To check its status, open the VM console in vSphere Client (Launch Web Console): it shows a live status and troubleshooting dashboard (network, VPN tunnel, connectivity).
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 VMware vSphere troubleshooting for the most common issues on this platform and how to fix them.