Jump to content
Welcome to our new Citrix community!

Upgrading from 9.2


Christian DiGi

Recommended Posts

Hi All,

 

We have an ancient Citrix NetScaler VPX 9.2.  I hear there are some issues with that release, and we wish to upgrade. 

 

We also want TLS 1.2 or later.

 

My first question is whether it is safe to upgrade from this version on the fly, or whether we should order a new device, configure it, and cut over.  

 

Not asking for any guarantees, merely whether anyone has had success moving on from 9.2.

 

The second question is to what version should we upgrade?  11.0?  11.1?  12.1?  Something else?

 

Our current NetScaler never breaks a sweat, so in terms of performance, we're happy.  We do however, want the better security, and to move on from the exploits or whatever are inherent in 9.2.

 

I welcome anyone's thoughts and experiences.

Link to comment
Share on other sites

If you can't find the old copies of the documentation to confirm this, it will be harder to confirm.

From memory, I think you have to go from 9.2 to 9.3, then a 10.x (Can't remember if 10.1 or 10.5) version before you can go to 11.1 or later (due to changes with bsd shell in one of those upgrades were implemented).  11.1 would be your safest interim target before moving to 12.0/12.1 or later (if your hardware can run it).   I looked, but I don't have enough of the old admin guides to confirm, but using google to search the old forums will turn up a few a options.  As an example from these ancient threads mention going from 9.2 to 9.3 and then 10.x:  https://discussions.citrix.com/topic/327133-netscaler-92-to-10-upgrade/

But interim unsupported releases aren't going to be possible for you.  So if you want to do this "in place" then BACKUPS are critical, but a separate appliance would be most flexible and safer.

 

The fact that you are still on 9.2 makes this high risk. But see my thoughts on the hardware next as well.

 

 

First, if this is physcial hardware, you need to see if it can even run anything 9.3 ncore or later releases and if the hardware is even supported for a 12.1 or later release. Because some of the 9.2 hardware would have been classic kernel only, if I recall correctly. In which case, you have to have a physcial hardware change.

If this is a VPX, are you running Classic Kernel or ncore?  As the classic (limited vcpu) will not upgrade in place to ncore and you will need to have a new image version.  (My guess is hardware though.)

 

If anyone thinks I've remembered this wrong, please feel free to correct me.

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Thank you both for your answers, and know that they are appreciated.  I am doing some research to confirm what the hardware is.  It looks like we have a VPX implementation.  I'll find out about the Classic Kernel or ncore.

 

With regarding to moving to 12.1, I know we can export the current configuration into a script.  Does anyone have any expertise on whether that version of the configuration script will execute correctly on a 12.1 NetScaler?  Or perhaps there have been changes in the myriad interim releases which make that configuration language obsolete.

 

I welcome any expert thoughts on that matter.  If the configuration script is portable, then most likely we would simply order new hardware and build from the script.  That seems like a more pain-free approach.

 

Thanks very much.

Link to comment
Share on other sites

If its vpx (aka a virtual machine), you have more flexibility.  If you do a show ns version it should say a build  number, which should indicate classic vs ncore (unless I'm remembering wrong and 9.2 was ncore only; but I think it was the last build to do both.)

show ns version will give you build number and there is an indicator of classic vs ncore on the 9.2 release.

show ns license will confirm if you are VPX what license and bandwidth limit you have.

 

For the most part the 9.2 config will work on 12.1, BUT the caveat is that any deprecated features/commands will be ignored and/or lost.  With this big of a jump, your biggest risk are features that moved from classic to advanced engine or settings that changed signifcantly overtime (like available cipher suites).

 

Best attempt for you would be to deploy a test vpx instance (like in an offline lab config initially to avoid network conflicts). This vpx would be a 12.1 or 13.0 deployment. You could then import your config (since this system should not be on the live network, you shouldn't have to worry about ip conflicts). And then you can review whether any settings are missing or wonky or not prior to doing anything against the production system.  Even if you have an MPX, spin up a test VPX on a 12.1 or 13.0 build to "test" the portability of the config to look to see if there are any major errors.

 

Features most likely affected 9.2/9.3 going to much later (though this may not be comprehensive):

1) Integrated Caching went from classic only to advanced only in either 9.0 or 9.2. If later, then thinks may be weird. Early releases would convert the classic to advanced, but not always successfully during the upgrade. If you just load a bunch of classice cache policies onto a later build that is advanced only, it will likely ignore and delete them so you would have to recreate them manually, if in use.   MOST other features that were classic dependent were dual supported as classic or advanced. And as long as the classic engine isn't fully deprecated, your features should be okay...but 9.2 was current as of 2009-ish...so there's a lot to forget over the years.

2) Gateway would have undergone significant changes so as Carl mentioned, any gateway customizations may be lost or not work as expected on newer releases and have to be redone via the portal themes and rewrite policies.  

AND, if your 9.2 environment was frontending a legacy Web Interface/XenApp config you may have some compatibility issues with the lastest Gateway supporting something without storefront or that old of an XA version (it depends on versions  of all components here.)

3) Some old parameters/syntax may have been deprecated, so there may be some impacts that can't be predicted. 

4) Use of MIP will mostly still be supported but flagged for deprecation. It would be a good idea to switch MIPs to SNIPs prior to the porting of the config.

5) The custom monitor location moved from the old builds to the current location of /nsconfig/monitors. But I don't recall when that path change was made. So backup any custom monitors first. 

 

I know lots of little parameter changes...but the impact really depends on what features you are using.

 

 

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...