FortiManager can show a FortiGate as connected while still reporting that its configuration is out of sync. The reason is that FortiManager does not manage one single copy of “the configuration.” It maintains different management layers: the device database stores device-specific configuration state and revisions, while the ADOM policy/object database contains centrally managed policy packages and shared objects. The real FortiGate is a third state that can change independently if local administrators make direct edits.
The NSE 6 FortiManager 7.6 Administrator exam tests this configuration-management model. The practical skill is learning which database owns a setting, what a retrieve operation updates, and how to reconcile differences without accidentally overwriting a valid change.
The device database represents FortiGate-specific configuration
FortiManager maintains a device database for managed configuration such as system and device-level settings. Fortinet describes it as a configuration repository that supports revision history, comparing configurations, retrieving current device state, and reverting to earlier revisions. It is therefore both a management workspace and a historical record.
Changes made in the device database do not automatically exist on FortiGate. They must be installed to the device. Similarly, a local change made directly on FortiGate can make the real device differ from FortiManager’s stored device configuration until that difference is retrieved or otherwise reconciled.
Revision history is important because it turns “the configuration changed” into an auditable sequence. Administrators can compare revisions, inspect who created them, review install status, and use known-good points during troubleshooting or recovery.
The ADOM database owns centrally managed policy and objects
Policy packages, firewall rules, and the objects referenced by those packages live in the ADOM’s policy/object management layer. This separation allows common security policy to be managed centrally even when each FortiGate has different interfaces, routes, addresses, or system settings.
The distinction explains why two devices can share a policy package but still have unique device-level configuration. It also explains why a local FortiGate edit to a policy-managed setting can be overwritten on the next policy installation. FortiManager treats the centralized package as the intended policy state.
When troubleshooting drift, ask whether the disputed setting belongs to the policy package or the device database. Without that classification, an administrator may retrieve the device configuration and expect the policy package to change, even though Fortinet explicitly documents that retrieval does not update the policy package.
Retrieve updates the device database, not the policy package
Fortinet’s retrieve operation reads the current FortiGate configuration and stores it in the FortiManager device database. If the device differs from the repository, a new revision can be created. However, the policy package is not updated by that retrieve.
This behavior protects the centralized policy model. Imagine a local administrator changes a firewall policy directly on FortiGate. A retrieve operation can record the current device configuration, but it does not silently redefine the centrally managed policy package as the new standard. If the same setting is controlled by the policy package, the next installation can overwrite the local change.
Therefore, “retrieve and install” must be used carefully. Retrieval is not a generic conflict-resolution button. It is a deliberate choice to bring device state into FortiManager’s device repository, after which the administrator still needs to reconcile any policy/object differences according to the organization’s source-of-truth rules.
Revision history is evidence, not merely a backup list
FortiManager revision history can show configuration versions, timestamps, administrator information, installation status, and differences between revisions. During an outage, this helps answer what changed, when it changed, and whether the new state was actually installed to the device.
Use revision diffs to narrow investigations. Comparing a working revision with the current state is more reliable than visually scanning a complete configuration. If the incident started after a change window, compare the specific revisions associated with that window and correlate them with install logs.
The approved FortiManager Administrator material provides historical exam context, but current operations should be interpreted through FortiManager 7.6 behavior and the current NSE 6 certification naming.
Out-of-sync status is a symptom that needs classification
A device can become out of sync because a local change was made, an installation partially failed, FortiManager state changed without a corresponding device install, or connectivity was lost during a change. Do not solve every status indicator by forcing an installation. First establish which side contains the intended configuration.
If FortiManager is authoritative and the device has an unauthorized local change, reinstalling the intended FortiManager configuration may be correct. If the local device contains an emergency fix that must be preserved, retrieve and then reconcile the intended central state before installing anything. The operational decision depends on ownership, not on which copy is newer.
Document direct-device emergency changes so they can be incorporated into FortiManager later. Otherwise the next normal installation may remove them. A mature process treats out-of-band changes as temporary exceptions that must be reconciled back into the central management model.
Policy installs and device installs affect different layers
FortiManager can install policy packages and device settings, and the Install Preview helps administrators see what will change. The preview is particularly valuable when database states have drifted because it can reveal whether a planned operation would remove or replace configuration that exists on FortiGate.
Do not assume a successful policy-package install means every device setting is synchronized, or that installing device settings means the policy package matches. Review the status indicators for the relevant layer and use the correct installation type.
The separation is a scaling advantage: central policies can be changed once and installed broadly without rewriting every unrelated system setting. Troubleshooting should preserve that advantage by changing only the layer that is actually wrong.
Database discipline prevents accidental rollback
Teams should define where changes are allowed to originate. If FortiManager is the normal source of truth, direct FortiGate edits should be restricted to emergency cases with a reconciliation procedure. If local operations are intentionally allowed, administrators need a defined retrieve-and-review workflow so the central repository does not drift silently.
Use comments, change tickets, revision names, and install logs consistently. Configuration history is far more useful when an operator can connect revision 42 to a specific maintenance request than when every revision is an anonymous automatic snapshot.
Centralized configuration benefits from network automation principles such as deterministic state, reviewable changes, and observable results. FortiManager’s databases provide those capabilities only if operators respect the distinction between intended state, stored state, and running state.
A safe reconciliation workflow
When a device is out of sync, first capture the current FortiGate state and FortiManager revision information. Identify whether the difference is in device configuration, policy/object configuration, or both. Determine which side contains the approved change. Review the relevant diff before retrieving or installing.
If the device change is legitimate, retrieve it into the device database, then reproduce any centrally managed policy change in the ADOM policy package rather than assuming retrieval handled it. If FortiManager contains the intended state, preview the installation and confirm the resulting changes before pushing them.
After reconciliation, verify synchronization and create a fresh revision. The goal is not simply to make the status icon green. The goal is to end with a known authoritative configuration, an audit trail that explains how it was reached, and no hidden local changes waiting to be overwritten later.
Separate configuration authority from emergency access
Central management works best when everyone knows which system is authoritative. Many organizations still keep local FortiGate administrator access for emergencies, but that does not mean local changes should become normal practice. Define the conditions under which direct changes are allowed, who can approve them, and how quickly they must be reconciled into FortiManager.
During an outage, an engineer may fix routing or policy locally because FortiManager is unavailable. Once service is restored, capture the exact local change before normal central operations resume. Decide whether to reproduce the change in the policy package or device database, retrieve the device state, or intentionally roll the emergency change back. The worst outcome is to do nothing and allow the next routine installation to overwrite the fix without warning.
Use revision history to make this process auditable. Tag or name known-good states, include ticket references in comments, and retain install logs. When several engineers participate in an incident, these records reduce ambiguity about which changes were proposed, saved, installed, or reverted.
Periodic drift reviews are also useful. A device that stays out of sync for weeks may indicate a broken process rather than a technical error. Repeated local edits, failed installs, unsupported commands, or unclear ownership can create chronic drift. Treat persistent status differences as a governance problem and correct the workflow that produces them.
Database understanding becomes especially important during migrations between FortiManager systems or ADOM reorganizations. Preserve revision history and verify policy/object ownership before moving devices. A successful device import without the intended central policy context is not a complete migration.
Scheduled compliance checks can make drift visible before an outage. Compare selected high-risk configuration areas—administrative access, routing, VPN, interface state, and security policy ownership—against the expected FortiManager source. The purpose is not to force every difference away automatically, but to identify unexplained differences early enough for a human to classify them.
During FortiOS upgrades, expect the configuration model to evolve. New commands, renamed options, and unsupported features can affect FortiManager’s representation of the device database. Review compatibility and ADOM version before treating post-upgrade differences as unauthorized drift.
When decommissioning a FortiGate, retain the required revision history and audit evidence before removing the device object. Configuration repositories are often useful after hardware retirement for incident reconstruction, compliance, or migration reference. Lifecycle management should include a deliberate archive decision, not only deletion from Device Manager.