Upgrade failure of CRS 313 to CRS 405 ...ldap failure?

chris_b · ‎12-10-2007

Trying to upgrade a multicluster (5 servers)from ccm 333 to 335 with CRS 313 and then on to 423 with CRS 405. I assume that the ccm goes first since the CRS 405 is only compatible with V4 ccm so i got the CCM up to 423 and left the CRS at 313, then commenced the CRS upgrade process to lift the V3 to V4. all goes well, and i can Bars backup the CRS 313 using CD #1 as expected, i re-image the CRS server to the higher OS (2000-4-3a) and then start the upgrade process, which starts with a partial Bars upgrade up to 19%, as per the cisco procedure. CRS build continues and finally i am prompted for CD #2 and #3, but then following the server restart things go wrong. The restore continues and fails at 63% trying to link the CRS to the Ldap server? and i end up with a CRS that i can only login using Administrator / ciscocisco which is only partially data populated. Is my upgrade sequence wrong? Cisco docs cover the individual box's ok, but not the relationship between ccm and crs.

added a screen dump of the event.

any ideas?

kbyrd · ‎12-10-2007

Chris, we had a similar problem when we did the upgrade. I cannot find the specific bug ID we hit, but we had a "team ID" that included a "/" in the name that was valid with 3.5 but was an invalid name under 4.0(5). When BARS tried to restore, it would blow up when it hit that name. We renamed the team to something else without the "/" and the upgrade went flawlessly after that. Good luck.

chris_b · ‎01-02-2008

This issue has been addressed by one of your TAC engineers,(Brendan Shank)... The bug is CSCsh48057 - Backup/Restore/Upgrade of CRS fails - TCP connections to DCD maxed out...and is solved by loading the Sr1 upgrade, I guess this means that it is not possible to upgraded from a V3 to V4 CRS since it is not possible to load the Sr1 before the upgrade process starts..Maybe CRS 404 works ok?

Cheers

Chris

kbyrd · ‎01-02-2008

I had a slight error in my previous response. We actually upgraded from 3.5(4) to 4.0(4). The reason was that an upgrade directly to 4.0(5) required re-imaging the server. The alternative that we chose was to go to 4.0(4) - which did not require the re-image - and then upgrade from 4.0(4) to 4.0(5), which also did not require a re-image. We thought that was a less risky upgrade because of the time to re-image.

So, I would recommend the 4.0(4) upgrade first.