Importing your new configuration into FortiManager
The example in the procedures uses FortiManager 5.2 and global policies and objects. The procedures are similar for environments that don't use the global feature.
To configure FortiManager
On FortiManager, enable the ADOM feature and create an ADOM for each source domain that you want to migrate.Ensure that all the ADOMs (including the global ADOM) use the same version of FortiOS.
The output folder
The output folder provides both a global folder and a folder for each source domain. Both folders contain the subfolder FMGR\.
Object configuration is located in the FMGR\FWObject\ folder, which contains the following files:
- Several text and HTML files that are used for reporting. They aren't used to import the configuration.
- The text file
config-all, which contains all the CLI commands for the object configuration. - Text files that duplicate sections of the
config-allfile: address,address groups,services,scheduled, and so on. When there are many objects (for example, most environments have many firewall address objects), these sections are divided into multiple, indexed files. To make the import process simpler, Fortinet recommends that you import configurations using the files for individual sections.
Policy scripts are located in policy package folders in \FMGR\Policy as one or more firewall policy files (config-firewall-policy-1, config-firewall-policy-2, and so on).These files are the same content as the conversion output file config-all in smaller, indexed files that are easier to import.
Running scripts
With the exception of config-system-session-helper, you run all scripts using the Policy Package, ADOM Database script target.
You run the config-system-session-helper script on the device database to set device-level settings.
If the global folder contains a config-system-session-helper script, review its contents. In most cases, it isn't required because the global policies and objects configuration doesn't contain devices. You can add any configuration in this script to session helper scripts for each domain that uses the global objects. However, in most cases, the domain-level script also contains these settings.
To import policies and objects
You import your global object and policies first because the ADOM configuration can depend on them. Import objects before policies because polices depend on objects.
- In the FortiManager system settings, to enable scripts, go to System Settings > Admin > Admin Settings. Under Display Options on GUI, select Show Script.
- To display the scripts in the Global Objects menu, on the Policy & Objects tab, go to Tools > Display Options > All On.
- Go to Global Objects > Advanced > Script.
- Click Import, enter a name for the script you are importing, and then click Browse to navigate to and select a script from the
Global\FMGR\FWObjectfolder. - For the script target, select Policy Package, ADOM Database, and then select OK.
- When the import is complete, review any error messages that FortiConverter inserted as comments and make any required corrections. For more information, see To troubleshoot script import and execution errors .
- To run the script, right-click it, and then select Run. Because global objects are applied to all ADOMs by default, for Run script on policy package, you can use the default policy package.If the script execution fails, troubleshoot the process and make any required changes. For more information, see To troubleshoot script import and execution errors .
- Repeat the script import and run process for all the scripts in the
Global\FMGR\FWObjectfolder. - When you have imported all the objects, use the same procedures to import and run the policy scripts using the firewall policy configuration files located in the
Global\FMGR\Policyfolder, which contains a folder for each policy package. don't import theconfig-allfile. - When the policy package is correct, assign it to your ADOM. By default, FortiManager assigns the selected policy package to all policy packages in the ADOM.
- To complete the ADOM assignment, on the Assignment tab, click Assign.
- When the process of assigning the polices and objects is complete, on the Policies & Objects tab, select the ADOM to review the policies.
- To import the domain-level polices and objects into your ADOM, on the Device Manager tab, select the ADOM, and then go to Scripts > Script.
- Repeat the procedure for importing the object and policy scripts with the contents of the
<domain_name>\FMGR\FWObjectand<domain_name>\FMGR\Policyfolders. Import the objects first, but don't import theconfig-system-session-helpersscript. For the script target, select Policy Package, ADOM Database. - Run each imported object script. For Run script on, select Policy Package, ADOM Database. Correct any errors that prevent the script from executing. For more information, see To troubleshoot script import and execution errors .
- Before you run the policy scripts, create new policy packages that correspond to each policy package folder in
<domain_name>\FMGR\Policy. On the Policy & Objects tab, right-click on the default policy package and choose Policy Package Create New. - On the Device Manager tab, run each imported policy script. For Run script on, select Policy Package, ADOM Database. When you are prompted for a policy package, select the name of the appropriate package, which you created earlier.
The list of global scripts is displayed.
For more information on the output folders and files, see The output folder.
After the scripts have run successfully, review the policies.
Ensure you check for error messages that FortiConverter inserted as comments and make any required corrections. For more information, see To troubleshoot script import and execution errors .
If there are many address objects, you import several scripts because the address file is indexed to keep the files at a manageable size.
Clear the Clone Policy Package option.
Because global polices and objects were assigned to all policy packages in this ADOM, they are automatically part of each new policy package. The next import task adds the domain-level policies.
Correct any errors that prevent the script from executing. For more information, see To troubleshoot script import and execution errors .
To troubleshoot script import and execution errors
FortiConverter inserts any error messages in output scripts as comments.
In some cases, the script can't run unless you edit it to correct the errors. Double-click the name of the script in the list of scripts to edit it.
In the following example, the address objects that generate the errors are assigned using the global objects and can be ignored.
If an error occurs during script execution, go to System Settings > Task Monitor to view the error message and identify the error. Look for "Failed to commit to DB" in the task information.
Unlike a FortiGate import, which creates an object up to the point of failure, FortiManager creates no objects or policies if the script execution fails.
If you identify the cause, correct it in your script.
For example, the following error was generated by a firewall policy that contained both IPv4 and IPv6 objects, which FortiOS doesn't support and FortiConverter did not correct.
Another example of a script execution error generates the following message:
To resolve the error, determine which object precedes the error, locate it in the script, and correct any configuration errors. In this example, the configuration doesn't specify the subnet. If an object you don't want to use generates the error, you can delete it from the script or use # (hash) at the start of the appropriate lines to convert them to comments. Then, try to run the script again. Repeat the troubleshooting process until the script execution is successful.
If there is no obvious error in the output, try dividing the script into two smaller scripts. If only one script runs successfully, you have narrowed the focus of your troubleshooting to the content of the failed script. To divide a script, right-click it and select Clone. Using the policy numbers to determine and keep track of which policies you delete, edit the files so that they each contain a different section of the script. Then, run both scripts.
Dividing scripts into two or more smaller scripts is also useful if you suspect the length of a script is causing the execution to fail. Scripts that are too long fail without generating an error message.
In some cases, if a script fails, Fortinet recommends that you create a new script instead of editing or deleting it, because sometimes files can remain after you delete it. If you preserve the failed script, you can review it and the error it generates later. In the following example, the following config user server objects took several attempts to run successfully.
