FortiManager Revision Control<\/a> covers revision history, workspace\/workflow, and recovery more deeply.<\/p>\nCreate revisions at meaningful release boundaries rather than after every trivial edit or only once per year.<\/p>\n
ADOM health should include device\/version consistency<\/h3>\n Current FortiManager provides ADOM health checks and version-compatibility views.<\/p>\n
Use them during upgrades and periodically to identify problematic devices, stale status, or incompatible version combinations.<\/p>\n
Governance should surface an ADOM that has become a permanent mix of versions contrary to the original design.<\/p>\n
Backup and restore time should be considered at scale<\/h3>\n Fortinet notes that many ADOMs increase configuration size and backup\/restore time.<\/p>\n
Large service-provider or enterprise deployments should test backup, restore, HA\/DR, and migration procedures at realistic ADOM counts.<\/p>\n
An ADOM design that looks tidy in the GUI can be operationally expensive during disaster recovery if partition count grows without control.<\/p>\n
ADOM design is successful when management boundaries remain stable and understandable<\/h3>\n The mature design can explain why each ADOM exists, which devices and versions belong there, who can administer it, which policy is shared, how upgrades proceed, and how revisions protect significant change.<\/p>\n
ADOMs should reduce management complexity through deliberate isolation\u2014not create another layer of fragmentation that operators must navigate during every incident.<\/p>\n
Global ADOM or global policy use should be planned carefully in environments that need enterprise-wide objects or policy. Global objects can reduce duplication, but they also create cross-ADOM coupling and a larger blast radius for shared changes. Use global scope only for controls that are genuinely common across the managed estate.<\/p>\n
Managed service providers should align ADOM boundaries with customer isolation and delegation. Per-customer ADOMs make administrator scope, policy ownership, and reporting clearer, while shared infrastructure ADOMs may still be needed for central services. Document every cross-customer\/global dependency explicitly.<\/p>\n
Large enterprises may prefer regional or regulatory ADOMs when data\/control responsibilities differ. That can simplify delegated administration and upgrade windows, but it should not force duplicate policy if the same security standard applies everywhere. Balance operational autonomy with policy reuse.<\/p>\n
ADOM naming should encode stable purpose, not transient organization charts. Business-unit names change more often than firmware or management boundaries. Names such as region + environment + device family can remain useful through reorganizations while ownership metadata can change separately.<\/p>\n
Backup design should include ADOM-aware recovery. Test whether one ADOM can be restored or reconstructed without disrupting unrelated domains and understand what global configuration dependencies must be restored first. Disaster recovery is where excessive ADOM complexity becomes visible quickly.<\/p>\n
Device movement between ADOMs should be treated as a migration. Policy package, objects, dynamic mappings, versions, administrators, and install state may all change. A device should not be reassigned casually simply because another ADOM looks administratively convenient.<\/p>\n
Version upgrades should preserve a clear rollback point. Create protected ADOM revisions, backup FortiManager, confirm managed-device state, then move through the supported upgrade sequence. If an ADOM upgrade introduces syntax\/feature changes, testing should include install preview on representative FortiGates.<\/p>\n
ADOM design should be reviewed periodically against real use. Empty domains, permanently mixed-version domains, duplicate policy domains, or ADOMs with one forgotten device may indicate the original partitioning no longer matches the environment. Simplification can reduce operational cost and policy drift.<\/p>\n
ADOM design should include administrator-role mapping. A separate ADOM creates value only if access, workflow, and accountability actually differ. If every administrator can enter every ADOM with identical permissions, the partition may be adding operational complexity without meaningful governance separation.<\/p>\n
Policy reuse across ADOMs should be planned through global mechanisms or standard templates rather than manual copy\/paste. Duplicated object and policy sets diverge over time, and fixes applied to one ADOM can be forgotten in another. Where policy must differ, preserve the reason for divergence.<\/p>\n
Monitoring should show ADOM-level health such as out-of-sync devices, failed installs, version mismatch, stale locks\/sessions, and revision growth. A large FortiManager can appear globally healthy while one ADOM has become operationally unhealthy and risky to change.<\/p>\n
Decommissioning an ADOM should verify every device, policy package, administrator dependency, revision, script, and global reference has been migrated or retired. Simply deleting an apparently empty domain can remove history or break automation that still references it.<\/p>\n
ADOM boundaries should be documented in onboarding standards. New FortiGates should land in the correct ADOM based on version, ownership, tenant\/customer, and policy model from the beginning. Moving devices later is possible but adds migration risk and can complicate policy-package history.<\/p>\n
Capacity planning should include administrator concurrency and workflow behavior. One giant ADOM with hundreds of devices and many administrators may technically work but create lock contention and change coordination problems. Conversely, dozens of tiny ADOMs increase overhead. Use real change patterns to find the right partition size.<\/p>\n
The best ADOM design is boring in daily operation: engineers know where devices belong, permissions align with ownership, version upgrades follow a repeatable sequence, shared policy is reused sensibly, and the partition rarely becomes the reason a security change is delayed.<\/p>\n
ADOM design should also account for automation boundaries. API clients, scripts, CI\/CD jobs, and external orchestration should target the same ADOM structure used by human administrators and should not rely on globally privileged accounts merely because automation spans several domains. Scoped service accounts and per-ADOM permissions preserve the isolation the architecture was meant to create.<\/p>\n
Keep the partition model documented in service onboarding and upgrade plans so new devices, administrators, and automation inherit the intended boundary instead of creating ad hoc management islands that later have to be reconciled under pressure.<\/p>\n
Keep ADOM ownership, purpose, and version alignment visible.<\/p>\n
Before creating another ADOM, test whether the proposed boundary really needs independent administrators, policy packages, objects, upgrade timing, or operational ownership. A boundary that exists only for visual neatness can create more cross-ADOM coordination than it removes.<\/p>\n","protected":false},"excerpt":{"rendered":"
FortiManager Administrative Domains (ADOMs) partition devices, policy packages, objects, administrators, and version-specific management data into separate logical management areas. They are useful for managed service providers, large enterprises, multi-team environments, mixed device families, and firmware-lifecycle separation, but Fortinet best practices explicitly caution against creating more ADOMs than the business needs because each ADOM adds configuration […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19853","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t