Jump to content
Welcome to our new Citrix community!

Net Scaler VPX Question - Upgrade Question


Michael Harris

Recommended Posts

Hi Citrix Community, 

 

I have an upgrade question that I am not sure of the best path forward.  

 

Background info - 

I have a current Xenapp 7.9 environment that is connected to a NetScaler 11.1 device (remote connectivity).  The Citrix receivers are currently connected to a load balanced vip on the Netscaler device.

internal_lvip.company.com.

 

I am in the process of migrating to LTSR 1912 and as such have built up a new clean install of 1912.  

 

My questions -   

-  I am wondering if my single Netscaler device can connect to both environments , old and new?  

-  Can I keep the same external DNS  and have it service both sites?  I know I can configure Store Front to connect to multiple sites/farms, I'm just struggling with how that looks.  

- Can I keep the same internal load balanced VIP ?  meaning that I would not have to change the URL the receivers are pointed to? 

- Should I just install a new instance of Netscaler and start from scratch ? would love to just be able to in place upgrade the 11.1 to 12.1 and connect it to the new environment.

 

My Citrix is a bit rusty, so I am reaching out to see what's the best possible path forward.

 

Thanks in advance.

 

 

 

Link to comment
Share on other sites

-  I am wondering if my single Netscaler device can connect to both environments , old and new?  

Yes, it can.

 

-  Can I keep the same external DNS  and have it service both sites?  I know I can configure Store Front to connect to multiple sites/farms, I'm just struggling with how that looks.  

No. You would need a different FQDN for the second site (if you need them to both be accessible). 

 

- Can I keep the same internal load balanced VIP ?  meaning that I would not have to change the URL the receivers are pointed to? 

If you want to be able to keep both environments up at the same time, you should create a second LB VIP for the new environment.

 

- Should I just install a new instance of Netscaler and start from scratch ? would love to just be able to in place upgrade the 11.1 to 12.1 and connect it to the new environment.

A new instance of NetScaler is not necessary, you just need to create a new gateway virtual server. If you plan to do an in-place upgrade, make sure that you sabe a copy of the configuration first.

Link to comment
Share on other sites

There might be some confusion on your original request and exactly which things you are trying to deploy in parallel vs. migrate.

 

For this particular statement:

10 hours ago, Michael Harris said:

I know I can configure Store Front to connect to multiple sites/farms, I'm just struggling with how that looks. 

 

If you want to have one storefront store access both XD/CVAD Sites, the answer is YES.  There might have been some confusion about whether you meant two different gateways, two different storefront environments, or two different XD/CVAD Sites...and even I can't tell for sure which one you were asking about as it initially sounded like you were trying to keep both your OLD NS 11.1 and your NEW NS 12.1 accessible at same time...which would require separate fqdns.

 

If you want to have one StoreFront Store to aggragate your XD 7.9 and your NEW CVAD LTSR 1912 (as you continue your migration), you would do the following:

1) Deploy the appropriate storefront version and/or upgrade. You could then switch your lb vserver (same fqdn) from old to new (if not doing an in place upgrade).

2) On your Store (Store-1), you would keep your existing XD79Site entry and the list of its xml brokers/controllers.  Then ADD a new Site entry (under Manage Delivery Controllers) for your new CVAD1912 Site and lists 2 or more controllers with proper xml brokers/ports for the new environment.  This would be separate rows in the "site list".  Old Site, only has list of its controllers; new site only has the new controllers.

 

When users connect to this store via path https://<storefront lb fqdn>/Citrix/Store-1Web or /Store-1 (depending on client type and what your actual store name is), it will present any published apps/desktops from OLD environment in parallel with apps/desktops from new environment. As you migrate, you can unpublish from OLD and publish in NEW for one consistent list of resources.

 

3) The load balance FQDN wouldn't have to change. And internal users would still use the internal Storefront LB FQDN for resources.  And external users could still connect via Gateway to this store as well.

 

----

this isn't a complete "plan" as there a couple of details that should be defined first.  But based on what I think you were describing above, you have choices depending on what you do in parallel and what you do in-place.  If you use one storefront store to aggregate your old and new sites, you can keep most of your gateway and storefront fqdns as is. If you decide you want to have the option to switch users from old gateway to new gateway or old storefront to new storefront, then separate deployments and separate fqdns would be needed.

 

So for example...

If you are going to keep XD79Site (c1, c2) and deploy a new parallel CVAD1912Site (c3, c4)

You could then deploy a single Store to aggregate both (but remember, your current version of storefront will likely have to upgrade to a minimal version...so if you decide to build in parallel it may give you some more options.

 

You can still load balance this storefront. If upgrading the existing, then the lb fqdn and store path don't change. If you build in parallel, then you *could* keep the lb fqdn the same but point to the new storefront deployment (and its store path). If there's an issue, just point to back to original storefront.  The main point is whether you view an inplace upgrade a risk that you want a rollback option for by reverting VMS (for an inplace upgrade) OR having a new build running on a separate set of VMS and hiding change from users. 

 

If instead you want some users to go to https://storefrontold/citrix/<storename> while others go to https://storefrontnew/citrix/<storename> you would have to have two separate fqdns and load balancers.

 

 

For gateway deployment, you *should* be able to upgrade from 11.1 to 13 (or 12.1 as appropriate), but 1) backup your config first and have a recovery plan. If you have a lot of gateway customizations/portal themes, it will be best to TEST this first.  An in place upgrade usually works, but if this is a vpx that you can make a copy of and test in an isolated environment, you'll have a better chance to know for sure.  Again, what is your recovery plan if there is a problem (config backup/downgrade/restore OR rollback to a vms snapshot, etc...).

If the storefront fqdn hasn't changed, then the gateway config session policies won't change. You might upgrade your STA lists on both gateway and storefront to include resources from old and new site and as you decommission on 7.9 environment both STA lists would have to be updated.

 

The trick for you is to identify how your build out will go and what minimizes risk or what minimizes your effort.  Then plan the site deployment, the storefront deployment (one or two) and then you can define the gateway deployment (one gateway with single store doing two sites; one gateway with old store vs new store; old gateway and old store vs new gateway/new store).  That plan will help you see whether you can use your existing gateway fqdn or need two and whether you can use a single storefront internal fqdn or need two.

 

 

 

 

 

 

 

 

  

 

 

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

Thanks everyone for getting responding.  I apologize for the significant delay in responding.  My original entry came at a point where there was extra time on hand.  However Co-Vid affected our business significantly (Bus Transportation) and required that I pivot to help in the more pressing areas.  I am not coming back to this project and would like to complete it.  Based on what is written here, I think I could do the following.  

 

Netscaler - Upgrade the NetScaler.  Since the Netscaler operates independent of the XA environment, it makes sense to go ahead and just deal with that as a stand-alone.

 

Store Front  -  I should be able to use the SF 1912 servers to replace the SF 7.9 servers.  I would need to have the site name stay the same between sites.  The internal SF name is currently storefront.domain.com which is a load balanced vip.  I would need to add the 2 new SF 1912 servers as hosts and bind them to this VIP.  Then unbind the 7.9 SF.  

 

At this point, both my Net Scaler and SF would be updated and I'd have both old farm and new farm available simultaneously.   I would not have to change the URL for the internal clients (other than upgrading them).  I would be able to decommission the old farm by publishing apps from the new and deleting them from the old.  

 

Did I get it correctly?   

Thanks again for the response, it's much clearer now.  

 

 

On 4/23/2020 at 9:43 PM, Rhonda Rowland1709152125 said:

There might be some confusion on your original request and exactly which things you are trying to deploy in parallel vs. migrate.

 

For this particular statement:

 

If you want to have one storefront store access both XD/CVAD Sites, the answer is YES.  There might have been some confusion about whether you meant two different gateways, two different storefront environments, or two different XD/CVAD Sites...and even I can't tell for sure which one you were asking about as it initially sounded like you were trying to keep both your OLD NS 11.1 and your NEW NS 12.1 accessible at same time...which would require separate fqdns.

 

If you want to have one StoreFront Store to aggragate your XD 7.9 and your NEW CVAD LTSR 1912 (as you continue your migration), you would do the following:

1) Deploy the appropriate storefront version and/or upgrade. You could then switch your lb vserver (same fqdn) from old to new (if not doing an in place upgrade).

2) On your Store (Store-1), you would keep your existing XD79Site entry and the list of its xml brokers/controllers.  Then ADD a new Site entry (under Manage Delivery Controllers) for your new CVAD1912 Site and lists 2 or more controllers with proper xml brokers/ports for the new environment.  This would be separate rows in the "site list".  Old Site, only has list of its controllers; new site only has the new controllers.

 

When users connect to this store via path https://<storefront lb fqdn>/Citrix/Store-1Web or /Store-1 (depending on client type and what your actual store name is), it will present any published apps/desktops from OLD environment in parallel with apps/desktops from new environment. As you migrate, you can unpublish from OLD and publish in NEW for one consistent list of resources.

 

3) The load balance FQDN wouldn't have to change. And internal users would still use the internal Storefront LB FQDN for resources.  And external users could still connect via Gateway to this store as well.

 

----

this isn't a complete "plan" as there a couple of details that should be defined first.  But based on what I think you were describing above, you have choices depending on what you do in parallel and what you do in-place.  If you use one storefront store to aggregate your old and new sites, you can keep most of your gateway and storefront fqdns as is. If you decide you want to have the option to switch users from old gateway to new gateway or old storefront to new storefront, then separate deployments and separate fqdns would be needed.

 

So for example...

If you are going to keep XD79Site (c1, c2) and deploy a new parallel CVAD1912Site (c3, c4)

You could then deploy a single Store to aggregate both (but remember, your current version of storefront will likely have to upgrade to a minimal version...so if you decide to build in parallel it may give you some more options.

 

You can still load balance this storefront. If upgrading the existing, then the lb fqdn and store path don't change. If you build in parallel, then you *could* keep the lb fqdn the same but point to the new storefront deployment (and its store path). If there's an issue, just point to back to original storefront.  The main point is whether you view an inplace upgrade a risk that you want a rollback option for by reverting VMS (for an inplace upgrade) OR having a new build running on a separate set of VMS and hiding change from users. 

 

If instead you want some users to go to https://storefrontold/citrix/<storename> while others go to https://storefrontnew/citrix/<storename> you would have to have two separate fqdns and load balancers.

 

 

For gateway deployment, you *should* be able to upgrade from 11.1 to 13 (or 12.1 as appropriate), but 1) backup your config first and have a recovery plan. If you have a lot of gateway customizations/portal themes, it will be best to TEST this first.  An in place upgrade usually works, but if this is a vpx that you can make a copy of and test in an isolated environment, you'll have a better chance to know for sure.  Again, what is your recovery plan if there is a problem (config backup/downgrade/restore OR rollback to a vms snapshot, etc...).

If the storefront fqdn hasn't changed, then the gateway config session policies won't change. You might upgrade your STA lists on both gateway and storefront to include resources from old and new site and as you decommission on 7.9 environment both STA lists would have to be updated.

 

The trick for you is to identify how your build out will go and what minimizes risk or what minimizes your effort.  Then plan the site deployment, the storefront deployment (one or two) and then you can define the gateway deployment (one gateway with single store doing two sites; one gateway with old store vs new store; old gateway and old store vs new gateway/new store).  That plan will help you see whether you can use your existing gateway fqdn or need two and whether you can use a single storefront internal fqdn or need two.

 

 

Quote

 

 

 

 

 

 

  

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

3 hours ago, Michael Harris said:

Store Front  -  I should be able to use the SF 1912 servers to replace the SF 7.9 servers.  I would need to have the site name stay the same between sites.  The internal SF name is currently storefront.domain.com which is a load balanced vip.  I would need to add the 2 new SF 1912 servers as hosts and bind them to this VIP.  Then unbind the 7.9 SF.  

 

At this point, both my Net Scaler and SF would be updated and I'd have both old farm and new farm available simultaneously.   I would not have to change the URL for the internal clients (other than upgrading them).  I would be able to decommission the old farm by publishing apps from the new and deleting them from the old.  

 

Did I get it correctly?   

 

Covid time. No problem;  life and or work happens.

 

Yes, exactly for storefront:  you would keep same storefront FQDN/VIP on your existing storefront lb vserver. Create services for new storefront (stf3/4), unbind old and bind new.  If problem, you can just revert back to original services. Since storefront path/store doesn't change, your gateway settings won't need to be updated (in most cases).  The new storefront store, would aggregate your OLD site controllers and your NEW site controlelrs...so yes, your new store would access both environments.

 

Gateway should then point to the new storefront/store via the existing fqnd/store path.  Don't forget to define the gateway settings on the new storefront.

 

If any issues that are unexpected, just unbind new services and rebind old services (or disable old services until you don't need them).

 

You also don't have to "delete" delivery groups from old farm, just unassign them from their assigned user groups.  This way if you have any migration issues, you can just unassign in new and reassign in old to restore previous delivery.

 

But, yes, the procedure should work for you with minimum risk.  Good luck.

 

 

 

 

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...