Mixed FortiOS Estate After an Acquisition
Acme Retail runs FortiManager 7.4.3 on a single VM and has one ADOM named FORTI-7.4 that contains 48 FortiGates running FortiOS 7.4.4. The company acquires 8 branch FortiGates running 7.2.12 and 4 older 6.4.15 units that must remain in service until Q3. The network team wants to add all 12 devices to FORTI-7.4 to keep one policy package and one set of address objects. The first import of a 7.2.12 device fails immediately. The change window is four hours, and upgrading the 8 branches is explicitly out of scope for this quarter. The 6.4 units have a support contract but no upgrade date. Management wants the minimum number of ADOMs and no loss of central policy control.
1. Explain why the 7.2.12 import fails and propose an ADOM design that meets the constraints.
Read the worked answer
FortiManager binds an ADOM to a FortiOS version; the policy/object schema and install engine are version-specific, so a 7.2.12 FortiGate cannot be imported into a 7.4 ADOM just because FMG 7.4.3 supports both. The minimum workable design is three ADOMs: FORTI-7.4 (existing), FORTI-7.2 for the eight branches, and FORTI-6.4 for the four older units. This is not 'one ADOM', but it keeps central policy control and avoids unsupported object references. Do not use a backup-only ADOM for the 7.2/6.4 devices if the requirement is policy installation; backup mode does not give the same policy-package workflow. Put shared address and service objects in the Global Database and assign them to all three ADOMs, then create version-specific policy packages that reference those global objects. When the branches upgrade to 7.4.4, move each device into FORTI-7.4 and install the 7.4 package; expect to re-import the device database and re-map interfaces.
2. Compare keeping the 6.4.15 devices in a 6.4 ADOM against upgrading them to 7.4.4 now. Which is the better immediate choice?
Read the worked answer
Option A: keep a 6.4 ADOM until Q3, then upgrade the four units to 7.4.4 and move them into the 7.4 ADOM. This preserves central management now, but costs an extra ADOM, duplicate policy packages, and a later migration project; it also keeps older code longer. Option B: upgrade the four 6.4 units to 7.4.4 now, before adding them to FMG. That gives one fewer ADOM and one policy-package family, but requires a maintenance window, config backups, and acceptance testing of the 7.4 build on older hardware. Given the four-hour window and no upgrade date, Option A is the lower-risk immediate choice; plan Option B as the target state. In either case, do not add a 6.4 device to the 7.2 ADOM, and do not rely on FMG to convert the configuration during import.
3. When a device later moves from the 7.2 ADOM to the 7.4 ADOM, what happens to its policy package and device database, and what should be checked before the move?
Read the worked answer
Moving a device between ADOMs is not a policy migration. The device is removed from the old ADOM and imported into the new one, and the device-level database is rebuilt from the device or from provisioning. The old ADOM's policy package does not follow it. Before the move, export and back up the device config, confirm the new ADOM's policy package has the right interface mappings and object values, and schedule the move in a window. After the move, install the new package and verify with Install Preview and the device configuration. Global objects can be assigned to the new ADOM, but per-ADOM objects and policy packages must exist in the target ADOM. This is why doing the ADOM design up front is cheaper than a later consolidation.