Detailed Change Log

Last Modified: Apr 25, 2018 @ 6:10 am

This post lists all minor and major changes made to carlstalhood.com.

NetScaler Scripting

Last Modified: Jan 4, 2018 @ 8:14 am

Navigation

💡 = Recently Updated

Changelog

  • 2018 Jan 4 – For Configuration Extractor, Sirius’ Mark Scott added code to browse to open and save files. Added kcdaccounts to extraction.
  • 2018 Jan 3 – new Powershell-based NetScaler Configuration Extractor script

NetScaler Configuration Extractor

New and improved NetScaler Configuration Extractor. This time using PowerShell. Here are some features of the script:

  • Given a ns.conf file, the script extracts CLI commands for one or more Virtual Servers.
  • Given a Virtual Server name, the script enumerates all objects linked to the Virtual Server (e.g. Responder Policies) and provides their configuration too.
  • Finds global settings that might affect the operation of the chosen Virtual Servers.
  • The CLI output is listed in proper order. For example, create monitors before binding them to Service Groups.
  • If an exact Virtual Server name is not specified in the script, then the script will prompt you to select one or more Virtual Servers. The list of Virtual Servers can be filtered.

The extracted Virtual Server CLI configuration can be used for documentation, or to apply the configuration to a different appliance.

I originally attempted a dynamic extraction using complicated regular expressions, but there wasn’t enough control over the extraction and output process. The new PowerShell script explicitly enumerates specific objects, thus providing complete control over the output. For example, before binding a cipher group to a Virtual Server, the current ciphers must first be removed.

The script uses several techniques to avoid false positive matches, primarily substring matches.

Let me know what bugs you encounter.

Configure NetScaler from PowerShell

You can use any scripting language that supports REST calls. This section is based on PowerShell 3 and its Invoke-RestMethod cmdlet.

Brandon Olin published a PowerShell module for NetScaler at Github.  💡

CTP Esther Barthel maintains a PowerShell module for NetScaler at https://github.com/cognitionIT/PS-NITRO. See Citrix Synergy TV – SYN325 – Automating NetScaler: talking NITRO with PowerShell for an overview.

The below NetScalerPowerShell.zip contains PowerShell functions that use REST calls to configure a NetScaler appliance. It only takes a few seconds to wipe a NetScaler and configure it with almost everything detailed on this site. A glaring omission is file operations including licenses, certificate files, and customized monitor scripts and the PowerShell script assumes these files are already present on the appliance.

Most of the functions should work on 10.5 and 11.0 with a few obvious exceptions like RDP Proxy. Here are some other differences between 10.5 and 11.0:

  • PUT operations in NetScaler 11 do not need an entity name in the URL; however 10.5 does require entity names in every PUT URL.
  • https URL for REST calls works without issue in NetScaler 11, but NetScaler 10.5 had inconsistent errors. http works without issue in NetScaler 10.5.

Nitro REST API Documentation

NetScaler Nitro REST API documentation can be found on any NetScaler by clicking the Downloads tab. The documentation is updated whenever you upgrade your firmware.

Look for the Nitro API Documentation.

Extract the files, and then launch index.html.

Start by reading the Getting Started Guide, and then expand the Configuration node to see detailed documentation for every REST call.

The Nitro API is also documented at REST Web Services at Citrix Docs.

Global Server Load Balancing (GSLB)

Last Modified: May 4, 2017 @ 2:05 pm

Navigation

GSLB Planning

GSLB is nothing more than DNS. GSLB is not in the data path. GSLB receives a DNS query and GSLB sends back an IP address, which is exactly how a DNS server works. However, GSLB can do some things that DNS servers can’t do:

  • Don’t give out an IP address unless it is UP (monitoring)
    • If active IP address is down, give out the passive IP address (active/passive)
  • Give out the IP address that is closest to the user (proximity load balancing)
  • Give out different IPs for internal vs external (DNS View)

GSLB is only useful if you have a single DNS name that could resolve to two or more IP addresses. If there’s only one IP address then use normal DNS instead.

Citrix Blog Post Global Server Load Balancing: Part 1 explains how DNS queries work and how GSLB fits in.

Citrix has a good DNS and GSLB Primer.

When configuring GSLB, don’t forget to ask “where is the data?”. For XenApp/XenDesktop, DFS multi-master replication of user profiles is not supported so configure “home” sites for users. More information at Citrix Blog Post XenDesktop, GSLB & DR – Everything you think you know is probably wrong!

GSLB can be enabled both externally and internally. For external GSLB, configure it on the DMZ NetScaler appliances and expose it to the Internet. For internal GSLB, configure it on internal NetScaler appliances. Note: Each NetScaler appliance only has one DNS table so if you try to use one NetScaler for both public and internal then be aware that external users can query for internal GSLB-enabled DNS names.

For internal and external GSLB of the same DNS name on the same appliance, you can use DNS Policies and DNS Views to return different IP addresses depending on where users are connecting from. Citrix CTX130163 How to Configure a GSLB Setup for Internal and External Users Using the Same Host Name.

However, GSLB monitoring applies to the entire GSLB Service so it would take down both internal and external GSLB. If you need different GSLB monitoring for internal and external of the same DNS name, try CNAME:

  • External citrix.company.com:
    • Configure NetScaler GSLB for citrix.company.com.
    • On public DNS, delegate citrix.company.com to the NetScaler DMZ ADNS services.
  • Internal citrix.company.com:
    • Configure NetScaler GSLB for citrixinternal.company.com or something like that.
    • On internal DNS, create CNAME for citrix.company.com to citrixinternal.company.com
    • On internal DNS, delegate citrixinternal.company.com to NetScaler internal ADNS services.

Some IP Addresses are needed on each NetScaler pair:

  • ADNS IP: An IP that will listen for ADNS queries. For external, create a public IP for the ADNS IP and open UDP 53 so Internet-based DNS servers can access it. This can be an existing SNIP on the appliance.
  • GSLB Site IP / MEP IP: A GSLB Site IP that will be used for NetScaler-to-NetScaler communication, which is called MEP or Metric Exchange Protocol. The IP for ADNS can also be used for MEP / GSLB Site.
    • RPC Source IP: RPC traffic is sourced from a SNIP, even if this is different than the GSLB Site IP. It’s less confusing if you use a SNIP as the GSLB Site IP.
    • Public IP: For external GSLB, create public IPs that are NAT’d to the GSLB Site IPs. The same public IP used for ADNS can also be used for MEP. MEP should be routed across the Internet so NetScaler can determine if the remote datacenter has Internet connectivity or not.
    • MEP Port: Open port TCP 3009 between the two NetScaler GSLB Site IPs. Make sure only the NetScalers can access this port on the other NetScaler. Do not allow any other device on the Internet to access this port. This port is encrypted.
    • GSLB Sync Ports: To use GSLB Configuration Sync, open ports TCP 22 and TCP 3008 from the NSIP (management IP) to the remote public IP that is NAT’d to the GSLB Site IP. The GSLB Sync command runs a script in BSD shell and thus NSIP is always the Source IP.
  • DNS Queries: The purpose of GSLB is to resolve a DNS name to one of several potential IP addresses. These IP addresses are usually public IPs that are NAT’d to existing Load Balancing, SSL Offload, Content Switching, or NetScaler Gateway VIPs in each datacenter.
  • IP Summary: In summary, for external GSLB, you will need a minimum of two public IPs in each datacenter:
    • One public IP that is NAT’d to the IP that is used for ADNS and MEP (GSLB Site IP). You only need one IP for ADNS / MEP no matter how many GSLB names are configured. MEP (GSLB Site IP) can be a different IP, if desired.
    • One public IP that is NAT’d to a Load Balancing, SSL Offload, Content Switching, or NetScaler Gateway VIP.
    • If you GSLB-enable multiple DNS names, each DNS name usually resolves to different IPs. This usually means that you will need additional public IPs NAT’d to additional VIPs.

ADNS

  1. Identify a SNIP that you will use for MEP and ADNS.
  2. Configure a public IP for the SNIP and configure firewall rules.
  3. If you wish to use GSLB configuration sync then management access (SSH) must be enabled on this SNIP.
  4. On the left, expand Traffic ManagementLoad Balancing, and click Services.
  5. On the right, click Add.
  6. Name the service ADNS or similar.
  7. In the IP Address field, enter an appliance SNIP.
  8. In the Protocol field, select ADNS. Then click OK.
  9. Scroll down and click Done.
  10. On the left of the console, expand System, expand Network, and then click IPs.
  11. On the right, you’ll see the SNIP is now marked as the ADNS svc IP. If you don’t see this yet, click the Refresh icon.
  12. Repeat on the other appliance in the other datacenter.
  13. Your NetScaler appliances are now DNS servers.

Metric Exchange Protocol

  1. Open the firewall rules for Metric Exchange Protocol. You can use the same SNIP and same public IP used for ADNS.
  2. On the left, expand Traffic Management, right-click GSLB, and enable the feature.
  3. Expand GSLB, and click Sites.
  4. On the right, click Add.
  5. Add the local site first. Enter a descriptive name and in the Site Type drop-down, select LOCAL.
  6. In the Site IP Address field, enter an appliance SNIP. This SNIP must be in the default Traffic Domain. The NetScaler listens for GSLB MEP traffic on this IP.
  7. For Internet-routed GSLB MEP, in the Public IP Address field, enter the public IP that is NAT’d to the GSLB Site IP (SNIP). For internal GSLB, there is no need to enter anything in the Public IP field. Click Create.
  8. Go back to System > Network > IPs, and verify that the IP is now marked as a GSLB site IP. If you don’t see it yet, click the Refresh button.
  9. If you want to use the GSLB Sync Config feature, then you’ll need to edit the GSLB site IP, and enable Management Access.
  10. Scroll down and enable Management Access. SSH is all you need.
  11. Go to the other appliance and also create the local GSLB site using its GSLB site IP and its public IP that is NAT’d to the GSLB site IP.
  12. In System > Network > IPs on the remote appliance, there should now be a GSLB site IP. This could be a SNIP. If GSLB Sync is desired, enable management access on that IP and ensure SSH is enabled.
  13. Now on each appliance add another GSLB Site, which will be the remote GSLB site.
  14. Enter a descriptive name and select REMOTE as the Site Type.
  15. Enter the other appliance’s actual GSLB Site IP as configured on the appliance. This IP does not need to be reachable.
  16. In the Public IP field, enter the public IP that is NAT’d to the GSLB Site IP on the other appliance. For MEP, TCP 3009 must be open from the local GSLB Site IP to the remote public Site IP. For GSLB sync, TCP 22, and TCP 3008 must be open from the local NSIP to the remote public Site IP. Click Create.
  17. Repeat on the other appliance.
  18. MEP will not function yet since the NetScaler appliances are currently configured to communicate unencrypted on TCP 3011. To fix that, on the left, expand System, expand Network, and click RPC.
  19. On the right, edit the new RPC address (the other site’s GSLB Site IP), and click Edit.
  20. On the bottom, check the box next to Secure, and click OK.
  21. Do the same thing on the other appliance.
  22. If you go back to GSLB > Sites, you should see it as active.

GSLB Services

GSLB Services represent the IP addresses that are returned in DNS Responses. DNS Query = DNS name. DNS Response = IP address.

GSLB should be configured identically on both NetScalers. Since you have no control over which NetScaler will receive the DNS query, you must ensure that both NetScalers are giving out the same DNS responses.

Create the same GSLB Services on both NetScalers:.

  1. Start on the appliance in the primary data center. This appliance should already have a traffic Virtual Server (NetScaler Gateway, Load Balancing, or Content Switching) for the DNS name that you are trying to GSLB enable.
  2. On the left, expand Traffic Management > GSLB, and click Services.
  3. On the right, click Add.
  4. The service name should be similar to the DNS name that you are trying to GSLB. Include the site name in the service name.
  5. Select the LOCAL Site.
  6. On the bottom part, select Virtual Servers, and then select a Virtual Server that is already defined on this appliance. It should automatically fill in the other fields. If you see a message asking if you wish to create a service object, click Yes.
  7. Scroll up and make sure the Service Type is SSL. It’s annoying that NetScaler doesn’t set this drop-down correctly.
  8. The Public IP field contains the actual IP Address that the GSLB ADNS service will hand out. Make sure this Public IP is user accessible. It doesn’t even need to be a NetScaler owned IP.
  9. Scroll down and click OK.
  10. If the GSLB Service IP is a VIP on the local appliance, then GSLB will simply use the state of the local traffic Virtual Server (Load Balancing, Content Switching, or Gateway). If the GSLB Service IP is a VIP on a remote appliance, then GSLB will use MEP to ask the other appliance for the state of the remote traffic Virtual Server. In both cases, there’s no need to bind a monitor to the GSLB Service.
  11. However, you can also bind monitors directly to the GSLB Service. Here are some reasons for doing so:
    • If the GSLB Service IP is a NetScaler-owned traffic VIP, but the monitors bound the traffic Virtual Server are not the same ones you want to use for GSLB. When you bind monitors to the GSLB Services, the monitors bound to the traffic Virtual Server are ignored.
    • If the GSLB Service IP is in a non-default Traffic Domain, then you will need to attach a monitor since GSLB cannot determine the state of Virtual Servers in non-default Traffic Domains.
    • If the GSLB Service IP is not hosted on a NetScaler, then only GSLB Service monitors can determine if the Service IP is up or not.
  12. If you intend to do GSLB active/active and if you need site persistence then you can configure your GSLB Services to use Connection Proxy or HTTP Redirect. See Citrix Blog Post Troubleshooting GSLB Persistence with Fiddler for more details.
  13. Click Done.
  14. On the other datacenter NetScaler, create a GSLB Service.
  15. Select the REMOTE site that is hosting the service.
  16. Since the service is on a different appliance and not this one, you won’t be able to select it using the Virtual Servers option. Instead, select New Server.
  17. For the Server IP, enter the actual VIP configured on the other appliance. This local NetScaler will use GSLB MEP to communicate with the remote NetScaler to find a traffic Virtual Server with this VIP. The remote NetScaler respond if the remote traffic Virtual Server is up or not. The remote Server IP configured here does not need to be directly reachable by this local appliance. If the Server IP is not owned by either NetScaler, then you will need to bind monitors to your GSLB Service.
  18. In the Public IP field, enter the IP address that will be handed out to clients. This is the IP address that users will use to connect to the service. For Public DNS, you enter a Public IP that is usually NAT’d to the traffic VIP. For internal DNS, the Public IP and the Server IP are usually the same.
  19. Scroll up and change the Service Type to match the Virtual Server defined on the other appliance..
  20. Click OK.
  21. Just like the other appliance, you can also configure Site Persistence and GSLB Service Monitors. Click Done when done.
  22. Create more GSLB Services, one for each traffic VIP. GSLB is useless if there’s only one IP address to return. You should have multiple IP addresses (VIPs) through which a web service (e.g. NetScaler Gateway) can be accessed. Each of these VIPs is typically in different datacenters, or on different Internet circuits. The mapping between DNS name and IP addresses is configured in the GSLB vServer, as detailed in the next section.

GSLB Virtual Server

The GSLB Virtual Server is the entity that the DNS name is bound to. GSLB vServer then gives out the IP address of one of the GSLB Services that is bound to it.

Configure the GSLB vServer identically on both appliances:

  1. On the left, expand Traffic Management > GLSB and click Virtual Servers.
  2. On the right, click Add.
  3. Give the GSLB vServer a descriptive name. For active/active, you can name it the same as your DNS name. For active/passive, you will create two GSLB Virtual Servers, one for each datacenter, so include Active or Passive in the Virtual Server name.
  4. Make sure Service Type is set correctly.
  5. If you intend to bind multiple GSLB Services to this GSLB vServer, then you can optionally check the box for Send all “active” service IPs. By default, GSLB only gives out one IP per DNS query. This checkbox always returns all IPs, but the IPs are ordered based on the GSLB Load Balancing Method and/or GSLB Persistence.
  6. Click OK.
  7. On the right, in the Advanced column, click Service.
  8. On the left, click where it says No GSLB Virtual Server to GSLBService Binding.
  9. Click the arrow next to Click to select.
  10. Check the box next to an existing GSLB Service and click OK. If your GSLB is active/passive then only bind one service.
  11. If your GSLB is active/active then bind multiple GSLB Services. Also, you’d probably need to configure GSLB persistence (Source IP or cookies).
  12. Click Bind.
  13. On the right, in the Advanced column, click Domains.
  14. On the left, click where it says No GSLB Virtual Server Domain Binding.
  15. Enter the FQDN that GSLB will resolve.
  16. If this GSLB is active/passive, there are two options:
    • Use the Backup IP field to specify the IP address that will be handed out if the primary NetScaler is inaccessible or if the VIP on the primary appliance is marked down for any reason.
    • Or, create a second GSLB Virtual Server that has the passive GSLB service bound to it. Don’t bind a Domain to the second GSLB Virtual Server. Then edit the Active GSLB Virtual Server and use the Backup Virtual Server section to select the second GSLB Virtual Server.
  17. Click Bind.
  18. If this is active/active GSLB, you can edit the Method section to enable Static Proximity. This assumes the Geo Location database has already been installed on the appliance.
  19. Also for active/active, if you don’t want to use Cookie-based persistence, then you can use the Persistence section to configure Source IP persistence.
  20. Click Done.
  21. If you are configuring active/passive using the backup GSLB Virtual Server method, create a second GSLB Virtual Server that has the passive GSLB service bound to it. Don’t bind a Domain to the second GSLB Virtual Server. Then edit the Active GSLB Virtual Server and use the Backup Virtual Server section to select the second GSLB Virtual Server.

  22. On the left, if you expand Traffic ManagementDNS, expand Records, and click Address Records, you’ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN.

  23. Create identical GSLB Virtual Servers on the other NetScaler appliance. Both NetScalers must be configured identically.
  24. You can also synchronize the GSLB configuration with the remote appliance by going to Traffic Management > GSLB.
  25. On the right, click Sychronize configuration on remote sites.
  26. Use the check boxes on the top, if desired. It’s usually a good idea to Preview the changes before applying them. Then click OK to begin synchronization.

Some notes regarding GSLB Sync:

  • It’s probably more reliable to do it from the CLI by running sync gslb config and one of the config options (e.g. -preview).
  • GSLB Sync runs as a script on the BSD shell and thus always uses the NSIP as the source IP.
  • GSLB Sync connects to the remote GSLB Site IP on TCP 3008 (if RPC is Secure) and TCP 22.

Test GSLB

  1. To test GSLB, simply point nslookup to the ADNS services and submit a DNS query for one of the DNS names bound to a GSLB vServer. Run the query multiple times to make sure you’re getting the response you expect.
  2. Both NetScaler ADNS services should be giving the same response.
  3. To simulate a failure, disable the traffic Virtual Server.
  4. Then the responses should change. Verify on both ADNS services.

  5. Re-enable the traffic Virtual Server, and the responses should return to normal.


DNS Delegation

If you are enabling GSLB for the domain gateway.corp.com, you’ll need to create a delegation at the server that is hosting the corp.com DNS zone. For public GSLB, you need to edit the public DNS zone for corp.com.

DNS Delegation instructions will vary depending on what product host’s the public DNS zone. This section details Microsoft DNS, but it should be similar in BIND or web-based DNS products.

There are two ways to delegate GSLB-enabled DNS names to NetScaler ADNS:

  • Delegate the individual record. For example, delegate gateway.corp.com to the two NetScaler ADNS services (gslb1.corp.com and gslb2.corp.com).
  • Delegate an entire subzone. For example, delegate the subzone gslb.corp.com to the two NetScaler ADNS services. Then create a CNAME record in the parent DNS zone for gateway.corp.com that is aliased to gateway.gslb.corp.com. When DNS queries make it to NetScaler, they will be for gateway.gslb.corp.com and thus gateway.gslb.corp.com needs to be bound to the GSLB Virtual Server instead of gateway.corp.com. For additional delegations, simply create more CNAME records.

This section covers the first method – delegating an individual DNS record:

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the NetScalers in each data center. These host records for ADNS are used for all GSLB delegations no matter how many GSLB delegations you need to create.
  3. The first Host record is gslb1 (or similar) and should point to the ADNS service (Public IP) on one of the NetScaler appliances.
  4. The second Host record is gslb2 and should point to the ADNS Service (public IP) on the other NetScaler appliance.
  5. If you currently have a host record for the service that you are delegating to GSLB (gateway.corp.com), delete it.
  6. Right-click the parent DNS zone and click New Delegation.
  7. In the Welcome to the New Delegation Wizard page, click Next.
  8. In the Delegated Domain Name page, enter the left part of the DNS record that you are delegating (e.g. gateway). Click Next.
  9. In the Name Servers page, click Add.
  10. This is where you specify gslb1.corp.com and gslb2.corp.com. Enter gslb1.corp.com and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message.
  11. Then click Add to add the other GSLB ADNS server.
  12. Once both ADNS servers are added to the list, click Next.
  13. In the Completing the New Delegation Wizard page, click Finish.
  14. If you run nslookup against your Microsoft DNS server, it will respond with Non-authoritative answer. That’s because it got the response from NetScaler and not from itself.

That’s all there is to it. Your NetScalers are now DNS servers. For active/passive, the NetScalers will hand out the public IP address of the primary data center. When the primary data center is not accessible, GSLB will hand out the GSLB Service IP bound to the Backup GSLB vServer.

Geo Location Database

If you want to use DNS Policies or Static Proximity GSLB Load Balancing or Responders based on user’s location, import a geo location database. Common free databases are:

For IP2Location, see the blog post Add IP2Location Database as NetScaler’s Location File for instructions on how to import.

For GeoLite Legacy:

  1. Download the GeoLite Country database CSV from http://dev.maxmind.com/geoip/legacy/geolite/.
  2. Note: GeoLite City is actually two files that must be merged as detailed at Citrix Blog Post GeoLite City as NetScaler location database. GeoLite Country doesn’t need any preparation.
  3. Upload the extracted database (.csv file) to the NetScaler appliance at /var/netscaler/locdb.

To import the Geo database:

  1. In the NetScaler GUI, on the left, expand AppExpert, expand Location, and click Static Database (IPv4).
  2. On the right, click Add.
  3. Browse to the location database file.
  4. In the Location Format field, select geoip-country and click Create.
  5. When you open a GSLB Service, the public IP will be translated to a location.

You can use the Geo locations in a DNS Policy, static proximity GSLB Load Balancing, or Responders:

Horizon View Load Balancing

Last Modified: Oct 6, 2015 @ 10:03 pm

Navigation

Use this procedure to load balance Horizon View Connection Servers, Horizon View Security Servers, and/or VMware Access Points.

Overview

A typical Horizon View Installation will have at least six connection servers:

  • Two Internal View Connection Servers – these need to be load balanced on an internal VIP
  • Two DMZ View Security Servers – these need to be load balanced on a DMZ VIP
  • The DMZ View Security Servers are paired with two additional internal View Connection Servers. There is no need to load balance the internal Paired Connection Servers. However, we do need to monitor them.

If you are using Access Points instead of Security Servers then you’ll have the following machines. Server pairing is not necessary.

  • Two Internal View Connection Servers – these need to be load balanced on an internal VIP
  • Two DMZ VMware Access Point appliances – these need to be load balanced on a DMZ VIP

This topic is focused on traditional View Security Servers but could be easily adapted for Access Point appliances. The difference is that with Access Points there are no paired servers and thus there’s no need to monitor the paired servers. The VIP ports are identical for both solutions.

Monitors

Users connect to Horizon View Connection Server, Horizon View Security Server, and Access Point appliances on four ports: TCP 443, TCP 8443, TCP 4172, and UDP 4172. Users will initially connect to port 443 and then be redirected to one of the other ports on the same server initially used for the 443 connection. If one of the ports is down, the entire server should be removed from load balancing. To facilitate this, create a monitor for each of the ports (except UDP 4172).

  1. On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name it View-PCOIP or similar.
  4. Change the Type drop-down to TCP.
  5. In the Destination Port field, enter 4172.
  6. Scroll down and click Create.
  7. On the right, click Add.
  8. Name it View-Blast or similar.
  9. Change the Type drop-down to TCP.
  10. In the Destination Port field, enter 8443.
  11. Scroll down and click Create.
  12. On the right, click Add.
  13. Name it View-SSL or similar.
  14. Change the Type drop-down to HTTP-ECV.
  15. In the Destination Port field, enter 443.
  16. Scroll down and check the box next to Secure.
  17. On the Special Parameters tab, in the Send String section, enter GET /broker/xml/
  18. In the Receive String section, enter clientlaunch-default.
  19. Scroll down and click Create.
  20. View Security Servers are paired with View Connection Servers. If the paired View Connection Server is down, then we should probably stop sending users to the corresponding View Security Server. Let’s create a monitor that has a specific IP address in it. Right-click the existing View-SSL or View-SSLAdv monitor and click Add.

  21. Note: this step does not apply to Access Points. Normally a monitor does not have any Destination IP defined, which means it uses the IP address of the service that it is bound to. However, we intend to bind this monitor to the View Security Server but we need it to monitor the paired View Connection Server, which is a different IP address. Type in the IP address of the paired View Connection Server. Then rename the monitor so it includes the View Connection Server name.
  22. Note: this step does not apply to Access Points. Since we are embedding an IP address into the monitor, you have to create a separate monitor for each paired View Connection Server IP.

Servers

Create Server Objects for the DMZ Security Servers and the internal non-paired Connection Servers. Do not create Server Objects for the Paired Connection Servers.

  1. On the left, expand Traffic Management, expand Load Balancing, and click Servers.
  2. On the right, click Add.
  3. Enter a descriptive server name, usually it matches the actual server name.
  4. Enter the IP address of the View Connection Server or View Security Server.
  5. Enter comments to describe the server. Click Create.
  6. Continue adding View Connection Servers or View Security Servers.

Services

If deploying View Security Servers, create Services Objects for the DMZ Security Servers and the internal non-paired Connection Servers. Do not create Services Objects for the Paired Connection Servers.

If deploying Access Points, create Services Objects for the DMZ Access Point appliances and the internal Connection Servers

Each connection server and security server needs separate Service objects. Each Security Server listens on multiple port numbers and thus there will be multiple Services Objects for each Security Server.

For Internal Connection Servers (not the paired servers), load balancing monitoring is very simple:

  • Create services for SSL 443
  • To verify server availability, monitor port TCP 443 on the same server.
  • If tunneling is disabled then internal users connect directly to View Agents and UDP/TCP 4172 and TCP 8443 are not used on Internal Connection Servers. There’s no need to create services and monitors for these ports.

Security Servers and Access Points are more complex:

  • The PCoIP Secure Gateway and HTML Blast Secure Gateway are typically enabled on Security Servers and Access Points but they are not typically enabled on internal Connection Servers.
  • All traffic initially connects on TCP 443. For Security Servers and Access Points, the clients then connect to UDP 4172 or TCP 8443 on the same Security Server. If UDP 4172 or TCP 8443 are down, then you probably want to make sure TCP 443 is also brought down.
  • Each Security Server is paired with an internal Connection Server. If the internal Connection Server is down then the Security Server should be taken down. This does not apply to Access Points.
  • To accommodate these failure scenarios, bind multiple monitors to the View Security Server or Access Point load balancing Services. If any of the monitors fails then NetScaler will no longer forward traffic to 443 on that particular server.

If you have two View Security Servers or Access Points named VSS01 and VSS02, the configuration is summarized as follows (scroll down for detailed configuration):

  • Service = VSS01, Protocol = SSL_BRIDGE, Port = 443
    • Monitors = PCoIP (TCP 4172), SSL (443), and Blast (8443)
    • Monitor = SSL (443) on paired View Connection Server VCS01. This monitor is not needed on Access Points.
  • Service = VSS02, Protocol = SSL_BRIDGE, Port = 443
    • Monitors = PCoIP (TCP 4172), SSL (443), and Blast (8443)
    • Monitor = SSL (443) on paired View Connection Server VCS02. This monitor is not needed on Access Points.
  • Service = VSS01, Protocol = TCP, Port = 4172
    • Monitor = PCoIP (TCP 4172)
  • Service = VSS02, Protocol = TCP, Port = 4172
    • Monitor = PCoIP (TCP 4172)
  • Service = VSS01, Protocol = UDP, Port = 4172
    • Monitor = PCoIP (TCP 4172)
  • Service = VSS02, Protocol = UDP, Port = 4172
    • Monitor = PCoIP (TCP 4172)
  • Service = VSS01, Protocol = SSL_BRIDGE, Port = 8443
    • Monitor = Blast (8443)
  • Service = VSS02, Protocol = SSL_BRIDGE, Port = 8443
    • Monitor = Blast (8443)

If you are not using HTML Blast then you can skip 8443. If you are not using PCoIP Secure Gateway, then you can skip the 4172 ports.

  1. On the left, expand Traffic Management, expand Load Balancing, and click Services.
  2. On the right, click Add.
  3. Give the Service a descriptive name (e.g. svc-VSS01-SSL).
  4. Change the selection to Existing Server and select the View Security Server or internal (non-paired) View Connection Server you created earlier.
  5. Change the Protocol to SSL_BRIDGE and click OK.
  6. On the left, in the Monitors section, click where it says 1 Service to Load Balancing Monitor Binding.
  7. Click Add Binding.
  8. Click the arrow next to Click to select.
  9. Select the View-SSL monitor and click OK.
  10. Then click Bind.
  11. If this is a View Security Server, add monitors for PCoIP and HTML Blast. If any of those services fails, then 443 needs to be marked DOWN.

  12. If this is a View Security Server, also add a monitor that has the IP address of the paired View Connection Server. If the paired View Connection Server is down, then stop sending connections to this View Security Server.
  13. The Last Response should indicate Success. If you bound multiple monitors to the Service, then the member will only be UP if all monitors succeed. There’s a refresh button on the top-right. Click Close when done.
  14. Then click Done.
  15. Right-click the first service and click Add.
  16. Change the name to match the second View Server.
  17. Use the Server drop-down to select to the second View Server.
  18. The remaining configuration is identical to the first server. Click OK.
  19. You will need to configure the monitors again. They will be identical to the first server except for the monitoring of the paired View Connection Server. Click Done when done.

  20. Add another Service for PCoIP on TCP 4172.
    1. Name = svc-VSS01-PCoIPTCP or similar.
    2. Server = Existing Server, select the first View Server.
    3. Protocol = TCP
    4. Port = 4172.
    5. Monitors = View-PCoIP. You can add the other monitors if desired.
  21. Repeat for the 2nd View Security Server.
  22. Add another Service for PCoIP on UDP 4172.
    1. Name = svc-VSS01-PCoIPUDP or similar.
    2. Existing Server = first View Server
    3. Protocol = UDP
    4. Port = 4172.
    5. Monitors = View-PCoIP. You can add the other monitors if desired.
  23. Repeat for the 2nd View Server.
  24. Add another Service for HTML Blast on SSL_BRIDGE 8443.
    1. Name = svc-VSS01-HTMLBlast or similar.
    2. Existing Server = the first View Server
    3. Protocol =
    4. Port = 8443.
    5. Monitors = View-Blast. You can add the other monitors if desired.
  25. Repeat for the 2nd View Server.
  26. The eight services should look something like this:
  27. Repeat these instructions to add the internal (non-paired) View Connection Servers except that you only need to add services for SSL_BRIDGE 443 and only need monitoring for 443.

Load Balancing Virtual Servers

Create separate load balancers for internal and DMZ.

  • Internal load balances the two non-paired Internal View Connections Servers.
  • DMZ load balances the two View Security Servers or Access Point appliances.

The paired View Connection Servers do not need to be load balanced.

For the internal View Connection Servers you only need a load balancer for SSL_BRIDGE 443. If tunneling is disabled then you don’t need load balancers for the other ports (UDP/TCP 4172 and SSL_BRIDGE 8443).

However, tunneling is enabled on the View Security Servers and Access Point appliances so you will need separate load balancers for each port number. Here is a summary of the Virtual Servers:

  • Virtual Server on SSL_BRIDGE 443 – bind both View SSL Services.
  • Virtual Server on UDP 4172 – bind both View PCoIPUDP Services.
  • Virtual Server on TCP 4172 – bind both View PCoIPTCP Services.
  • Virtual Server on SSL_BRIDGE 8443 – bind both View Blast Services.

Do the following to create the Virtual Servers:

  1. On the left, under Traffic Management > Load Balancing, click Virtual Servers.

  2. On the right click Add.
  3. Name it View-SSL-LB or similar.
  4. Change the Protocol to SSL_BRIDGE.
  5. Specify a new internal VIP. This one VIP will be used for all of the Virtual Servers.
  6. Enter 443 as the Port.
  7. Click OK.
  8. On the left, in the Services and Service Groups section, click where it says No Load Balancing Virtual Server Service Binding.
  9. Click the arrow next to Click to select.
  10. Select the two View-SSL Services and click OK.
  11. Click Bind.
  12. Click OK.
  13. Then click Done. Persistency will be configured later.
  14. If this is a View Security Server or Access Point or if tunneling is enabled then create another Load Balancing Virtual Server for PCoIP UDP 4172:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = UDP, Port = 4172
    3. Services = the PCoIP UDP Services.
  15. If this is a View Security Server or Access Point or if tunneling is enabled then create another Load Balancing Virtual Server for PCoIP TCP 4172:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = TCP, Port = 4172
    3. Services = the PCoIP TCP Services.
  16. If this is a View Security Server or Access Point or if tunneling is enabled then create another Load Balancing Virtual Server for HTML Blast SSL_BRIDGE 8443:
    1. Same VIP as the 443 Load Balancer.
    2. Protocol = SSL_BRIDGE, Port = 8443
    3. Services = the HTML Blast SSL_BRIDGE Services.
  17. This gives you four Virtual Servers on the same VIP but different protocols and port numbers.

Persistency Group

For Security Servers and Access Point appliances, users will first connect to SSL_BRIDGE 443 and be load balanced. Subsequent connections to the other port numbers must go to the same load balanced server. Create a Persistency Group to facilitate this.

If tunneling is disabled on the internal View Connection Servers then you probably only have one load balancer for those servers and thus you could configure persistence directly on that one load balancer instead of creating a Persistency Group. However, since the View Security Servers have multiple load balancers then you need to bind them together in a Persistency Group.

  1. On the left, under Traffic Management, expand Load Balancing and click Persistency Groups.
  2. On the right, click Add.
  3. Give the Persistency Group a name (e.g. View).
  4. Change the Persistence to SOURCEIP.
  5. Enter a timeout that is equal to or greater than the timeout in View Administrator, which defaults to 10 hours (600 minutes).
  6. In the Virtual Server Name section, click Add.
  7. Move all four View Security Server / Access Point Load Balancing Virtual Servers to the right. Click Create.

Horizon View Configuration

  1. On the View Security Servers (or View Connection Servers), request a certificate that matches the FQDN that resolves to the Load Balancing VIP.
  2. Make sure the private key is exportable.
  3. Set the Friendly Name to vdm and restart the View Security Server services.
  4. In View Administrator, go to View Configuration > Servers.
  5. On the right, switch to the Security Servers tab.
  6. Highlight a server and click Edit.
  7. Change the URLs to the FQDN that resolves to the load balancing VIP.
  8. Change the PCoIP URL to the VIP. For View Security Servers, this is typically a public IP that is NAT’d to the DMZ Load Balancing VIP.

Web Interface Load Balancing

Last Modified: May 4, 2017 @ 2:08 pm

Navigation

This procedure is only needed if you are running Web Interface instead of StoreFront.

Monitor

  1. On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
  2. On the right, click Add.
  3. Name it Web Interface or similar.
  4. Change the Type drop-down to CITRIX-WEB-INTERFACE.
  5. If you will use SSL to communicate with the Web Interface servers, then scroll down and check the box next to Secure.
  6. Switch to the Special Parameters tab.
  7. In the Site Path field, enter the path of a XenApp Web site (e.g. /Citrix/XenApp/).
    • Make sure you include the slash (/) on the end of the path or else the monitor won’t work.
    • The site path is also case sensitive.
  8. Click Create.

Servers

  1. On the left, expand Traffic Management, expand Load Balancing, and click Servers.
  2. On the right, click Add.
  3. Enter a descriptive server name, usually it matches the actual server name.
  4. Enter the IP address of the server.
  5. Enter comments to describe the server. Click Create.
  6. Continue adding Web Interface servers.

Service Group

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.

  2. On the right, click Add.
  3. Give the Service Group a descriptive name (e.g. svcgrp-WI-SSL).
  4. Change the Protocol to HTTP or SSL. If the protocol is SSL, ensure the Web Interface Monitor has Secure enabled.
  5. Scroll down and click OK.
  6. On the right, under Advanced, click Members.
  7. Click where it says No Service Group Member.
  8. If you did not create server objects then enter the IP address of a Web Interface Server. If you previously created a server object then change the selection to Server Based and select the server object.
  9. Enter 80 or 443 as the port. Then click Create.

  10. To add more members, click where it says 1 Service Group Member and then click Add. Click Close when done.

  11. On the right, under Advanced, click Monitors.
  12. On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
  13. Click the arrow next to Click to select.
  14. Select the Web Interface monitor and click OK.
  15. Then click Bind.
  16. To verify if the monitor is working or not, on the left, in the Service Group Members section, click the Service Group Members line.
  17. Highlight a member and click Monitor Details.
  18. The Last Reponse should indicate that Set-Cookie header was found. Click Close twice when done.
  19. Then click Done.

Load Balancing Virtual Server

  1. Create or install a certificate that will be used by the SSL Virtual Server. This certificate must match the DNS name for the load balanced Web Interface servers.
  2. On the left, under Traffic Management > Load Balancing, click Virtual Servers.

  3. On the right click Add.
  4. Name it Web Interface-SSL-LB or similar.
  5. Change the Protocol to SSL.
  6. Specify a new internal VIP.
  7. Enter 443 as the Port.
  8. Click OK.
  9. On the left, in the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
  10. Click the arrow next to Click to select.
  11. Select your Web Interface Service Group and click OK.
  12. Click Bind.
  13. Click OK.
  14. Click where it says No Server Certificate.
  15. Click the arrow next to Click to select.
  16. Select the certificate for this Web Interface Load Balancing Virtual Server and click OK.
  17. Click Bind.
  18. Click OK.
  19. On the right, in the Advanced column, click Persistence.
  20. Select SOURCEIP persistence. Note: COOKIEINSERT also works with Web Interface. However, it doesn’t work with StoreFront.
  21. Set the timeout to match the timeout of Web Interface.
  22. The IPv4 Netmask should default to 32 bits.
  23. Click OK.
  24. On the right, in the Advanced column, click SSL Parameters.
  25. If the NetScaler communicates with the Web Interface servers using HTTP (aka SSL Offload), at the top right, check the box next to SSL Redirect. Otherwise the Web Interface page will never display.
  26. Uncheck the box next to SSLv3 and click OK. This removes a security vulnerability.
  27. NetScaler VPX 10.5 build 57 and newer lets you enable TLSv11 and TLSv12. See Citrix Blog – Scoring an A+ at SSLlabs.com with Citrix NetScaler – 2016 update. Click OK.
  28. On the right, in the Advanced column, click SSL Ciphers.
  29. On the left, in the SSL Ciphers section, remove all RC4 ciphers. See Anton van Pelt Make your NetScaler SSL VIPs more secure (Updated) for recommended ciphers.

    You can also run the following from the command line as described by Heikki Harsunen in Citrix Discussions:
    unbind ssl vserver <oursslvservername> -cipherName DEFAULTbind ssl vserver <oursslvservername> -cipherName TLS1-ECDHE-RSA-AES256-SHAbind ssl vserver <oursslvservername> -cipherName TLS1-ECDHE-RSA-AES128-SHAbind ssl vserver <oursslvservername> -cipherName TLS1-ECDHE-RSA-DES-CBC3-SHAbind ssl vserver <oursslvservername> -cipherName TLS1-AES-256-CBC-SHAbind ssl vserver <oursslvservername> -cipherName TLS1-AES-128-CBC-SHAbind ssl vserver <oursslvservername> -cipherName TLS1-DHE-RSA-AES-256-CBC-SHAbind ssl vserver <oursslvservername> -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA
    
  30. Click OK.
  31. Then click Done.
  32. Consider enabling Strict Transport Security by creating a rewrite policy and binding it to this SSL Virtual Server. See Anton van Pelt Make your NetScaler SSL VIPs more secure (Updated).

SSL Redirect – Down vServer Method

If you created an SSL Virtual Server that only listens on SSL 443, users must enter https:// when navigating to the website. To make it easier for the users, create another load balancing Virtual Server on the same VIP that listens on HTTP 80 and then redirects the user’s browser to reconnect on SSL 443.

  1. On the left, under Traffic Management > Load Balancing, click Virtual Servers.

  2. On the right, find the SSL Virtual Server you’ve already created, right-click it and click Add. Doing it this way copies some of the data from the already created Virtual Server.
  3. Change the name to indicate that this new Virtual Server is an SSL Redirect.
  4. Change the Protocol to HTTP on Port 80.
  5. The IP Address should already be filled in. It must match the original SSL Virtual Server. Click OK.
  6. Don’t select any services. This vServer must intentionally be marked down so the redirect will take effect. Click OK.
  7. On the right, in the Advanced column, click Protection.
  8. In the Redirect URL field, enter the full URL including https://. For example: https://citrix.company.com/Citrix/XenApp. Click OK.
  9. Click Done.
  10. When you view the SSL redirect Virtual Server in the list, it will have a state of DOWN. That’s OK. The Port 80 Virtual Server must be DOWN for the redirect to work.

NetScaler Insight Center

Last Modified: Jul 12, 2017 @ 6:18 am

This article is for Insight Center 11.0 and older. Consider Insight Center 11.1, which works with older NetScaler appliances.

Navigation

💡 = Recently Updated

Planning

Note: HDX Insight only works with Session Reliability on NetScaler 10.5 build 54 or newer. Older builds, including NetScaler 10.1, do not support Session Reliability with HDX Insight. Read the release notes for your NetScaler firmware build to see the latest known issues with AppFlow, Session Reliability, and High Availability.

Requirements for HDX Insight:

  • Your NetScaler appliance must be running Enterprise Edition or Platinum Edition.
  • NetScaler must be 10.1 or newer. Insight Center 11 does work with NetScaler 10.5.
  • HDX Insight works with the following Receivers:
    • Receiver for Windows must be 3.4 or newer.
    • Receiver for Mac must be 11.8 or newer.
    • Receiver for Linux must be 13 or newer.
    • Notice no mobile Receivers. See the Citrix Receiver Feature Matrix for the latest details.
  • ICA traffic must flow through a NetScaler appliance:

 

For ICA round trip time calculations, in a Citrix Policy, enable the following settings:

  • ICA > End User Monitoring > ICA Round Trip Calculation
  • ICA > End User Monitoring > ICA Round Trip Calculation Interval
  • ICA > End User Monitoring > ICA Round Trip Calculation for Idle Connections

Citrix CTX204274 How ICA RTT is calculated on NetScaler Insight: ICA RTT constitutes the actual application delay. ICA_RTT = 1 + 2 + 3 + 4 +5 +6:  💡

  1. Client OS introduced delay
  2. Client to NS introduced network delay (Wan Latency)
  3. NS introduced delay in processing client to NS traffic (Client Side Device Latency)
  4. NS introduced delay in processing NS to Server (XA/XD) traffic (Server Side Device Latency)
  5. NS to Server network delay (DC Latency)
  6. Server (XA/XD) OS introduced delay (Host Delay)

 

For Web Insight, HTML Injection for NetScaler 10.0 is only available in Platinum Edition. In NetScaler 10.1, HTML Injection is available in all editions.

The version/build of Insight Center must be the same or newer than the version/build of the NetScaler appliances.

Insight Center 11 lets you scale the deployment by building multiple nodes. After building the first Insight Center Server, you can go to Configuration > NetScaler Insight Center > Insight Deployment Method to enter some planning data (e.g. # of concurrent ICA connections) and it will tell you the number of Insight Center nodes you should build. The number of nodes is based on the VM specs shown at the top of the page.

In this example, it recommends two Database Nodes and two Connectors. Agents are only used for HTTP traffic. There’s more information at NetScaler Insight Center Deployment Management at docs.citrix.com.

Import Appliance

You can use either the vSphere Client or the vSphere Web Client to import the appliance. In vSphere Client, open the File menu and click Deploy OVF Template. vSphere Web Client instructions are shown below.

You might see this operating system error when not using the vSphere Web Client. Click Yes and proceed. It seems to work.

  1. Download Insight Center for ESX and then extract the .zip file.
  2. In vSphere Web Client, navigate to the vCenter object. Open the Actions menu and click Deploy OVF Template.
  3. In the Select source page, if you see a message regarding the Client Integration Plug-in, download the installer, run it, and then return to this wizard.
  4. In the Select source page, select Local file and browse to the NetScaler Insight .ovf file. Click Next.
  5. In the Review details page, click Next.
  6. In the Select name and folder page, enter a name for the virtual machine and select an inventory folder. Then click Next.
  7. In the Select a resource page, select a cluster or resource pool and click Next.
  8. In the Select storage page, change it to Thin Provision.
  9. Select a datastore and click Next.
  10. In the Setup networks page, choose a valid port group and click Finish.
  11. In the Ready to Complete page, click Finish.
  12. View the progress of the import in the Recent Tasks pane at the top-right of the window.
  13. After the appliance is imported, power it on.

IP Configuration and Multi-Node

  1. Open the console of the virtual machine and configure an IP address.
  2. Insight Center 11 lets you configure a DNS server.
  3. Enter 6 when done.
  4. When prompted for Insight Deployment Type, enter 1 for NetScaler Insight Server. The first appliance must always be NetScaler Insight Server.
  5. Enter Yes to reboot.
  6. Subsequent nodes can be Database Node, Connector node, etc. If you choose one of the other node types it asks you for the IP address of the NetScaler Insight Server node.
  7. Once you’ve built all of the nodes, in the NetScaler Insight Server webpage, go to NetScaler Insight Center > Insight Deployment Management.
  8. Scroll down and click Get.
  9. It should show you the nodes. Then click Deploy.

  10. After it reboots you’ll see the performance of each node.
  11. Since the database is on a separate node, you might want to enable database caching. Go to System > Change Database Cache Settings.
  12. Check the box next to Enable Database Cache.

Initial Web Configuration

  1. Point your browser to the Insight IP address and login as nsroot/nsroot.
  2. Click Get Started

  3. Enter the IP address and credentials of a NetScaler appliance and click Add.

    Note: if your NetScaler appliances require https for management communication then this won’t work. Click Cancel. On the Configuration tab, click System. On the right, in the left column, click Change System Settings.
    Change the drop-down to https and click OK.
    On the left, click Inventory. On the right, click Add.
    Enter the NSIP and nsroot credentials again. This time it should work.
  4. At the top of the page, if desired, check the box next to Enable Geo data collection for Web and HDX Insight.
  5. With Load Balancing selected in the View list, right-click your StoreFront load balancer and click Enable AppFlow.

  6. Type in true and click OK.
  7. Note: if your StoreFront Load Balancing vServer uses Service Groups, you might need to enable AppFlow logging on the Service Group. In the NetScaler GUI, edit the Service Group. In the Basic Settings section, check the box next to AppFlow Logging.
  8. Back in Insight Center, use the View drop-down to select VPN.
  9. Right-click a NetScaler Gateway Virtual Server and click Enable AppFlow.
  10. In the Select Expression drop-down, select true.
  11. For Export Option select ICA and HTTP and click OK. The HTTP option is for Gateway Insight.
  12. The TCP option is for the second appliance in double-hop ICA. If you need double-hop then you’ll also need to run set appflow param -connectionChaining ENABLED on both appliances. See Enabling Data Collection for NetScaler Gateway Appliances Deployed in Double-Hop Mode at docs.citrix.com for more information.
  13. New in NetScaler 11 is the ability to use SOCKS proxy (Cache Redirection) for ICA traffic without requiring users to use NetScaler Gateway and without making any routing changes. You configure this on the NetScaler appliance. See Enabling Data Collection for Monitoring NetScaler ADCs Deployed in LAN User Mode at docs.citrix.com for more information.
  14. If you want to add more appliances, click the Configuration tab. The Inventory node will be selected by default.
  15. On the right, click Add.

Citrix Blog PostNetScaler Insight Center – Tips, Troubleshooting and Upgrade

Nsroot Password

  1. On the Configuration tab, expand System, expand User Administration and click Users.
  2. On the right, highlight the nsroot account and click Edit.
  3. Enter a new password.
  4. You can also specify a session timeout. Click OK.

Management Certificate

The certificate to upload must already be in PEM format. If you have a .pfx, you must convert it to PEM (separate certificate and key files). You can use NetScaler to convert the .pfx and then download the converted certificate from the appliance.

  1. On the left, switch to the System node.
  2. In the right pane, in the left column, click Install SSL Certificate.
  3. Browse to the PEM format certificate and key files. If the keyfile is encyrpted, enter the password. Click OK.
  4. Click Yes to reboot the system.

System Configuration

  1. Click the Configuration tab on the top of the page.
  2. On the left, click the System node.
  3. On the right, modify settings (e.g.Time Zone) as desired.

  4. To set the hostname, click Change Host name.

  5. To change the Session Timeout, click Change System Settings.

  6. The ICA Session Timeout can be configured by clicking the link. Two minutes of non-existent traffic must occur before the session is considered idle. Then this idle timer starts. See Managing ICA Sessions at docs.citrix.com for more information

  7. On the left, expand System and click NTP Servers.
  8. On the right, click Add.

  9. After adding NTP servers, click NTP Synchronization.
  10. Check the box next to Enable NTP Sync and click OK.
  11. On the left, expand Auditing and click Syslog Servers.

  12. On the right, click Add.
  13. Enter the syslog server IP address and select Log Levels. Click Create.
  14. In the Action menu you can click Syslog Parameters to change the timezone and date format.

Email Notifications

  1. On the left, expand System, expand Notifications and click Email.
  2. On the right, on the Email Servers tab, click Add.
  3. Enter the SMTP server address and click Create.
  4. On the right, switch to the Email Distribution List tab and click Add.
  5. Enter an address for a destination distribution list and click Create.

Authentication

  1. On the left, expand System¸ expand Authentication and click LDAP.
  2. On the right, click Add.
  3. This is configured identically to NetScaler. Enter a Load Balancing VIP for LDAP. Change the Security Type to SSL and Port to 636. Scroll down.
  4. Enter the bind account.
  5. Check the box for Enable Change Password.
  6. Click Retrieve Attributes and scroll down.
  7. For Server Logon Attribute select sAMAccountName.
  8. For Group Attribute select memberOf.
  9. For Sub Attribute Name select cn.
  10. To prevent unauthorized users from logging in, configure a Search Filter. Scroll down.
  11. If desired configure Nested Group Extraction.
  12. Click Create.
  13. On the left, expand User Administration and click Groups.
  14. On the right, click Add.
  15. Enter the case sensitive name of your NetScaler Admins group.
  16. Select the admin Permission.
  17. If desired, configure a Session Timeout. Click Create.

  18. On the left, under System, click User Administration.
  19. On the right click User Lockout Configuration.
  20. If desired, check the box next to Enable User Lockout and configure the maximum logon attempts. Click OK.
  21. On the left, under System, click Authentication.
  22. On the right, click Authentication Configuration.
  23. Change the Server Type to LDAP.
  24. Select the LDAP server you created and click OK.

Thresholds

  1. Go to NetScaler Insight Center > Thresholds.
  2. On the right, click Add.
  3. Enter a name.
  4. In the Entity field select a category of alerts. What you choose here determines what’s available in the Rule section.
  5. Check the box to Notify through Email.
  6. In the Rule section, select a rule and enter threshold values. Click Create.

Geo Map

  1. Download the Maxmind database from http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz.
  2. Extract the .gz file.
  3. On the Configuration tab, expand NetScaler Insight Center and click Geo Database Files.
  4. On the right, click the Action drop-down and click Upload.
  5. Browse to the extracted GeoLiteCity.dat file and click Upload.
  6. Click the Inventory node.
  7. Click the IP address for a device in the inventory.
  8. Check the box to Enable Geo data collection for Web and HDX Insight.
  9. You can define Geo locations for internal subnets. Go to NetScaler Insight Center > Private IP Block.
  10. On the right, click Add.
  11. Enter a name.
  12. Enter the starting and ending IP address.
  13. Select a Geo Location. Note that these are not necessarily alphabetical.
  14. Click Create.

Director Integration

Integrating Insight Center with Director requires XenApp/XenDesktop to be licensed for Platinum Edition. The integration adds Network tabs to the Trends and Machine Details views.

If using HTTPS to connect to Insight Center then the Insight Center certificate must be valid and trusted by both the Director Server and the Director user’s browser.

To link Citrix Director with NetScaler HDX Insight, on the Director server run C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /confignetscaler. Do this on both Director servers.

Use Insight Center

HDX Insight

HDX Insight Dashboard displays ICA session details including the following:

  • WAN Latency
  • DC Latency
  • RTT (round trip time)
  • Retransmits
  • Application Launch Duration
  • Client Type/Version
  • Bandwidth
  • Licenses in use

HDX Insight can also display Geo Maps. Configure Insight Center with Private IP Blocks.

More info at HDX Insight Reports and Use Cases: HDX Insight at docs.citrix.com

Gateway Insight

Insight Center 11.0 build 65 adds a new Gateway Insight dashboard.

This feature displays the following details:

  • Gateway connection failures due to failed EPA scans, failed authentication, failed SSON, or failed application launches.
  • Bandwidth and Bytes Consumed for ICA and other applications accessed through Gateway.
  • # of users
  • Session Modes (clientless, VPN, ICA)
  • Client Operating Systems
  • Client Browsers

More details at Gateway Insight at docs.citrix.com.

Security Insight

The new Security Insight dashboard in 11.0 build 65 and newer uses data from Application Firewall to display Threat Index (criticality of attack), Safety Index (how securely NetScaler is configured), and Actionable Information. More info at Security Insight at docs.citrix.com.
localized image

Troubleshooting

Citrix CTX215130 HDX Insight Diagnostics and Troubleshooting Guide: Syslog messages; Error counters; Troubleshooting checklist, Logs

Citrix Blog PostNetScaler Insight Center – Tips, Troubleshooting and Upgrade

See docs.citrix.com Troubleshooting Tips. Here are sample issues covered in docs.citrix.com:

  • Can’t see records on Insight Center dashboard
  • ICA RTT metrics are incorrect
  • Can’t add NetScaler appliance to inventory
  • Geo maps not displaying

Upgrade Insight Center

  1. Download the latest Upgrade Pack for Insight Center.
  2. Login to Insight Center.
  3. If you are running Insight Center 10.5 or older, on the Configuration tab, go to NetScaler Insight Center > Software Images and upload the file. If running Insight Center 11.0 or newer, you can skip this step.
  4. On the Configuration tab, on the left, click the System node.
  5. On the right, in the right pane, click Upgrade NetScaler Insight Center.
  6. Browse to the build-analytics-11.0.tgz Software Image Upgrade Pack and click OK.
  7. Click Yes to reboot the appliance.

  8. After it reboots, login. The new firmware version will be displayed in the top right corner.

NetScaler Gateway RADIUS Authentication

Last Modified: May 4, 2017 @ 2:20 pm

Navigation

RADIUS Overview

For two-factor authentication using Azure Multi-factor Authentication, see Jason Samuel How to deploy Microsoft Azure MFA & AD Connect with Citrix NetScaler Gateway

Citrix CTX125364 How to Configure Dual Authentication on NetScaler Gateway Enterprise Edition for Use with iPhone and iPad

Some two-factor products (e.g. SMS Passcode) require you to hide the 2nd password field. Receiver 4.4 and newer supports hiding the 2nd field if you configure a Meta tag in index.html. See CTX205907 Dual-Password Field Shows in First Authentication When Connecting to NetScaler Gateway from Windows Receiver for instructions.

Two-factor authentication to NetScaler Gateway requires the RADIUS protocol to be enabled on the two-factor authentication product.

On your RADIUS servers, you’ll need to add the NetScaler appliances as RADIUS Clients. When NetScaler uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the NetScaler NSIP (NetScaler IP). Use the correct IP(s) when adding the appliances as RADIUS Clients. And adjust firewall rules accordingly.

For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

Two-factor Policies Summary

When configuring the NetScaler Gateway Virtual Server, you can specify both a Primary authentication policy and a Secondary authentication policy. Users are required to successfully authenticate against both before being authorized for NetScaler Gateway.

For browser-based StoreFront, you need two authentication policies:

  • Primary = LDAPS authentication policy pointing to Active Directory Domain Controllers.
  • Secondary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.

For Receiver Self-service (native Receiver on mobile, Windows, and Mac), the authentication policies are swapped:

  • Primary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.
  • Secondary = LDAPS authentication policy pointing to Active Directory Domain Controllers.

If you need to support two-factor authentication from both web browsers and Receiver Self-Service, then you’ll need at least four authentication policies as shown below.

Primary:

  • Priority 90 = RADIUS policy. Expression = REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
  • Priority 100 = LDAP policy. Expression = REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

Secondary:

  • Priority 90 = LDAP policy. Expression = REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
  • Priority 100 = RADIUS policy. Expression = REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

Create Two-factor Policies

Do the following to create the Two-factor policies:

  1. Create an LDAP policy/server.
  2. For RADIUS, on the left, expand NetScaler Gateway, expand Policies, expand Authentication, and click Radius.
  3. On the right, switch to the Servers tab. Click Add.
  4. Give the RADIUS server a name.
  5. Specify the IP address of the RADIUS load balancing Virtual Server.
  6. Enter the secret key specified when you added the NetScalers as RADIUS clients on the RADIUS server. Click Create.

    add authentication radiusAction RSA -serverIP 10.2.2.210 -serverPort 1812 -radKey Passw0rd
  7. On the right, switch to the Policies tab, and click Add.
  8. Name it RSA-SelfService or similar.
  9. Select the RADIUS server created earlier.
  10. Enter an expression. You will need two policies with different expressions. The expression for Receiver Self-Service is HTTP.HEADER User-Agent CONTAINS CitrixReceiver.
  11. Click Create.

    add authentication radiusPolicy RSA-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" RSA
    
    add authentication radiusPolicy RSA-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" RSA
    
    add authentication ldapPolicy Corp-Gateway-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" Corp-Gateway
    
    add authentication ldapPolicy Corp-Gateway-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" Corp-Gateway
  12. Create another policy to match the ones shown below. Both RADIUS policies are configured with the same RADIUS server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS)
    Name Expression Server
    RSA-SelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver RSA
    RSA-Web REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver RSA

  13. Go to NetScaler Gateway\Policies\Authentication\LDAP. On the Policies tab, create two policies with the expressions shown below. Both LDAP policies are configured with the same LDAP server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS).
    Name Expression Server
    LDAP-Corp-SelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver LDAP-Corp
    LDAP-Corp-Web REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver LDAP-Corp

Bind Two-factor Policies to Gateway

  1. When you create the NetScaler Gateway Virtual Server, bind the policies as shown in the following table. Priority doesn’t matter because they are mutually exclusive.
    Policy Name Type Bind Point
    LDAP-Corp-Web LDAP Primary
    RSA-SelfService RADIUS Primary
    LDAP-Corp-SelfService LDAP Secondary
    RSA-Web RADIUS Secondary

    bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverForWeb -priority 100
    
    bind vpn vserver gateway.corp.com -policy RSA-ReceiverSelfService -priority 110
    
    bind vpn vserver gateway.corp.com -policy RSA-ReceiverForWeb -priority 100 -secondary
    
    bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverSelfService -priority 110 -secondary
  2. The session policy/profile for Receiver Self-Service needs to be adjusted to indicate which authentication field contains the Active Directory password. On the Client Experience tab or the Session Profile is Credential Index. This needs to be changed to SECONDARY. Leave the session policy for Web Browsers set to Primary.

    set vpn sessionAction "Receiver Self-Service" -ssoCredential SECONDARY
  3. On the StoreFront server, when creating the NetScaler Gateway object, change the Logon type to Domain and security token.

RADIUS Load Balancing

Last Modified: Jul 9, 2016 @ 11:46 am

Navigation

RADIUS Load Balancing Overview

Two-factor authentication to NetScaler Gateway requires the RADIUS protocol to be enabled on the two-factor authentication product.

On your RADIUS servers you’ll need to add the NetScaler appliances as RADIUS Clients. When NetScaler uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the NetScaler NSIP (NetScaler IP). Use the correct IP(s) when adding the NetScaler appliances as RADIUS Clients. And adjust firewall rules accordingly.

For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

When load balancing RADIUS, you’ll want a monitor that verifies that the RADIUS server is functional. The RADIUS monitor will login to the RADIUS server and look for a response. You will need static credentials that the RADIUS monitor can use to login to the RADIUS server.

If you don’t want your monitor to login to RADIUS, then the only other monitoring option is Ping. Adjust the firewall accordingly.

If you have RADIUS Servers in multiple datacenters, you can create multiple load balancing Virtual Servers and cascade them so that the local RADIUS Servers are used first and if they’re not available then the Virtual Server fails over to RADIUS Servers in remote datacenters.

RADIUS Monitor

The RADIUS Monitor attempts to successfully log into the RADIUS server. For RSA, create an account on RSA with the following parameters as mentioned by Jonathan Pitre:

  • Setup a user with a fixed passcode in your RSA console.
  • Ensure you login with that user at least once to the RSA console because you’ll be asked to change it the first time.
  • There is no need to assign a token to your monitor user as long as you are using a fixed passcode. You don’t want to waste a token on a user just for monitoring.

Henny Louwers – Configure RSA RADIUS monitoring on NetScaler:

  1. In the NetScaler Configuration Utility, on the left under Traffic ManagementLoad Balancing, click Monitors.
  2. On the right, click Add.
  3. Name the monitor RSA or similar. Change the Type drop-down to RADIUS.
  4. On the Standard Parameters tab, you might have to increase the Response Time-out to 4.
  5. On the Special Parameters tab, enter valid RADIUS credentials. Make sure these credentials do not change or expire. For RSA, in the Password field, enter the fixed passcode.
  6. Also enter the RADIUS key configured on the RADIUS server for the NetScaler as RADIUS client.
  7. For Response Codes, add both 2 or 3means success while 3 indicates some kind of failure. Either result means that the RADIUS server is responding and thus is probably functional. But 2 is the ideal response.
  8. Click Create when done.
    add lb monitor RSA RADIUS -respCode 2-3 -userName ctxsvc -password Passw0rd -radKey Passw0rd -resptimeout 4

Servers

  1. On the left, expand Traffic Management, expand Load Balancing, and click Servers.
  2. On the right, click Add.
  3. Enter a descriptive server name; usually it matches the actual server name.
  4. Enter the IP address of the server.
  5. Enter comments to describe the server. Click Create.

    add server RSA01 192.168.123.13
    add server RSA02 192.168.123.14
  6. Continue adding RADIUS servers.

Service Groups

  1. On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
  2. On the right click Add.
  3. You will create one Service Group per datacenter. Enter a name reflecting the name of the datacenter.
  4. Change the Protocol to RADIUS.
  5. Click OK.
  6. On the right, in the Advanced column, click Members.
  7. On the left, in the Service Group Members section, click where it says No Service Group Member.
  8. If you did not create server objects then enter the IP address of a RADIUS Server in this datacenter. If you previously created a server object, then change the selection to Server Based, and select the server object.
  9. In the Port field, enter 1812 (RADIUS).
  10. Click Create.

  11. To add more members, in the Service Group Members section, click where it says 1 Service Group Member.
  12. Click Add to add another member. Click Close when done.
  13. On the right, in the Advanced column, click Monitors.
  14. On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
  15. Click the arrow next to Click  to select.
  16. Select your new RADIUS monitor, and click OK.
  17. Click Bind.
  18. To verify the member is up, click in the Service Group Members section.
  19. Highlight a member and click Monitor Details.
  20. It should say Radius response code 2 (or 3) received. Click OK.
  21. Click Done to finish creating the Service Group.

    add serviceGroup svcgrp-RSA RADIUS
    bind serviceGroup svcgrp-RSA RSA01 1812
    bind serviceGroup svcgrp-RSA -monitorName RSA
  22. The Service Group is displayed as UP.
  23. Add additional service groups for Radius servers in each data center.

Virtual Server

  1. On the left, expand Traffic Management, expand Load Balancing, and click Virtual Servers.

  2. On the right, click Add.
  3. Name it lbvip-RADIUS-HQ or similar. You will create one Virtual Server per datacenter so include the datacenter name.
  4. Change the Protocol drop-down to RADIUS.
  5. Enter a Virtual IP. This VIP cannot conflict with any other IP + Port already being used. You can use an existing VIP if the VIP is not already listening on UDP 1812.
  6. Enter 1812 as the Port. Click OK.
  7. In the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
  8. Click the arrow next to Click to select.
  9. Select a previously created Service Group and click OK.
  10. Click Bind.
  11. Click OK.
  12. Configuring RADIUS Load Balancing with Persistence at Citrix Docs recommends Rule Based Load Balancing. On the right, in the Advanced Settings column, add the Method section.
  13. Change the Load Balancing Method to TOKEN.
  14. In the Expression field, enter UDP.RADIUS.USERNAME and click OK.
  15. Click Done to finish creating the Virtual Server.
  16. If you are configuring this RADIUS Load Balancer for more than just NetScaler Gateway, you can add another Load Balancer on port 1813 for RADIUS Accounting. Then you need a Persistency Group to tie the two load balancers together. See Configuring RADIUS Load Balancing with Persistence at Citrix Docs.
    add lb vserver lbvip-RSA RADIUS 10.2.2.210 1812 -persistenceType RULE -lbMethod TOKEN -rule CLIENT.UDP.RADIUS.USERNAME
    bind lb vserver lbvip-RSA svcgrp-RSA
  17. The new Virtual Server should show as Up.
  18. Create additional Virtual Servers for each datacenter. These additional Virtual Servers do not need a VIP so change the IP Address Type to Non Addressable. Only the first Virtual Server will be directly accessible.

    add lb vserver lbvip-RSA-Backup RADIUS 0.0.0.0 0 -persistenceType NONE -cltTimeout 120
  19. Notice that the additional datacenter Virtual Servers show up with an IP Address of 0.0.0.0 and port of 0.
  20. After you are done creating a Virtual Server for each datacenter, right-click the primary datacenter’s Virtual Server, and click Edit.
  21. On the right, in the Advanced column, click Protection.
  22. On the left, in the Protection section, change the Backup Virtual Server to one of the other datacenter Virtual Servers. If all of the services in this datacenter are DOWN, the backup Virtual Server will be used instead. You can cascade multiple Virtual Servers using this method. Click OK and Done.

    set lb vserver lbvip-RSA -backupVServer lbvip-RSA-Backup
  23. You may now use this Virtual IP in your RADIUS authentication policies for NetScaler Gateway or NetScaler management login.

NetScaler Firewall Rules

Last Modified: Sep 14, 2017 @ 6:47 pm

Navigation

See CTX101810 Communication Ports Used by Citrix Technologies

💡 = Recently Updated

NetScaler Firewall Rules

From To Protocol / Port Purpose
Administrator machines NSIPs (and/or SNIPs) TCP 22
TCP 80
TCP 443
TCP 3010
TCP 3008
SSH and HTTP/SSL access to NetScaler configuration GUI. TCP 3008/3010 is Java and 3008 is used if traffic is encrypted. Java not needed in 10.5 build 57 and newer.
Administrator machines NetScaler SDX SVM, XenServer TCP 22
TCP 80
TCP 443
To administer NetScaler SDX
Administrator machines NetScaler Lights Out Module TCP 443
TCP 623
TCP 5900
CTX200367
NSIP
SNIP
DNS servers Ping
UDP 53
TCP 53
Ping is used for monitoring. Can be turned off by load balancing on the same appliance.
NSIPs
SNIP
NTP servers UDP 123 NTP
NSIPs
SNIP (NS 11+)
Syslog server UDP 514 Syslog
NSIPs callhome.citrix.com
cis.citrix.com
taas.citrix.com
TCP 443 Call Home
NSIPs (default)
SNIP
LDAP Servers(Domain Controllers) TCP 389 (Start TLS)
TCP 636 (Secure LDAP)
Secure LDAP requires certificates on the Domain Controllers. Secure LDAP enables password changes when they expire.SNIP if Load Balanced on same appliance
NSIPs LDAP Servers TCP 389
TCP 636
Monitor Domain Controllers
NSIPs (default)
SNIP
RADIUS servers UDP 1812 RADIUS is used for two-factor authentication. SNIP if Load Balanced on same appliance
SNIP RADIUS servers UDP 1812
Ping
Monitor RADIUS servers
NetScaler SDX Service virtual machine NSIPs Ping
TCP 22
TCP 80
TCP 443
Only if NetScaler VPX runs as a virtual machine on top of NetScaler SDX
Local GSLB Site IP
SNIP
GSLB Site IP (public IP) in other datacenter TCP 3009
TCP 3011
GSLB Metric Exchange Protocol between appliance pairs
NSIPs GSLB Site IP (public IP) in other datacenter TCP 22
TCP 3008
TCP 3010
GSLB Configuration Sync
Local GSLB Site IP
SNIP
All Internet Ping
UDP 53
TCP (high ports)
RTT to DNS Servers for Dynamic Proximity determination
SNIP StoreFront Load Balancing VIP TCP 443 NetScaler Gateway communicates with StoreFront
SNIP StoreFront servers TCP 80
TCP 443
TCP 808
StoreFront Load Balancing
NSIPs StoreFront servers TCP 80
TCP 443
Monitor StoreFront servers
StoreFront servers NetScaler Gateway VIP (DMZ IP) TCP 443 Authentication callback from StoreFront server to NetScaler Gateway.
SNIP Each individual Controller in every datacenter TCP 80
TCP 443
Secure Ticket Authorities.This cannot be load balanced.
TCP 443 only if certificates are installed on the Delivery Controllers.
SNIP All internal virtual desktops and session hosts (subnet rule?) TCP 1494
TCP 2598
UDP 1494
UDP 2598
UDP 16500-16509
UDP 3224-3324
HDX ICA
Enlightened Data Transport
Session Reliability
UDP Audio
Framehawk
All InternetAll internal users NetScaler Gateway VIP (public IP) TCP 80
TCP 443
UDP 443
Connections from browsers and native Receivers
DTLS for UDP Audio
All InternetAll internal DNS servers SNIP (public IP) UDP 53 ADNS(for GSLB)
Web logging server NSIPs TCP 3010 Web logging polls the NetScalers.
NSIPs Citrix Command Center or other SNMP Trap Destination UDP 161
UDP 162
SNMP Traps
NSIPs Citrix Insight Center or other AppFlow Collector UDP 4739 AppFlow
  • Authentication traffic uses NSIPs by default. This can be changed by creating a local Load Balancing Virtual Server on the same appliance and sending authentication traffic through the load balancer.
  • If a NetScaler will load balance, a monitor is required to determine if the service is up or not. Several of the monitors run as Perl scripts, which require connectivity from the NSIPs. But actual load balancing traffic can use SNIP as the source IP.
  • DNS uses ping for monitoring. This can be disabled by creating a local Load Balancing Virtual Server on the same appliance and sending DNS traffic through the load balancer. 
  • In a NetScaler with a dedicated mgmt network and default route is on a different data network, for traffic that is normally sourced by NSIP, if NetScaler can’t find a route on the NSIP network then NetScaler will use SNIP instead. To revert to NSIP as source, add a static route on the NSIP network.

NetScaler MAS Firewall Rules

NetScaler Management and Analytics System (NetScaler MAS) is a combination of Command Center and Insight Center.

From To Protocol / Port Purpose
NetScaler MAS NSIPs Ping
TCP 22
TCP 80
TCP 443
Discovery and configuration of NetScaler devices
NSIPs NetScaler MAS UDP 4739 AppFlow
NSIPs
SNIP
NetScaler MAS TCP 5557 ULFD (unified logging format)
NSIPs NetScaler MAS UDP 161
UDP 162
SNMP Traps
CPX Instances NetScaler MAS TCP 27000
TCP 7279
Citrix Licensing
Administrator Machines NetScaler MAS TCP 22
TCP 80
TCP 443
Web-based GUI
XenDesktop Controllers NetScaler MAS TCP 443 Insight Integration with Director
NetScaler MAS LDAP(S)
LDAP(S) VIP
TCP 389
TCP 636
LDAP authentication
NetScaler MAS Mail Server TCP 25 Email alerts
NetScaler MAS NTP Server UDP 123 NTP
NetScaler MAS Syslog Server UDP 514 Syslog

Command Center Firewall Rules

From To Protocol / Port Purpose
NSIPs Citrix Command Center / NMAS UDP 161
UDP 162
SNMP Traps
Citrix Command Center SQL Server TCP 1433
UDP 1434
Other static port
SQL database
Citrix Command Center / NMAS NSIPs TCP 22
UDP 161
UDP 162
SSH to configure the appliance.SNMP to poll the appliance.
SNMP ping.
Citrix Command Center / NMAS Mail server TCP 25 SMTP
Citrix Command Center / NMAS Domain Controllers TCP 389
TCP 636
LDAP
LDAPS
Administrator Machines Citrix Command Center TCP 8443
TCP 3389
Web-based GUI
RDP

Insight Center Firewall Rules

From To Protocol / Port Purpose
Insight Center NSIPs Ping
TCP 22
TCP 80
TCP 443
Configures NetScaler to send AppFlow to Insight Center
NSIPs Insight Center UDP 4739 AppFlow
NSIPs
SNIP
Insight Center TCP 5557 ULFD (unified logging format)
Administrator Machines Insight Center TCP 80
TCP 443
Web-based GUI
XenDesktop Controllers Insight Center TCP 443 Insight Integration with Director
Insight Center LDAP(S)
LDAP(S) VIP
TCP 389
TCP 636
LDAP authentication to Insight Center
Insight Center Mail Server TCP 25 Email alerts
Insight Center NTP Server UDP 123 NTP
Insight Center Syslog Server UDP 514 Syslog

XenApp/XenDesktop Firewall Rules

From To Protocol / Port Purpose
Administrator machines Controllers TCP 80/443
TCP 3389
PowerShell
RDP
Controllers SQL Server TCP 1433
UDP 1434
Other static port
SQL database
Controllers vCenter TCP 443 vCenter
Controllers SCVMM TCP 8100 SCVMM
Controllers Citrix Licensing TCP 27000
TCP 7279
TCP 8082-8083
TCP 80
Citrix Licensing
StoreFront servers Citrix Delivery Controllers TCP 80
TCP 443
XML
Secure Ticket Authority
StoreFront servers StoreFront servers TCP 808 Subscription Replication
StoreFront servers Trusted Domain Controllers TCP 135
TCP 49151-65535
RPC
Administrator machines StoreFront servers TCP 3389 RDP
Administrator machines Citrix Licensing TCP 8082-8083
TCP 80
TCP 3389
Web-based administration GUI
RDP
Controllers All VDAs TCP 80 Brokering
All VDAs Controllers TCP 80 Registration
All VDAs Global Catalogs
(Domain Controllers)
TCP 3268 Registration
All Receivers
(Internal)
StoreFront SSL Load Balancing VIP TCP 80
TCP 443
Internal access to StoreFront
All Receivers NetScaler Gateway VIP TCP 80
TCP 443
External (or internal) access to NetScaler Gateway
All Receivers
(Internal)
All VDAs TCP 1494
TCP 2598
UDP 16500-16509
UDP 3224-3324
ICA/HDX
Session Reliability
UDP Audio
Framehawk
Administrator machines Director TCP 3389 RDP
Administrator machines
Help Desk machines
Director TCP 80
TCP 443
Web-based GUI
Director Controllers TCP 80
TCP 443
Director
Administrator machines
Help Desk machines
All VDAs TCP 135
TCP 3389
Remote Assistance

Also see Microsoft Technet Which ports are used by a RDS 2012 deployment?

Provisioning Services Firewall Rules

From To Protocol / Port Purpose
Provisioning Servers SQL Server TCP 1433
UDP 1434
Other static port
SQL database for Provisioning Services
Provisioning Servers Provisioning Servers SMB File copy of vDisk files
Provisioning Servers Provisioning Servers UDP 6890-6909 Inter-server communication
Provisioning Servers Citrix Licensing TCP 27000
TCP 7279
TCP 8082-8083
TCP 80
Citrix Licensing
Provisioning Servers Controllers TCP 80
TCP 443
Setup Wizards to create machines
Provisioning Servers vCenter TCP 443 Setup Wizards to create machines
Provisioning Servers Target Devices UDP 6901
UDP 6902
UDP 6905
Provisioning Services Console Target Device power actions (e.g. Restart)
Administrator machines Provisioning Servers TCP 3389
TCP 54321
TCP 54322
TCP 54323
RDP
SOAP
Controllers Provisioning Servers TCP 54321
TCP 54322
TCP 54323
Add machines to Catalog
Target Devices DHCP Servers UDP 67 DHCP
Target Devices KMS Server TCP 1688 KMS Licensing
Target Devices Provisioning Servers UDP 69
UDP 67/4011
UDP 6910-6969
TFTP
PXE
Streaming (expanded port range)
Target Devices Provisioning Servers UDP 6969
UDP 2071
Two-stage boot (BDM)
Target Devices Provisioning Servers TCP 54321
TCP 54322
TCP 54323
Imaging Wizard to SOAP Service

Receiver for Windows 4.11

Last Modified: Apr 4, 2018 @ 12:44 pm

Navigation

This post applies to all Receiver versions 4.0 and newer, including the LTSR versions.

💡 = Recently Updated

Change Log

Receiver Modules

The Receiver installer deploys multiple modules. Here are the important ones:

  • ICA Engine (wfica.exe) – process that uses the ICA protocol to connect to published apps and desktops.
  • Self-Service (selfservice.exe) – local GUI that gets icons from StoreFront. When icon is clicked, ICA Engine performs the connection.
  • Single Sign-on (SSON) for ICA (ssonsvr.exe) – captures user credentials and submits them to VDAs
  • Receiver Auto-Update (CitrixReceiverUpdater.exe) – Receiver 4.8 and newer – Notifies users of Receiver updates

The PNAgent module is no longer included in Receiver 4.0 and newer. The older Receiver Enterprise includes the PNAgent module, but does not include Self-Service. The last version of Receiver Enterprise is 3.4.

Custom ICA files are no longer supported. However, Ryan Butler has created a script that asks StoreFront for an ICA file. Explicit credentials are supported. Find the script at Github.

Receiver Discovery and Beacon Process

If you are using Receiver’s built-in user interface (instead of  a web browser), then Receiver first prompts you to perform discovery, which is also called Add Account.

Enter either a StoreFront FQDN, or a NetScaler Gateway FQDN. Just enter the FQDN. There’s no need to enter https or a path.

Receiver will contact the FQDN and request download of the StoreFront Provisioning File.

  • If you entered a StoreFront FQDN, then Receiver will download the Provisioning File directly from the StoreFront server.
  • If you entered a Gateway FQDN, then Gateway will first prompt the user to authenticate. After authentication, Gateway will connect to its configured Account Services address, and download the Provisioning File from StoreFront. The Account Services address is configured in the NetScaler Gateway Session Profile on the Published Applications tab.

If your StoreFront server is configured with multiple stores, then the user will be prompted to select a store. Unfortunately, there’s no configuration option in NetScaler Gateway to force a particular store.

The Provisioning File downloaded from StoreFront is an XML document containing values for several items configured in the StoreFront console. You can export the Provisioning File from the StoreFront console by right-clicking a Store.

The ReceiverConfig.cr Provisioning File looks something like this:

Here are the values in the Provisioning File:

  • Address – the Base URL configured in StoreFront Console
  • Internal Beacon – as configured in StoreFront Console. This can be the Base URL, or a manually specified URL.
  • External Beacons – as configured in StoreFront Console
  • Gateways – as configured in StoreFront Console. If there are multiple Gateways, when enabling Remote Access on the Store, then only one Gateway is selected as Default
  • SRID – Store ID. An important value to consider for multi-datacenter configurations. The SRID is set when the Store is created. It can also be changed by editing C:\inetpub\wwwroot\Citrix\Roaming\web.config.

Receiver reads the Provisioning File, and configures itself by inserting the file’s contents into the user’s registry. The values are located under HKCU\Software\Citrix\Dazzle\Sites and HKCU\Software\Citrix\Receiver\SR. If you performed discovery through NetScaler Gateway, notice that the internal Base URL is added to the user’s registry.

Once Receiver is configured, it then performs the following steps:

  1. Attempt to connect to the Internal Beacon.
  2. If the Internal Beacon is reachable, connect directly to the StoreFront Base URL (Address).
  3. If the Internal Beacon is not reachable:
    1. Attempt to connect to the External Beacons. If the External Beacons are not reachable, then stop attempting to connect.
    2. Connect to the Gateway address configured in the Provisioning File. If there is more than one Gateway, connect to the Gateway that is marked as the Default.

Here are some interesting notes on this connection process:

  • The FQDN you entered during Discovery has absolutely nothing to do with how Receiver connects to StoreFront or Gateway. The actual connection process is controlled by the contents of the Provisioning File, not the Discovery address.
  • If the Provisioning File has multiple Gateways defined, Receiver uses whichever Gateway is marked as Default. Receiver completely ignores whatever Gateway FQDN you entered during Discovery. To use a non-default Gateway, the user must manually select the other Gateway in Receiver’s Advanced Preferences.

In StoreFront Console, if any configuration changes are performed that affect the Provisioning File, do the Receivers reconfigure themselves automatically? Or do users have to remove Accounts and re-add so the updated Provisioning File is imported?

Here are some additional methods of performing Receiver Discovery:

  • After exporting the Provisioning File from StoreFront Console, distribute it to users, and ask them to double-click it.


  • After logging in to Receiver for Web, at the top right, click the user name, and click Activate. This downloads the receiverconfig.cr file, which is identical to the one you can export from StoreFront Console. The user then must run the downloaded file.

Uninstall Old Clients

Receiver 4.4 and newer includes Receiver Clean-Up, so, in theory, it’s not necessary to uninstall old clients first. For more details, see Citrix CTX135933 Upgrading to Citrix Receiver for Windows. To run it silently, run CitrixReceiver.exe /RCU /Silent 

For a reliable upgrade experience, write a script to remove the old clients, clean up the registry and file system, and then deploy the new Receiver.

Citrix Blog Post Cookbook to Upgrade from Receiver 3.4 for Windows to Receiver 4.2.100 and Citrix Article CTX135933 Upgrading to Citrix Receiver for Windows contains step-by-step procedure to use Group Policy to uninstall Receiver Enterprise 3.4 and install/configure Receiver 4.x.

The Receiver Clean-Up utility is designed to assist with the following scenarios:

  • When errors occur during upgrade from an earlier version of Receiver or Online Plug-in
  • When unexpected behavior or performance is experienced after upgrade from an earlier Receiver or Online Plug-in
  • If Receiver upgrade is not possible due to feature incompatibility and/or a clean uninstall is required
  • The Receiver Clean-Up Utility removes components, files, and registry values of Online Plug-in 11.x, 12.x, and Receiver for Windows 3.x, 4.x (Online Plugin-in 13.x, 14.x). This includes the Offline Plug-in component if installed.

Citrix CTX325140: How to Remove Client Files Remaining on System after Uninstalling Receiver for Windows.

Blog posts from Shaun Ritchie:

Installation and Configuration

This section contains a summary of all common command line switches, registry keys, and policy settings for Receiver.

Links:

CitrixReceiver.exe version 4.11 (Current Release), or version 4.9.2000 (Long Term Service Release), or version 4.4.5000 (LTSR), can be installed by simply double-clicking it.

Administrator vs non-administrator

  • Non-administrator – If a non-administrator installs Receiver, then each non-administrator that logs in to the workstation will have to reinstall Receiver. Non-administrator installations are installed to %USERPROFILE%\AppData\Local\Citrix\ICA Client for each user.
  • Administrator – If CitrixReceiver.exe is installed using an administrator account. then the Receiver only needs to be installed once. Administrator installations are installed to C:\Program Files (x86)\Citrix\ICA Client. Administrator installations cannot be upgraded by non-administrators.
  • Conflicts – If an administrator install of Receiver is performed on a machine that has non-administrator installs of Receiver, then the two Receivers will conflict. Best option is to uninstall non-admin Receiver before installing admin Receiver. Otherwise, the user’s profile probably has to be reset before Receiver is functional again.

Auto-Update

Receiver 4.8 and newer support auto-update. Some notes:

  • If Receiver is installed as administrator, then only administrators can install the auto-update.
  • If Receiver is installed on a VDA, auto-update is automatically disabled. This includes Remote PC.
  • Auto-update can be limited to LTSR updates only.
  • Auto-update is configurable through several mechanisms: group policy, StoreFront, Receiver GUI, installer command line. See Configuring Citrix Receiver Updates at Citrix Docs.
  • See George Spiers Citrix Receiver for Windows Auto-Update.

To troubleshoot Auto-update, see Citrix CTX226779 Troubleshooting Citrix Receiver Updates.

Auto-update is configured using Receiver group policy under the Receiver Updates or Auto-Update node.


Add Account Wizard

From Citrix CTX135438 How to Suppress the Add Account Window in Citrix Receiver for Windows: After installation, Receiver will launch and ask you to add an account. If Receiver 4.4.1000 or newer, notice the new checkbox Do not show this window automatically at logon.

For Receiver 4.4 and newer, FTU (First Time Use aka Add Account Wizard) will be displayed only if a store is not configured. If a store is already configured via command line, GPO, or Citrix Studio, then FTU screen will not be available after installation. Otherwise, FTU can be suppressed by doing one of the following:  (Note: Receiver 4.4.1000 and newer has a fix for preventing the Add Account wizard)

  • Rename CitrixReceiver.exe to CitrixReceiverWeb.exe.
  • Install using a command line switch: CitrixReceiver.exe /ALLOWADDSTORE=N
  • Set the registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\EnableFTU=dword:00000000 (or EnableX1FTU =dword:0)
  • Disable the EnableFTU policy setting in Receiver.admx.
  • Change Registry values post installation to suppress the Add Account window. Under HKLM\Software\Wow6432Node\Citrix\Dazzle, set AllowAddStore value to N.
  • Set the registry value: HKEY_LOCAL_MACHINE\Software\Citrix\Receiver\NeverShowConfigurationWizard (REG_SZ) = true
  • Also see Suppressing Add Account dialog at Citrix Docs.

Discover Hidden Stores

When Receiver is first launched, it must perform Discovery, which is the process of downloading the .xml provisioning file from StoreFront. Discovery is performed by entering a StoreFront FQDN or Gateway FQDN. To discover a hidden store (a store that’s not advertised), add %StoreName to the end of the FQDN. CTX214819 Unable to add account from Receiver dialog If the store is hidden in storefront.

CitrixReceiver.exe Command line switches

Citrix Blog Post Citrix Receiver Command Line Helper Tool contains a GUI tool to build your installer command line.  💡

Installer Command Line Switches are detailed at Configure and install Receiver for Windows using command-line parameters at Citrix Docs. Common Command line switches include the following:

  • /silent
  • /includeSSON – enables pass-through authentication. GPO configuration is also required as detailed below.
    CitrixReceiver.exe /includeSSON
  • /ALLOWADDSTORE=A – by default, only SSL (HTTPS) stores are accepted. To allow non-SSL stores:
    CitrixReceiver.exe /ALLOWADDSTORE=A
  • /STORE0 – To add a store from the installation command line:
    CitrixReceiver.exe STORE0="AppStore;https://Citrix.corp.com/Citrix/MyStore/discovery;on;App Store"
    • Receiver 4.10 and newer can discover the Store through NetScaler Gateway.
      CitrixReceiver.exe STORE0="AppStore;https://gateway.corp.com#MyStore/Citrix/MyStore/Discovery;On;App Store"
  • /SELFSERVICEMODE=False – disables the Self-Service interface and enables shortcut-only mode:
    CitrixReceiver.exe /SELFSERVICEMODE=False
  • /AutoUpdateCheck=auto /AutoUpdateStream=LTSR – enables Citrix Receiver Update notifications and sets it to LTSR Branch only. AutoUpdateCheck can also be set to manual or disabled. AutoUpdateStream can also be set to Current. See Configuring Citrix Receiver Updates at Citrix Docs.
    CitrixReceiver.exe /AutoUpdateCheck=auto /AutoUpdateStream=LTSR
  • /ENABLEPRELAUNCH=True – enables prelaunch:
    CitrixReceiver.exe /ENABLEPRELAUNCH=True
  • /ALLOW_CLIENTHOSTEDAPPSURL=1 – enables Local App Access:
    CitrixReceiver.exe /ALLOW_CLIENTHOSTEDAPPSURL=1

Registry values

HKLM\Software\Wow6432Node\Citrix\Dazzle on the Receiver machine. All are of type REG_SZ (string) unless specified. Note: several of these are configurable using the Reciever.admx group policy template.

  • SelfServiceMode (REG_SZ) = False – Turns off Receiver’s Self-Service interface.
  • PutShortcutsOnDesktop (REG_SZ) = True – If Self-Service interface is disabled, places all shortcuts on desktop.
  • UseDifferentPathsforStartmenuAndDesktop (REG_SZ) = True
    • UseCategoryAsStartMenuPath (REG_SZ) = True or False
    • UseCategoryAsDesktopPath (REG_SZ) = True or False
  • StartMenuDir (REG_SZ) = name of folder on Start Menu where shortcuts are placed.
  • DesktopDir (REG_SZ) = name of folder on Desktop where shortcuts are placed
  • EnablePreLaunch (REG_SZ) = True – If SSON is enabled then PreLaunch is already enabled by default.
  • AllowAddStore (REG_SZ) = A – Only if using http (instead of https) to connect to StoreFront.
  • AllowSavePwd (REG_SZ) = A – Only if using http (instead of https) to connect to StoreFront.
  • UserDomainName (REG_SZ) = pre-filled domain name
  • InitialRefreshMinMs (REG_SZ) = 1 – minimizes the launch delay before contacting store
  • InitialRefreshMaxMs (REG_SZ) = 1 – minimizes the launch delay before contacting store
  • RefreshMs (REG_SZ) = 3600000 (1 hour) – interval for Receiver icon refreshes. 1 hour is the default value.
  • MaxSimultaneousFetches (REG_DWORD) = 6  – improves the time of loading icons in Start Menu
  • MaxSimultaneousSubscribes (REG_DWORD) = 6 – improves the time of loading icons in Start Menu
  • DontWarnOfRemovedResources (REG_SZ) = True – prevents dialog boxes when resources are removed from the server. (or False as mentioned at Citrix Discussions?)
  • SilentlyUninstallRemovedResources (REG_SZ) = True – prevents dialog boxes when resources are removed from the server
  • PreferTemplateDirectory (REG_SZ) = UNC path or local path containing shortcuts copied by the prefer keyword. Give the shortcuts a short name.
  • PnaSSONEnabled (REG_SZ) = True – Enables Single Sign-on for PNAgent (Web Interface).
  • WSCReconnectMode (REG_SZ) = 3 (default) – If this Receiver is running inside a VDA published desktop, set it to 0.
  • AlwaysUseStubs (REG_SZ) = True. Receiver 4.3.100 and newer don’t create .exe stubs by default. Set this to create .exe stubs. Also see Citrix CTX211893 Controlling Shortcut behavior in Receiver 4.3.100.
  • DontCreateAddRemoveEntry (REG_SZ) = True – don’t create “Delivered by Citrix” entries in Programs and Features
  • DesktopNameFormatString = format string for shortcut names – For example “{0}_{1}_{2}_{3}”. See the link for details.
  • SelfServiceFlags (REG_DWORD) = 4 – prevents duplicate shortcuts when roaming and Desktop is redirected.

To prevent the Win+G popup on Windows 10 machines:  💡

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
    • AllowGameDVR (REG_DWORD) = 0

To allow adding non-HTTPS stores to Receiver:

  • HKLM\Software\Wow6432Node\Citrix\AuthManager
    • ConnectionSecurityMode (REG_SZ) = Any

To increase ICA bandwidth consumption over high latency links, set:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\TCP/IP

To prevent beacon probing from using proxy, set:

  • HKEY_LOCAL_MACHINE\Software\WOW6432Node\Citrix\Receiver\inventory
    • BeaconProxyEnabled (REG_DWORD) = 0

To enable foreground progress bar, set:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client
    • ForegroundProgressBar (REG_DWORD) = 1

For client-to-server file type redirection, set:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientDrive
    • NativeDriveMapping=”TRUE”

To fix USB devices that emulate a keyboard, set:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Keyboard
    • KeyboardTimer=”10”

To prevent “USB Hub Power Exceeded” message, set (not needed in 4.2.100 and newer):

  • HKLM\SOFTWARE\Citrix\ICA Client\GenericUSB (same path for 32-bit and 64-bit, create the keys)
    • DisableInternalDeviceCtlDispatchHook (DWORD) = 0x1

To override the devices that are mapped using optimized channels instead of generic USB, see Citrix CTX123015 How to Configure Automatic Redirection of USB Devices

Group Policy Settings

Copy the Receiver ADMX template (C:\Program Files\Citrix\ICA Client\Configuration\receiver.admx) to C:\Windows\PolicyDefinitions (or Sysvol). Also copy receiver.adml to C:\Windows\PolicyDefinitions\en-us (or Sysvol). Edit a GPO that applies to client machines, go to Computer Configuration | Policies | Administrative Templates | Citrix Components | Citrix Receiver.

  • To enable pass-through authentication: go to | User Authentication |.
  • To add a store, go to | StoreFront |
    • StoreFront Accounts List – see the help text
  • To enable Auto-Update, go to |AutoUpdate| or |Receiver Updates|. (the node was renamed in 4.11)
    • Enable or Disable AutoUpdate or
    • Receiver Updates
  • To enable Local App Access, go to | User Experience |
    • Local App Access Settings
  • To configure the Self-Service interface, go to | SelfService |
    • Set Manage SelfServiceMode to Disabled to completely disable the Self-Service window. This causes all icons to be placed on the Start Menu.
    • Enable Manage App Shortcut and configure it as desired.
      • To allow the Self-Service window, but prevent it from automatically opening (reside in systray), tick Prevent Citrix Receiver performing a refresh of the application list when opened. Source  💡
    • Enable Control when Receiver attempts to reconnect to existing sessions. If this is a VDA published desktop, set it to Disabled. Otherwise configure it as desired.
    • Set Enable FTU to Disabled  to prevent the Add Account wizard from displaying.
    • Enable Allow/Prevent users to publish unsafe content if publishing content that’s opens a file or file share.

Enable automatic client drive and client microphone mapping.

  • In a client-side GPO, add the GPO ADM template from http://support.citrix.com/article/CTX133565.
  • Enable the setting Create Client Selective Trust Keys. See Below for details.
  • Configure the FileSecurityPermission setting in one or more of the regions.
  • Configure the MicrophoneAndWebcamSecurityPermission setting in one or more of the regions.

Citrix CTX203658 Start Menu Icons Set to Default (Blank Document) After Update to Receiver 4.3.100 – Windows 8 and newer

  • Computer Configuration | Policies | Administrative Templates | Windows Components | File Explorer
    • Allow the use of remote paths in file shortcut icons = enabled

Deploy Receiver using Active Directory

To deploy Receiver using Active Directory, configure a GPO with a computer startup script that runs the Receiver installer executable. Citrix has provided sample scripts that can be downloaded from one of the Receiver download pages (version 4.11 (Current Release), version 4.9.2000 (LTSR), or version 4.4.5000 (LTSR)) by expanding Downloads for Admins (Deployment Tools). An enhanced version of the installation script can be found in Citrix Discussions.

Change Receiver Store Configuration, including Reset Receiver

You can change Receiver’s configured Store/Account with a couple command lines: (from 4.4 LTSR store configuration per user at Citrix Discussions)

"C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe" -deleteproviderbyname Corporate 
"C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe" -init -createprovider Corporate https://storefront.corp.com/Citrix/Store/discovery

 

It is sometimes necessary to reset Receiver settings by right-clicking the Receiver icon, clicking Advanced Preferences, and clicking Reset Receiver. You can do this from the command line by running “C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\CleanUp.exe" -cleanUser -silent. See CTX140149 How to Reset Receiver Using the Command Line.

Receiver for Edge

The Receiver for Web experience in Microsoft Edge is not ideal. Every time a user clicks an icon, the user has the click the Open button after the .ica file is downloaded.

Citrix Blog Post Providing Full Receiver for Web Experience for Microsoft Edge has instructions for enabling the Receiver Launcher for Edge. Use your preferred text editor to open web.config for the RfWeb site you would like to configure (typically C:\inetpub\wwwroot\Citrix\StoreWeb\web.config). Locate the line like this: <protocolHandler enabled="true" platforms="(Macintosh|Windows NT).*((Firefox/((5[3-9]|[6789][0-9])|\d\d\d))|(Chrome/((4[2-9]|[56789][0-9])|\d\d\d)))(?!.*Edge)". Remove (?!.*Edge) and save the file.

But once you do that, you get a new switch apps prompt every time you launch an icon from Edge.

To stop the switch apps pop-up, on the client side, edit the registry, go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute\receiver (create missing registry keys), create DWORD value WarnOnOpen, and set it to 0 (zero). You can use Group Policy Preferences to deploy this registry value.

Receiver Group Policy ADMX Template

Many of the Receiver configuration settings must be configured in group policy. These Receiver settings are only available after installing the GPO templates.

  1. From a machine that has Receiver installed, find the .admx and .adml files in the C:\Program Files (x86)\Citrix\ICA Client\Configuration.
    • You can also download the ADMX files from one of the Receiver download pages (version 4.11 (Current Release), version 4.9.2000 (LTSR), or version 4.4.5000 (LTSR)) by expanding Downloads for Admins (Deployment Tools).
  2. Copy the CitrixBase.admx and receiver.admx files. Also copy the en-US folder.
  3. Go to your domain’s SYSVOL share and in the Policies folder look for a PolicyDefinitions folder. If one exists, paste the .admx file directly into the PolicyDefinitions folder. If this folder doesn’t exist in SYSVOL, instead copy the .admx file to C:\Windows\PolicyDefinitions. Overwrite any existing Receiver ADMX files.
  4. The GPO settings can then be found at Computer Configuration > Policies > Administrative Templates > Citrix Components > Citrix Receiver.
  5. For example, you can disable Customer Experience Improvement Program (CEIP) from here.
  6. See http://www.carlstalhood.com/delivery-controller-7-15-ltsr-and-licensing/#ceip for additional places where CEIP is enabled.
  7. Receiver Updates (aka AutoUpdate) can be configured using group policy. See Configuring Citrix Receiver Updates at Citrix Docs.

  8. Receiver 4.10 and newer have settings to hide Advanced Preferences, enable/disable DPI, and enable/disable H265.
  9. Receiver 4.8 and newer have SplitDevices GPO setting under Citrix Receiver | Remoting client devices | Generic USB Remoting. See Configuring composite USB device redirection at Citrix Docs.

Pass-through Authentication

Citrix blog post – A Comprehensive Guide to Enabling Pass-Through Authentication with XenDesktop 7.5

From Citrix Knowledgebase article How to Configure Desktop Pass-Through with Storefront and Receiver 3.x: To enable Single Sign-on with StoreFront, you must install CitrixReceiver.exe using the /includeSSON switch. This will only be successful for administrators.

  1. Run the command
    Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $True from a Windows PowerShell command prompt on a Delivery Controller.

  2. Login to the PC as an administrator.
  3. If installing Receiver for Windows 4.4 or newer, as an administrator, on the Enable Single Sign-on page, check the box next to Enable Single Sign-on. Then finish the installation.
  4. If installing an older version of Receiver:
    1. Go to the downloaded Citrix Receiver. Shift-right-click CitrixReceiver.exe, and click Copy as path.
    2. Open a command prompt.
    3. Right-click to paste the path in the command prompt and then add /includeSSON to the end of the command. Press <Enter>.
    4. Click Install when prompted.
  5. To verify that SSON is installed, go to C:\Program Files (x86)\Citrix\ICA Client and look for the file ssonsvr.exe.
  6. And if you open regedit and go to HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order, you should see PnSson in the ProviderOrder.
  7. Install the receiver.admx (and .adml) template into PolicyDefinitions if you haven’t already.
  8. Edit a GPO that is applied to the client PCs where the Citrix Receiver is installed.
  9. Go to Computer Configuration > Policies > Administrative Templates > Citrix Components > Citrix Receiver.
  10. Expand Citrix Receiver and click User authentication.
  11. On the right, double-click Local user name and password.
  12. Select Enabled and then check the box next to Allow pass-through authentication for all ICA connections. Click OK.
  13. Ensure that the internal StoreFront FQDN is in the Local Intranet zone in Internet Explorer. You can use a GPO to configure this on the client side.
  14. Local Intranet zone should have Automatic logon only in Intranet zone enabled.
  15. Logoff Windows and log back on. In Task Manager you should now see ssonsvr.exe. This won’t appear unless you logoff and log back on.
  16. If Receiver won’t connect or is slow to enumerate icons, then you might have to disable Automatically detect settings in IE.
  17. In Receiver 4.5 and newer, right-click the Receiver icon and click Advanced Preferences.
  18. Click Configuration Checker.
  19. Check the box next to SSONChecker and click Run.
  20. The lines with red x will indicate the issue and corrective action.

StoreFront Accounts

You can use a client-side GPO to add a store (Account) to Receiver Self-Service.

  1. Install the receiver.admx (and .adml) template into PolicyDefinitions if you haven’t already.
  2. Edit a GPO that applies to endpoint devices that have Citrix Receiver Self-Service installed.
  3. Go to Computer Configuration > Administrative Templates > Policies > Citrix Components > Citrix Receiver > StoreFront.
  4. On the right, double-click NetScaler Gateway URL/StoreFront Accounts List.
  5. Select Enabled, and then click Show.
  6. Enter a store path based on the example shown in the Help box. Receiver 4.5 lets you enter a Gateway path. Then click OK.
  7. Note: Gateway paths work in GPO, but don’t seem to work when specified in the CitrixReceiver.exe installation command line.

Published Shortcuts and Reconnect

Citrix CTX200924 How to Customize App Shortcuts with Receiver for Windows

Receiver 4.5 and newer has a user interface for setting Shortcut Paths. Right-click the Receiver icon, click Advanced Preferences, and then click Settings Option.


From Citrix Docs Configuring application delivery: There are several methods of controlling how Receiver displays shortcuts on the Start Menu and Desktop as detailed below:

Under HKLM\Software\Wow6432Node\Citrix\Dazzle (or HKCU\Software\Wow6432Node\Citrix\Dazzle) are several registry values related to shortcuts. Some of the settings only apply if SelfServiceMode is set to False. Here are some common options:

  • SelfServiceMode – set to False so Receiver disables the Self-Service interface and automatically places all published shortcuts on the Start Menu and/or Desktop. More details in Configuring application delivery at Citrix Docs.
  • PutShortcutsOnDesktop – set to True to place every app on the desktop
  • DesktopDir – Receiver places every shortcut on the desktop so it’s probably best to place them in a folder.
  • StartMenuDir – If there is potentially a conflict between local apps and remote apps, then you should place the Start Menu shortcuts in a folder.
  • PreferTemplateDirectory (with KEYWORDS:prefer=shortcutname) – copies the shortcutname from the template directory to the Start Menu and/or Desktop.

If you import the receiver.admx (and .adml) into the PolicyDefinitions folder, under Computer Configuration > Administrative Templates > Citrix Components > Citrix Receiver is a new node called SelfService.

Disable the Manage SelfServiceMode setting to hide the Receiver Window.

Enable the Manage App shortcut setting to control placement of shortcuts.

Receiver 4.2.100 and newer has the ability to configure (or disable) Workspace Control using group policy. Enable the setting Control when Receiver attempts to reconnect to existing sessions and configure it as desired.

Prelaunch

Staring with Receiver 4.2, prelaunch is automatically enabled if Receiver is installed with SSON enabled. Otherwise, set registry values to enable prelaunch. Receiver 4.2.100 prevents the prelaunch icon from appearing on the Start Menu.

  • HKLM\Software\[Wow6432Node\]Citrix\Dazzle
    • EnablePreLaunch (REG_SZ) = true or false

Additional customizations can be configured at:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Prelaunch

  • Name: State
    • REG_SZ: 0 = disable, 1 = just-in-time pre-launch, 2 = scheduled pre-launch
  • Name: Schedule
    • REG_SZ: HH:MM|M:T:W:TH:F:S:SU where HH and MM are hours and minutes. M:T:W:TH:F:S:SU are the days of the week. For example, to enable scheduled pre-launch on Monday, Wednesday, and Friday at 1:45 p.m., set Schedule as Schedule=13:45|1:0:1:0:1:0:0 . The session actually launches between 1:15 p.m. and 1:45 p.m.
  • Name: UserOverride
    • REG_SZ: 0  = HKLM overrides HKCU, 1 = HKCU overrides HKLM

Device Access Behavior (Client Selective Trust)

When connecting to a XenApp/XenDesktop session, you might see the following:

To configure the default behavior, see the Citrix Knowledgebase article How to Configure Default Device Access Behavior of Receiver, XenDesktop and XenApp. Note: there is a bug fixed in Receiver 4.2.100 and newer.

  1. Download the ADMX file from http://support.citrix.com/article/CTX133565.
  2. Copy the .admx and .adml files to PolicyDefinitions (Sysvol, or C:\Windows).
  3. The .adml file goes in the en-US folder.
  4. Edit a GPO that applies to the endpoint devices that are running Receiver.
  5. Go to Computer Configuration | Policies | Administrative Templates | Citrix Components | Citrix Receiver |  Citrix Client Selective Trust (x64).
  6. Enable the setting Create Client Selective Trust Keys.

  7. Then expand the regions, and configure the permission settings as desired.

Desktop Lock

As an alternative to Receiver Desktop Lock, see Transformer in Citrix Workspace Environment Manager.

External links:

Use Studio to configure Receiver Accounts in Published Desktop

In published desktops, the Receiver can be used for placement of shortcuts on the user’s Start Menu and Desktop. Use group policy to hide the common program groups and then use Receiver to place published applications back on the Start Menu and Desktop based on user’s group membership and subscription preference.

  1. In Citrix Studio, on the left, expand the Configuration node, right-click StoreFront and click Add StoreFront.
  2. Enter a descriptive name for the StoreFront server.
  3. Enter the internal https URL of the load balanced StoreFront servers. Add the path to your store (e.g. /Citrix/Store) and then /discovery on the end of the URL. The full URL would be similar to https://citrix.corp.com/Citrix/Store/discovery. Click OK.
  4. Edit a Delivery Group that has a published desktop and Citrix Receiver installed.
  5. On the StoreFront page, change the selection to Automatically, using the StoreFront servers selected below, and then check the box next to the StoreFront URL. Click OK. Now when users launch the published desktop, Receiver will be automatically configured with this URL.

Published Desktop – use Receiver to control Shortcuts

If you install Receiver inside a published desktop (Receiver on a VDA), then Receiver can get icons from StoreFront and put those icons on the user’s published desktop Start Menu and Desktop. This is an alternative to using a User Experience Management product to control shortcut placement.

Configuration of Receiver inside a published desktop is simplified if you have the following minimum versions:

  • Receiver 4.11 installed inside the VDA
  • VDA 7.17
  • StoreFront 3.14

If you meet these minimum version requirements, then Receiver installed in the VDA automatically tries to launch published applications on the same local VDA rather than trying to launch them from a different VDA (aka double-hop). This feature is called vPrefer.

Do the following for all versions of Receiver, VDA, and StoreFront, whether using the Prefer keyword or not:

  1. Make sure Receiver version 4.11 or newer is installed on the VDA. Or install version 4.9.2000 (LTSR), or version 4.4.5000 (LTSR)
  2. Install the Receiver ADMX files if you haven’t already. For vPrefer, make sure they are the ADMX files from Receiver 4.11 or newer.
  3. Enable the Group Policy setting Remove common program groups from Start Menu and apply it to non-administrators.
    • This removes all Public (aka All Users) Start Menu shortcuts. Receiver will re-add the shortcuts based on user group membership.
  4. On the VDA, configure the following Receiver Registry keys (or corresponding settings in the receiver.admx GPO template):
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\WSCReconnectMode=”0″ so Receiver doesn’t try to reconnect to the published desktop you’re already running.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\SelfServiceMode to False. This turns off the Receiver Self-Service GUI and acts like all icons are subscribed. Otherwise, only subscribed (favorited) icons would be placed on the Start Menu and Desktop.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\UseCategoryAsStartMenuPath = True. This creates a Start Menu folder based on the published app’s configured Category.
  5. Configure each desired published app to Add shortcut to user’s desktop.

    • Or, configure HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\PutShortcutsOnDesktop = True to place all icons on the desktop.
  6. To control icon placement, configure the following registry values:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\StartMenuDir to place published applications in a sub-folder. Note: Windows 2012 and newer only supports a single level of Start Menu folders, so setting this effectively turns off published app categories.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\DesktopDir to place published applications in a sub-folder on the desktop.
  7. Pass-through authentication:
    1. In a GPO that applies to the VDA, import the receiver.admx file, and set Local user name and password to Enabled. Check the box next to Allow pass-through authentication for all ICA connections.
    2. In a user-level GPO that applies to the VDA, add the StoreFront FQDN to the Local Intranet zone. Make sure it is not in the Trusted Sites zone, or enable Automatic logon with current user name and password for the Trusted Sites zone.
    3. Make sure ssonsvr.exe is running after you login to the VDA. If not, troubleshoot it.
  8. When configuring Citrix Profile Management, make sure !ctx_startmenu! is not excluded from roaming.
  9. In Citrix Studio, configure a Delivery Group with delivery type = Desktop and Applications. Assign users to the delivery group, and the individual published applications (if visibility is limited).
    1. In Citrix Studio, edit each published application, and on the Delivery tab, specify a category. This will become the Start Menu folder name.
    2. If Receiver Self Service Mode (GUI) is enabled, in Studio, edit each application, and add KEYWORDS:Auto and/or KEYWORDS:Mandatory to the published application description. This forces the applications to be subscribed/favorited. Only subscribed (or Favorite) apps are displayed in the Start Menu and Desktop. Unless you disable Receiver’s SelfService interface as described earlier.
    3. Another option is to go to the StoreFront Console, click Stores on the left, and on the right, click Configure Store Settings, and click Disable User Subscriptions. This causes all apps to appear on the Start Menu and/or Desktop depending on Receiver configuration.
  10. Create a group policy that applies to VDAs, and configure the group policy to define the Store URL for Receiver similar to https://citrix.corp.com/Citrix/Store/discovery. Replace the FQDN with your load balanced StoreFront FQDN. Also replace the path to the store with your store path. Make sure there is /discovery on the end. By default, Receiver only supports https.
    1. Your StoreFront store probably delivers both application and desktop icons. If you want to filter out the desktop icons, then create a new StoreFront store, and configure the Receiver on the VDA to connect to the new Store.
    2. In StoreFront Console, click the store for VDAs, and click Configure Store Settings. On the Advanced Settings page, in the Filter resources by type row, choose Citrix.MPS.Desktop.
  11. For vPrefer in Receiver 4.11, VDA 7.17, and StoreFront 3.14, edit a GPO that applies to the VDAs.
    1. Go to Computer Configuration | Policies | Administrative Templates | Citrix Components | Citrix Receiver | SelfService.
    2. Edit the setting vPrefer. This setting is only in Receiver ADMX templates from Receiver 4.11 and newer.
    3. Set it to Allow all apps. Source = 7.17 vPrefer – not working with 32Bit Apps at Citrix Discussions.
  12. On your Delivery Controller, in PowerShell, run set-brokersite -TrustRequestsSentToTheXmlServicePort $true
    • This is required for Pass-through Authentication from Receiver.
  13. Configure your client devices to connect to the published desktop.
    1. When users connect to the published desktop, Receiver will auto-launch and hopefully auto-login.
    2. If Receiver Self-Service Mode is disabled, all published applications should automatically appear in the Start Menu and Desktop.
    3. If Receiver Self-Service Mode is enabled, then only applications with KEYWORDS:Auto and/or KEYWORDS:Mandatory in the published application description will be displayed. Users can open the systray icon to subscribe to more applications.
    4. Users can copy icons from the Start Menu to the desktop. Make sure the user Copies the icon and doesn’t Move it.
    5. Users can then launch applications directly from the Start Menu, from the Desktop, or from the Receiver (if the Self-Service interface is enabled).
    6. If Receiver 4.11, VDA 7.17, and StoreFront 3.14, then vPrefer is enabled by default. When launching an app icon that came from Receiver, Receiver checks the local VDA machine to see if the application can be launched on the local VDA instead of by creating a new Citrix double-hop session.
    7. If the application is installed locally on the VDA then the local application shortcut should launch quickly. If the application is on a different delivery group then a second (double-hop) Citrix HDX/ICA connection will be established.
    8. If the user deletes Receiver shortcuts from the Start Menu, you can get them back by going to the systray icon and refreshing the applications. Or sometimes you have to reset Receiver.

If you are running components older than Receiver 4.11, VDA 7.17, and StoreFront 3.14, then you’ll need to configure the prefer keyword to get Receiver delivered icons to launch on the local VDA instead of in a new double-hop Citrix connection.

  1. Enable the Group Policy setting Remove common program groups from Start Menu and apply it to non-administrators.
    1. For applications that are installed on the same VDA that is publishing the desktop, configure Group Policy Preferences to recreate the application shortcuts based on Active Directory group membership. Applications on other delivery groups are handled by Receiver.
    2. Or use the prefer keyword to copy shortcuts from the PreferTemplateDirectory.
  2. On the VDA, configure the following Receiver Registry keys (or corresponding settings in the receiver.admx GPO template):
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\PreferTemplateDirectory = a UNC path or local path containing shortcuts to be copied by the prefer keyword. This can point to C:\ProgramData\Microsoft\Windows\Start Menu.
  3. In Citrix Studio, configure a Delivery Group with delivery type = Desktop and Applications. Assign users to the Delivery Group and the applications (if visibility is limited).
    1. In Studio, edit each application and change KEYWORDS:Prefer to KEYWORDS:prefer. Notice the lower case p. It doesn’t work with uppercase P.
      • With the prefer keyword, if you publish an application that is also created using Group Policy Preferences, the Group Policy Preferences icon will take precedence. This is good. Otherwise the Receiver published application icon would result in a new Citrix double-hop session.
      • See Ralph Jansen Citrix Receiver 4.1 Prefer keyword examples
    2. If using the prefer keyword with the PreferTemplateDirectory, enter it as KEYWORDS:prefer=shortcutname where shortcutname is the name of the shortcut that is copied from the Template directory.
  4. Configure your client devices to connect to the published desktop.
    1. When users connect to the published desktop, Group Policy Preferences will create shortcuts to local applications.
    2. Receiver will auto-launch and hopefully auto-login.
    3. If Receiver Self-Service Mode is disabled, all published applications should automatically appear in the Start Menu and Desktop.
    4. If Receiver Self-Service Mode is enabled then only applications with KEYWORDS:Auto and/or KEYWORDS:Mandatory in the published application description will be displayed. Users can open the systray icon to subscribe to more applications.
    5. For published applications with KEYWORDS:prefer=shortcutname, Receiver should copy icons from the template directory to the Start Menu and/or Desktop. See below for considerations.
    6. Users can copy icons from the Start Menu to the desktop. Make sure the user Copies the icon and doesn’t Move it.
    7. Users can then launch applications directly from the Start Menu, from the Desktop, or from the Receiver (if Self-Service interface is enabled).
    8. If a local shortcut (e.g. Group Policy Preferences shortcut, or copied from template directory) matches a published application with KEYWORDS:prefer then the local shortcut will override the published application icon.
    9. If the application is installed locally on the VDA then the local application shortcut should launch quickly. If the application is on a different delivery group then a second (double-hop) Citrix HDX/ICA connection will be established.
    10. If the user deletes Receiver shortcuts from the Start Menu, you can get them back by going to the systray icon and refreshing the applications. Or sometimes you have to reset Receiver.

Notes regarding Prefer Template Directory

  • Prefer Template Directory can point to C:\ProgramData\Microsoft\Windows\Start Menu, which is the All Users Start Menu.
  • The shortcuts copied from the Prefer Template Directory are renamed to match the published app name.
  • For prefer local apps, any command line parameters specified in the published app are ignored. If you need these command line parameters, add them to the shortcut in the Prefer Template Directory.
  • If you have multiple published apps pointing to the same prefer local shortcut, then only one copy will be made, and it will have the name of only one of the published apps. To workaround this, in the Prefer Template Directory, create separate shortcuts for each published app, and adjust the published app prefer keyword accordingly.
  • Jan Hendrik Meier Automatic Shortcut generation for local installed applications in a Citrix XenDesktop / XenApp 7.x environment has a script that can create shortcuts based on the published apps with prefer keyword. These shortcuts can then be copied to your Prefer Template Directory.

How to Script Receiver Self-Service

From Citrix Knowledgebase article Driving the Citrix Receiver Self-Service Plug-in Programmatically: by default, Receiver Self-Service (SSP) activities are driven by user interaction. However, SSP exposes sufficient information for its activities to be scripted.

When SSP builds a shortcut, it builds it to a small stub application in a file %appdata%\Citrix\SelfService\app-name-with-spaces-removed.exe for each resource. These files allow SSP to create a fake ‘install’ record for Add/Remove Software. Running these .exe files causes the application to launch. Note: Receiver 4.3.100 and newer don’t create stubs by default. To enable, set HKLM\Software\Wow6432Node\Citrix\Dazzle\AlwaysUseStubs (REG_SZ) = true.

If you want to drive SSP directly for launch instead of through an .exe stub, look at the keys under HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall. There will be keys in there named farm-name@@server-farm-name.app-friendly-name. In these keys you’ll find a LaunchString value that shows the relevant parameters. These parameters are user-independent and can therefore be cloned from a reference user to a general case. You can copy and reuse these parameters without interpretation.

Running the command selfservice.exe –init –ipoll –exit starts SSP, performs a refresh (interactive poll) from the current provider, and forces a clean exit.

Additional command line parameters are detailed at Driving the Citrix Receiver Self-Service Plug-in Programmatically.

 

Citrix Receiver comes with a .dll file that implements the Citrix Common Connection Manager SDK. You can use the CCM SDK to do the following:

  • Launch Sessions
  • Disconnect Sessions
  • Logoff Sessions
  • Get Session Information

Citrix was kind enough to develop a PowerShell module that calls functions from the .dll. Get the CCMPowershellModule from Github. The PowerShell module contains functions like the following:

  • CCMTerminateApplication
  • CCMLaunchApplication
  • CCMGetActiveSessionCount
  • CCMDisconnectAllSessions

Launcher Scripts

Ryan C Butler Storefront ICA file creator at Github. See Create an ICA File from Storefront using PowerShell or JavaScript for more info.

Stan Czerno – Powershell Script to launch one or more Published Applications from Citrix Storefront 2.x through 3.6: the script launches a browser, connects to StoreFront (or NetScaler Gateway), logs in, and launches an icon. This is a very well-written script that uses a .dll file from Citrix Receiver to display session information.

Citrix Solutions Lab StoreFront Launcher Script at Github. It attempts to closely resemble what an actual user would do by:

  1. Opening Internet Explorer.
  2. Navigating directly to the Receiver for Web site or NetScaler Gateway portal.
  3. Completing the fields.
  4. Logging in.
  5. Clicking on the resource.
  6. Logging off the StoreFront site.

David Ott StoreFront App/Desktop Launch Testing Script uses Internet Explorer to login to StoreFront and launch a resource. Sends email with the result. Uses wficalib.dll to get session information.

Skype for Business

Citrix has a HDX plug-in (HDX RealTime Optimization Pack) for Receiver that enables offloading of Skype for Business media protocols to the client device. The latest version is 2.4.

The HDX RealTime Optimization Pack comes in two pieces: the Connector (on the VDA), and the Media Engine (on the Receiver machine). Usually both pieces must be the same version, but versions 2.3 and higher now allow version mixing.

Receiver and HDX RealTime Media Engine are also available as a bundle at Citrix Receiver 4.9 and HDX RealTime Media Engine 2.3 for Windows

24-page Citrix PDF Delivering Microsoft Skype for Business to XenApp and XenDesktop Users.

For Skype for Business Location Based Routing, you’ll need the following: (Source = Citrix Derek Thorslund at Location based routing at Citrix Discussions)

  • Microsoft added support for Location Based Routing (LBR) with the virtualized Skype for Business 2016 client (and HDX RTOP 2.1 and above) in the Click-to-Run (C2R) download quite a long time ago, but it hasn’t yet been introduced in the MSI package.
  • It requires setting IsLBRInVDIEnabled on the Skype for Business Server to True:
    $x = New-CsClientPolicyEntry -Name "IsLBRInVDIEnabled" -Value "true"
    Set-CsClientPolicy -Identity "<ClientPolicyName>” -PolicyEntry @{Add=$x}

When offloading voice and video to Receiver machines, don’t forget to configure QoS on the client machines. See Citrix Blog Post Implementing the Citrix HDX RealTime Optimization Pack: Don’t Forget About QoS/DSCP.

Citrix CTX222459 RealTime Optimization Pack Capability Checker: It will list out endpoint hardware/software information which will be used to process audio and video. The tool is independent of RealTime Optimization Pack version and runs any Windows machine.

Citrix CTX214237 LOPper – Lync Optimization Pack Log Parser: parses log files generated by Citrix HDX RealTime Optimization Pack (HROP) when an audio/video call is made using Lync 2013/Skype for Business (SfB) and shows relevant information in a UI.

Troubleshooting – Citrix QuickLaunch

Citrix CTX219718 QuickLaunch Tool (Testing Application and Desktop Launch) lets you launch Citrix sessions directly from a Controller without needing StoreFront.

You enter a Controller address, credentials, and then it shows you the published resources. You can pick a resource, edit properties on the other tabs, and then Connect. This allows you to easily try different connection properties.

If you run into problems launching a session, use Sysinternals DebugView while running CQL in Debug mode (/debug switch).

Troubleshooting – Receiver Logging

There are a couple methods of logging Receiver for Windows operations. One method is CTX141751 Citrix Receiver Diagnostics Tool – For Windows, which creates a CDF trace that can be parsed by CDFControl.

Another method is CTX132883 How to Enable Logging on Receiver for Windows Using Registry Entries. The logfiles in %USERPROFILE%\Appdata\Local\Citrix\ are human readable. And CTX206102 Enable SSON Logging Using Registry Key.

Instead of creating the registry keys manually,  you can use the following .reg file provided by Wolfgang Thürr:

Windows Registry Editor Version 5.00

;only for x64 windows os
;import with admin rights
;restart your computer to activate the logging and tracing settings
;create C:\TEMP for the launch ICA log and SSON logn (no environment variables can be used)

;general Receiver logging
;************************
;logpath: %USERPROFILE%\Appdata\Local\Citrix\Receiver
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix]
"ReceiverVerboseTracingEnabled"=dword:00000001

;Authentication Manager logging
;******************************
;logpath: %USERPROFILE%\Appdata\Local\Citrix\AuthManager
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\AuthManager]
"LoggingMode"="verbose"
"TracingEnabled"="True"
"SDKTracingEnabled"="True"

;Self Service logging
;********************
;logpath: %USERPROFILE%\Appdata\Local\Citrix\SelfService
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle]
"Tracing"="True"
"AuxTracing"="True"
"DefaultTracingConfiguration"="global all –detail"

;save launch ICA
;***************
;logpath: C:\TEMP\ica.log (no environemnt variables allowed)
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging]
"LogConfigurationAccess"="true"
"LogConnectionAuthorisation"="true"
"LogEvidence"="true"
"LogICAFile"="true"
"LogFile"="C:\\TEMP\\ica.log"
"LogStartup"="true"

;Receiver Always On Tracing
;**************************
;generates ETL Files for analyzing with CDFControl see CTX111961 for details
;can be configured or overruled by GPOs (icaclient.admx)
;path %USERPROFILE%\AppData\Local\Temp\CTXReceiverLogs
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\ICA Client\AoLog]
"EnableTracing"=dword:00000001

;Single Sign-on Logging
;**************************
;https://support.citrix.com/article/CTX206102
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Install\SSON]
"DebugEnabled"="true"
"LogPath"="C:\\Temp"

Troubleshooting – Duplicate Stores

Stores are sometimes duplicated in Receiver, especially if you are running Receiver inside a VDA. (h/t Dan High)

StoreFront URLs can be defined in several places:

  1. In Studio, go to Configuration > StoreFront and delete all URLs configured here.
  2. Look in GPOs for Computer Configuration > Administrative Templates > Policies > Citrix Components > Citrix Receiver > StoreFront > NetScaler Gateway URL/StoreFront Accounts List. Remove any URLs configured here.
  3. In the client-side registry, at HKLM\Software\Wow6432Node\Citrix\Dazzle\Sites, you might see store addresses that were specified during a command line installation of Receiver.
  4. When Citrix Receiver switches between StoreFront servers in multiple datacenters, it’s possible for each datacenter to be treated as a separate Receiver site. This can be prevented by doing the following. From Juan Zevallos at Citrix Discussions:
    1. Match the BaseURL in all datacenters.
    2. Match the SRID in all datacenters – The SRID can be safely edited in the C:\inetpub\wwwroot\Citrix\Roaming\web.config. Make sure to propagate changes to other servers in the group.
    3. Match the Delivery Controller names under “Manage Delivery Controllers” – The XML brokers can be different, but the actual name of the Delivery Controller/Farm must be identical. Here’s the exact setting I’m referring to: https://citrix.sharefile.com/d/sa562ba140be4462b

If you are running Receiver on a VDA, once you’ve removed the configured URLs shown above, do the following to clean up the VDAs:

  1. On the VDA, HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix – Delete the number folders representing policy entries.
  2. On session host VDAs, HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Citrix – Remove the entries for storefront in the following folders.
    1. Under \receiver\ctxaccount delete all entries.
    2. Under \SR\Store delete the entries.
  3. On the VDA, C:\ProgramData\CitrixCseCache – Delete all files
  4. On the VDA, C:\ProgramData\Citrix\GroupPolicy – Delete all folders and files.
  5. Run gpupdate and logoff.
  6. In the user’s registry, HKEY_CURRENT_USER or the profile registry hive. Possible profile reset.
    1. Under Software\Citrix\Dazzle\Sites – Delete all entries.
    2. Under Software\Citrix\Receiver\ctxaccount – delete all entries.
    3. Under Software\Citrix\SR\Store – delete the entries.
  7. Verify no cached profile folders for user on server.