Rollback ISE 2.2 to 2.0

[geekit]

I am planning an upgrade from 2.0 to 2.2 in the near future. While my documentation for the upgrade is complete, I do not have a roll back plan. 

Sure I can backup the config, export the certificates, etc. I have be scouring the web for days now and have not found a sound roll back plan. Our two ISE servers are Virtual but taking a snapshot is not an option so my hands are tied there.

Any suggestions?

[marce1000]

 Yes, and I too feel it is  dead-locked situation, because even if you have 2-radius servers in a cube, there's no guarantee that an overall upgrade will end smoothly (ISE has been prone to the 'step50-from-102 failed syndrome...). I feel built-in rollback can not be guaranteed too a by the product. It's a complex product and not suited for  upgrading production environments. The only alternative I see is to build a new deployment from the current production environment, with the intended ISE version and import the configuration from a backup of the production configuration OR enter the intended policies manually (again). We did the latter, you then have the benefit to be able to  test the new environment, before switching it to production (changing radius servers on the switches(e.g.)),

M.

[geekit]

I agree. After everything we have discussed it looks like this is the route we will be taking. It is just surprising to me that Cisco doesn't have some type of rollback procedure for this.

[Octavian Szolga]

Hi,

My opinion about this (what I've done in the past) is just upgrade one VM, test it intensively (does 802.1x, VPN, WiFi, profiling, guest work?) and if everything ok (after a day or two where you've used only the upgraded box) just upgrade the other one.

In case something goes wrong, just delete/reinstall the (failed) upgraded box and join it to the same deployment with the 2.0 box ;)

Regards,

Octavian

[Arne Bier · Accepted solution]

ISE is not in the league of a well thought out product in terms of install, upgrade.  It's a pain to install (cannot be automated) and pain to upgrade (upgrades usually break the deployment).

If you are forced to upgrade (rather than rebuild from .iso and restore config backup) then at least run the URT tool first.  That gives some level of assurance that at least the upgrade *process* will work.  It does not tell you how many bugs Cisco just introduced though ;-0

In large distributed deployments you can upgrade your standby PAN, all MnT's and then all PSN's ... and then monitor for a while.  If you are happy, then you upgrade the last node, the standalone PAN running the old release.  That IS your backout plan.  Yes it's crappy but that's it.  You can rebuild the entire deployment from that old PAN node.

In a VM environment it's actually a lot easier.  We NEVER upgrade our ISE releases.  Yes. Never!

We create a duplicate set of VM's and install the .iso and get it to setup prompt.

Then we shut down each old ISE VM as we go along, and replace like for like (we build the master PAN node from a config backup - that creates the new deployment). 

The good news is that the old VM is shut down and the ready for power-up in case of a backout.  So the VM environment affords you the luxury of creating a shadow copy of the VM's in case you need it.