Central Management simplifies network operations by using FortiManager and FortiAnalyzer to handle device configurations, log analysis, and security policies across large-scale environments.
FortiManager is a centralized management tool designed to simplify configuration and policy management across multiple FortiGate devices.
Import FortiGate Configurations:
Device Groups:
Policy Packages:
Scripts for Bulk Changes:
Use scripts to perform bulk configuration updates, saving time in large deployments.
Example:
A script to set an NTP server across all devices:
config system ntp
set server "pool.ntp.org"
end
Configuration Snapshots:
Rollbacks:
FortiAnalyzer is a logging and analytics platform that collects data from FortiGate devices to provide insights into network performance and security.
Log Collection:
Dashboards:
Custom Report Templates:
Automated Reports:
Global management capabilities allow administrators to create security rules and configurations that apply to multiple devices or domains, reducing redundancy.
Centralized Rules:
Use Case:
Here’s an example of how FortiManager and FortiAnalyzer might be used in a real scenario:
In environments with multiple FortiGate devices, managing each one individually becomes inefficient. FortiManager and FortiAnalyzer allow you to:
If you’re new to FortiManager and FortiAnalyzer, start by adding a single device to FortiManager, explore the policy creation process, and view logs in FortiAnalyzer to get hands-on experience.
ADOMs (Administrative Domains) are logical containers in FortiManager that allow multiple customers, business units, or regions to be managed independently within the same FortiManager instance.
config system global
set adom-mode advanced
end
config system admin adom
edit "CustomerA"
next
edit "DeptB"
next
end
FortiManager verifies the synchronization status between policy packages and the configurations currently on managed FortiGate devices.
You may be asked: "How can an administrator identify if the policy configuration on FortiGate is out-of-sync with FortiManager?"
Answer: By checking the color-coded policy status indicator under the Device Manager or Policy & Objects sections.
While most FortiManager tasks are performed via the GUI, certain exam scenarios or advanced workflows may require knowledge of CLI commands.
diagnose dvm device list
execute fmpolicy push <device-name>
diagnose fmupdate adom-lock-status
CLI is also used in script-based bulk configuration workflows within FortiManager.
FortiAnalyzer is primarily used for centralized log collection, analysis, and reporting, but it also supports log forwarding to external systems.
config log fortianalyzer setting
set status enable
set reliable enable
set server "192.168.1.100"
set enc-algorithm high
end
config system log-forward
edit "SIEM"
set server "10.10.10.10"
set format syslog
set mode reliable
next
end
| Topic | Description |
|---|---|
| ADOM | Logical domains to separate devices, policies, logs across tenants or units |
| Policy Status Check | Color-coded sync indicators for policy packages before deployment |
| FortiManager CLI Commands | Useful for script execution, sync troubleshooting, and device monitoring |
| FortiAnalyzer Log Forwarding | Sends logs to third-party SIEM or syslog servers with filtering and retry control |
Why can a FortiGate stop connecting to FortiManager after an upgrade?
A common cause is certificate validation or authorization behavior changing after the upgrade, not simple IP reachability.
A recent Reddit thread points to FortiManager 7.2.5 certificate-validation changes as the trigger for post-upgrade registration failures, and FortiManager documentation confirms that centrally managed devices must be authorized properly before management works. In practice, admins should verify three things in order: basic reachability on the management path, matching registration/serial expectations, and certificate trust on the FortiManager side. If transport is fine but validation fails, the device may appear reachable yet still remain unauthorized or disconnected. This is a classic exam scenario because it tests whether you distinguish control-plane connectivity from management-plane trust. The right mindset is: ping and routing are necessary, but not sufficient. In central management, authorization state and certificate handling are often the real blockers after upgrades or version changes.
Demand Score: 89
Exam Relevance Score: 92
Why does adding a FortiGate to FortiManager sometimes seem to wipe the existing configuration?
Because the onboarding method matters: importing an existing device and low-touch/ZTP-style enrollment do not behave the same way.
This question appears often because admins assume every “add device” workflow preserves the current live config. Community discussion shows that if the manager-driven workflow is used without importing the existing configuration properly, the FortiGate can receive default or staged settings instead of preserving what is on the box. The practical safeguard is to decide the onboarding model first. If the goal is to adopt an already-configured firewall, import its configuration into FortiManager and review mappings before installation. If the goal is zero-touch provisioning, expect templates and metadata variables to define the desired state. The exam point is understanding central management ownership: once FortiManager becomes authoritative, local expectations must match the selected workflow. Confusion here causes many real outages because engineers mix “adopt existing config” and “push desired config” as if they were the same operation.
Demand Score: 84
Exam Relevance Score: 90
Why does FortiManager fail to add or register a FortiGate even though the IP address and credentials look correct?
Because registration can fail on validation, config parsing, or compatibility issues even when the device is reachable.
Fortinet’s own troubleshooting article on adding FortiGate to FortiManager highlights that the manager may detect invalid data during config loading, and community threads also show registration failures tied to version or SSL-level quirks in lab or trial setups. The important lesson is that successful reachability does not guarantee successful onboarding. When adding a device, FortiManager may reject or choke on a configuration element, ADOM mismatch, or trust-related issue. A good workflow is to check unauthorized devices, review onboarding logs, run the configuration diagnostics Fortinet recommends, and correct the offending config rather than repeatedly retrying registration. For the exam, the right conclusion is that device-add problems are often caused by management compatibility or config validation, not by “bad password” alone. That distinction is exactly what experienced operators use to shorten troubleshooting time.
Demand Score: 82
Exam Relevance Score: 87
Why might FortiManager not detect changes after moving AP management from device-based to centralized management?
Because the source of truth has changed, and some settings may no longer be tracked where the admin expects.
A recent Fortinet Community post shows exactly this confusion during migration to centrally managed AP administration. After the shift, engineers often still expect changes to appear under the old device-centric workflow, but FortiManager may now treat the controller templates or central objects as authoritative. That leads to “no changes detected” even though the admin knows something was edited somewhere. The practical fix is to verify which layer owns the AP settings now: local FortiGate, FortiManager object/template, or another central construct. This is exam-relevant because central management is fundamentally about ownership and install scope. If you troubleshoot from the wrong ownership model, every symptom looks misleading. In production, always confirm whether the change should appear as a device diff, a policy package diff, or a template/object change instead.
Demand Score: 74
Exam Relevance Score: 79