Jump to content
Welcome to our new Citrix community!

Changing Gateway using same URL, workspace app doesn't update

Michael B

Recommended Posts

Hi All.   I am working on moving our Gateway config to a newly created Gateway on the same ADC.  This new Gateway Vserver was generated using the xenapp/xendesktop Wizard so has less session policies and we also are changing the authentication policy, but that's the only difference,  Session Profiles, certificate, backend Storefront servers etc. are all the same.  So with that said, in testing if I just swap the VIPs so the URL doesn't change the endpoints using Workspace don't seem to be able to update/refresh.  The account has to be removed and re-added.  Not sure if anyone has experience this or knows of a reason why. 

When I make the change existing sessions have a brief disconnect and then reestablish their connection so thats not an issue.    Just trying to lesson the need for users to call in when we officially make this change.


We tried the simple, rebooting,  closing the workspace app, etc.  Occurs on IOS devices and Windows PCs.   No issues if using the web interface.



Link to comment
Share on other sites

The wizard has some limits on what you can change without rerunning the wizard.


You can still potentially bind the policies/profiles created by the wizard to a new vserver. But someone editing by "deleting" the entity in the wizard might affect your new instance to.

So either run the wizard again, or create a new version of the policy/profile you need to bind to the new entity to give you full control.


Don't forget the Storefront itself will need to update to the new gateway fqdn/vip  if changed.


I'm not sure which policy/profile you updated that failed to update the services clients. You have both a web profile and a services profile; if you only changed one, then some of the clients would have been left out.  If you didn't update the storefront with the change on teh gateway info, then other problems occur.  If FQDN's aren't changing, but VIP's are, then you may also be running into some cached dns queries in the middle as well.


If you have two vpn vservers, the easiest thing to do is to run the wizard for the new gateway. Then when ready, just change the storefront config from gateway1 to gateway2.


If you can better describe what changes you made, then it will be easier to give you a better plan or identify the original issue.


Link to comment
Share on other sites

Thanks Rhonda and Wayne for the responses.


To add some more detail:     The public IP/URL will stay the same (citrix.company.com) and I was planning on just swapping the VIPs so the NAT on the firewall wouldn't need to change either. 

The old Gateway has a number of session policies instead of just the two, they seem to be legacy with more granular User-Agent expressions for IOS, Windows Phone, Windows RT, etc.   I would like to clear that out and have just the two policies for web and service policy/profile.

When I made the switch I didn't update policies I just switched the Gateway VIPs like I planned.

Everything worked fine, Except the Only issue was with Workspace.  There may be some caching or something within Workspace local files causing it to hang/not refresh.  I'm trying to recreate the issue in my secondary data center and have something to test with.

Hopefully that provides a little more helpful info.


Wayne,   I'm not sure what you are referring to with the $EMEAGateway and GSLBurl,  Could you explain further?



Link to comment
Share on other sites

So, you have to have at least one session policy or the default policy on the vpn vserver to do gateway-to-storefront integration.

If the one set of clients worked and the services didn't, its possible the one policy you have in effect is NOT handling services connections, so you should at least have the one additional policy/profile equivalent to the PL_OS/AC_OS policy you probably had in the original vserver.  The web services config may not support those clients depending on how legacy they are.  Or check your original legacy policies for hits and see if any of their header types are being used by the clients not working.


Next, be sure your storefront can accept any other changes from the change in gateway. If the gateway name/ip isn't changing; you may want to explicitly disable the old one to make sure there aren't any caching issues resulting in some traffic going to your original vpn vserver.



Link to comment
Share on other sites

  • 2 weeks later...

Hi All.  Just a follow up on this.  In a roundabout way and some suggestions from Citrix support we ended up changing some settings on the Storefront side and that cleared up the issues we were having with the Workspace App.  There were no errors that would of made me think that was the issue, but apparently some old settings that had been around for a while and making a Gateway change caused what was working to not work.  A simple fix by changing the SF logon type along with adding in our domains for authentication.  Using Any wouldn't work.  So anyways, thanks for the suggestions as always!

  • Like 1
Link to comment
Share on other sites

  • 6 months later...

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