Deploying on multiple machines

PreviewMonitor is two unsigned binaries dropped into Adobe's shared plug-in folders, a per-user JSON config, and three inbound firewall rules. It has no server, no account system, no license check and no update mechanism. This page is the deployment detail.

Ports

The TCP control port is chosen by which Adobe host loaded the plugin. The UDP ports are fixed and are destination ports on the iPhone — the plugin's UDP sockets are never bound locally, so nothing needs to be opened inbound for them on the host.

Ports are spaced by ten per host so Premiere Pro and After Effects can run on one machine at the same time without colliding on a single control port. IPv4 only. Payload sizing assumes a 1500-byte MTU.

Firewall

The Inno installer (PreviewMonitor-<version>.exe) adds three inbound rules, all named PreviewMonitor, and deletes them on uninstall:

The rules are port-scoped, not program-scoped — deliberately, because the Premiere Pro executable path changes with every version. They exist to pre-empt Windows' own "Private / Public networks" prompt, which users cancel, and a cancel writes a Block rule that then has to be found and removed by hand.

The MSI does not add firewall rules. If you deploy by MSI you own the firewall configuration entirely. The equivalent commands:

netsh advfirewall firewall add rule name="PreviewMonitor" dir=in action=allow protocol=TCP localport=47100,47110,47120,47130 profile=domain,private,public
netsh advfirewall firewall add rule name="PreviewMonitor" dir=in action=allow protocol=UDP localport=47101-47102 profile=domain,private,public
netsh advfirewall firewall add rule name="PreviewMonitor" dir=in action=allow protocol=UDP localport=5353 profile=domain,private,public

Three rows share the single rule name; the Profile column is where a domain-joined machine's problem becomes visible.

The plugin never calls a firewall API at runtime, on either platform. On macOS nothing configures the firewall at all, which is why the first stream raises an unexplained "accept incoming connections?" dialog.

Choosing an installer

Both install per-machine and require elevation. Neither ships PremiereLiveAE.aex, the After Effects transport bridge — see Working in After Effects for the manual placement.

The Start-menu group the Inno installer creates has two entries: How to Connect, which is a URL shortcut to previewmonitor.app/docs/getting-started/connect, and Uninstall PreviewMonitor. Nothing is bundled locally.

Silent install

The MSI supports the standard msiexec /i PremiereLive.msi /qn. It declares a fixed UpgradeCode of 5b7a3d2e-1c4f-4e2a-9a1b-2c4d5e6f7a8b with a major-upgrade rule, so a newer build replaces an older one and a downgrade is refused. It declares no ProductCode — one is generated per build — and it exposes no custom properties, so there is nothing to set on the command line. It attempts to close Premiere Pro, Media Encoder and After Effects before installing.

The Inno installer accepts Inno's standard /SILENT and /VERYSILENT, and its finish-page action is correctly flagged to skip in silent mode.

Uninstall

The Inno uninstaller removes both plugins and the firewall rules. Neither installer removes user data. Config and logs survive an uninstall and a reinstall:

%APPDATA%\PremiereLive\          install.json, trusted.json, trusted-ae.json
%LOCALAPPDATA%\PremiereLive\     plugin.log, plugin.log.1, plugin-ae.log, debug_*.log

Delete those directories for a genuinely clean state. Note the split: config roams, logs do not.

The plugin writes no registry keys. All state is JSON under %APPDATA%\PremiereLive\. The only registry entries belong to Add/Remove Programs.

macOS

PreviewMonitor-<version>.pkg installs two bundles system-wide, which is why it needs admin:

/Library/Application Support/Adobe/Common/Plug-ins/7.0/MediaCore/PremiereLive.bundle
/Library/Application Support/Adobe/Common/Plug-ins/ControlSurface/PremiereLiveCtrl.bundle

System-wide rather than per-user because Premiere Pro only scans the system-level ControlSurface folder.

Config and logs on macOS:

~/Library/Application Support/PremiereLive/    install.json, trusted.json
~/Library/Logs/PremiereLive/                   debug_*.log

There is no plugin.log on macOS. Main logging goes to os_log under subsystem com.premierelive.plugin. Read it with Console.app, or:

log show --predicate 'subsystem == "com.premierelive.plugin"' --last 10m --info

Unsigned binaries

Nothing in this product is code-signed or notarized. Plan for it.

The warning is SmartScreen reacting to an unsigned binary with no reputation, not a detection.

For a managed rollout this means the installer will not pass a policy that requires signed executables, and you should distribute it from a location your users already trust rather than asking them to click past a warning.

Discovery

Bonjour/mDNS, service type _premierelive._tcp, on UDP 5353.

The TXT record carries five keys: ver (record version, currently 5), id (the host's install UUID), name (display name), transmit (1/0, whether the plugin is currently transmitting), and pv (plugin version). The iPhone keys its paired-host list on id, so that value is the machine's identity as far as the app is concerned.

What breaks discovery

• Guest Wi-Fi and AP client isolation. These block device-to-device traffic. Discovery finds nothing, and a manual IP will not help either if unicast between clients is blocked — only multicast filtering is survivable by the manual path.
• Different subnets. mDNS does not cross a router. Host on Ethernet and phone on Wi-Fi is fine only if they are on the same L2 segment.
• mDNS filtering. Some managed APs suppress multicast to save airtime. This is the case the manual-IP path exists for.

The fallback is on the phone: Connect a Device → Connect via IP address instead, which asks for the host's address and which Adobe application it is running (choosing the port for you). It still requires the pairing code. A manually-entered host has no Bonjour id, so it will not follow the machine to a new DHCP address — a static reservation is worth setting for lab machines.

One Windows-specific note: DnsServiceRegister publishes PTR, SRV and TXT records but never an A record, so hostname resolution relies on the machine's own auto-registered <computername>.local. Two Adobe hosts on one PC share that single name.

Pairing is per-user and per-machine

An iPhone pairs with a 6-digit code shown on the host, over the TCP control channel. On success the host mints a 64-character session token, stores it, and hands a copy to the phone; subsequent connections from that phone present the token and skip the code.

The trusted list is a plain JSON file in the user's roaming profile, one file per Adobe host:

%APPDATA%\PremiereLive\trusted.json        Premiere Pro
%APPDATA%\PremiereLive\trusted-ae.json     After Effects
~/Library/Application Support/PremiereLive/trusted.json

Each entry is {id, name, token, firstPaired}. Consequences for a multi-machine deployment:

• Pairing does not follow the plugin. A user pairing on machine A is not paired on machine B. Every user pairs with every machine they use, once.
• It is per-user. Two Windows accounts on one workstation each keep their own trusted list.
• There is no bulk pre-seeding path. The host-side file is trivially writable, but the token has to byte-match what the phone presents and there is no supported mechanism to provision the iOS side. Budget for one pairing interaction per user, per machine.
• There is no "forget all" button. Peers are removed one at a time with a Forget button in the setup window. To clear a machine, delete the trusted*.json files.

The Instance ID under the trusted list is the id from install.json — the value to quote in a support request.

Do not copy install.json between machines when imaging. It carries the mDNS id, and cloning it gives every machine the same identity, which is the value the iPhone uses to tell hosts apart.

One phone at a time

Each host accepts a single client. A second iPhone connecting replaces the first — the old connection is closed rather than the new one being refused. The replacement is treated as unauthenticated and must pair before it receives video, so a replacement cannot inherit the previous phone's stream.

Premiere Pro and After Effects on one machine are two independent hosts on two ports, each with its own client, log file, trusted list and mDNS identity. Within one host, the Source Monitor and Program Monitor share the single connection.

What leaves the machine

The desktop plugin makes no outbound internet connection of any kind. No telemetry, no analytics, no update check, no license check, no crash reporting. Verified by grep across the plugin source: the only sockets are the LAN TCP listener and the UDP sender aimed at the paired phone's address. Crash handling writes to a local file.

The install.json identifier is generated locally and used for exactly three things, all of them local: the mDNS TXT record, the pairing QR payload, and the setup window's on-screen support ID.

The iPhone app is a different matter, and worth knowing about if you are answering a security questionnaire:

There is no account, no login, and no server of ours that stores anything.

Deployment checklist

Related

• Network reference — the full protocol, FEC and packet layout
• Trusted devices — the pairing UI in detail
• Two hosts on one machine — Premiere Pro and After Effects side by side
• Logs and diagnostics — reading plugin.log and os_log
• Can't find device — discovery failures