topic Re: R77.30.03 to R80.30 Endpoint migration hell in Endpoint

R77.30.03 to R80.30 Endpoint migration hell

Howard_Gyton — Tue, 10 Sep 2019 16:11:57 GMT

Hi,

After attending a recent CheckMates meeting, and being invited to share my exerperiences of this process with rest of the community, here goes.

Having done several of these Endpoint migration before, having been a user since the original R80/E80 release on Windows, and being one of the first European sites to have a Gaia Endpoint server, I was used to the process, however as I found out R80.30 Endpoint was somethig of a disaster for us.

The new server was installed without error, but it all went wrong when attempting to import the old R77.30.03 database, so I opened a support ticket.

1. Database failed to export with the R80.30 migration tools. I was provided with some code to tweak the database, and this allowed the export to proceed.

2. Database failed to import. It turns out you need to add the AntiMalware signature update installed in Gaia first, as per sk151533.

3. We also need to confirm the permissions on the following file: /opt/CPuepm-R80.30/engine/conf/updates/bin/8.6.0.34/confZLToProduction.xml

4. Was also advised to use the R80.30 servers own migration tools and not the R77.30->R80.30 migration tools used for the export.

5. I was also provided with an "AM script" that would make further tweaks to allow the import to succeed.

6. Finally, and this was the kicker, at the point I ran the migrate import, I had to quickly edit the file "/opt/CPsuite-R80.30/fw1/tmp/migrate/uepm_configuration", and remove the line "AM_blade_exist (true)", and this had to be done during the import and before it go too far through the process and failed again.

Finally, after all of this we had a functioning R80.30 Endpoint server, but even after all this we found that we could not manage new MacOS machines, so a further hotfix was provided to fix this.

TLDR, this process made me wonder what QA process was followed for this release? Endpoint isn't a niche product as far as I know, and neither would an R77.30.03 migration to R80.30 be a niche process, so it concerns me that it was released in this state.

Howard

Re: R77.30.03 to R80.30 Endpoint migration hell

PhoneBoy — Tue, 10 Sep 2019 23:34:27 GMT

That process could definitely be improved.
Was this a standalone endpoint management that you were Migrating?

Re: R77.30.03 to R80.30 Endpoint migration hell

Howard_Gyton — Wed, 11 Sep 2019 07:16:04 GMT

Hi,

Yes, it is. I assume that a greenfield site would have none of the import issues we experienced, although I suspect the MacOS issues would be there.

I would hope that when R80.40 comes out more rigorous testing be carried out for those that have not yet jumped to R80.x.

Howard

Re: R77.30.03 to R80.30 Endpoint migration hell

Alex- — Wed, 11 Sep 2019 08:40:49 GMT

Interesting story. Did you only have this with R80.30?

I remember migrating R77.30.03 to R80.20 using the published migration tools without any issues. However it was a fairly small deployment without all the blades and no FDE and MAC so maybe it was a factor.

Re: R77.30.03 to R80.30 Endpoint migration hell

Howard_Gyton — Thu, 12 Sep 2019 08:04:00 GMT

Yes. We've migrated servers before but all were R77 of one flavour or another.

We recently migrated our R77.30 firewall manager to R80.30 and that was a snap in comparison, and just worked....although initially we had zero logging from the firewall but a database install post-migration sorted that out.