Upgrading to ISE 2.3 - dude, where's my Policy Sets?

[Arne Bier]

I finally took the plunge to upgrade my ISE2.2 patch 2 to ISE 2.3 patch 1 (the new patch 1, not the old patch 1 )

It was inevitable because there are features I truly needed.  But I was dreading the new Policy Sets, because I had just got my head around how ISE 2.2 works and 2.3 didn't immediately feel like an improvement.

I will probably change my opinion on that in future as I get more used to it, but I currently can't see what the fuss is all about.  It certainly doesn't look pretty and it doesn't read more easily.

The point of this document is to showcase the Policy Set migrations that were performed during my ISE 2.3 upgrade because this is specifically highlighted in the ISE 2.3 Upgrade Guide as well as in the Release Notes, but I couldn't make much sense of it prior to the upgrade to gauge the impact. I just went ahead and upgraded in my lab and then had a look at the result.

In case anyone is interested, the attached document shows the before (upgrade) and after (upgrade) to get an idea of the upgrade logic.

My advice to anyone attempting upgrade to 2.3 is to test this out in lab first to see what the Policy Sets look like.  It may be a bit of a nasty surprise to anyone who upgrades to 2.3 without bearing this in mind.

[ognyan.totev]

I tested it before month and i really dont like new policy sets style,they make some mess in my head. I prefer old style of policy sets and i am still on 2.2 version.

[Ali Koussan]

I do not know the reason behind the policy set changes in 2.3, I'm working on ISE since the very first release, this was the worse change I have ever seen so far on ISE. I did not like at all.

[Arne Bier]

Give it some time. It also messed with my head at first.  Now I am used to it.  It certainly wasn't a subtle change, that's for sure.

What the world needs now is a way to export these Policy Sets and then Import them into a new deployment.  I think ISE 2.4 was heading that way. 

[Greg Gibbs]

I found the same issues with duplicated Policy Sets when testing in 2.3 Beta with a customer. After some testing in my lab, I found that some minor changes to the Policy Set conditions prior to upgrade mitigated the duplicates and resulted in a much more streamlined structure post-upgrade.

The key is to modify the AuthC Policy to reduce the number of different Allowed Protocols lists and Use sequences, including having the Default rule just mirror your last (or any other) policy above.

Example:

Starting AuthC Policy used different Allowed Protocols lists for 'PEAP' and 'MAB' and a unique Default policy.

My new Allowed Protocols list 'PEAP_MAB' simply combines the two.

After the changes, my AuthC Policy looked like the below screenshot. I used the same logic to modify any other relevant Policy Sets.