FCP FortiClient EMS 7.4 cheat sheet

FortiClient EMS 7.4 is delivered as a hardened Linux virtual appliance (OVA/OVF for VMware, Hyper-V VHD, KVM qcow2); there is no Windows installer for EMS itself, only for FortiClient endpoints.

Minimum production sizing baseline: 4 vCPU, 8 GB RAM, 200 GB disk for up to ~2,000 endpoints; add vCPU/RAM and separate the database volume for larger fleets, and never thin-provision the log partition.

EMS requires two IP addresses/ports to be reachable: TCP 8443 for the admin GUI and endpoint telemetry/registration (FortiClient uses 8443 by default, 443 optional), plus TCP 10443 for the FortiClient installer/update portal and certificate provisioning.

Initial access is https://:8443; the default admin account must set a new password at first login, and the appliance license (FortiClient EMS trial = 3 endpoints, 30 days) is applied under System Settings > Dashboard.

EMS supports two deployment modes: standalone (local database) and Fabric/HA; HA pairs require identical firmware, a dedicated heartbeat link, and a shared virtual IP for endpoint registration.

Chassis/interface configuration is done at the console via the CLI menu (option 1 for network settings); changing the management IP breaks existing endpoint registrations unless the new address is advertised via DNS or the FortiClient telemetry setting is updated.

EMS must trust the FortiGate(s) it pairs with: add the FortiGate serial number under Fabric > FortiGate and import the FortiGate CA so the FortiGate can act as a security fabric root and push ZTNA/EMS tags.

Time synchronization (NTP) must be configured before certificate operations; clock skew greater than 5 minutes breaks FortiClient certificate enrollment and fabric authorization.

Backup the EMS configuration (System Settings > Maintenance > Backup) and the PostgreSQL database before firmware upgrades; downgrades require a restore from a backup taken on the target version.

FortiClient registers to EMS by telemetry: the endpoint is configured with the EMS address (invitation code, DNS discovery via _fortinet-forticlient._tcp, or manual entry) and appears under Endpoints > Unmanaged/Managed.

An invitation code (generated under Endpoint Registration) is a one-time or limited-use token that binds an endpoint to a specific endpoint profile group; codes can be set to expire and to limit the number of registrations.

Provisioning is profile-driven: an endpoint profile assigned to a group controls which FortiClient features (AV, web filter, firewall, VPN, ZTNA, vulnerability scan) are installed and locked on the endpoint.

Locked settings cannot be changed locally; a feature is only visible to the user if it is enabled in the profile, and 'lock' prevents the user from disabling it.

FortiClient installer packages are built in EMS (Deployment > Installers) by selecting FortiClient version, features, and the EMS address baked in; the resulting MSI/EXE/DMG/DEB/RPM is downloaded and distributed.

Installers can be pushed by Active Directory GPO, Microsoft Intune/SCCM, or a FortiClient deployment script; the EMS address must be embedded or supplied at install time for zero-touch registration.

Endpoint groups can be static (manual membership) or dynamic (based on AD/LDAP directory groups or endpoint tags); dynamic groups require directory connector synchronization.

Directory connectors (AD/LDAP, Azure AD/Entra ID, Okta) synchronize users and groups so endpoints can be auto-assigned to groups and profiles; sync runs on a schedule and can be triggered manually.

Endpoint profiles are ordered and assigned by group; when multiple profiles apply, EMS evaluates them in list order, and locked settings from the first matching profile win.

Anti-malware settings include real-time scan, scheduled scans, scan on removable media, quarantine, and exclusions; exclusions should be path- and hash-based to avoid weakening protection.

Web Filtering on the endpoint uses categories and FortiGuard rating; it can block, allow, or warn, and supports per-category overrides plus safe-search enforcement.

Application Firewall/Application Control restricts which executables may run (allowlist or blocklist by signature/hash), independent of the Windows firewall policy.

FortiClient Firewall profiles define inbound/outbound rules and can be locked so users cannot create exceptions; the profile also controls whether the Windows firewall is disabled in favor of FortiClient.

Vulnerability Scan settings in the profile schedule OS and application CVE checks and feed results to EMS for compliance and patch correlation.

Zero Trust tagging: EMS can apply endpoint tags based on compliance or on-demand scans, and those tags are consumed by FortiGate ZTNA and FortiClient EMS fabric connectors.

Profile assignment precedence: a more specific group assignment overrides the default/global profile; test with a pilot group before promoting a profile to all endpoints.

ZTNA in FortiOS 7.4 uses a ZTNA server (access proxy) with a virtual host, certificate, and server mapping to a real internal server; clients reach it through a ZTNA gateway/access proxy rather than a full tunnel.

FortiClient ZTNA destinations are provisioned from EMS: the EMS pushes ZTNA destination tags to endpoints, and FortiGate matches on the EMS tag in the ZTNA firewall policy.

ZTNA device posture is enforced via EMS tags (e.g., compliant, AV running, patch level); a FortiGate ZTNA policy that references an EMS tag denies endpoints without the tag.

Two ZTNA deployment models: endpoint-mode (FortiClient on managed endpoint, no client certificate needed if using EMS tags) and client-mode (certificate-based, for unmanaged/BYOD endpoints).

SSL VPN remains available in 7.4 but ZTNA is the recommended replacement for per-application access; SSL VPN web mode and tunnel mode are configured as portal + firewall policy on FortiGate.

FortiClient EMS acts as the certificate authority for ZTNA client certificates; the FortiGate trusts the EMS CA, and certificates are delivered to endpoints during registration.

ZTNA rules on FortiGate reference source (EMS tag), destination (ZTNA server mapping), and service; implicit deny applies when no rule matches, so order rules from most to least specific.

Secure remote access troubleshooting: verify FortiClient shows 'Connected' to EMS, the ZTNA tag appears under FortiGate > ZTNA > Tags, and the access proxy certificate chain validates on the endpoint.

Compliance rules in EMS are built from conditions such as AV installed and up to date, real-time protection enabled, OS patch level, disk encryption, firewall enabled, and vulnerability scan age.

A compliance rule is attached to an endpoint profile; the endpoint is evaluated continuously and its status is Compliant, Non-Compliant, or At Risk (unknown/not yet scanned).

Non-compliance actions include notify user, block network access (via FortiGate/NAC), quarantine, or trigger a remediation script; actions are configured in the compliance rule, not the profile.

FortiNAC integration consumes EMS compliance status for network access control; the EMS connector on FortiNAC must be authorized and the endpoint must be registered to EMS.

Compliance status can be exported via EMS reports and consumed by FortiGate as a dynamic tag for ZTNA/VPN posture checks.

Grace periods let newly registered endpoints remain 'at risk' for a defined window before enforcement; set grace periods shorter than the patch cycle to avoid permanent exemptions.

Compliance evaluation depends on timely telemetry: if an endpoint stops checking in, EMS marks it stale and compliance reverts to unknown, which typically fails closed in enforcement policies.

FortiClient Vulnerability Scan detects missing OS and third-party application patches by CVE; results appear in EMS under Vulnerability Management with severity (critical/high/medium/low).

Scan types: on-demand scan from EMS, scheduled scan via endpoint profile, and scan-on-registration; scan results include CVE ID, affected software, and remediation reference.

Patch Management in EMS 7.4 uses a patch management connector (e.g., WSUS, Intune, or a supported third-party patch tool) to correlate detected vulnerabilities with available patches and to trigger deployment.

Risk scoring prioritizes by CVSS severity, exploit availability, and number of affected endpoints; remediate critical/high with known exploits first.

Vulnerability reports can be scheduled and emailed; use them to track mean time to remediate (MTTR) and open critical findings per group.

Patch deployment status is tracked per endpoint (pending, installed, failed); failed patches usually indicate reboot pending, disk space, or WSUS/connector approval gaps.

Exclusions for vulnerability scans should be limited to known false positives and documented, because excluded CVEs disappear from compliance calculations.

EMS logs are viewed under Logs & Reports (FortiClient events, system events, admin events); logs can be forwarded to a syslog server or FortiAnalyzer under System Settings > Log Settings.

Common registration failure causes: wrong EMS address/port, invitation code expired or exhausted, certificate trust failure, endpoint clock skew, or firewall blocking TCP 8443.

FortiClient diagnostic tool (FortiClient > Settings > Backup/Diagnostics or the Support tool) collects telemetry logs, EMS connection state, and version info for support cases.

EMS CLI access is available via console or SSH (if enabled); useful commands include 'diagnose debug application ems' and service restarts via 'execute service restart'.

FortiGate fabric status: check Security Fabric > Fabric Connectors for the EMS connector state; 'disconnected' usually means FortiGate serial not authorized in EMS or certificate mismatch.

Upgrade order for fabric: upgrade EMS first, then FortiClient, then FortiGate; mismatched FortiClient versions outside the supported range fail to register or lose features.

Performance symptoms (slow GUI, delayed telemetry) usually trace to database growth or insufficient disk; monitor disk usage and purge old logs on a schedule.

Certificate troubleshooting: verify the EMS server certificate is valid and trusted, and that the FortiClient endpoint trusts the issuing CA; expired EMS certificates break all new registrations.