CastEdge Appliance — VMware Deployment Guide

Image version: 2026.06.13.1501

Current release: castedge-appliance-2026.06.13.1501.ova — SHA-256 49bac099e5844d3e4e1908aa316a756d91f964a859c95c2a97201e808602d86d

1. What this covers

This guide takes you from the downloaded OVA to a running, cloud-connected CastEdge appliance. Bring-up is staged:

• Stage 1 (this guide): import the OVA, attach the Mediacast-provided configuration file, power on. The appliance binds to the Mediacast control plane and begins reporting in over outbound HTTPS. Mediacast confirms receipt on our side — nothing to check on yours.
• Stage 2 (scheduled with Mediacast): secure-tunnel activation and venue AV integration (e.g. Wipro VisionEDGE), done together in a short working session. No action needed from you before then beyond the firewall rules in section 3.

2. What you need (requirements)

3. Network prerequisites

The appliance is outbound-only: it initiates every connection, and no inbound ports need to be opened.

Why the S3 row is separate: update artifacts are served from Amazon S3 under a presigned URL, so the hostname the appliance connects to is an amazonaws.com one — a rule that allows only *.mediacast.app lets the appliance register and heartbeat perfectly well, then silently fails every software update. If your policy cannot allow that destination, tell us: we will note the appliance as manual-update and you accept that updates require a scheduled touch.

Web-gateway / TLS-inspection note: if outbound DMZ traffic passes through a secure web gateway with TLS inspection (Cisco Umbrella, Zscaler, Netskope, Prisma Access), please allowlist and bypass inspection for *.mediacast.app and the S3 destination above. The appliance validates certificates directly, and an inspecting proxy that re-signs the traffic will cause every cloud connection — and every update download — to fail.

Mediacast support access

The appliance is configured with a single Mediacast support account (mcops), used for activation (Stage 2) and for support during an incident.

• SSH public-key authentication only. Password login is disabled on the account and on the appliance as a whole.
• No inbound port is opened for it. It is reachable over your LAN, or over the Stage-2 outbound tunnel — never from the public internet.
• Your own administrators keep console access through vCenter/ESXi at all times, and can disable the account if your policy requires it. Tell your deployment contact if you would prefer it removed, and we will build your appliance without it — note that support then becomes console-only screen sharing, which materially slows incident response.

4. Deploy — step by step

First, which path are you on?

• vCenter (you log in to a vCenter Server and see the Hosts & Clusters tree) → follow 4A.
• Standalone ESXi host (you log in directly to the host at https://<host>/ui — the ESXi Host Client; no vCenter) → follow 4B. Most single-host DMZ deployments are this path.

Either way, the two rules that matter: attach the configuration before first power-on, and thin provisioning is fine.

4A — vCenter

1. Import. Deploy OVF Template → select the .ova → choose host/cluster and datastore → disk format Thin Provision → network mapping to your DMZ port group → Finish. Do not power on yet.
2. Attach the configuration. Right-click the VM → Edit Settings → vApp Options → enable if needed → under Properties click Add: Label cloud-init userdata, Category Mediacast, Key user-data, Type string, Value = the entire contents of <customer>-userdata.yaml. Under OVF Environment → Transport select ISO image. Save.
3. Power on.

4B — Standalone ESXi host (Host Client)

The Host Client tries to extract an uploaded OVA inside your browser, which stalls on an image this size — so on this path you skip the OVA entirely and download the appliance image already in pieces:

1. Download the three image files from your Downloads page (or the direct links Mediacast sent): the small .ovf descriptor, the large .vmdk disk, and the .mf checksum file (keep it with the others — it's the record of what the files should hash to).
2. Import. In the Host Client: Virtual Machines → Create/Register VM → Deploy a virtual machine from an OVF or OVA file → name it → in the file picker select both the .ovf and the .vmdk (multi-select; leave the .mf out — the wizard doesn't take it) → datastore → disk provisioning Thin → network mapping to your DMZ port group → uncheck "Power on automatically" → Finish. Keep the browser tab in the foreground while the .vmdk uploads (background tabs are throttled and the upload can stall).
3. Attach the configuration. Standalone hosts have no vApp Properties editor, so the configuration rides a small CD-ROM image instead:
   • Upload <customer>-seed.iso from your bundle to a datastore (Storage → datastore → Datastore browser → Upload).
   • VM → Edit settings → Add other device → CD/DVD drive → Datastore ISO file → pick the uploaded <customer>-seed.iso → tick Connect at power on → Save.
4. Power on.

Alternative for scripted deployments (either path): govc can attach the configuration as guestinfo.userdata (base64) + guestinfo.userdata.encoding=base64 on the VM. Ask Mediacast for the exact commands if you prefer this route.

Power on. First boot takes about two minutes. The appliance configures itself from the attached configuration, binds to the Mediacast control plane, and begins sending health reports over HTTPS.

If the VM was powered on before the configuration was attached: the one-time setup will already have run empty. The clean fix is quick — delete the VM, re-import (4A.1 / 4B.2), attach the configuration (4A.2 / 4B.3), then power on. Nothing on the Mediacast side is affected.

5. How you'll know it worked

• Mediacast confirms. We watch for the appliance's first check-in in real time and confirm to your team, typically within minutes of power-on.
• On the VM console (optional): the login banner appears and the VM stays running. No console interaction is needed or expected.
• The appliance's tunnel indicator remains down until the Stage-2 activation window — this is expected and not an error.

If Mediacast hasn't confirmed within ~10 minutes of power-on, the usual causes are, in order: the configuration wasn't attached before first power-on (see the box above), outbound TCP 443 from the DMZ is blocked, or DNS isn't resolving from that subnet.

6. Support

After the appliance is confirmed running, delete local copies of the configuration files (.yaml and .iso) from any workstation that touched them — the values are baked into the running VM.