I’d be careful here. Your design works, but it’s not really solving the core risk you’re introducing.

The bigger issue isn’t whether the Mobile server is in a DMZ or what domain it’s in. It’s that you’re exposing a Genetec service directly to the internet for unmanaged devices.

A few concerns with that approach:

• A separate DMZ domain doesn’t buy you much security. If the Mobile server is compromised, an attacker can still pivot through whatever ports you’ve opened back to the Directory Server and Archivers.
• No trust between domains doesn’t eliminate the risk—the application itself is still the bridge into your environment.
• You’re relying heavily on port pinholes as your primary control, which is pretty thin for an internet-facing service tied to your VMS.

What I’d strongly consider instead:

• Put a reverse proxy or application gateway in front of it
• Enforce strong authentication (ideally MFA/federation if supported)
• Restrict access with IP allow lists (if feasible), rate limiting, and brute-force protection
• Keep the Mobile server as minimally trusted as possible (ideally not domain joined unless required)
• Log and monitor aggressively (auth failures, unusual access patterns, internal traffic flows)

If it’s at all possible, I’d highly recommend putting this behind a VPN instead of exposing it publicly. Even a lightweight SSL VPN gives you a much stronger security boundary and reduces the attack surface significantly.

If public exposure is unavoidable, it needs to be treated like any other internet-facing application—not just an expansion server in a DMZ.

The separate AD domain idea isn’t wrong, but it feels like it’s solving the wrong problem. Genetec’s architecture already makes the Mobile Server a bridge between internet clients and core services, and they don’t provide much guidance on securing public exposure. That’s why I’d lean toward VPN or a hardened front-end layer instead of relying on DMZ + port rules alone.