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.
Tag: Radio receiver
“This account is already added. Please select another account to add or press the close button” While Configuring Receiver
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:
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
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
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.