This message was deleted.

I think 13.0 is EOL in July 2024, but I have the same question about classic expressions. And is 13.1 ready for production?

Stupid question but are security updates released after EOM? And yeah I've heard not so great things about 13.1. We went from 12.1 to 13.0 last year due to the classic expression and stability issue.

Convert classic to advanced if you can. I haven’t done it personally https://mickhilhorst.com/citrix/converting-citrix-adc-policies-with-nspepi/

Following this thread

EOM = "The date that signifies when a specific product release will have no further code level maintenance. At Citrix discretion, security related updates may occasionally be released to address issues that are reported to Citrix through the vulnerability response process." EOL = "The date that signifies when security related maintenance builds, technical support through phone, e-mail or e-service, and product downloads will no longer be available. Technical support for other issues will be limited to information contained in the Citrix Knowledge Center. If the issues cannot be corrected through this method, then an upgrade path or migration to the latest version or product replacement is recommended." https://www.citrix.com/support/product-lifecycle/networking.html

I'll stick to 13.0 as long as 13.1 is not stable and a new feature version is released.

I upgraded the remaining 12.1 NetScalers to 13.1 last month. The NetScaler upgrade will warn you if something is removed. My classic policies for authentication continued to work on 13.1. I am in the process of replacing them with Advanced. From my understanding, Citrix wants you to use Advanced, but Classic will still work for the time being. I think they would rather have you upgrade than have policies be the hold up.

Thanks @Kari Ruissalo (WyW) and @Matt Sliva Yeah i think classic expressions are still functional but deprecated on 13.1, but I think they're taking it away sometime in Q2. That's good info on EOM. Sounds like I might have a little more time. I would think they'd release updates for any post EOM significant security vulnerability. At least that's what I've seen them do with 12.1. It's a shame to hear there are still bugs in 13.1. In addition to the classic expressions, I have a super old theme in use lol

General consensus is that 13.0 is good and should have no issues with NetScalers running potentially some Classic policies and majority (if not all) using Advanced?

13.0 does work. I've seen a lot of weirdness with NFactor, cannot view policy labels in the UI. they just don't show. NFactor visualizer does not always show the correct updates in the UI. I had to do a lot of cross-referencing in the CLI to make sure all was in place.

This is something I struggle with myself. Trying to figure out how to convert the auth policies. It’s like my brain can’t get out of the basic policy mode

We have recently had to do this for a customer and I think the biggest issue was the inability to bind Advanced auth policies to a Gateway vServer. The customer had both LDAP and RADIUS policies bound originally but we had to create a AAA vServer and then create an n-Factor flow. May not be a massive issue but just something to be aware of. There may be more work required than just converting the policies.

Yea, that is what I have a hard time with. I have setup this on a new deployment with FAS and Azure IdP using AAA vServer before once. It was straight foward. But converting them and to know what is what is where my mind goes "BLANK". I just need to do it more and it will click soon.

@Chris Curson Thanks for that info. We have that exact setup where we have both LDAP + RADIUS configured on the vServer. This is sounding more complicated already.

I'd advice getting rid of the classic expressions irregardless of the version since they seem to cause all sorts of weird issues on the newer builds (even on 13.0)

@mick hilhorst - just pulling you into this thread for visibility, I know you are a NetScaler automation wiz and will probably come up with a "this is the way" forward on this.

Hi All, Not included in my blog (thanks @Ray Davis 🙂 )but some things to keep in mind. The conversion can be done by NSPEPI, but you are not done after this. I got a couple tips I'd happily share.. Be mindful of: *Gateway policies (most important are the session policies). These will not convert when they are still bound. You cannot bind an advanced policy while a classic policy is still bound there. Gateway session bindings use either advanced across the whole NS or classic policies. There is no option to do both. You can however create advanced policies there, you just cant bind them yet until every classic policy is unbound. *There is an old rewrite(?) fix that quite some people still have active. It will break your gateway (and good nights sleep) if you still have it after the conversion. I'm trying to find one of the original articles but can't right now. Sorry for being vague, I will try and pull up one of the old articles for some more clarification later. *Make sure to read the warn_conf logs. Sometimes some policies show up that are not in any way relevant to your active setup. Mostly seen on long-time-use netscalers. *Make sure to disable HA-SYNC if you convert on your secondary first, it will otherwise be overwritten, also, convert on your secondary first and test. If you are stuck on something and need some help, I'd gladly try. Feel free to DM me.

Can you just build us a magic migrate button @mick hilhorst lol

For anybody interested; my colleague Alexander and myself will be doing a live session on this subject: https://app.livestorm.co/the-positive-thinking-company/master-your-netscaler-migration-strategies-and-best-practices-for-a-seamless-transition

https://worldofeuc.slack.com/archives/CKHRXATV2/p1678298021432229?thread_ts=1677876756.438309&cid=CKHRXATV2 But Ray, in all seriousness, Mick should do this!

@Leee Jeffries I’m positive he has the talent to do so. Big task indeed. Maybe……. 🙏

I'm down to work with you on that Mick, the only issue - I don't do this "Python" stuff. Needs to be PowerShell and Nitro.

It can be done, but it's too big of a task sadly. The API does not give a lot opportunities on this topic. You'd need to get the ns.conf file, parse through that data directly and write a tool that can convert the expressions from classic to advanced (which is quite a task). Then you would also need to handle bindings etc in a logical manner that does not mess up your conversion attempt. Additionally you'd need to write some superior regex statements to match all the classic policies.

So maybe a week or so and you’ll be done? That’s is a joke fyi haha

Now you laid out the process Mick, all you need is the time ;-)

I'd suggest you guys push your config in xconfig. There you can spot the classic policies in an instant and do the conversion manually.

I feel uncomfortable uploading config file to an online service... Is it just me?

Don't worry; it's client side Javascript. The config does not actually go to arrow. I work with PTC who manage this tool with arrow, they really do not see your config unless you choose to share it. Even then there was functionality to filter hashed data / IP's and remove them from the file 🙂

do you need to unbind every single classic vpn session policy before you can used a single advanced one?

@Mike Streetz (O_P) did you ever figure out a solution to your policy conversion issue?

Yes, you need to unbind all of them.

pretty sure that’s the solution. Step 1, unbind EVERYTHING