Uninstall redundant patches for quick redeploy on ISE 2.4

[cnegrete]

Hi everyone.

First a small background.

My customer needs to run some Acceptance Test Protocols, which includes the complete deletion of a VM (which runs a ISE PSN), and restore it from scratch.  We use one of the ovf files to create the VM, and we need to patch it to be able to join the deployment.

Per CSCuz23479 we need to manually patch the ISE PSN with 3 different patches at the moment (1,5 and 6) before it can be restored to the deployment and be able to run. The problem is that last time we tried to do this, the first patch took about 25 minutes, the second about 35, and the last one went on for more than hour, with no network connectivity (later that night it started answering but since it wasn't added to the deployment it was silently ignoring all TACACS requests).

The question here is, what are the implications of, say, removing patch 1, 5 (which was even removed by Cisco from the download page), and just leave 6 installed? We also would like to upgrade to patch 8, but the need to do patch 1, 5, 6 and 8 is just not practical for this environment, the server needs to be up and running as fast as possible.  Is this doable? I'm under the impression that the patches are cumulative, so if we remove 1, 5, 6 and leave just 8 it should work fine, is this correct?

Thanks for your time, please give me good news so we can restore the server quickly :)

[Damien Miller]

So there are a few options here. Since this bug only impacts upgrading from the GUI, you can disregard per patch matching if you plan for an upgrade in the future using the CLI, my preferred method anyways.

In order to remove patch 1 and 5, you must first remove 8 then 6 first. You can only remove the most recently installed patch. You can work on backing out patches, or you could rebuild each node one at a time installing only p8. Either way you go about it there is significant work.

So just to clarify here, to remove patches 1, 5, and 6 you must;
Remove patch 8
Remove patch 6
Remove patch 5
Remove patch 1
Install patch 8 again

There is certainly some risk involved in going through this process. I would be inclined to ignore the matching opting for understanding that upgrade from 2.1 to 2.4/2.6 would be via the CLI or restore method. Alternatively choosing to rebuild each node one at a time installing only p8.

[Jason Kunst]

The patches are cumulative. Why would you want to remove the old ones? What’s the problem leaving there? Since it’s cumulative does it even matter? Seems like asking for trouble

[Damien Miller]

I completely missed 2.4 in title. I assumed 2.1 since it has 8 patches and is impacted by that GUI upgrade bug. Agree with Jason, non issue at all if on 2.4.

[cnegrete]

The issue here is that if one of the machines dies, to restore it we have to use the ISO/OVF file, then install patch 1, then 4, then 6 (and even 8 if we install it), and then register the server to the deployment. Will it work if I only install the latest patch and then try to register it to the deployment? From what I can remember it doesn't work, it will bark about the server not having the same version/patch set (1,4,6) and it will not be registered.

We did the test last week, and had to install patch 1 (about 25 mins), then patch 4 (another 30-40), and patch 6 in the end (which took more than hour). We don't have access to the console, just ssh access, and after the first reboot in patch 6 the machine wouldn't respond pings or ssh (we assumed it died). It started answering about an hour later.

[Jason Kunst · Accepted solution]

it should honor just the latest patch as they are cumulative, please open a tac case otherwise to investigate further