Pass-Through Authentication Fails when Using Standard Receiver on a PNagent Services Site

Pass-Through Authentication for a services site can only use the Receiver Enterprise Edition, also known as the Legacy PNA. There is a misconception that the Standard Receiver can be installed with command line switches to enable to Pass-Through. Then use the Standard receiver to connect to a services site and Pass-Through will work. However, this does not work.

Related:

  • No Related Posts

“This account is already added. Please select another account to add or press the close button” While Configuring Receiver

This article is intended for Citrix administrators and technical teams only.

Non-admin users must contact their company’s Help Desk/IT support team and can refer to CTX297149 for more information.

When customer attempts to configure Receiver, he gets an error:

  • This account is already added. Please select another account to add or press the close button.

Related:

  • No Related Posts

Error “Cannot Connect to Server” when configuring receiver externally

This article is intended for Citrix administrators and technical teams only.

Non-admin users must contact their company’s Help Desk/IT support team and can refer to CTX297149 for more information.


While configuring the receiver; We may get the error message still beacons are perfect to connect receivers;

Error “Cannot Connect to Server” While configuring the receiver externally

Related:

  • No Related Posts

While Installing Receiver, Users May Encounter an Error: “Setup Cannot Continue Because This Version of Receiver is Incompatible With a Previously-installed Version”

Install the latest supported version of Citrix Receiver.

All versions of Receiver for Windows after version 4.4 can upgrade from any older version of Receiver without the need of using the clean up utility.

Receiver cleanup utility is not required and not recommended while upgrading to the Receiver for Windows 4.4, or later.

Related:

Native Receiver Access to Internal and External Store with Always-on NetScaler Gateway VPN Fails

An already existing internal / external store integrated with ICA proxy Netscaler Gateway Vserver has beacons configured to detect internal or external location. Depending on the beacon check Receiver decides whether to contact storefront directly or via NSG (if external).

1. When user moves from LAN to intranet, this triggers a beacon check (changes in physical adapter) and in this scenario the external beacon check will be successful.

2. This beacon check happens before full VPN could be established, so when VPN is eventually established receiver has already detected it’s location to be external.

3. Now, when receiver resolves the Storefront fqdn (after VPN is connected) it will resolve to internal SF and also SF becomes reachable directly

Due to #3 receiver connections land on internal SF but due to #2, since it “thinks” its external the connection method (request url etc) used are that of NSG e.g. /cgi/login which does not exist on StoreFront and receiver is never able to authenticate.

If receiver is exited and restarted (while vpn is already connected), now beacon check will return internal, and also SF resolved directly, so now apps become accessible.

Related:

Native Receiver access to Internal and External Store with Always-on VPN

An already existing internal / external store integrated with ICA proxy Netscaler Gateway Vserver has beacons configured to detect internal or external location. Depending on the beacon check Receiver decides whether to contact storefront directly or via NSG (if external).

1. When user moves from LAN to intranet, this triggers a beacon check (changes in physical adapter) and in this scenario the external beacon check will be successful.

2. This beacon check happens before full VPN could be established, so when VPN is eventually established receiver has already detected it’s location to be external.

3. Now, when receiver resolves the Storefront fqdn (after VPN is connected) it will resolve to internal SF and also SF becomes reachable directly

Due to #3 receiver connections land on internal SF but due to #2, since it “thinks” its external the connection method (request url etc) used are that of NSG e.g. /cgi/login which does not exist on StoreFront and receiver is never able to authenticate.

If receiver is exited and restarted (while vpn is already connected), now beacon check will return internal, and also SF resolved directly, so now apps become accessible.

Related:

CSQX506E error on sender channel communicating with iSeries receiver channel

A sender channel is started and this error message is received : ‘CSQX506E message receipt confirmation not received for channel’ error. Display the status of the remote receiver channel and indicates that the channel is indoubt, which is an invalid state for a receiver channel. Attempts to resolve and delete the receiver channel do not succeed.

Related: