Error while upgrading Multi Domain Server from R81.20 to R82

[PrasannaRout]

migrate_server import fails from R81.20 to R82 with Error -

Failed to import: Failed: Trying to link between 2afa56ef-e5ce-42b9-8ab4-ddb06068122b and b35d3e7f-823a-4581-a7e0-735f10daae65, where feature dependency exists, and the destination object does not exist. Detailed upgrade report is available at /opt/CPsuite-R82/fw1/log/upgrade_report/upgrade_report.html

Multi Domain Server Hardware Models -> Smart-1 6000-XL running in High Availability

Current JHA - R81.20 Take 98

Normal upgrade via CPUSE failed - Found somewhere - upgrades are not supported due to changes in partitioning and system architecture in R82.  So have to go with Advanced upgrade

Procedure Used for Advanced upgrade

Install the latest upgrade tools and deployment agent and any take required to install the latest versions of these products in production.
#cd $MDS_FWDIR
#cd scripts
#./migrate_server verify -v R82 -skip_upgrade_tools_check ( it should succeed)

NOTE - If Pre-Export Verifications Succeeded with Warnings, To export the database, address all the warnings or run the --ignore_warnings flag

#./migrate_server export -v R82 -skip_upgrade_tools_check --ignore_warnings -o /home/admin/<servername>_migrate_export.tgz
offload the migration file.

Do a clean install of R82 . Once the OS, JHF Take, Deployment agent, and installation and upgrade tools proceed to uploading the migration file.

#cd $MDS_FWDIR/scripts
#./migrate_server  import -v R82 -skip_upgrade_tools_check --ignore_warnings /home/admin/<servername>_migrate_export.tgz

[Amir_Senn]

Hi,

Which migration tools build did you use?

[PrasannaRout]

998001160

[Tal_Paz-Fridman]

Do you have Cluster members in your environment? From looking at other cases its seems like a database related to a mirrored object.

The best course of action is to open a case with Check Point Support.

[PrasannaRout]

Yes 2 Multi Domain Servers running in High Availability . Is there any way to find out those UID to which object it points to ? 

[Tal_Paz-Fridman]

This is something that is better left to TAC as it might require a dedicated script or fix.

[Duane_Toler · Accepted solution]

As @Tal_Paz-Fridman said, TAC is likely the best option here.  You can try to look at the database yourself via the management API, but this isn't guaranteed to work:

mgmt_cli -r true -d <MDS domain> show-object uid 2afa56ef-e5ce-42b9-8ab4-ddb06068122b
mgmt_cli -r true -d <MDS domain> show-object uid b35d3e7f-823a-4581-a7e0-735f10daae65

You can look through the upgrade report, and the various logs in /opt/CPInstLog/, $MDS_CPDIR/log/migrate*.log, and the logs in $MDS_FWDIR/log/upgrade* to search for those UUIDs.  That may give you some clues for what domain to search for those object UUIDs.  These could live in the MDS domain (-d MDS) or some specific domain (mgmt_cli -r true -d MDS show-domains).

Again, no guarantees here, but this may help while you await TAC assistance.

[PrasannaRout]

Thanks It helped to find that UID. able to move ahead now . 

[Duane_Toler]

Excellent!  Be sure to mark that as a solution in case others run across this (and add a Kudo, if you don't mind).