ISE 2.1 to 2.3 failed

[konsecioner]

Hello, I tried to upgrade my ISE from 2.1 to 2.3 and this is an error log I've got:

Tue Nov 14 22:50:21 CST 2017 stty: standard input: Inappropriate ioctl for device
Tue Nov 14 22:50:21 CST 2017 STEP 1: Stopping ISE application...
Tue Nov 14 22:51:23 CST 2017 STEP 2: Verifying files in bundle...
Tue Nov 14 22:52:07 CST 2017 -Internal hash verification passed for bundle
Tue Nov 14 22:54:32 CST 2017 STEP 3: Validating data before upgrade...
Tue Nov 14 22:56:26 CST 2017 STEP 4: De-registering node from current deployment...
Tue Nov 14 22:57:14 CST 2017 % Error: De-registering node from current deployment failed!
Tue Nov 14 22:57:15 CST 2017 Starting application after rollback...
Tue Nov 14 22:59:41 CST 2017
Tue Nov 14 22:59:41 CST 2017 % Manual rollback required: Perform the following steps to revert node to its pre-upgrade state:
Tue Nov 14 22:59:41 CST 2017 -Ensure that node is still present in current deployment from Primary UI; if it is not present, register this node back again.
Tue Nov 14 22:59:53 CST 2017 stty: standard input: Inappropriate ioctl for device
Tue Nov 14 22:59:53 CST 2017 Initiating Application Upgrade...
Tue Nov 14 22:59:53 CST 2017 % Warning: Do not use Ctrl-C or close this terminal window until upgrade completes.
Tue Nov 14 22:59:53 CST 2017 % Application install or upgrade cancelled.

please help,

Neil

[Arne Bier · Accepted solution]

Hey Neil

Did you give the URT (Upgrade Readiness Tool) a try before doing the upgrade ?  I would highly recommend this because then you can at least test the integrity of the ISE database.  The URT tool can be downloaded and you run it on the Standby PAN without disrupting operations.

Having said all that, I have just had a disaster after disaster with the upgrade process.  I had a similar problem to yours.  I fixed it by restarting the application on the node and then upgrade proceeded.  Maybe it was just luck.

My advice is: don't upgrade!  Yes, don't upgrade.

Install a fresh ISE 2.3 and then restore your latest backup onto that new node.  Then, one by one, kill the other nodes and register them into the new 2.3 deployment.  I tell you man, this is the way forward.  I have spoken to many engineers who have given up on ISE upgrades since 1.x days because the code is appallingly bad.  And since you are going 2.1 to 2.3 you'll have no issues.

Just one other thing.  The Policy Sets in ISE 2.3 not only LOOK different - sometimes, VERY different - prepare yourself for that.  But also, the conversion that Cisco does when restoring/upgrading to 2.3 is something you need to understand.  It's explained in the Upgrade guide but it's painful to understand.  I had to test my stuff in the lab and then analyse the results.  Make sure you don't mix and match the Allowed Protocols WITHIN an Authentication Policy.  It will create new Policy Sets as a result. 

Test it, then test it and then test it again.

So far 2.3 patch 1 is running nicely

[Cody Hensc303]

I will second Arne's statement of "don't upgrade". After spending a good part of my weekend rebuilding after and upgrade from 2.2 to 2.3 gone wrong, I can safely say that the upgrade process is not the best route. I asked the TAC engineer I was working with; and he agreed with me that if you are able to that the best route is to stand up new servers and restore your config (it upgrades the database to the new code level during restore). So if you have the technical skills/ability to stand up fresh VMs from the .iso, I would recommend going that route.

[Frank Lothar Weber]

---

@Arne Bier wrote:
Make sure you don't mix and match the Allowed Protocols WITHIN an Authentication Policy.  It will create new Policy Sets as a result. 

---

Hi, Arne.

What exactly do you mean with that sentence ? Something like this: ???

If so, could this be one of the reasons, all upgrade processes (URT, install 2.3 and restore 2.2 backup, etc.) fail on our deployment ???

Rgs

Frank

[Arne Bier]

Hi Frank

apologies for the slow reply. 

In your Authentication Policy you only have one Policy (AUTHENPOL_wired_eap) and it has its associated Allowed Protocols.  When you upgrade to 2.3 that will remain the same.

What I was talking about is the case, when you have multiple Policies (e.g. AUTHENPOL_wired_eap and then AUTHENPOL_wireless_eap) and each one has its own Allowed Protocols, then ISE 2.3 will create two new policy sets for you.

It's all (badly) explained in the Admin Guide and I don't profess to understand it.  I gave up trying to understand it and eventually just tested it in the lab.  My workaround prior to 2.3 upgrade was to make sure I didn't mix and match Allowed Protocols within the same Policy Set.

[PAUL GILBERT ARIAS]

In case anyone is interested. I had the same issue and stopping and starting the application solved the issue. I did application stop ise and application start ise, after that I was able to run the upgrade.