Jump to content
Welcome to our new Citrix community!

Applicaton launches fail intermittently - NetScaler Console shows "STA server lookup failed"


Recommended Posts

Greetings,

 

Hoping someone could assist.  The environment consist of.  

 

- NetScaler 12.1.57.18nc

- Storefront 1912.0.1000.17 (CVAD 7 1912 LTSR CU1).

- Windows Server 2012 R2 and are patched monthly

 

There are two sites - west and east.  Each site mirrors the other.  2 x ADC appliances in an HA pair, 2 x controllers, 2 x SQL, 2 x PVS.  GSLB is enabled in an active/active configuration.  Resource aggregation is enabled.

 

Each ADC pair has two virtual servers defined - a single factor virtual server and multi-factor virtual server.  Each virtual server uses the same broker/controller/STA server in their site - westcontroller1/westcontroller2 for west and eastcontroller1/eastcontroller2 for east.

 

A separate callback URL is defined in each site.  The two virtual servers use the same callback URL.  The host files on the broker/controller/STA servers have entries pointing the callback FQDN to the IP of the callback virtual server on the NetScaler.  Essentially west traffic stays within the west site and east stays within east.   

 

Users are able to log in and see the applications assigned to them, but application launches fail intermittently.  This occurs regardless of the virtual server the user logs in to.  No error message appears (the launch times out).  The help desk advises the users to wait 30 seconds and try again which usually works.  

 

I'm assuming AD/RADIUS authentication at the NetScaler is successful.  Storefront enumeration is successful too since the user can log in and see their apps.  Nothing screamed at me in the NetScaler GUI.  The console however shows "STA server lookup failed". The strange thing is the STA ID in the error message is from the east site.  The east broker/controller/STA servers are not bound on the west virtual servers.  There is also no global STA binding defined.  The east servers only exist as server objects in the west NetScaler configuration.  I'm also seeing similar messages when logged in to the console of the east NetScaler.

 

NetScaler console error message.   

 

Feb  4 14:09:46 <local0.err> <NetScaler IP> 02/04/2021:14:09:46 GMT <NetScaler Hostname> 0-PPE-0 : default SSLVPN Message 568661687 0 :  "[CGP][ICAUUID=nnnnnnxn-nnnx-nnnx-nnnn-nnxnxxnnxnnn] STA server lookup failed {sta-auth-id=STAnnnnnnnnn}"


I've checked/done the following with no luck.

 

- Each STA server has a unique ID.

- The STAs listed under "Manage Citrix Gateways" in Storefront are not load balanced.

- The STA URL for each server defined in Storefront matches the STA URL bound in the virtual servers under "VPN Virtual Server STA Server Binding".  

- Ran a packet capture on the NetScaler which Citrix support reviewed.  Nothing found.

- Removed the "Everyone" user mapping so I could remove the east site in the Storefront site aggregation.  The error messages remained.  

 

Anyone have any ides of where else to check, or what to try?  I'm not sure why the remote STAs are referenced in the local console error messages when they are not bound to the virtual servers.  Thanks in advance.

Link to comment
Share on other sites

OK, looking back you are having multiple issues:

1) STA lookup failure on gateway caused by the unexpected SiteWest sta being returned to Gateway EAST and vice versa.

1b) (Which is likely an incorrect implementation of the storefront site selection/gateway mapping being used) Which may be an issue on top of the first one.

2) You have the authentication failures, which should be something separate from the STA issue... 

I'm going to focus on the sta issue first as it is likely a gslb/optimal hdx mapping issue

 

But you may also just have an issue with how the EASTSite and WESTSite are aggregated in Storefront to achieve your final result (are they mean to be active/passive failover partners or different resources from different users, or queried active/active but once selected getting users to proper east vs west gateway.)  And you have your optimal gateway routing on top of that.  

 

For normal STA troubleshooting, I would usually start here, but I think your issue is elsewhere...

  • Check all storefront servers in the storefront group for a) consistent propagated config and b) check the event viewer for any intermittent sta failures. Looking to see if an STA storefront is using or a rogue config on one server is NOT a sta the gateway is aware of.
  • Check the controllers for service interruptions or broker service issues in the event viewer that might be causing the sta to fail intermittently.
  • Confirm from both participating gateways that there aren't any DNS resolution issues with the sta name.
  • You can also change the gateway for name based resolution to the STA IP addresses and see if that eliminates the sta server lookup failure or create a dns host record on teh gateway for the sta name to ip lookup.
  • And check gateway syslog events for any other errors that indicate what else is going on that might be in addition to the sta failure. (Check nslog too.)

 

 

BUT:  I have a concern around this statement (and its further confirmed by your eastside/westside comments):

1 hour ago, Eric Ortiz1709161203 said:

Each ADC pair has two virtual servers defined - a single factor virtual server and multi-factor virtual server.  Each virtual server uses the same broker/controller/STA server in their site - westcontroller1/westcontroller2 for west and eastcontroller1/eastcontroller2 for east.

So my concern is that depending on exactly how the storefront-site mapping is made and then the storefront-gateway mapping is made. We may not be sending only east requests to east gateway and west requests to west gateway, which might explain your STA resolution issues.

 

If your storefront can talk to either Controller1 or Controller2 as STA's, then the gateway must know about both Controllers to redeem.  If a storefront asks Controller3 for an sta ticket and that traffic goes to the gateway to resolve and it doesn't know Controlle3 you will get that sta lookup failure because it is asked to redeem a ticket for an staid it doesn't know. Which sounds like what is happening.

 

My guess is your east site/west site gateways only know one set of controllers/stas and they are being asked to resolve the others. Which means your optimal gateway routing of which gateway to which site is probably wrong somewhere. May need more information on what you want to have done to fix what you have configured to actually do this.

 

It would probably help,  to explain the exact store to site (xml lists) you ahve, the store to gateway/sta mappings (on storefront), and the optimal hdx routing, and the gateway to sta mappings (on vpn vserver).  For a GSLB config, you storefront should have a GSLB shared name defined as authentication gateway only and then two site specific names gatewayeast and gatewaywest for the hdx proxy only.    You need to make sure that EAST site stuff goes to appropriate EAST gateway and WEST site goes to WEST gateway, but the gslb config has a few more settings for optimal gateway routing to work.

 

Skipping gslb for a second, just to look at the basic communication requirements with one store getting two sites to two name-specific gateways:

 

Example 1:  1 Gateway, 1 storefront aggregating two sites

So, if you have a CVAD SiteEAST (with controllers C1 and C2) and a CVAD siteWEST (c3 and c4) to keep it simple.

Then if we had one storefront and one gateway to aggregate resources:

StoreFront Store-1:  SiteEast (xml: c1, c2) and Store-2 (xml:c3,c4)

StoreFront when it knows about the Gateway integration (gateway1 fqdn) and the STA list would likely include any of the STA's:  c1, c2, c3,c4.  Now:  Storefront queries any sta in the list regardless of which "site" it belongs to. As a name lookup service any sta can do a ticket issuance for any name whether a resource in its site or not.  

Gateway would then know about the Store-1 path and the list of STA's:  (c1,c2,c3,4)

 

 

Example 2:  Store1 routing SiteEAST to Gateway1 and SiteWEST to Gateway2...

Still without GSLB as more complicated.

One store, different gateways per different cvad sites...

Store1:

XML List:  SiteEAST (xml:  c1, c2); siteWEST (xml:c3, c4)

Gateway1:  STA's for SiteEast (sta:c1, c2)  and the gateway1 fqdn

Gateway2:  STAs for SiteWest (sta:c3,c4) and the gateway2 fqdn

 

If you integrate both gateways to Store1 for remote access.

Then under Optimal HDX Routing, you will map Gateway1 to SiteEast and Gateway2 to SiteWest (site aware mapping as opposed to zone)

On Gateway

vpn vserver for Gateway 1 would have necessary session policies for Store1 and SiteEAST sta's.

vpn vserver for Gateway 2 would have necessary session policies for Store2 and SiteWest sta's.

 

Then when storefront identifies that the user request should go to SiteEAST resources, it should only query a SiteEAST STA (on the storefront gateway config) and route traffic through Gateway1.

Then when storefront identifies that the user request should go to SiteWEST resources, it should only query a SiteWEST STA (on gateway config) and route traffic through Gateway2.

 

GSLB adds additional details on top of this.

So where possible, I try to start with just making sure the site to gateway mapping works for site specific gateway names. Then if there are issues fix those, then move into the gslb config once all the underlying site to gateway stuff is working.

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Thanks for responding (much appreciated).  I'm happy to share xml snippets if I'm not explaining correctly.  

 

A 3rd party deployed the solution in 2016.  The goal was for redunancy everywhere.  The sites were to run active/active with GSLB addressing site outages.  Each site is to be enumerated regardless of which site the user logs in from (there are a few applications which only reside in a single site).  If both brokers/controllers/STAs within a site were to go offline, the NetScaler is to use the broker/controller/STAs in the remote site.   The servers sit behind a load balancing virtual server.  The Session Profile has the load balancing virtual server IP referenced for the "Web Interface Address" on the Published Applications tab.

 

There are two delivery controller groups per site - West and East.  Each controller group contain the respective broker/controllers/STAs for the site.  The check box for load balancing is enabled.  
 
Each site has a single store with two gateways defined - "singlefactor.gw.com" and "multifactor.gw.com".  Both gateways are set for "Authentication and HDX Routing".  Both are using the broker/controller/STA in their respective site.  Neither controller group is assigned to a gateway under "Optimal HDX Routing".  

 

Under User mapping and multi-site aggregation --> Map Users to Controllers, the "Everyone" group is mapped to both controller groups.  The local controller group is first in the list (and vice versa for the other site).  

 

Under "Aggregate Resources", both controller groups are listed under "Aggregated".  The checkbox for "Controllers publish identical resources" is selected.

 

I logged in to the NetScaler in each site.  While I can successfully resolve the local controllers hostnames from the NetScaler, resolving the remote controller hostnames fail.  While this could be corrected with adding the A records to the NetScalers, I imagine a different error message would appear for the sta lookup failure (asked to redeem a ticket for an staid it doesn't know).

 

Is this current configuration not optimal?

 

Link to comment
Share on other sites

You need to look at the vpn vservers STA list. If it is being asked to resolve the STAID for controller3 and it only knows controllers 1 and 2, then the STAID will not match a valid STA.  Even if it knows the controller3 name, it if it can't resolve it to the IP address it will also fail.

 

Bottom line: if a user can go to STore1 and and it will use either Controller 1/2 in SiteA or Controllers 3/4 in siteB for STA's then your gateway needs to know and resolve all 4 stas. 

If we are then requesting the wrong site resources and resolving to the wrong gateway, then that is a separate set of issues to solve.

 

But if you have the storefront aggregating two CVAD sites and then going to either of two gateways without any optimal gateway mapping, then the expectation is that either gateway has to get to either sites' vdas and potential all sta's.  Without changing somethings.

So I would start by adding all sta's to both gateways and see if this solves the intermittent sta/resolution issue.

Then, if you are getting users to the wrong site resources or the wrong gateway, we'd have to go back over the setup of the site selection and gateway selection behavior.

 

 

To confirm the list of STA's on the vpn vservers:

GUI:

Citrix Gateway > Virtual Servers

Select each <vpn virtual server> and under "Published Resources" select "STAs" and verify the list and up/down state.

CLI:
show vpn vserver <vpn vserver name>

And confirm list of STA's or use

show ns runningconfig | grep <vpn vserver name> -i

 

 

 

  • Like 1
Link to comment
Share on other sites

Understood.  I created the DNS entries and added all STAs to the VPN vservers.  I no longer see the "STA server lookup failed" error in the console!


I do see this message occasionally in the console now:

 

> Mar  4 14:14:40 <local0.err> NSIP 03/04/2021:14:14:40 GMT NSHOSTNAME 0-PPE-2 : default SSLVPN Message 2316375074 0 :  "[CGP][ICAUUID=nnnXnXnn-XXnn-nnnx-nnnn-nnXnXXnnXXXn] STA ticket validation failed"


As well as this in the "Citrix Delivery Services" event log.

 

An authentication request was made before establishing a web session. This typically occurs when sticky load-balancing between client and StoreFront is misconfigured.
Citrix.DeliveryServicesClients.Authentication.Exceptions.NoSessionForAuthenticationException, Citrix.DeliveryServicesClients.Authentication, Version=3.22.0.0, Culture=neutral, PublicKeyToken=null
No session for authentication
   at Citrix.Web.AuthControllers.Controllers.GatewayAuthController.Login()

 

 

Could this relate to your earlier point of traffic not staying within a site?  If yes, could you advise of what I should investigate next?

 

Link to comment
Share on other sites

I would start by confirming on the ADC(s):

Basic Load Balancing Requirements for storefront and xml brokers (if done by the adc...)  You want to make sure that both ADC's are properly configured.

1) If you are using the ADC to load balance storefront, confirm the lb method, persistence type, and persistence timeout for the storefront lb vservers (in both ADC locations)  << Your error sounds like an issue with the storefront load balancing / persistence setting.

 

2) For the StoreFront to Controller communication, are you load balancing the XML brokers as well or not on the ADC?  If yes, confirm the xml load balance method (persistence must be none) and you only have C1/C2 for CVAD siteA load balanced together and C3/C4 for CVAD siteB together.  Confirm that the StoreFront is using the load balanced controllers for the xml configuration (Store > Delivery Controller config) and you have the right xml lb for each CVAD Site in the Store.  If you are not load balancing the XML at the ADC, then the storefront store should be doing it, so under the Store > Delivery Controller Config the CVAD SiteA should have only C1/C2 listed (controllers) and the SiteB entry should have only the C3/C4 controllers. One store knows both sets.  And the option to "load balance" makes the storefront alternate between the xml brokers.

3) For the STA list on both the SToreFront and the Gateway this cannot point to the load balanced xml brokers (if in use); the gateway must see the individual controllers listed as STAs (don't think this is a problem, but have to check) .  Also i the storefront what is the time set for the STA ticket expiration, it might be too short (and check your storefront clocks are correct)

 

So if its not a load balancing or sta issue, then it is possbly the association of gateway to cvad sites is wrong and that would bring us to gslb.

For the GSLB, we would need to look at this in more details as it doesn't sound like it was really done the way it should BUT I could be misinterpreting things.  So, start with the load balancing confirmation first.

 

 

 

Link to comment
Share on other sites

With regard to the roles provided on each server (C1/C2/C3/C4).  Each has the same the components installed - Storefront, XML, Director, Studio etc.  They are essentially collapsed controllers.  I'm wondering if this is contributing to the issue.

 

 

6 hours ago, Rhonda Rowland1709152125 said:

1) If you are using the ADC to load balance storefront, confirm the lb method, persistence type, and persistence timeout for the storefront lb vservers (in both ADC locations)  << Your error sounds like an issue with the storefront load balancing / persistence setting.


-- A lb vserver does exist on each ADC.  The lb method, persistence type, and persistence timeout match on both (least connection, source IP, 60 minutes).

 

 

6 hours ago, Rhonda Rowland1709152125 said:

2) For the StoreFront to Controller communication, are you load balancing the XML brokers as well or not on the ADC?  If yes, confirm the xml load balance method (persistence must be none) and you only have C1/C2 for CVAD siteA load balanced together and C3/C4 for CVAD siteB together.  Confirm that the StoreFront is using the load balanced controllers for the xml configuration (Store > Delivery Controller config) and you have the right xml lb for each CVAD Site in the Store.  If you are not load balancing the XML at the ADC, then the storefront store should be doing it, so under the Store > Delivery Controller Config the CVAD SiteA should have only C1/C2 listed (controllers) and the SiteB entry should have only the C3/C4 controllers. One store knows both sets.  And the option to "load balance" makes the storefront alternate between the xml brokers.

 

It appears the storefront store is doing the load balancing.  I have the two sites listed.  CVAD site A with C1/C2 and CVAD site B with C3/C4.  Could the issue be here given the "all-in-one" server approach?

 

 

 

6 hours ago, Rhonda Rowland1709152125 said:

3) For the STA list on both the SToreFront and the Gateway this cannot point to the load balanced xml brokers (if in use); the gateway must see the individual controllers listed as STAs (don't think this is a problem, but have to check) .  Also i the storefront what is the time set for the STA ticket expiration, it might be too short (and check your storefront clocks are correct)

 

Each individual controller is listed as an STA in the gateway.  I apologize, I'm having difficulty finding STA ticket expiration at the moment.  I don't believe the defaults were changed.  The storefront clocks are correct.

Link to comment
Share on other sites

Discussing based on the three quotes you provided above:

 

[1] So, in this case your storefront and broker service (xml/sta) are the same system unless you move the ports separate.

It just means you can point things to the lb for storefront communication BUT don't use the lb for any xml or sta list (anything talking to them should use the individual controller names).

 

 

[2]Your second section where the Storefront is aggregating the CVAD sites then, would list the xml brokers for each CVAD Site:

  • SiteA is c1/c2
  • SiteB is c3/c4 
  • This is likely correct.  And the "load balanced" check box should be listed for the controller list in each site, indicating for storefront to alternate between the xml brokers.

[3] The STA ticket duration is listed in the Storefront management console, go to the storefront's Gateway definition, edit, and then look at the STA config section.  There's a settings that has ticket duration set (there is a settings or properties button that the ticket duration if its not on the main property list).  The default is usually is either 120 second or 200 seconds, I think.  If its marked significantly shorter this might be the issue with sta ticket expirations.  But the issue might be something else.

 

I would still check the storefront events (Desktop Delivery Service under eventvwr Apps and Forwarded events) and the application log for Broker service events in case there is something on the controller/sta's that gives a better idea.

 

Otherwise the complication is likely related to the way the site aggregation and GSLB are working and the launch request is getting to the wrong set of controllers for the ICA connection phase and it doesn't recognize the launch request OR the STA is going up/down.

 

-----

 

GSLB adds a layer of complication to troubleshooting because you have one name going to different IPS and its hard to "tell" what is happening and when it goes wrong.

If someone else doesn't get to it; i'll try to break this down tomorrow.

Is GSLB set just for the gateway FQDN or also the Storefront name?  

Link to comment
Share on other sites

On 3/4/2021 at 11:45 PM, Rhonda Rowland1709152125 said:

[1] So, in this case your storefront and broker service (xml/sta) are the same system unless you move the ports separate.

It just means you can point things to the lb for storefront communication BUT don't use the lb for any xml or sta list (anything talking to them should use the individual controller names).

 

 

-  Would having the LB IP specified as the "Web Interface address" on the Published Applications tab of the session profile fall under "pointing to the lb for storefront communications"?

 

 

On 3/4/2021 at 11:45 PM, Rhonda Rowland1709152125 said:

[2]Your second section where the Storefront is aggregating the CVAD sites then, would list the xml brokers for each CVAD Site:

  • SiteA is c1/c2
  • SiteB is c3/c4 
  • This is likely correct.  And the "load balanced" check box should be listed for the controller list in each site, indicating for storefront to alternate between the xml brokers.

 

 

 - Understood.  Yes, the "load balanced" check box is selected for the controller list of each site.

 

On 3/4/2021 at 11:45 PM, Rhonda Rowland1709152125 said:

[3] The STA ticket duration is listed in the Storefront management console, go to the storefront's Gateway definition, edit, and then look at the STA config section.  There's a settings that has ticket duration set (there is a settings or properties button that the ticket duration if its not on the main property list).  The default is usually is either 120 second or 200 seconds, I think.  If its marked significantly shorter this might be the issue with sta ticket expirations.  But the issue might be something else.

 

 

- Found it.  The ticket TTL is set to 200 across both site.

 

I reviewed the Citrix Delivery Services log as well as the application log across all 4 servers and am not seeing anything to correlate to the sta ticket validation failed messages.  I haven't found messages indicating the broker service is restarting either. 

 

I have seen instances of this in the log.

 

image.thumb.png.30e1296472e97d96065fcb34b7115837.png

 

 

Could this be indicative of sessions jumping across the sites?  The DG in each site has plenty of capacity for sessions.  GSLB is only set for the Gateway FQDN, not for Storefront. 

 

 

Link to comment
Share on other sites

1 minute ago, Eric Ortiz1709161203 said:

I reviewed the Citrix Delivery Services log as well as the application log across all 4 servers and am not seeing anything to correlate to the sta ticket validation failed messages.  I haven't found messages indicating the broker service is restarting either. 

 

I have seen instances of this in the log.

 

That last message: "citrix broker service" failed to broker ... cannot find any available machines...

This could be the request went to the correct site, but none of your vda's are avaialble: still in maintenance mode, no resources to power on, all available resources consumed...

 

Usually, if you are asking the wrong site for vda's the error should be different.

 

One way to troubleshoot this without having to go to the specified controller and see what events are happening in that time frame, go to Citrix Director for that site, look at the connection failures dashboard which usually gives a reason "no resources available" or connection failure and a subreason that may narrow this down.  There are otherways to troubleshoot this, but director can usually narrow it down the fastest.

 

This is error is typically pre-STA request. and is a separate issue preventing storefront from generating an ica file (before making the gateway connection attempt).

--------------

 

Back to the first question:

 

4 minutes ago, Eric Ortiz1709161203 said:

-  Would having the LB IP specified as the "Web Interface address" on the Published Applications tab of the session profile fall under "pointing to the lb for storefront communications"?

 

Hard to clarify out of context.

Storefront == Web Interface.

So, if you are on the Gateway (ADC) config and looking at the value of the session policies WI Address field, than yes this should point to the STorefront LB address (which should be only the c1/c2 of the EAST side or the c3/c4 of the WEST side). If you are load balancing all 4 controllers as one storefront we have a problem.

 

To extend this point, even though you have storefront and controllers running on the same server.

Conceptually, we have 4 different conversations we have to track:  Storefront and the 3 controller conversations:  XML Brokers, STA, and VDA Registrations.

Even though the three controller conversations are handled by a single service, we still treat them as separate conversations because some can be load balanced, others cant.

 

Storefront:

- EAST LB StoreFront address which is only storefront on EAST C1/C2.  Usually SSL.

-A separate WEST LB Storefront would point to the storefront servers for the WEST Site (c3/c4)

 

EAST Site Controller communication:

- EAST XML conversations can be load balanced by pointing to C1/C2. Storefront can use the EAST XML LB for xml access OR point to the controllers and alternate itself.

- WEST XML conversations can also be load balanced by pointing to WEST C3/C4.  StoreFront would see these as the WEST Site and use the lb name or the individual C3/C4.

- StoreFront would see the EAST and WEST xml brokers as separate sites for multi-site aggregation which you are already doing..

 

Anytime STA's are referenced to keep it simple, you will use the individual controller names. But these can span C1, C2 and C3, C4. Don't load balance the STA's with lb vserver; let storefront alternate between them.  Gateway will then be configured with the same list of STA's.

 

The list of VDA's in each CVAD site will only register with controllers in their own site. They must have the individual controllers listed EAST (c1/c2) or WEST (c3,c4); DO NOT CONFIGURE THE XML LB Name as a Controller name for vda registrations (that will cause problems).

 

Basic GSLB:

Finally, the GAteway config is dependent on GSLB and the final storefront config is too, which is where I think your problem is.

Gateway EAST:  Will then need to know about StoreFront EAST (LB vserver).  

Gateway WEST:  Will then need to know about SToreFront WEST (lb Vserver).

Whether the gateway knows about the OTHER storefront is TBD.

 

StoreFront EAST needs to know that traffic can either came from the Gateway GSLB FQDN (the shared name).  And it will also know about a Gateway EAST specific name and a Gateway WEST specific name.  The GSLB FQDN is usually seen during authentication phases only.  the Site specific names (Gateway EAST and Gateway WEST) would then be seen during the HDX Proxy phase.  The site specific names are usually mapped to the Sites under the optimal gateway routing. So when storefront is sending you to EAST Site VDA's it will use the EAST GAteway FQDN and the WEST Site VDA's through the WEST Gateway FQDN.

 

The StoreFront WEST should have a similar config.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

2 hours ago, Rhonda Rowland1709152125 said:

Storefront == Web Interface.

So, if you are on the Gateway (ADC) config and looking at the value of the session policies WI Address field, than yes this should point to the STorefront LB address (which should be only the c1/c2 of the EAST side or the c3/c4 of the WEST side). If you are load balancing all 4 controllers as one storefront we have a problem.

 

Good here thankfully.  There are 2 LB VIPs c1/c2 for EAST and c3/c4 for WEST.

 

 

 

 

2 hours ago, Rhonda Rowland1709152125 said:

EAST Site Controller communication:

- EAST XML conversations can be load balanced by pointing to C1/C2. Storefront can use the EAST XML LB for xml access OR point to the controllers and alternate itself.

- WEST XML conversations can also be load balanced by pointing to WEST C3/C4.  StoreFront would see these as the WEST Site and use the lb name or the individual C3/C4.

- StoreFront would see the EAST and WEST xml brokers as separate sites for multi-site aggregation which you are already doing..

 

Yes, there are separate EAST and WEST sites defined for multi-site aggregation.

 

 

3 hours ago, Rhonda Rowland1709152125 said:

The list of VDA's in each CVAD site will only register with controllers in their own site. They must have the individual controllers listed EAST (c1/c2) or WEST (c3,c4); DO NOT CONFIGURE THE XML LB Name as a Controller name for vda registrations (that will cause problems).

 

The respective individual controllers names are being pushed to the VDAs via GPO in each site.

 

 

2 hours ago, Rhonda Rowland1709152125 said:

StoreFront EAST needs to know that traffic can either came from the Gateway GSLB FQDN (the shared name).  And it will also know about a Gateway EAST specific name and a Gateway WEST specific name.  The GSLB FQDN is usually seen during authentication phases only.  the Site specific names (Gateway EAST and Gateway WEST) would then be seen during the HDX Proxy phase.  The site specific names are usually mapped to the Sites under the optimal gateway routing. So when storefront is sending you to EAST Site VDA's it will use the EAST GAteway FQDN and the WEST Site VDA's through the WEST Gateway FQDN.

 

 

If I understand correctly, what I currently have is not best practice (2 gateways with no delivery controllers defined for optimal routing).

 

image.thumb.png.72e7dd24dab5c75cd8a326f5f0606364.png

 

This configuration could potentially send EAST users to WEST resources and vice versa, correct?

 

 

I should have something similar to this (per gateway):

 

image.thumb.png.b1fa2019c6f5e728e2b30a080c82d70d.png

 

 

 

 

Link to comment
Share on other sites

That's what I would expect for a typical GSLB config.  

If the gateway is also making decisions about which store to send users two (because of your single factor vs. multi-factor requirements which I don't understand the trigger for), but I would think that if the estorefront can talk to either CVAD site and what dictates which gateway you need to hit is which store we select, then mapping the correct gateway to the correct store is needed.

 

If there are more decisions about once the user hits gateway, and the gateway needs to decide which store or site they are supposed to get depending on whether they did single factor or multi factor authentication or if gateway directs them to a store based on group membership there could be other configs requirements.

 

You started with what sounded like two issues:  sta's are timing out which may have been a config issue AND possibly a bonus issues about incorrect store/gateway mapping.

 

So, my thought is to always isolate the individual things that are supposed to work and then start fixing the gslb once all the underlying connections are confirmed.

 

We would really need to understand the single factor / multi factor, the active/active gslb you want and the decisions being made that gets users from a gateway to a storefront and then from there the cvad sites.  If the decisions are based on requirements different than I assumed, then the config would need different requirements.

 

Sorry, this is a standard "it depends" answer. 

 

 

 

Link to comment
Share on other sites

The single vs multi-factor mandate came from the Information Security dept for PCI compliance.  Call center agents are to use the single factor gateway (which has firewall restrictions limiting access to authorized call centers).  Employees are to use the multi-factor.  

 

The gateway does not need to make a decision based on single factor, multi-factor authentication or group membership.  The session only needs to stay within the site it landed on.

 

 

23 hours ago, Rhonda Rowland1709152125 said:

You started with what sounded like two issues:  sta's are timing out which may have been a config issue AND possibly a bonus issues about incorrect store/gateway mapping.

 

Oh, how I love a bonus!

 

 

23 hours ago, Rhonda Rowland1709152125 said:

Sorry, this is a standard "it depends" answer. 

 

Nature of the technology beast. 

 

Thanks for your guidance and time!  It's very much appreciated!

   

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