Jump to content
Welcome to our new Citrix community!

Netscaler storefront integration


Al Zabar

Recommended Posts

All,

 

I experience weird issue with netscaler launching my storefront externally, whilst getting "cannot complete your request" after login.

My intentions are to use single FQDN for internal and external access. Internally I have no problems accessing storefront, this issue appears only externally. I followed the following articles:

https://docs.citrix.com/en-us/storefront/1912-ltsr/advanced-configurations/configure-single-fqdn.html

https://www.carlstalhood.com/citrix-gateway-storefrontauth-and-xendesktop-wizard/

https://www.carlstalhood.com/storefront-cr-configuration-for-citrix-gateway/

 

First, I deployed virtual gateway via wizard, with different name than single FQDN, added SSL, following import gateway file to store gateway and uploaded SSL to ISS. Renamed citrix gateway URL to single FQDN, added callback URL an beacons and externally I have above issue. No error logs in the event viewer, therefore I can't think of any further steps.

 

I troubleshot as per below link, and there s no issues with ping apart my netscaler's url is single FQDN, therefore cannot ping as it resolves either internal or external vip address but not netscaler.

 

https://support.citrix.com/article/CTX207162

 

Any help appreciated.

Link to comment
Share on other sites

From the NetScaler, cli if you ping the FQDN does it resolve from the Gateway itself to its own gateway VIP or the internal storefront IP?

Usually because the gateway is sitting between external and internal DNS you have to give it a host entry in its local dns table to override the dns resolution so that when gateway resolves <access fqdn> it resolves to the storefront IP so the gateway can actually talk to storefront.

- First issue, is usually missing the local host entry for ADC to resolve to storefront

- Second issue is if gateway can't reach storefront via teh shared fqdn to validate storefront functionality (errors will appear in nslog)

- Third issue is possibly an issue on StoreFront regarding beacons and/or how to identify the gateway vs. internal connections.  make sure the storefront beacons use a different address as the internal beacon and not the shared fqdn; also make sure the external beacon IS NOT using the shared fqdn.

 

While external users will still resolve the <access fqdn> to the gateway vip.

 

Same thing internally, the storefront will possibly need a host file entry so that when it calls back to gateway the "gateway fqdn" resolves to the the gateway or callback address if a separate callback name isn't used.

 

 

 

 

 

Link to comment
Share on other sites

Hi Rhonda,

 

From the putty, on netscaler gateway, I can ping shared FQDN and it resolves internal storefront server IP. 

Internally I have replaced my my gateway url with shared FQDN, which resolves internal storefront IP, added callback URL, which is different from shared FQDN and resolves vcerver IP on netscaler and finally added beacons as CNAME for shared FQDN which resolves internal storefront IP.

 

Still have the same issue.

Link to comment
Share on other sites

Now that I saw this:

 

6 hours ago, Al Zabar said:

First, I deployed virtual gateway via wizard, with different name than single FQDN, added SSL, following import gateway file to store gateway and uploaded SSL to ISS. Renamed citrix gateway URL to single FQDN, added callback URL an beacons and externally I have above issue. No error logs in the event viewer, therefore I can't think of any further steps.

 

If you ran the wizard the first time and then updated it for single unified fqdn, did you change the settings in the session policies too?

More than likely, you're going to have to review the entire gateway side of the config and the storefront side of the config to find the problem. Notes/Thoughts below.

 

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

You can't use the shared name as either an internal or an external beacon.

You have to use something that is internal only as the internal beacon and something different from shared url as external beacon.

 

Basically, now, you have to verify all the config in a couple of different ways. Gateway side and SToreFront side.

 

If possible, it would be nice if you could go back to a separate gateway fqdn vs storefront fqdn and confirm if a traditional gateway/storefront config is working. IF this works, but the shared fqdn doesn't, then we know it is specifically the shared fqdn issue. If it doesn't work at all, then the overall gateway/storefront config needs to be reviewed.  But I understand that this might not be a possible test case.

 

So a couple of things to confirm:

Gateway-side

1) Gateway has correct storefront fqdn (aka shared fqdn) and it resolves to storefront IP (which you said you confirmed).

2) Correct store is specified.

3) Is the Gateway doing the storefront load balancing too or is this load balanced on a separate load balancer?  (The answer here may affect other settings in different ways.)

4) Gateway 11.1 and later probes the storefront url specified so if the probe fails it will not attempt a storefront/ica proxy connection. This failure could be caused by name resolution to ip failures, lack of usable SNIP between gateway and storefront destination (which even if load balanced on this appliance, the gateway must be able to have the probe egress to the vip specified, or authorization policies denying traffic flow).  Review nslog for potential failures of this storefront probe:

shell

cd /var/nslog

nsconmsg -K newnslog -d event

nsconmsg -K newnslog -d consmsg

(In one of these look for your storefront fqdn for possible errors)

5) Review authorization policies (or session policies making authorization decisions) and or firewall rules which may require a trace. Typically if the traditional gateway works (with separate fqdns), then this is not a problem here, but hard to verify.

6) Check syslog for any other obvious errors being reported:

shell

cd /var/log

tail -f ns.log | grep -v CMD_EXECUTED

7) AGain, break down the gateway cert, the gateway authentication, sta list, and the session policy(ies) in use for correct ica proxy/sson domain, web passthrough, and other dependent settings that could cause gateway to storefront to fail.

 

NOTE when the connection fails, are you seeing the <shared fqdn>/vpn/<stuff> or <shared fqdn>/Citrix/<Storename> in the browser?  If still seeing /vpn you are still on gateway and never made it to storefront. If seeing /Citrix/<stuff> gateway is happy and attempted to send you to storefront, so the issue is more than likely storefront side.

 

StoreFront Side:

1) Internal users resolve shared fqdn to StoreFront LB VIP (if load balanced)

2) From StoreFront, does shared fqdn resolve to <gateway vip> and does <callback fqdn> resolve to callback ip which is a vpn vserver (or did you use a SNIP...which won't work)?

3) For the SToreFront's gateway config: confirm the following

- Gateway FQDN must be the shared fqdn (unless doing the separate fqdn test)

- STA's must be listed on storefront and on gateway

- Source IP for gateway should use the Gateway VIP and NOT the SNIP (especially if the gateway is doing both storefront load balancing and gateway)

- Callback Address should be the callback fqdn you specified AND resolve to the correct IP to be reachable (this IP if not the vpn vserver vip, should be a backend vpn vip and not a snip)

- Double check the beacons. Neither beacon can be the shared fqdn. Choose especially a separate internal url that is only resolvable on network and a different public external Fqdn.

- Double check the storefront base url and storefront cert (on load balancer) matches the shared fqdn that users use to get to storefront

-propagate all config changes properly

4) Check the storefront eventviewer under the custom sections  for Desktop Delivery Services for primary storefront events to see if anything looks to indicate a possible problem.

=========

Single shared FQDN is complicated, because instead of just the usual what does gateway need to know about storefront and storefront need to know about gateway config. You have to use one name to mean different things and you have to confirm that the name resolution is resolving problem at each point. It's like standing in a room where everyone is named Joe and then expecting the right Joe to respond when you yell, "Hey, Joe?".

 

External Clients: <shared fqdn> must resolve to gateway VIP

Gateway itself:  <shared fqdn> must resolve to storefront VIP/IP (usually via host file/local dns on Gateway to override the external dns that might apply)

StoreFront itself:  <shared fqdn> must resolve to gateway vip (but usually the gateway callback address will be used instead); but still this must get storefront back to the gateway vip (for shared fqdn) and gateway callaback to the appropraite callback ip (if not the gateway vip, then a backend vpn vserver vip and not a snip). 

Internal users:  <shared fqdn> must resolve to storefront VIP via internal DNS

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Rhonda,

 

When I run wizard on netscaler I haven't made any changes as they seems pointing to correct addresses.

"Cannot complete your request" pops out on /Citrix/mystore which looks like storefront server issue.

 

Gateway side:

My VIP is created on snip data network , with different FQDN which later has been replaced on storefront server to my shared FQDN.

I did run step by step with troubleshooting outlined above and all seems fine only syslog  come back with one error listed below:

 

"0-PPE-0 : default AAA Message 5229 0 :  "SSO : skipping sso trafficaction_flag 1, sso_type 5 state 0 ntlm_flags 0 user domain\administrator"

"0-PPE-0 : default AAA Message 5230 0 :  "SSO FAIL forwading to client because of weak SSO user domain\administrator"

 

Founded couple of issues asper below:

 

7602  7649 PPE-0 MonServiceBinding_shared FQDN:443_(tcp-default)(vpndbssvc_-368404201): DOWN; Last response: Failure - Time out during TCP connection establishment stage

7603     0 PPE-0 'server_svc_internal_NSSVC_SSL_shared FQDN:443(vpndbssvc_-368404201)' DOWN

 

External Clients: <shared fqdn> must resolve to gateway VIP  - it does resolve my public IP which is natted to gateway IP

Gateway itself:  <shared fqdn> must resolve to storefront VIP/IP (usually via host file/local dns on Gateway to override the external dns that might apply)  - it resolves my internal storefront server , as I only run single controller without load balancer

StoreFront itself:  <shared fqdn> must resolve to gateway vip (but usually the gateway callback address will be used instead) - it doesn't resolve  gateway IP as Internal DNS record points to internal server

; but still this must get storefront back to the gateway vip (for shared fqdn) and gateway callaback to the appropraite callback ip (if not the gateway vip, then a backend vpn vserver vip and not a snip). - callback resolves gateway IP

Internal users:  <shared fqdn> must resolve to storefront VIP via internal DNS - it resolves storefront server IP

 

 

Link to comment
Share on other sites

Does the storefront event viewer have any issues?  Look in the desktop delivery service event viewer under the second section (not the main section where application and system logs appear)
What authentication type is the gateway using LDAP or other?

Does the session policy the gateway uses have the enable passthrough crednetials to web setting on and the single sign on domain specified for sending to storefront?

 

On gateway you can look at aaad.debug for authentication errors:

shell

cd /tmp

cat aaa.debug

(look at output while performing a gateway authentication)

Link to comment
Share on other sites

There are no issues in Citrix Delivery service log, all only for information purposes.

I setup Storfront Authentication when run netscaler wizard.

Passtrough for gateway, domain has been enabled for any domain, but not sure about single sign on domain.

 

The cat aaa.debug command returned - cat: aaa.debug: No such file or directory

 

below logs for

nsconmsg -K newnslog -d event

nsconmsg -K newnslog -d consmsg

 

  0 PPE-0 MonServiceBinding_sharedFQDN:443_(tcp-default)(vpndbssvc_-368404201): UP; Last response: Success - TCP syn+ack received. Wed Sep  9  2020
 1557     0 PPE-0 MonServiceBinding_internal storefront server:80_(sta)(vpndbssvc_770861475): UP; Last response: Success - Probe to STA server succeeded. Wed Sep  9

 

Link to comment
Share on other sites

I get the following log:

 

 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Wed Sep  9 22:24:03 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Wed Sep  9 22:24:11 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[962]: process_kernel_socket 0-2: partition id is 0
Wed Sep  9 22:24:11 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[6811]: ns_aaad_decrypt_auth_passwd 0-2: ns_aaad_decrypt_auth_passwd performed : status 0
Wed Sep  9 22:24:11 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[1231]: process_kernel_socket 0-2: call to authenticate
user :Domain\Administrator, vsid :11310, userlen 22
Wed Sep  9 22:24:11 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[1295]: process_kernel_socket 0-2: call to authenticate
user :Domain\Administrator, vsid :11310, req_flags 802
Wed Sep  9 22:24:11 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[5662]: start_cascade_auth 0-2: starting cascade authentication
Wed Sep  9 22:24:11 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[5859]: cascade_auth 0-2: Delegating storefront auth offload to kernel for : Domain\Administrator
Wed Sep  9 22:24:13 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 1 firing...
Wed Sep  9 22:24:13 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Wed Sep  9 22:24:23 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Wed Sep  9 22:24:33 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Wed Sep  9 22:24:43 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 1 firing...
Wed Sep  9 22:24:43 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Wed Sep  9 22:24:53 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...

Link to comment
Share on other sites

Thanks, Carl. I was forgetting when the original poster said he used the wizard which meant that he might have delegated to storefront instead of having gateway do the authentication.

So, yeah, there is an issue with the gateway/storefront authentication handoff.  So, now that needs to be looked at.

 

In the gateway wizard, if you said storefront was doing authentication (instead of gateway is the default), you probably need a storefront authentication policy.

If you make the gateway do the authentication first, then the SSON domain, gateway passthrough to web, and the storefront expecting credentials from gateway are needed.

And the ldap policy on gateway may need to be inspected.

Link to comment
Share on other sites

Carl,

 

I am using latest ADC, 64.35.

 

Rhonda,

 

Will it be better then to change default policy from Storefront authentication to LDAP/RADIUS which will be new challenge for me. Is there guidance available to implement new authentication and should I remove existing storefront gateway to start all from scratch, or amend existing.

Link to comment
Share on other sites

It's a straightforward test if your Gateway can reach LDAP to do the authentication.

The problem with troubleshooting the config is that we're only getting pieces of information at a time. I assumed the traditional gateway authentication model and focused on the usual issues with the shared fqdn and missed the gateway deferring authentication to storefront.  

I don't think you need to start your gateway config over, but there's just a lot of things to check that the single fqdn makes harder to verify.

 

If you are configuring the gateway to hand off authentication to storefront, then there are configuration requirements that have to be checked (again there could be multiple issues...so it takes a while to work through each layer.)

If you wanted to do a traditional gateway authentication, then handoff to storefront, then that is possible too.

 

I'll try to give you notes about both below.

============

First, is your authentication requirement: LDAP (AD) and Radius or LDAP only?  I'm going to describe LDAP only to keep it simple...then you can add ldap after its working (ideally).

If you want to do LDAP+Radius, you need to let the gateway do the authentication first.  Here's an example of the primary/secondary policy: https://docs.citrix.com/en-us/citrix-gateway/12-1/authentication-authorization/configure-ldap-radius-with-mobile.html

 

Gateway with Storefront handling the authentication:

FAQ:  https://support.citrix.com/article/CTX223882

and config details here:  https://www.jgspiers.com/netscaler-gateway-authentication-direct-storefront/

In addition to the storefront config, you would need the storefront authentication policy settings as well.

 

 

 

For Gateway authentication with Handoff to StoreFront:

1) You should backup your config so you can restore if needed. (create system backup > full under the System node for easy restoration)

2) On the Gateway, you could redo the storefront integration via the gateway wizard and leave the "storefront authentication" off.

 

The manual process would require you to create on the ADC and LDAP authentication policy for your domain:  (See https://support.citrix.com/article/CTX123782))

You will need the domain's base DN in ldap form. Example domain demo.com would be dc=demo,dc=com

A domain username (upn format) and password as the LDAP bind account.

Configure Server Logon Name as sAMAccountName (shown in article)

Search Filter should be blank for now.

Group Attribute: memberOf

Sub AttributeName CN

SSO Name Attribute (blank but can be configured later)

Additional settings depends on environment such LDAP as plaintext or secure and the ports in use.

 

Bind the LDAP Policy to the basic authentication Primary bind point on the vpn vserver.

 

Be sure the session policy/profile in use

1) Client Experience tab > passthrough credentials to web (is enabled)

2) SSON Domaon on Published Apps tab includes sson domain (demo for demo.com as an example)

3) all other storefront settings as expected.

 

On StoreFront, be sure gateway is configured to do both Authentication & HDX Proxy.  Then all other settings the storefront needs to know about gateway including under the store's authentication enabling passthrough authentication from gateway.

 

 

 

 

 

Link to comment
Share on other sites

Rhonda,

 

Did the following changes today:

  • created LDAP load balance with vip (located on my internal VPX) based on Carl's article https://www.carlstalhood.com/citrix-gateway-ldap-authentication/#action
  • recreated integration with storefront with wizard, but this time without storefront authentication and bound too existing server, which has been created above.
  • Policies has been created automatically, I just created LDAP policy located in Citrix Gateway/Policies/Authentication/LDAP/Policies and bound to existing LDAP server with binding to "Primary VPN Global Bindings"
  • checked on storefront all seems fine and authentication set to domain and all works fine internally.
  • finally run commend and got below error.

 


 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[6033]: register_timer 0-12: setting timer 47
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/ldap_drv.c[2130]: receive_ldap_user_bind_event 0-12: Got user bind event.
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/ldap_common.c[465]: ns_ldap_check_result 0-12: checking LDAP result.  Expecting 97 (LDAP_R                          ES_BIND)
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/ldap_common.c[503]: ns_ldap_check_result 0-12: ldap_result found expected result LDAP_RES_                          BIND
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/ldap_drv.c[2139]: receive_ldap_user_bind_event 0-12: Bind OK.
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[6110]: unregister_timer 0-12: releasing timer 47
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/ldap_drv.c[2233]: receive_ldap_user_bind_event 0-12: User authentication (Bind event) for                           user Domain\Administrator succeeded
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[4243]: send_accept 0-12: sending accept to kernel for : Domain\Administrator
Thu Sep 10 20:28:57 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[4159]: aaad_alloc_serialize_keyValue_attrs 0-12: Total attribute values to PE : 65                          , email=Administrator@domain.com

Thu Sep 10 20:28:58 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Thu Sep 10 20:29:08 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Thu Sep 10 20:29:18 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 1 firing...
Thu Sep 10 20:29:18 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...
Thu Sep 10 20:29:28 2020
 /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[757]: main 0-0: timer 2 firing...

 

Link to comment
Share on other sites

Which error are you referring to?  As there is no error in the aaad.debug log it just stops...

So we see the connection to AD with the bind account worked. We can't see the group extraction for the test user or if the user authentication succeeded or failed.

Which could be an issue in the policy missing some parameters or something else...

You still need to create AAA Groups on the ADC representing the AD group names in AD that your users belong to and grant authorization allow rights to them if the gateway session profile doesn't make an ALLOW decision.

 

So, if the gateway completes the authentication and attempts to send the data to storefront, then you will see https://<shared fqdn>/Citrix/<StoreNameWeb> in the browser. If you have an error here, then it means gateway completed authentication and there is an issue between the handoff from gateway to storefront and there are things we can check.

 

If the gateway cannot complete the authentication (which is possible based on the lack of additional events in the above log), then the url in the user's browser will likely still say something like:  https://<shared fqdn>/vpn/index.htm or /vpn/tmindex.htm or anything but the /Citrix/<SToreNameWeb> in path.

 

Depending on the behavior and what "error" you are referring to would affect the recommended troubleshooting that happens next.

My guess is there is still an issue in the ldap authentication profile at this stage..but I don't have enough info to say for sure. 

 

 

Link to comment
Share on other sites

37 minutes ago, Al Zabar said:

I have the same error "Cannot complete your request"

 

Ok.  1) The fact that you get from gateway to storefront, means the authentication completed but the storefront is having the problem with the handoff from gateway.  So the focus is now on storefront.

 

2) The AAA groups on the ADC need to match the groups in AD if you are relying on group extraction AND granting either session policy or authorization policy behavior at the group level on the ADC. This is probably not a problem in your current config, but could be an issue in the future.

 

One thing to test, does this store currently work for internal users and it is failing for gateway connections only?

And you should now have an error in the storefront's event logs for application, system, or the desktop delivery service log...

I would also see if the application log on the delivery controller has any issues listed by the citrix broker service that might be applicable....

 

So to troubleshoot storefront:

1) What is your storefront server's base url AND does it match the shared fqdn (and do you have an https cert properly bound)

2) Does the Gateway session policy actually send the user to /citrix/Store or /citrix/StoreWeb.  Meaning the web browser must match the receiver for web path for the store in question. If the session policy is not going to the actual path of the storefront store's web pathway we could have an issue. But the fact that you are seeing the page, means this is likely correct (just double checking things).

3) For the store in question, check its authentication settings and is it configured for internal authentication AND passthrough from gateway. There is a little gear next to gateway that may have some advanced options set from your previous config.

4) Next is the gateway linked to this store under this store's remote access settings?

5) What beacons are configured. Again the shared fqdn cannot be used as either an internal or external beacon.

 

Double check again the gateway settings on this storefront:

Gateway FQDN

Source IP should be the gateway VIP and not a SNIP

Callback address should be the callback VIP (HTTPS) and resolvable from storefront

 

6) Double check the receiver for web setting for this store has its own authentication settings and that it also includes gateway (and it wasn't disabled at the web level)

7) Under Store settings, check the optimal hdx routing (if any site/zone or mulltiple gateways are specified...there may be other things we haven't looked at yet.)

 

common issues:

https://support.citrix.com/article/CTX207162

https://support.citrix.com/article/CTX238964

 

The single fqdn just makes the usual troubleshooting more difficult but all the same conditions apply, just harder to spot config issues vs dns resolution problems.

Be sure you have trusted certs and not self signed installed on the gateway and storefront and issued to the right names.

 

Link to comment
Share on other sites

I have same issue accessing internally on my ADC 13.0 that I upgraded to today. The error is seen on my Gateway CVPN mode accessing the storefront. I followed Carl Stallhood's suggestion https://docs.citrix.com/en-us/citrix-adc/13/aaa-tm/enable-sso-for-auth-pol.html

 

add vpn trafficaction tf_act http -SSO ON

add tm trafficaction tf_act -SSO ON

Link to comment
Share on other sites

1 hour ago, Charlie Ting said:

I have same issue accessing internally on my ADC 13.0 that I upgraded to today. The error is seen on my Gateway CVPN mode accessing the storefront. I followed Carl Stallhood's suggestion https://docs.citrix.com/en-us/citrix-adc/13/aaa-tm/enable-sso-for-auth-pol.html

 

add vpn trafficaction tf_act http -SSO ON

add tm trafficaction tf_act -SSO ON

 

Indeed, it does work as suggested by Carl.

 

Thank you, Carl & Rhonda for your support on this.

 

Could I please ask you to take a look at my other tiny issues on the below links:

https://discussions.citrix.com/topic/410350-external-access-to-exchange-server-lb/#comment-2070264

https://discussions.citrix.com/topic/410276-storefront-session-issues/#comment-2069995

 

 

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