Hyper-V Server: AI assistant (LLM)¶
If you are deploying with an AI coding assistant (Claude, Codex, and similar), copy the prompt below and paste it into your assistant. It drives the same Generation 2 build as the GUI (Hyper-V Manager) guide, using PowerShell on the Hyper-V Server host (or guiding you through Hyper-V Manager), written for the assistant to follow step by step, pausing for your confirmation and for the values only you can supply.
Before you paste
Give the assistant a session that can run PowerShell on the Hyper-V Server
host with Administrator rights (an agentic tool with shell access, or paste
the commands it returns into an elevated PowerShell). Have ready: both
extracted VHDX disks (the appliance OS/root disk and the small cidata
seed disk), the name of an existing external virtual switch bound to a
wired NIC, and a name for the VM. The assistant will ask for anything it
is missing.
Deployment prompt¶
You are helping me deploy the Sophos Remote Testing Appliance (RTA) as a
Generation 2 virtual machine on a Windows Server Hyper-V host, using PowerShell
(or by guiding me through Hyper-V Manager). Work through the steps below in order.
Before any command that changes state, tell me what it will do and wait for my
confirmation.
CONTEXT:
- The appliance ships as TWO VHDX disks my engagement lead sent me in a zip: an
OS/root disk and a small "cidata" seed disk. The disks are customized for my
engagement before I receive them, so once both are attached the appliance boots
already registered and connects to Sophos on its own. There is no code to read
or send back and no inbound access.
- It MUST run as a Generation 2 VM with Secure Boot DISABLED (the bootloader is
unsigned), and BOTH disks must be attached, or it will not boot correctly.
WHAT I WILL PROVIDE (ask me for any you do not have; never guess these):
- <OS_VHDX>: full path to the appliance OS/root disk (for example C:\RTA\rta_latest.vhdx).
- <CIDATA_VHDX>: full path to the cidata seed disk (for example C:\RTA\cidata.vhdx).
- <SWITCH_NAME>: the name of an existing External virtual switch bound to a wired NIC.
- <VM_NAME>: the name to give the VM (for example Sophos-RTA).
STEPS:
1. Confirm both disks exist and the external switch is present and External:
Test-Path <OS_VHDX>
Test-Path <CIDATA_VHDX>
Get-VMSwitch -Name <SWITCH_NAME> | Select-Object Name,SwitchType
Expect both paths True and SwitchType "External". If a path is False, stop and
ask me for the right path. If the switch is missing or is Internal/Private,
stop and tell me: the appliance needs an External switch on a wired NIC to
reach the headend and its targets.
2. Create the Generation 2 VM, attach the OS disk as the boot disk, connect the
switch, and set 8 GB of startup memory:
New-VM -Name <VM_NAME> -Generation 2 -MemoryStartupBytes 8GB \
-VHDPath <OS_VHDX> -SwitchName <SWITCH_NAME>
Generation 2 is required (the disk is GPT with an EFI System Partition); a
Generation 1 VM will not boot it.
3. Attach the cidata seed disk as a second SCSI disk:
Add-VMHardDiskDrive -VMName <VM_NAME> -Path <CIDATA_VHDX>
Both disks must be attached. Without the cidata disk the appliance has no
engagement identity and will not register.
4. Set the processor count to 4 (minimum 2):
Set-VMProcessor -VMName <VM_NAME> -Count 4
5. DISABLE Secure Boot (do not enable it):
Set-VMFirmware -VMName <VM_NAME> -EnableSecureBoot Off
The bootloader is unsigned; with Secure Boot on the firmware refuses to run it
and the VM shows a black screen. Never turn Secure Boot on.
6. Enable MAC address spoofing (required for the appliance's Layer-2 tooling):
Set-VMNetworkAdapter -VMName <VM_NAME> -MacAddressSpoofing On
7. Start the VM:
Start-VM -Name <VM_NAME>
Then open the console: double-click the VM in Hyper-V Manager, or run
vmconnect.exe localhost <VM_NAME>.
VERIFY:
8. Confirm the configuration is correct:
Get-VMFirmware -VMName <VM_NAME> | Select-Object SecureBoot
(Get-VMNetworkAdapter -VMName <VM_NAME>).MacAddressSpoofing
Get-VMHardDiskDrive -VMName <VM_NAME> | Select-Object Path
Expect SecureBoot "Off", MacAddressSpoofing "On", and TWO disk paths (the OS
disk and the cidata disk). If Secure Boot is On or only one disk is listed,
stop: the VM will not boot correctly.
9. Open the VM console. Because the image is customized for my engagement, it boots
already registered: the console shows a live status and troubleshooting
dashboard, and the outbound tunnel comes up on its own. There is nothing for me
to type in and no code to send back. If the console is black, Secure Boot is
probably still on or the cidata disk is not attached.
RULES YOU MUST FOLLOW:
- These steps are authoritative. If a command fails, returns something unexpected,
or reality does not match what is written here, STOP and show me the exact output.
Do not improvise, invent flags, or try alternative commands on your own.
- The appliance needs exactly ONE connection: an outbound tunnel on TCP/443 to
connect.remotetesting.secureworks.com. Never open, forward, or allow any INBOUND
port to it. If connectivity fails, the problem is on the outbound path, never a
missing inbound rule.
- Never enable Secure Boot and never change the firmware or boot type away from what
these steps specify (UEFI / Generation 2). The appliance will not boot otherwise.
- Do not SSH into, log in to, or reconfigure the appliance. Once it boots it
provisions itself; there is nothing to set up inside it.
- Every value in angle brackets (<LIKE_THIS>) must come from me. Never guess, invent,
or reuse one. Ask me for any you do not have before running the step that needs it.
- Do not weaken security to force the connection (do not disable TLS inspection, and
do not turn off a firewall). If something is blocked, tell me what and let me decide.
- Do only what these steps describe: deploy this one appliance. Do not create extra
resources, install extra software, or take any action beyond that.
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.