EMS publication for a mixed HQ, branch and laptop estate
A regional logistics company runs FortiClient EMS 7.4 on a Windows Server 2022 VM at 10.20.5.10 in its HQ server VLAN. It must manage 620 Windows endpoints: 480 at HQ, 140 across two branch offices, and 90 laptops that are usually off-site. The firewall team publishes EMS with a VIP so that 203.0.113.25:8013 maps to 10.20.5.10:8013; the GUI on TCP 10443 is allowed only from the admin subnet. HQ endpoints register normally because the pilot installer was built with the internal address 10.20.5.10. Branch and off-site endpoints fail to register and FortiClient reports that it cannot connect to EMS. Branch and guest egress is restricted to TCP 443, and there is no split DNS: ems.corp.example.com resolves only on internal servers. EMS still uses its default self-signed certificate. The purchased EMS licence covers 500 endpoints, and the dashboard already shows a licence warning. Management wants teleworkers managed within two weeks without exposing the admin GUI to the internet.
1. Explain the three independent faults that block branch and off-site registration, the order in which you would prove each one, and one workaround you would refuse to use.
Read the worked answer
Treat this as a layered connectivity problem, because fixing only one layer will still leave you with failures.
- Name resolution. The pilot provisioning embedded
10.20.5.10, which is unroutable from branch and home networks, andems.corp.example.comhas no public record. Prove it from a branch client with a name lookup before touching anything else; if the name does not resolve, port and certificate work is wasted effort. - Egress. FortiClient registers and sends telemetry over TCP 8013. Branch and guest egress permits only 443, so the session is dropped at the branch firewall even with correct DNS. Prove it with a TCP test from the client and by reading the deny logs on the branch policy and the VIP.
- Trust. The default self-signed EMS certificate is neither trusted by the endpoints nor matched to a name they use, so endpoints either prompt users to accept it or refuse to register. Only fix this after DNS and 8013 work, so you are not chasing certificate errors caused by unreachable hosts.
Refuse: publishing 10443 to the internet, or telling users to click through an untrusted certificate. The first exposes the admin console; the second trains users to ignore certificate warnings and hides a real security control failure. If egress can never allow 8013, publish a second VIP mapping external 443 to internal 8013, provision the endpoints with the explicit port, and document it as a controlled exception.
2. Design the addressing, certificate and provisioning plan that lets one installer work at HQ, at branches and at home, while keeping the admin GUI internal.
Read the worked answer
The anchor is a single FQDN that resolves correctly from everywhere, so nothing in the endpoint configuration ever contains a raw internal IP.
- Split DNS/hosting: internal DNS returns 10.20.5.10 for
ems.corp.example.com; public DNS returns 203.0.113.25. Both paths terminate on the same EMS listener, so HQ traffic stays internal and remote traffic uses the VIP. - Certificate: issue a certificate from the internal CA with the common name and SAN set to
ems.corp.example.com, and import it into EMS. Because the laptops are domain machines, they already trust the internal CA through GPO, so no user prompt appears. If unmanaged or personal devices are ever added, plan a public CA certificate instead, since those devices will not trust the internal root. - Provisioning package: build the installer from EMS so it carries the FQDN, the registration key and locked EMS settings. Locking matters: it stops users repointing their client at another EMS and keeps the registration key from becoming a free-for-all.
- Firewall rules: endpoint VLANs and branch subnets to the VIP on 8013 only; 10443 from the admin subnet only; EMS outbound 443 to FortiGuard for signatures and updates.
- Rollout: pilot a mixed group of five HQ, five branch and five home users, confirm registration and profile application, then mass deploy through your software distribution tool. Rebuilding the installer is not needed later; changing the DNS record is enough if the server moves.
3. The licence covers 500 endpoints but the estate is 620. Explain the consequence, and how you would sequence licensing against the rollout.
Read the worked answer
EMS enforces its licensed endpoint count. Once the cap is reached, additional endpoints cannot be brought under management: the dashboard warns, and the excess devices sit outside profiles, vulnerability scanning and patch reporting. That is a security and audit exposure, not merely an administrative annoyance - the newest devices, usually the travelling laptops with the highest exposure, are exactly the ones that would fall outside the cap.
Sequence the work like this:
- Reconcile before buying. Export the current endpoint inventory and match it against the CMDB/HR list. Reimaged, renamed and retired machines often linger and consume licences. Delete stale records (bearing in mind that deleting an endpoint removes its history and tags).
- Size with headroom. If the reconciled estate is genuinely 620, buy capacity above that figure - contractors, loaners and staging devices all register, and repeatedly hitting the ceiling creates helpdesk churn.
- Do not split the estate across two EMS instances to stay under the cap. You lose a single view of compliance, patch status and zero trust tags, and tags consumed by a FortiGate become inconsistent between servers.
- Order before the mass rollout, not after. The pilot fits comfortably inside 500 endpoints, so the shortage only becomes visible at scale, halfway through deployment, which is the worst time to discover it.