IISE 3.1 patching via CLI or GUI preferred?

[wags]

Hope this is not too big of a can of worms......

Is there a preference for applying upgrades and patches to ISE with the CLI or GUI?   I've applied patches and upgrades from 3.0 to 3.1+ via the GUI and have had good success on the deployment I am responsible for.  I applied the log4j patch via the CLI.   I've read quite a bit and seems like there are 2 camps one GUI other CLI.  A previous admin always did his deployment via CLI with great success, and recently another admin  is still cleaning up from failed GUI patches and upgrades (1/3 of deployment still offline).

So has the GUI matured enough to say that it is the best option?  Or should I apply some future patches with the CLI to become more familiar with it because it is somehow superior or safer?

[Arne Bier]

Perhaps I am one of the lucky ones, but I have never had a GUI patch update fail on me - ever - since ISE 2.2. I like the idea of uploading the file via the GUI and then walking away. And at that point, nodes will restart at semi-regular intervals - but this is nothing that should cause too much concern. Perhaps there are legitimate customer cases where the CLI is the only way, because it allows them to schedule and time the outages more precisely (e.g. remove a PSN from the load balancer prior to patching)

If a patch fails then it may reveal an underlying issue with the ISE node that has always been there, but never noticed before - e.g. insufficient/incorrect disk sizing. I think disk sizing is one of the causes of upgrade/patch failures. 

[ahollifield]

I'm with @Arne Bier on this one; I've never had a GUI patch fail.  CLI gives more control on exactly when the PSN services will restart but in a properly designed ISE deployment with multiple PSNs configured on the NADs (or a load balancer), endpoints should not notice a single PSN being unavailable.  

[marce1000 · Accepted solution]

 - I consider CLI 'safer' especially because if you logon trough most tools such as PuTTy you can have a log of the session and review afterwards all that happened in case of special issues or 'dark failures' coming up.

 M.

[wags]

I started when Cisco equipment was putty and orange colored.  CCNP from 2000-2022.  I can honestly say that our situation is the biggest mess I've seen in my career for any vendor.  How can a patch/upgrade brick an entire system and its logs?    Thankful it is not me dealing with it.

I've embraced the change to GUI, it is nice, I've had good luck so far.  However, our other deployment's situation has me concerned for "usable data", during a failure and why I was asking for advice..  I am thinking marce1000's comments, assuming you capture your SSH session,  at least you have some log that is independent of the system that crashes and burns with the data/logs in tow.

[Arne Bier]

I guess the saying "once bitten, twice shy" is very true. I have been bitten by GUI patching in other ways - I had a bunch of PSNs that relied on having a bunch of static host routes configured on them - of course I forgot to "copy run start" on the PSN and then a month later I ran the patch update. After patch update the system was very broken without those static routes, because the GUI patch just reboots without saving the ADE-OS.  I learned from that mistake.

If you find a bug or root cause of your patch failures, please share them here. 

I had an ISE 2.2 to 2.3 upgrade fail miserably because my PSN nodes we 200GB in size - that size issue is probably well documented by now. The linux file system choked on core files and we had to trash the VM and rebuild.

I hope I never have to resort to patching via CLI. With every new ISE version Cisco promises improvements to the GUI upgrade process. Heck, one day they will say it's better to perform an upgrade/patch via REST API. That's when I pack my bags and leave the building.

[Marcelo Morais]

Hi @wags ,

 I prefer to use CLI, 70% personal preference and 30% bad GUI experience on the past  :_(

If you use GUI, you are able to use the following command to check the logs during the Patch install:

ise/admin# show logging system ade/ADE.log tail

Hope this helps !!!

[wags]

I thank all who replied with great thoughts and ideas.   

Arne, We will never know what exactly happened.  The admin and TAC have basically moved on.  The machines  appear to be back ready to rejoin the deployment after several months.   Also, not being the person who was actually doing the work, I am not able to say if there was human factor contribution.

Marcelo, great command.  It appears that is documented in v2 docs, but maybe not v3.  Will look further and then try to read the document it shows up in to hopefully find other nuggets. 

Again thanks.