R80.10 is a major-version upgrade from R77. Other than fully exporting and fully importing, what are my options?
One recommended approach is to use the gradual Multi-Domain upgrades.
You start with upgrading your Global and MDS domain, and then upgrade Domain-by-Domain. This approach also supports environments with global policies (as well as environments without global policies...).
Why is this a good idea?
- You get easier control of your time. Instead of waiting for a full system upgrade, you can pause, observe the results of a few domains, and continue later.
- You can get a glimpse of your data as seen in R80.10 SmartConsole quicker than before.
1. Check your readiness for R80.10:
Either use the Check Point Upgrade Simulation Service to see if your DB is completely ready for upgrade, or run the full pre-upgrade verifier on your R7x machine. Check the resulting HTML page or log file to see which domains can be upgraded right away, and which domains require any preparations that you need to apply before upgrading them.
2. Install a clean, R80.10 Multi-Domain machine
3. Prepare for export: Add the R80.10 migrate tools to your R7x machine and extract them.
4. Upgrade the global domain:
Note: if you don't have a global assignment in your R7x environment, you can skip this step.
a. On your R7x machine:
migrate export [file]
b. Copy the file to the R80.10 machine
c. On your R80.10 machine:
- Your global domain and MDS domain are in R80.10!
5. Upgrade your first Domain.
a. On your R7x machine:
i. mdsenv [domain server name or IP]
ii. migrate export [file]
iii. copy the file to the R80.10 machine.
b. On your R80.10 machine:
i. Create the domain without starting it up using the R80.10 API (creating a domain without starting it up is actually only possible using the API):
# mgmt_cli --root true add domain name <my_domain_name> servers.ip-address <my_IP_address> servers.name <my_domain_server_name> servers.multi-domain-server <R80.10_multi-domain-server_Name> servers.skip-start-domain-server true
ii. Use the cma_migrate command to migrate your exported domain to the new server.
# cma_migrate <source management tgz file> <target Domain Management Server fwdir directory>
# cma_migrate tmp/branch_office_domain.tgz /opt/CPmds-R80.10/customer/branch_office_domain/CPsuite-R80.10/fw1
For more information about upgrading, visit the admin guide: http://downloads.checkpoint.com/dc/download.htm?ID=54846
I understand the idea, but I have two issues:
Am I right?
Do we have an answer to the VSX environment question from Ivo ?
Could i for example migrate one CMA/VS at a time from an R77.30 MDS to separate hardware R80.10 MDS or would i have to upgrade the whole existing MDS box from R77.30 to R80.10 for all customer CMAs in one go ?
Are there any other options I have not thought of ?
The licensing part can be sorted with evaluation licenses.
If there are a lot of domains involved, you may need to have your account team request the appropriate license with the appropriate timeframe.
For VSX, I don't believe you have to migrate all domains in one go.
Remember that you're going to have the same Internal CA key on both the "original" R77.30 and the "migrated" R80.10.
This means you should be able to install policy and make VS changes.
I think the question is relating more to the relationship between VSs across domains. For example, let's say we have VS0 that lies in CMA 0 and a VS instance in another domain, CMA 1. In CMA 1 there are references to VS0 in the slot objects. So if you build your R80.10 MDS and migrate CMA 1 over before CMA 0 I would believe you're in for a bad time. I imagine the supported path here would just be to ensure that the domain housing VS0 is migrated in first, then dependent domains coming after.
Regarding "Remember that you're going to have the same Internal CA key on both the "original" R77.30 and the "migrated" R80.10." :
Does this mean that the SIC will remain intact with both CMAs (DMS')?
In this case, what will prevent an accidental policy push from old R77.30 CMA?
How would the gateways or clusters know where to fetch the policy from on reboot or cpstop/cpstart?
The only way to prevent this, would be to explicitly deny the old CMA IP access to the gateways.
The SIC will indeed remain intact and is moved along to the new CMA/DMS.
The masters file is updated after you push a policy from the other environment, from that point on all logs will be sent to the log server defined in the environment you are pushing from.
This is also why you can easily do a migration without actually moving to the new DMS until you push the policy. Last week I used this to be able to push the policy later in the evening while I did the migration of the CMA during office hours.
All related VSX CMA's will need to be migrated at one go, you cannot make changes to the VS'es as long as the main VSX CMA is not on the same version. Next to that you cannot push a policy unless you want to have the VSX cluster itself to move between the 2 master CMA's all the time while you are migrating.
In other words it is really not recommendable to NOT move all related CMA's in one go.
that's if you're a VSX user.
Retrieving data ...