When you export a configuration, the FMC also exports other required configurations. For example, exporting an access control policy also exports any subpolicies it invokes, objects and object groups it uses, ancestor policies, and so on. As another example, if you export a platform settings policy with external authentication enabled, the authentication object is exported as well.

There are some exceptions, however:

• System-provided databases and feeds—The FMC does not export URL filtering category and reputation data, Cisco Intelligence Feed data, or the geolocation database (GeoDB). Each FMC needs to obtain up-to-date information from Cisco.

• Global Security Intelligence lists—The FMC exports Global Security Intelligence Block and Do Not Block lists associated with exported configurations. The import process converts these lists to user-created lists, then uses those new lists in the imported configurations. This ensures that imported lists do not conflict with existing Global Block and Do Not Block lists. To use Global lists on the importing FMC, manually add the lists to your imported configurations.

• Intrusion policy shared layers—The export process breaks intrusion policy shared layers. The previously shared layer is included in the package, and imported intrusion policies do not contain shared layers.

• Intrusion policy default variable set—The export package includes a default variable set with custom variables and system-provided variables with user-defined values. The import process updates the default variable set on the importing FMC with the imported values. However, the import process does not delete custom variables not present in the export package. The import process also does not revert user-defined values on the importing FMC, for values not set in the export package. Therefore, an imported intrusion policy may behave differently than expected if the importing FMC has differently configured default variables.

• Custom user objects—If you have created custom user groups or objects in your FMC, and if such a custom user object is a part of any rule in your access control policy, note that the export file (.sfo) does not carry the user object information, and therefore while importing such a policy, any reference to such custom user objects will be removed and will not be imported to the destination FMC. To avoid detection issues due to the missing user group, add the customized user objects manually to the new FMC, and re-configure the access control policy after import.

Default Resolution Behavior

When you attempt to import a configuration, the FMC determines whether a configuration of the same name and type already exists. When an import includes a duplicate configuration, the FMC offers resolution options:

• Keep existing

  The FMC does not import that configuration.

• Replace existing

  The FMC overwrites the current configuration with the configuration selected for import. This option is not available if the duplicate is in ancestor or descendant domain.

• Keep newest

  The FMC imports the selected configuration only if its timestamp is more recent than the timestamp on the current configuration. This option is not available if the duplicate is in ancestor or descendant domain.

• Import as new

  The FMC imports the selected duplicate configuration, appending a system-generated number to the name to make it unique. (You can change this name before completing the import process.) The original configuration remains unchanged.

Note	If you modify an imported configuration on the FMC and later re-import that configuration to the same FMC, you must choose which version of the configuration to keep.

File List Resolution Behavior

When you import an access control policy with a file policy that uses clean or custom detection file lists, and a file list presents a duplicate name conflict, the FMC offers conflict resolution options as described, but the action taken varies as described in the table: