This message was deleted.

SOURCEIP is the correct persistence type for storefront make sure your persistence time-out is set (i set this to 20 mins to match the storefront timeout)

Thanks. No according to Citrix https://docs.citrix.com/en-us/storefront/1912-ltsr/integrate-with-citrix-gateway-and-citrix-adc/load-balancing-with-citrix-gateway.html and based on my issue. As highlighted, because we use source IP, it is always coming from the NS DMZ SNIP so we are always hitting the same Storefront which is not good. Timeout is set to 2 min but with the rate of logon, it never have a chance to time out. So cookie insert is much better but it doesn't work with my thin client ...

sourceip is the correct persistence type for storefront and something i have used on multiple deployments 🙂 have a look at below i would trust carls documentation over citrix's any day of the week 🙂 what type of monitor are you using on your storefront service group ? if there was issues with a storefront server the dedicated storefront monitor probe would of failed and that server would be marked as down and no connections would be sent there or if you knew of issues with the storefront server you could of simply marked it out of service on the storefront LB service group again which would redirect requests to your other storefront server in the server group https://www.carlstalhood.com/storefront-load-balancing-citrix-adc/#vserver

Hi, fact is with source IP persistence with my setup which is not unusual, VIP Unified Gateway |NS DMZ| -> SF VIP |NS LAN| -> SF servers. You do not load balanced with source IP so it is bad as everything is coming from NS DMZ SNIP. Then we are tied down to the same SF because the persistence. I am not using the advanced Storefront monitoring (XML) but all it does is to check the services, nothing fancy. And in my case with the SF server full, the services were still up, I use Nagios, service was fine and event logs does show them up. So even with this adv monitor, I'm confident NetScaler would not detect this issue. In this case I think Citrix is correct, Cookie insert should be used, which is rare I have to agree! 🙂

Just going to throw this out there as an untested theory... Do you really need persistence at all if all of your StoreFront servers are configured with static and the same Machine Keys? (Validation and Decryption keys set static and copied across SF servers) Different product clued me in to this area when we were having issues with load balancing their product because of session keys.

Use another vip for external?

@Dennis Parker I don't think it would work, each request will be LB across each SF server. I think it will break the auth process, I'll give it a shot in my lab, who knows! @CitrixGruzel I thought about creating a new VIP on my NS DMZ, I'm just unsure of what IP will be used to access it as it will remain internal, I need to check this. If it is always use the same IP, the source IP will still be a problem. And creating a VIP on my NS LAN (internal), it doesn't solve the issue as I still need to change my persistence and I can't use Cookie insert. Thanks guys!

What’s filling up the SF drive? Maybe that’s more of the problem than the persistence method?

We will always have Storefront failing for whatever reason, storage or other, something the monitor won't catch. The source IP persistence bind my NS DMZ to a specific SF and it is not normal. For the SF drive, it was the IIS logs, I am planning to put a script in place to clean it up and change a bit the way Nagios alerts are handled.

Just following as I’m interested in the solution. Can follow the theory of you @jvitech, wondering why I never noticed that kind of problem, but agree with you 100% as it’s always the DMZ adc SNIP, so same source every time 🤨