Detailed Change Log

Last Modified: Jan 14, 2018 @ 9:57 am

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

Citrix Federated Authentication Service (SAML) 7.16

Last Modified: Dec 14, 2017 @ 11:20 am

Navigation

This article applies to Federated Authentication Services versions 7.16, 7.15.1000 (LTSR), 7.14, 7.13, 7.12, 7.11, and 7.9.

Changelog

Overview

Citrix Federated Authentication Service enables users to login to NetScaler Gateway and StoreFront using SAML authentication.

Citrix Federated Authentication Service uses Microsoft Certificate Authority to issue certificates on behalf of users. These certificates are used for the StoreFront and Virtual Delivery Agent logon process.

Requirements:

  • Microsoft Certificate Authority in Enterprise mode
  • XenApp/XenDesktop 7.9 or newer
  • StoreFront 3.6 or newer
  • NetScaler Gateway. Note: StoreFront 3.9 and newer also supports SAML authentication natively without NetScaler.
  • Receiver for Web only.
  • Receiver Self-Service for Windows 4.6 and newer supports SAML auth when connecting to StoreFront native SAML without NetScaler.

From Citrix CTX225721 Federated Authentication Service High Availability and Scalability: you can build multiple FAS servers. Enter all FAS server FQDNs in the Group Policy. StoreFront will then use a hashing algorithm on the username to select a FAS server.

  1. If you have less than 10K users, one FAS server with 4 vCPUs (2.5Ghz) should be sufficient.
  2. You will require a minimum of one FAS server (with 8 vCPUs) per 25,000 users if all users expect to be able to logon under cold start conditions (no keys or certificates cached) within 60-90 minutes.
  3. A single FAS server can handle greater than 50K users under warm start conditions (keys and certificates pre-cached)
  4. One reserve FAS server for every four FAS servers for “Day 1” cold start (Users get new keys/certificates) & disaster recovery scenarios
  5. Split the FAS Certificate Authority from Certificate Authority that performs other tasks for both security and scalability purposes.

Also see the Citrix Federated Authentication Service Scalability whitepaper.

Federated Authentication Service Versions

The most recent Federated Authentication Service Current Release is version 7.16. Current Releases are only supported for 6 months from release date and are expected to be upgraded every 3-6 months.

The most recent StoreFront Long Term Service Release (LTSR) is version 7.15.1000. LTSR versions are supported for 5 years from release date. Cumulative Updates are released periodically.

Install/Upgrade Federated Authentication Service

The service should be installed on a secure, standalone server that does not have any other Citrix components installed. The FAS server stores user authentication keys, and thus security is paramount.

Federated Authentication Service 7.16 is a Current Release, which is only supported for 6 months from release date. You are expected to upgrade it every 3-6 months. For longer term support, install Federated Authentication Service 7.15.1000 LTSR.

  1. On the Federated Authentication Service server, go to the XenDesktop 7.9 or newer ISO, and run AutoSelect.exe.
  2. In XenDesktop 7.13 and newer, in the lower half of the window, click Federated Authentication Service.
  3. Or in XenDesktop 7.9 through 7.12, on the bottom right, click Federated Authentication Service.
  4. In the Licensing Agreement page, select I have read, understand, and accept the terms of the license agreement, and click Next.
  5. In the Core Components page, click Next.
  6. In the Firewall page, click Next.
  7. In the Summary page, click Install.
  8. In the Finish Installation page, click Finish.

FAS Group Policy

  1. On the Federated Authentication Service server, browse to C:\Program Files\Citrix\Federated Authentication Service\PolicyDefinitions. Copy the files and folder.
  2. Go to \\domain.com\SYSVOL\domain.com\Policies\PolicyDefinitions and paste the files and folder. If PolicyDefinitions doesn’t exist in SYSVOL, then copy them to C:\Windows\PolicyDefinitions instead.
  3. Edit a GPO that applies to all StoreFront servers, all Federated Authentication Service servers, and all VDAs.
  4. Navigate to Computer Configuration > Policies > Administrative Templates > Citrix Components > Authentication.
  5. Edit the setting Federated Authentication Service.
  6. Enable the setting and click Show.
  7. Enter the FQDN of the Federated Authentication Service server. You can add more than one Federated Authentication Service server.
  8. Click OK twice.
  9. On the Federated Authentication Service server, and VDAs, run gpupdate.
  10. On the FAS server, and on VDAs, look in the registry at HKLM\Software\Policies\Citrix\Authentication\UserCredentialService\Addresses. Make sure this key and value exists. The number one cause why FAS doesn’t work is because this key is missing from VDAs. The FAS Address GPO must apply to VDAs too.
  11. If the VDAs and Users are in different domains, see CTX220497 Users from one AD Domain not able to get FAS user certificates from another trusted domain: add the Citrix StoreFront Servers, FAS server and VDA servers to the Windows Authorization Access Group in the users’ domain.
  12. By default, the VDAs will verify the certificates aren’t revoked by downloading the Certificate Revocation List. You can disable this by configuring HKEY_Local_Machine\System\CurrentControlSet\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors (DWORD) = 1 as detailed at CTX217150 Unable to login using the FAS Authentication – Getting Stuck on Please wait for local session manager.

FAS Configuration

  1. From the Start Menu, run Citrix Federated Authentication Service as administrator. Make sure you run it elevated.
  2. The Federated Authentication Service FQDN should already be in the list (from group policy). Click OK.
  3. In Step 1: Deploy certificate templates, click Start.
  4. Click OK to add certificate templates to Active Directory. Sufficient permission is required.
  5. Note: the deployed Certificate Templates have Autoenroll enabled. You might want to disable that.

    1. On the Security tab, check every group assign to the template.
    2. Repeat for the other two templates.
  6. In Step 2: Setup Certificate Authority, click Start.
  7. Select a Certificate Authority to issue the certificates, and click Ok.
  8. In Step 3: Authorize this Service, click Start.
  9. Step 3 automatically submits an online request for the Registration Authority certificate to the CA and stores the non-exportable private key in the standard Microsoft Enhanced RSA and AES Cryptographic Provider. Alternatively, you can submit the certificate request manually, and store the private key in TPM or HSM as detailed at Federated Authentication Service private key protection at Citrix Docs. When running New-FasAuthorizationCertificateRequest, the -UseTPM switch is optional.
  10. Select the issuing Certificate Authority, and click OK.
  11. Step 3 is now yellow.
  12. Go to the Certificate Authority Console > Pending Requests. Find the pending request and Issue it.
  13. In a minute or two, Federated Authentication Service will recognize the issued certificate and Step 3 will turn green. If it doesn’t turn green, then there might be a private hotfix. See David Lloyd at Citrix Discussions.
  14. Another user at XenDesktop 7.9 FAS at Citrix Discussions had to bump up the Validity Period of the Citrix_RegistrationAuthority_ManualAuthorization template to 2 days before it would authorize.
  15. After authorization, switch to the User Rules tab.
  16. Use the Certificate Authority drop-down to select the issuing Certificate Authority.
  17. Use the Certificate Template drop-down to select the Citrix_SmartcardLogon template.
  18. Click Edit next to List of StoreFront servers that can use this rule.
  19. Remove Domain Computers from the top half and instead add your StoreFront servers. You could add an Active Directory security group instead of individual StoreFront servers.
  20. On the bottom half, make sure Assert Identity is Allowed. Click OK.
  21. By default, all users and all VDAs are allowed. You can click the other two Edit boxes to change this.
  22. When done, click Apply.
  23. Click OK when Rule updated successfully.
  24. To further restrict who can be issued certificates, go to your Certificate Authority’s Properties, and use the Enrollment Agents tab to restrict enrollment agents.

StoreFront Configuration

  1. On the StoreFront 3.6 or newer server, run the following elevated PowerShell command:
    & "$Env:PROGRAMFILES\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"
  2. Run the following commands. Adjust the store name as required.
    $StoreVirtualPath = "/Citrix/Store"
    $store = Get-STFStoreService -VirtualPath $StoreVirtualPath
    $auth = Get-STFAuthenticationService -StoreService $store
    Set-STFClaimsFactoryNames -AuthenticationService $auth -ClaimsFactoryName "FASClaimsFactory"
    Set-STFStoreLaunchOptions -StoreService $store -VdaLogonDataProvider "FASLogonDataProvider"
  3. If you have multiple StoreFront servers, Propagate Changes.
  4. On a XenDesktop Delivery Controller, run the following commands:
    asnp citrix.*
    Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

If you ever need to disable FAS on StoreFront, run the following commands. Adjust the store name as required.

$StoreVirtualPath = "/Citrix/Store"
$store = Get-STFStoreService -VirtualPath $StoreVirtualPath
$auth = Get-STFAuthenticationService -StoreService $store
Set-STFClaimsFactoryNames -AuthenticationService $auth -ClaimsFactoryName "standardClaimsFactory"
Set-STFStoreLaunchOptions -StoreService $store -VdaLogonDataProvider ""

NetScaler Gateway Config

SAML on NetScaler Gateway

Configure the SAML iDP:
Every iDP has unique instructions. Search Google for your iDP and NetScaler and you might find a iDP-specific guide.

The screenshots in this section use ADFS as an example iDP. Your iDP will be different.

  1. In your SAML iDP, create a Relying Party Trust (aka service provider trust) or new Application.
  2. NetScaler doesn’t have a SAML metadata service, but you can create a metadata file manually by following the instructions at Citrix CTX133919 How to Configure NetScaler SAML to Work with Microsoft AD FS 2.0 IDP.
  3. Otherwise, select the option to enter relying party data manually.
  4. For the Assertion Consumer Service URL (aka relying party service URL), enter the URL to your NetScaler Gateway with /cgi/samlauth appended to the end (e.g. https://gateway.corp.com/cgi/samlauth)
  5. Enter a Relying party trust identifier. You must specify the same identifier (Issuer Name) on the NetScaler as detailed soon.
  6. Configure the SAML iDP to send email address or User-Principal-name as Name ID. NetScaler receives the Name ID and sends it to StoreFront. StoreFront will look in Active Directory for an account with userPrincipalName that matches the Name ID.
  7. NetScaler will sign the authentication requests it sends to the iDP. On the NetScaler, you will soon configure the NetScaler signing certificate with private key that signs the requests. In your SAML iDP, import the same NetScaler signing certificate but without private key.
  8. Copy the SAML authentication URL (aka Token Issuance URL) from your SAML iDP. You’ll need to enter this same URL on your NetScaler later.
  9. Export the iDP Token-signing certificate from your SAML iDP. The iDP could be ADFS, Okta, Ping, etc.

Configure the NetScaler:

  1. Instructions for NetScaler 11.1 and NetScaler 12 are essentially the same.
    • NetScaler 11 is very similar, except the Certificates are in a different place in the menu tree.
  2. On NetScaler, import the iDP SAML token-signing certificate (without private key) under Traffic Management > SSL > Certificates > CA Certificates. NetScaler uses this certificate to verify the signature of the SAML assertion from the iDP.

  3. Move up two nodes to Server Certificates and Import or create a NetScaler SAML signing certificate with private key for signing of SAML authentication requests to the iDP. This can be the same certificate used on NetScaler Gateway. Or a more common practice is to create a self-signed certificate.

    1. You’ll also need to import this NetScaler SAML SP signing certificate (without private key) to your SAML iDP so it can verify the SAML authentication request signature from the NetScaler.
  4. Go to NetScaler Gateway > Policies > Authentication > SAML. The quickest way to get here is to enter SAML in the search box on top of the menu.
  5. On the right, switch to the Servers tab, and click Add.
  6. Enter the information for authenticating with your SAML iDP. This configuration will vary depending on your SAML iDP.
    1. For iDP Certificate Name, select the SAML iDP’s certificate that was exported from the SAML iDP and imported to NetScaler. NetScaler will use this iDP certificate to verify SAML assertions from the iDP.
    2. For Redirect URL, enter the URL to the SAML iDP’s authentication page. NetScaler Gateway will redirect users to this URL. For ADFS, enter your ADFS URL appended with /adfs/ls (e.g. https://adfs.corp.com/adfs/ls). For other iDPs, get the URL from your iDP.
    3. For Signing Certificate Name, select the NetScaler certificate (with private key) that NetScaler will use to sign authentication requests to the iDP. This same certificate (without private key) must be imported to the iDP, so the iDP can verify the authentication request signature.
    4. Enter an Issuer Name that the SAML iDP is expecting for the Relying Party.  This Issuer Name must match the name you configured on the iDP’s Relying Party (Service Provider) Trust.
    5. Scroll down and click More.
    6. NetScaler defaults to SHA1. You might have to change the Signature Algorithm and Digest Method to SHA256.
    7. Review the other settings as needed by your iDP. Click Create when done.
  7. On the right, switch to the Policies tab, and click Add.

    1. Give the policy a name, select the SAML Server, and enter ns_true for the expression. Click Create.
  8. Create NetScaler Gateway Session Polices if you haven’t already.
  9. Edit your Session Policy/Profile.

    1. On the Published Applications tab, make sure Single Sign-on Domain is not configured.
  10. Create a NetScaler Gateway Virtual Server if you haven’t already.
  11. Edit your Gateway Virtual Server. Go to the Basic Authentication section, and add a policy.
  12. Bind the SAML policy. This is the only authentication policy you need. You can remove all other authentication policies.

  13. Next step: configure StoreFront for SAML NetScaler Gateway.

StoreFront Config for SAML NetScaler Gateway

  1. In StoreFront 3.6 or newer, right-click the store, and click Manage Authentication Methods.
  2. Make sure Pass-through from NetScaler Gateway is selected.
  3. Click the gear icon on the right, and click Configure Delegated Authentication.
  4. Check the box next to Fully delegate credential validation to NetScaler Gateway, and click OK twice.
  5. In StoreFront, add a NetScaler Gateway object that matches the NetScaler Gateway Virtual Server that has SAML enabled.
  6. On the Authentication Settings page, make sure you configure a Callback URL. It won’t work without it.
  7. Then assign (Configure Remote Access Settings) the Gateway to your Store.

  8. Next step: create Active Directory Shadow Accounts

Native SAML on StoreFront without NetScaler

StoreFront 3.9 and newer have native support for SAML Authentication without NetScaler. Notes:

  • SAML overrides Explicit and Pass-through authentication.
  • SAML in StoreFront without NetScaler seems to work in Receiver Self-Service for Windows.

To configure native SAML in StoreFront 3.9 or newer:

  1. Export the signing certificate from your SAML iDP. The iDP could be ADFS, Okta, Ping Identity, etc.
  2. In StoreFront 3.9 or newer console, right-click a Store, and click Manage Authentication Methods.
  3. Check the box next to SAML Authentication. If you don’t see this option (because you upgraded), click the Advanced button on the bottom of the window, and install the authentication method.
  4. On the right, click the gear icon for SAML, and click Identity Provider.
  5. Change the SAML Binding to the method your iDP expects.
  6. Enter the iDP token issuance endpoint URL. For example, in ADFS, the path is /adfs/ls.
  7.  Click Import.
  8. Browse to the signing certificate exported from your iDP, and click Open.
  9. Then click OK to close the Identity Provider window.
  10. On the right, in the SAML Authentication row, click the gear icon, and then click Service Provider.
  11. Click the first Browse button.
  12. Give the Signing certificate a name, and save it somewhere.
  13. Click the second Browse button.
  14. Give the Encryption certificate a name, and save it somewhere.
  15. Copy the Service Provider Identifier. Or you can change it to your desired value. Then click OK.
  16. In your iDP (e.g. ADFS), create a Relying Party Trust.
  17. Import the Encryption certificate that you exported from StoreFront.
  18. Enable SAML 2.0.
  19. For the Assertion Consumer Service (ACS) path, enter something similar to https://storefront.corp.com/Citrix/StoreAuth/SamlForms/AssertionConsumerService. The hostname portion of the URL is equivalent to your StoreFront Base URL. /Citrix/StoreAuth matches your Store name with Auth on the end. The rest of the path must be /SamlForms/AssertionConsumerService. You can get this ACS value by looking in the SAML metadata at the bottom of https://<storefront host>/Citrix/StoreAuth/SamlForms/ServiceProvider/Metadata.

  20. For the Relying party trust identifier, enter the identifier you copied from the Service Provider window in StoreFront.
  21. Configure the Claim Rules to send the user’s email address or userPrincipalName as Name ID.
  22. Edit the Relying Party Trust. Import the Signing certificate that you exported from StoreFront.

  23. Create Active Directory Shadow Accounts. Federated users must be userPrincipalName mapped to local Active Directory accounts.
  24. If you point your browser to https://<storefront-host>/Citrix/<storename>Auth/SamlTest, it should perform a SAML Login, and then show you the assertion that was returned from the iDP. See Citrix CTX220639 How to configure SAML Authentication-Test Configuration.
  25. See Citrix CTX220682 Storefront SAML Troubleshooting Guide for event logs, SAML Metadata, Active Directory account mapping, Trust XML, etc.
  26. When you go to your Receiver for Web page, it should automatically redirect you to your iDP. After authentication, it should redirect you back to StoreFront and show you your icons.
  27. ADFS also works in Receiver 4.6 and newer. Currently, the only supported configuration is ADFS with SAML to StoreFront without NetScaler.
  28. When you logoff, it won’t let you log on again unless you close your browser and reopen it.

  29. To fix this problem, see CTP Sacha Thomet StoreFront – Allow relogin without browser close. Edit the file C:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js, and add the following line:
    CTXS.allowReloginWithoutBrowserClose = true

  30. Now when you logoff, you’re given an option to log on again.

Active Directory Shadow Accounts

To login to Windows (Citrix VDA), every user must have an Active Directory account in a domain trusted by the VDA. For Federated Users, you typically need to create shadow accounts for each Federated user in your local Active Directory. These Shadow accounts need a userPrincipalName that matches the SAML attribute (usually email address) provided by the SAML iDP.

If the email address provided by the SAML iDP does not match the UPN suffix for your domain, then do the following:

  1. Open Active Directory Domains and Trust.
  2. Right-click the top left node (not a domain node), and click Properties.
  3. In the UPN Suffixes tab, add a UPN suffix that matches the email suffix provided by the SAML iDP.
  4. When creating a shadow account in your Active Directory, the new UPN suffix is available in the drop-down list. Note that the pre-Windows 2000 logon name can’t conflict with any other user in the domain.
  5. The password for these Shadow accounts can be any random complex password since the Federated users never need the Shadow account’s password.
  6. If the shadow account is already created, edit the account, and on the Account tab, use the drop-down to select the new UPN suffix.
  7. Create a shadow account for every federated user. There are third party Identity Management tools that can automate this. Or get an export from the iDP and use PowerShell scripting to create the acccounts.

Verify FAS

When FAS is enabled on StoreFront, every user that logs into StoreFront (local or remote) causes a user certificate to be created on the FAS server. You can see these user certificates by running the following PowerShell commands:

Add-PSSnapin Citrix.Authentication.FederatedAuthenticationService.V1
Get-FasUserCertificate -address fas01.corp.local

Citrix uses these certificates to logon to the VDA as the user. No password needed.

StoreFront 3.5 through 3.13 – Tweaks

Last Modified: Jan 3, 2018 @ 5:09 pm

Navigation

Here is a collection of optional StoreFront configurations.

This article applies to StoreFront versions 3.5, 3.6, 3.7, 3.8, 3.9, 3.11, 3.12, and 3.13.

💡 = Recently Updated

Changelog

CRL Checking – Disable

When the StoreFront server checks certificate revocation for its locally signed files, a delay can occur before the StoreFront logon page is displayed.

  1. Run the following PowerShell commands:
    Add-PSSnapin Citrix.DeliveryServices.Framework.Commands
    Set-DSAssemblyVerification $false
  2. Another potential tweak to speed up StoreFront is to disable NetBIOS. Right-click the Start Menu and click Network Connections.
  3. Right-click the NIC and click Properties.
  4. Highlight Internet Protocol Version 4 and click Properties.
  5. Click Advanced.
  6. On the WINS tab, change the selection to Disable NetBIOS over TCP/IP and click OK twice and Close once.
  7. Repeat on the other StoreFront servers.

Note: According to Microsoft, it is no longer necessary to configure generatePublisherEvidence in C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config.

Receiver Shortcuts

You can use StoreFront to control placement of shortcuts on Receiver machines.

  1. Run Notepad elevated (as administrator).
  2. Edit the file C:\inetpub\wwwroot\Citrix\Roaming\web.config.
  3. Search for <account id. Find the Store name in the name attribute.
  4. Scroll down to the first <properties> section located under <annotatedServices>.
  5. See Using StoreFront account settings to customize app shortcut locations at Citrix Docs for a list of properties. Add the properties as detailed at Citrix Docs. The properties should be added after the clear tag.
  6. Note: if subscriptions are enabled in StoreFront then only Favorites are added to the Start Menu and Desktop. If subscriptions are disabled then all applications are placed on the Start Menu or Desktop.
  7. Close and save the file.
  8. Then Propagate Changes.

PNAgent Authentication and Default Store

Default Store

If you point your browser to https://storefront.corp.com/Citrix/PNAgent/config.xml, which is the typical path for PNAgent, you’ll get a 404.

To fix this, in the StoreFront console, right-click the store, and click Configure XenApp Services Support.

In the bottom of the window, select the Default store, and click OK.

Now PNAgent can point to StoreFront without needing to specify a custom path. Note: this only works for /Citrix/PNAgent/config.xml.

Single Sign-on

From Configure authentication for XenApp Services URLs at Citrix Docs: XenApp Services URLs support explicit, domain pass-through, and pass-through with smart card authentication. Explicit authentication is enabled by default. You can change the authentication method, but only one authentication method can be configured for each XenApp Services URL. To enable multiple authentication methods, create separate stores, each with a XenApp Services URL, for each authentication method. To change the authentication method for a XenApp Services URL, you run a Windows PowerShell script.

  1. On the primary StoreFront server in your deployment, use an account with local administrator permissions to start Windows PowerShell.
  2. At a command prompt, type the following command to configure the user authentication method for users accessing the store through the XenApp Services URL.
    & "C:\Program Files\Citrix\Receiver StoreFront\Scripts\EnablePnaForStore.ps1" –SiteId 1 -ResourcesVirtualPath /Citrix/Store –LogonMethod sson
  3. Propagate changes.

Remember my password

If you leave PNAgent authentication set to Prompt, you can enable the Remember my password box by doing the following:

  1. Run Notepad as Administrator and edit the file C:\inetpub\wwwroot\Citrix\Store\Views\PnaConfig\Config.aspx.
  2. Near line 74 is EnableSavePassword. Change it to true.
  3. When PNAgent connects, there should now be a Remember my password checkbox.

Hide Applications

You can hide all icons of a particular type (Applications, Desktops, Documents). Or you can hide icons with a specific keyword.

Go to Stores > MyStore > Configure Store Settings > Advanced Settings, and look for the Filter options.

Filter resources by type lets you hide all Applications or all Desktops. If you are running Receiver inside a published desktop, then you probably don’t want desktop icons to be delivered by Receiver. In that case, create a new Store and filter the Desktop icons. Then only the application icons will be delivered.

Filter resources by excluded keywords lets you filter published icons that match a custom keyword.

Once the ExcludeKeyword has been defined, add the keyword to a published application or published desktop description, and that application/desktop will no longer display in Receiver. This works for both Receiver for Web and Receiver Self-Service (non-browser).

In XenDesktop 7.9 and newer, to assign a description to a Desktop, you edit the Delivery Group, go to the Desktops page, and edit one of the Desktops. Citrix CTX220429 Configure Resource Filtering to Allow Desktops to be filtered on Storefront.

Desktop Autolaunch

By default, if only a single desktop is published to the user, Receiver for Web will auto-launch it. You can change this behavior by going to Stores > MyStore > Manage Receiver for Web Sites > Configure > Client Interface Settings and uncheck the box next to Auto launch desktop.

Full Screen Desktop

Citrix CTX139762 How to Configure StoreFront to Start Published Desktops in Full Screen Mode: This article describes how to configure StoreFront to start published desktops in Full Screen Mode.

  1. Open the file C:\inetpub\wwwroot\Citrix\Store\App_Data\default.ica on the StoreFront server(s) with notepad (as Administrator)
  2. Add the line:
    [Application]
    DesktopViewer-ForceFullScreenStartup=On
  3. In older versions of StoreFront, it should be true instead of On.
  4. Save the file.
  5. Open the command prompt (cmd) and run iisreset.

Autolaunch Application

See the script.js code posted by Michael Bednarek at Citrix Discussions.

Store for Anonymous

If you intend to publish applications to anonymous users then you can create a StoreFront store that does not require authentication. Note: anonymous stores only work internally (no NetScaler Gateway).

  1. On the VDAs, create and configure anonymous accounts.
  2. In Citrix Studio, configure a Delivery Group to accept unauthenticated (anonymous) users.
  3. In the StoreFront Console, right-click Stores, and click Create Store.
  4. In the Store Name and Access page, enter a new store name.
  5. Check the box next to Allow only unauthenticated users to access this store.
  6. Then click Next and finish the wizard like normal.
  7. By default, Anonymous stores are hidden (not advertised). When performing discovery in Receiver you’ll need to enter the full path to the store (e.g. https://storefront.corp.com/Citrix/Anon/discovery).

Workspace Control

Workspace Control reconnects user sessions. It can be disabled. Or configure various reconnection options.

Citrix Blog Post Workspace Control: When You DON’T Want to Roam details complete session reconnection configuration instructions for XenApp, Remote Desktop Services, StoreFront, and Receiver.

Receiver for Web

Go to Stores > MyStore > Manage Receiver for Web Sites > Configure > Workspace Control page.

Receiver Self-Service

Citrix Blog Post – How to Disable Workspace Control Reconnect: For Receiver for Windows, Workspace Control can be managed on client devices by modifying the registry. Please see this Knowledgebase Article for how to implement it. This can also be done for domain-joined client devices using Group Policy.

In StoreFront Console, go to Stores > MyStore > Configure Store Settings > Advanced Settings, and there’s a setting for Allow session reconnect.

Treat Desktops as Applications

From Treating All Desktops as Applications at Citrix Blog Post What’s New in StoreFront 3.0: Desktops are treated differently from applications in StoreFront/Receivers. They are placed in a separate Desktop tab and in the case of Receiver for Web, they are not reconnected with workspace control. In some use cases, it is desirable to treat desktops as applications so that they are placed together with applications and get reconnected as part of workspace control. With StoreFront 2.x, you have to add the TreatAsApp keyword to all published desktops to achieve this effect. StoreFront 3.0 enables you to configure treating all desktops as applications at the store level without the need of adding the TreatAsApp keyword to all the published desktops. This is configurable using a PowerShell cmdlet.

& "C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"

Set-EnhancedEnumerationOptions -siteId 1 -storeVirtualPath /Citrix/Store `
-treatDesktopsAsApps $true

Also see Citrix CTX223817 How to Configure “TreatAsApp” in XenDesktop 7.8.

Special Folder Redirection

From Configure special folder redirection at Citrix Docs: With Special Folder Redirection configured, Citrix maps Windows special folders for the server, to those on their local computers. Special folders refer to standard Windows folders, such as \Documents and \Desktop.

In StoreFront Console, go to Stores > Configure Store Settings > Advanced Settings and there’s an option for Allow special folder redirection.

Receiver Self-service – Disable “Remember My Password”

By default, when Receiver Self-Service connects internally to StoreFront, the user is able to check the box next to Remember my password. Note: When connecting through NetScaler Gateway, this checkbox is never available.

This can be disabled by making a change on the StoreFront server. This procedure is documented by John Ashman at Citrix Discussions and Prevent Citrix Receiver for Windows from caching passwords and usernames at Citrix Docs.

  1. Note that this procedure seems to prevent Receiver for iOS from adding accounts.
  2. On the StoreFront server, run a text editor elevated (as administrator).
  3. Open the file C:\inetpub\wwwroot\Citrix\StoreAuth\App_Data\Templates\UsernamePassword.tfrm.
  4. Go to line 20, which should start with @SaveCredential.
  5. To comment out the line, wrap it in @* and *@. Save the file when done.

  6. Now the Remember My Password checkbox is gone.

“Activate” Option in Web Page – Disable

From Citrix Discussions: to disable the “activate…”; function for Citrix receiver for windows that is visible when a user clicks their username in the upper right hand corner of Receiver for Web, in StoreFront Console, go to Stores > MyStore > Manage Receiver for Web Sites > Configure > Client Interface Settings page. There’s a checkbox for Enable Receiver configuration.

HTML5 Receiver Getting Started Tour

The first time a user connects to HTML5 Receiver, the user is prompted to tour the interface.

The Getting Started Tour can be disabled by doing the following:

  1. Edit the file C:\Inetpub\wwwroot\Citrix\StoreWeb\custom\script.js.
  2. At the bottom of the file, add Feng Huang’s code from First time user tutorial at discussions.citrix.com. Make sure the quotes are straight quotes and not curly quotes.
    localStorage["showFtu"] = false;

Logoff RfWeb Seconds after Icon Launch

From Citrix Blog Post Logging Off Receiver for Web after an Application/Desktop Launch: Simply add the following code snippet to script.js in the custom folder for the Receiver for Web site (typically C:\inetpub\wwwroot\Citrix\StoreWeb\custom\) you would like to customize:

var delayLogoffInSeconds = 10;

CTXS.Extensions.beforeWebLogoffIca = function(action) {
    return 'none';
};

CTXS.Extensions.postLaunch = function(app, status) {
    if (! CTXS.Device.isNativeClient()) {
        if (status == CTXS.LAUNCH_SUCCESS) {
            function logoff() {
                CTXS.Environment.logOff();
            }
            window.setTimeout(logoff, delayLogoffInSeconds * 1000);
        }
    }
};

Customize Receiver UI in StoreFront 3.x

StoreFront 3.x customizations are visible in both Receiver for Web and in Receiver Self-Service.

 

If you are load balancing StoreFront and want to put the server name on the webpage (or Receiver), see Citrix Blog Post How To: Add a Server Identifier to the StoreFront Page Footer.

Citrix Blog Post Dynamic Subscription Icons in StoreFront explains how to change the Details link to a star icon based on subscription status. The star icons are not clickable (yet).

Trentent Tye at Citrix Storefront – Adventures in customization – Add a help button to your Storefront UI uses CTXS.ExtensionAPI.addHelpButton() and CTXS.ExtensionAPI.openUrl() to add a help button which opens a help page URL.

CTP Sam Jacobs and Rich Minichiello Adding an EULA Checkbox to StoreFront logon page

Nicolas Ignoto Lab: Part 22 – Ultimate StoreFront 3 customization guide contains many StoreFront customizations including:

  • Add disclaimer
  • Change logo/background
  • Add header
  • Add text
  • Change colors
  • Etc.

 

Citrix Blog Post Citrix Customization Cookbook contains a collection of customizations including:

  • Add Static or dynamic (read from file) text to the header and/or footer of the login page.
  • Click-through disclaimer before or after login page
  • Footer for every page
  • Default to Folder view when visiting the Apps tab
  • Change default text
  • Change background images for featured categories
  • Background image

 

Citrix Blog Post Storefront 3 Web Customization: Branding Your Deployment describes how to modify the following CSS to customize the appearance of StoreFront 3.x

  • Background images
  • Logon button
  • Colors for page and text
  • How to view the mobile version of the page
  • CSS for mobile pages

 

Jason Samuel Upgrading Citrix StoreFront 2.6 to StoreFront 3.0 – Things to Know details how to change the StoreFront logo to a Receiver logo.

 

Citrix Blog Post StoreFront Message Customization describes how to add a scrolling message to the top of the screen. This is displayed in both Browsers and Receivers. This post contains a new version of the executable that supports StoreFront 3.0 and newer.

 

Migrate Web Interface features to StoreFront at Citrix Docs details how to configure Web Interface features in StoreFront. This includes:

  • Enable return to last folder
  • Header logo
  • Pre-logon welcome message
  • Logon screen customization
  • Footer text

The code for pre-login message is already included in C:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js. Just remove the comment. Source = Citrix CTX227805 StoreFront 3.11 >>How to get the login banner on Storefront page

 

Rody Kossen and his colleague Leon Koppel built a customisation layer that reads the state of the resources presented to the end-user. If a desktop is under maintenance, inform the user so he knows before he tries to access the resource. Get the code from Citrix Blog Post Putting the Experience First, Where it Belongs.  💡

 

StoreFront 3.0 Receiver Customization APIs are detailed at Citrix Developer. Use the Receiver Customization API to brand or customize your end users’ app and desktop selection experience beyond capabilities provided in the StoreFront admin console. Customizations apply to latest Web, Chrome, Windows, Mac and Linux clients, and will be extended to mobile devices in future releases.

 

CTX221097 How to rename items on StoreFront? describes the strings that can be changed.

  1. Go to C:\inetpub\wwwroot\Citrix\<StoreName>Web\custom
  2. Open strings.en.js file
  3. See below for an example of overriding one of the built-in strings. See the article for the full list of strings.

 

Citrix Blog Post Receiver X1 APIs describes the following:

  • Overview of the CSS classes that can be customized.
  • Override Citrix’s JavaScript functions to modify behavior – exclude or restyle apps, change a sort order, add a warning message etc.
  • How to force X1 UI to display in either phone or larger mode.

 

Citrix Blog Post X1 Customization: Going deeper with CSS describes the following:

  • Use CSS (/custom/style.css) to style the three custom regions (#customTop, #customBottom, #customScrollTop). Shown below in red, blue, and pink.
  • Marker classes for showing/hiding or highlighting parts of the UI: large display, small display, high DPI, Favorites view, Desktops view, Apps view, appinfo view.

 

Citrix Blog Post Scripting X1 describes the following:

  • JavaScript code to display an Acceptance dialog box before users can login.
  • Use JQuery to add HTML code to custom regions (e.g. #customScrollTop) including using CSS to hide the HTML code unless a specific tab is selected by the user.

Citrix Blog Post – Rewriting the Session ClientName from StoreFront: I would like to offer the following customisation DLL which can apply client name rewrites based on a template. The customisation template can be any string, but where that string contains a particular token, the token will be replaced by some information from the User Context. If the intent was just to replace the ClientName with the user name, the template is then just “$U”. More details and the .dll file are in the blog post.

StoreFront Store Customization SDK at Citrix Developer: The Store Customization SDK allows you to apply custom logic to the process of displaying resources to users and to adjust launch parameters. For example, you can use the SDK to control which apps and desktops are displayed to users, to change ICA virtual channel parameters, or to modify access conditions through XenApp and XenDesktop policy selection. Key Customization Points:

  • Post-Enumeration
  • Post-Launch ICA File
  • Post-Session Enumeration
  • Access Conditions (pre-launch and pre-enumeration)
  • Provider List
  • Device information

Citrix Blog Post Adding a Language to StoreFront 3.0: A new language pack is comprised of a culture definition file, a string bundle file and a custom string bundle file. See the Blog Post for more details.

To force StoreFront to only use English, add the following to c:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js as detailed at Set default language to EN at Citrix Discussions:
CTXS.Environment.getPreferredLanguages = function () { return null; }

 

To change the StoreFront page title, see Sam Jacobs How to Change the Page Title in Citrix Receiver 3.x at mycugc.org.

 

Customizations detailed at topic Modify Receiver for Web site at Citrix Discussions:

  • Add Featured App Groups to Categories View
  • Increase the number of Featured applications beyond the default of 3.

StoreFront SDKs

Most of the StoreFront SDK documentation can be found at https://citrix.github.io/storefront-sdk/

StoreFront Store Customization SDK – Use the Store Customization SDK to apply custom logic to the process of displaying resources to users and to adjust launch parameters.  For example, you can use the SDK to control which apps and desktops are displayed to users, to change ICA virtual channel parameters, or to modify access conditions through XenApp and XenDesktop policy selection.

StoreFront Web API – Receiver for Web is a component of Citrix StoreFront that provides access to applications and desktops using a Web browser. It consists of a User Interface tier and a StoreFront Services Web Proxy tier.

StoreFront Authentication SDKs – With StoreFront 3.0, we have introduced a new Unified UI that is delivered from StoreFront to Receiver on all client platforms. Use the Receiver Customization API to brand or customize your end users’ app and desktop selection experience beyond capabilities provided in the StoreFront admin console. Customizations apply to latest Web, Chrome, Windows, Mac and Linux clients, and will be extended to mobile devices in future releases.

StoreFront PowerShell SDK – Citrix StoreFront provides an SDK based on a number of Microsoft Windows PowerShell version 3.0 modules. With this SDK, you can perform the same tasks as you would with the StoreFront MMC console, together with tasks you cannot do with the console alone.

StoreFront 3.x Portal Theme for NetScaler 11

See NetScaler Gateway 11 > Portal Themes. Build 62 and newer have a built-in X1 theme.

StoreFront 3.x Theme for NetScaler 10.5

You can make the NetScaler Gateway 10.5 logon page look like the Receiver for Web in StoreFront 3.0. Visit Citrix Blog Post X1 Skin for NetScaler Gateway to download an already developed theme package. Or see one of the following for instructions to manually edit the NetScaler Gateway theme to match StoreFront 3.x

To install the theme package:

  1. Download the X1 theme from the Citrix Blog post.
  2. WinSCP to the NetScaler and switch to /var/netscaler/gui/themes.
    1. On the right, rename the existing receivertheme.tar.gz file.

  3. Upload the theme that was downloaded from the Citrix Blog post.
  4. In NetScaler GUI, go to NetScaler Gateway > Global Settings > Change Global Settings.
  5. Switch to the Client Experience tab.
  6. At the bottom, if the current UI Theme is Green Bubble, change it to Default. Then go back into the screen and change it back to Green Bubble. This causes the theme to reload. Click OK.
  7. The logon page should now look more like Receiver for Web in StoreFront 3.0.

Related Pages

StoreFront 3.5 through 3.13 – Configuration for NetScaler Gateway

Last Modified: Dec 2, 2017 @ 8:41 am

Navigation

This article applies to StoreFront versions 3.5, 3.6, 3.7, 3.8, 3.9, 3.11, 3.12, and 3.13.

Changelog

  • 2017 Dec 2 – updated Docs links for current-release

StoreFront Configuration for NetScaler Gateway

See the NetScaler pages for instructions on creating a NetScaler Gateway Virtual Server for ICA Proxy and StoreFront. You then must configure StoreFront to enable the Gateway.

  1. In the StoreFront Console, in the middle, right-click your Store, and click Manage Authentication Methods.
  2. Ensure Pass-through from NetScaler Gateway is selected, and click OK.
  3. In the StoreFront Console, right-click the Stores node, and click Manage NetScaler Gateways.
  4. If StoreFront 3.6 or newer, notice the imported from file link on top. This is a new feature of NetScaler 11.1 and newer. An example configuration that uses this feature can be found in the StoreFrontAuth page.

  5. If you’re not using the Gateway config file from NetScaler 11.1 and newer, click Add.

    1. In the General Settings page, enter a display name. This name appears in Citrix Receiver, so make it descriptive.
    2. In the NetScaler Gateway URL field, enter the NetScaler Gateway Public URL that resolves to the NetScaler Gateway VIP. This can be a GSLB-enabled DNS name. Click Next.
    3. In the Secure Ticket Authority page, click Add.
    4. Enter the URL to a XenDesktop Controller. This can be http or https. Click OK.
    5. Continue adding Secure Ticket Authorities (XenDesktop Controllers). Whatever Secure Ticket Authorities you add here must also be added to the NetScaler Gateway Virtual Server on the NetScaler appliance. Click Next.
    6. In the Authentication Settings page, the vServer IP Address field is typically left blank. You only use this field if you have multiple Gateways (on separate appliance pairs) connecting to one StoreFront server. See below for details.
    7. If you need SmartAccess, then enter the Callback URL.
      • The Callback URL must resolve to any NetScaler Gateway VIP on the same appliance that authenticated the user.
      • If you are configuring Single FQDN, then the Callback URL must be different than the Single FQDN.
      • Edit the HOSTS file on the StoreFront server so the Callback URL resolves to NetScaler appliances in the same datacenter.
      • The Gateway Virtual Server that the Callback URL resolves to must have a trusted and valid (matches the FQDN) certificate.
      • The Gateway Virtual Server that the Callback URL resolves to must not have client certificates set to Mandatory.
    8. If you don’t need SmartAccess, then leave the Callback URL field empty.
    9. If you enabled two-factor authentication (LDAP and RADIUS) on your NetScaler, change the Logon type to Domain and security token. Otherwise leave it set to Domain only.
    10. Click Create.
    11. Then click Finish.
  6. You can add more Gateways depending on your design. Multiple datacenters typically requires multiple Gateways. Click Close when done.
  7. To enable the store to use NetScaler Gateway, in the middle, right-click your store, and click Configure Remote Access Settings.

    1. Check the box next to Enable Remote Access.
    2. Leave it set to No VPN tunnel.
      1. Note: if you want Receiver to automatically launch a VPN tunnel, then see CTX200664 How to Configure Receiver for Seamless Experience Through NetScaler Gateway.
    3. Check the box next to the NetScaler Gateway object you just created. This binds the Gateway to the Store.
    4. If you have multiple Gateways, select one of them as the Default appliance.
      • Note: when you point Receiver to a NetScaler Gateway URL for Discovery, after Discovery is complete, the Default appliance selected here is the Gateway that Receiver uses. In other words, Receiver ignores the Gateway you entered during discovery.
    5. Click OK to close the Configure Remote Access Settings dialog box.
  8. In the StoreFront Console, right-click the Stores node, and click Manage Beacons.
  9. In the top half of the window, make sure the Internal beacon is set to a URL that is only reachable internally.
    1. If you are configuring Single FQDN, then the Internal beacon must be different than the Single FQDN.
    2. Service URL = the StoreFront Base URL. If you’re not configuring Single FQDN, then the Base URL is usually not accessible externally.
    3. The Internal beacon must never go down. If it’s down, then internal native Receivers will stop working.
    4. Click OK when done.
  10. Right-click the Server Group node, and click Propagate Changes.

NetScaler Gateway Logon Page Theme

To make the NetScaler Gateway logon page look like Receiver 3.0 and newer, see one of the following:

Single FQDN

Overview

Links:

You can either define separate FQDNs for StoreFront Load Balancing (internal) and NetScaler Gateway (external). Or, you can define a Single FQDN for both.

Single FQDN has the following requirements:

  • Receivers:
    • Receiver for Windows 4.2 or newer
    • Receiver for Mac 11.9 or newer
    • Mobile Receivers
    • It doesn’t seem to work with Linux Receiver
  • StoreFront 2.6 or newer
  • Split DNS – different DNS resolution for internal vs external
    • Internal DNS should resolve the Single FQDN to the StoreFront Load Balancing VIP
    • External DNS should resolve the Single FQDN to the NetScaler Gateway VIP (public IP)
  • NetScaler 10.1 or newer
  • The FQDN for Internal Beacon must be different than the Single FQDN.
    • The Internal Beacon URL must not be externally resolvable or accessible.
    • If Internal Beacon is down, then internal Receiver Self-Service clients will not function correctly.
    • Internal Beacon URL can be http instead of https.
    • If Internal Beacon URL is https, then the machine hosting the IP address for the Internal Beacon must have a certificate that matches the Internal Beacon FQDN.
  • The FQDN for NetScaler Gateway Callback must be a different FQDN than the Single FQDN. Callback is only needed for SmartAccess and SAML.
    • Callback FQDN can resolve tot he same Gateway VIP used by external users. Or, you can create a new Gateway VIP on the same appliance that authenticated the users.
    • The Gateway Virtual Server for Callback must have a certificate that matches the Callback FQDN.

DNS caching interferes with Single FQDN – Note: if you have laptops that move from internal to external and back again, then DNS caching will interfere with Single FQDN. The DNS response for Single FQDN needs to change whenever the device moves from internal to external and back again. However, Receiver uses the same DNS cache as Internet Explorer, which caches DNS responses for 30 minutes. To clear the DNS cache, you have to close Receiver and re-open it. The DNS response you see when you ping the Single FQDN does not necessarily match the DNS response used by Internet Explorer and Receiver.

Configure Single FQDN without email-based discovery

If you don’t care about email-based discovery, then the configuration of Single FQDN is fairly simple. Sample DNS names are used below. Make sure the certificates match the DNS names.

  1. Internal DNS name = the Single FQDN (e.g. storefront.corp.com). Internally, the DNS name resolves to the internal Load Balancing VIP for StoreFront. Set the StoreFront Base URL to this address.
  2. External DNS name = the Single FQDN (e.g. storefront.corp.com). Externally, the DNS name resolves to a public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler. Set the NetScaler Gateway object in StoreFront to this FQDN.

  3. If you need SmartAccess, then the Callback URL = any DNS name (e.g. callback.corp.com) that resolves to a NetScaler Gateway VIP on the same DMZ NetScaler appliance that authenticated the user. The Callback URL cannot be the Single FQDN.

    • Callback URL can be omitted if you don’t need SmartAccess features, or SAML authentication.
    • The callback DNS name must be different than the Single FQDN.
    • The callback DNS name must resolve to a NetScaler Gateway VIP on the same appliance that authenticated the user. This could be the same DMZ Gateway VIP used by external users. Or you can create a separate internal Gateway VIP on the same appliance.
    • The NetScaler Gateway vServer for callback must have a certificate that matches the Callback DNS name.
  4. Internal Beacon = any internal website URL that is not externally accessible. You can’t use the Single FQDN as the Internal Beacon. Note: if the internal beacon is down, then internal Receiver Self-service will not work correctly.

    • Make sure the Internal Beacon is not resolvable externally.
    • The Internal Beacon URL cannot be the Single FQDN. It must be different.
    • Ideally, the Internal Beacon should be a new DNS name that resolves to a StoreFront Load Balancing VIP.
    • If the internal beacon is https, then the certificate must match the internal beacon DNS name. However, http URLs also work.
    • See CTX218708 How to Configure Internal Beacon for Single FQDN on StoreFront.
  5. Make sure the DMZ NetScaler resolves the Single FQDN to the internal StoreFront Load Balancing VIP. You typically add internal DNS servers to the NetScaler. Or you can create a local Address Record on NetScaler for the Single FQDN.

  6. In the NetScaler Gateway Session Profiles, on the Published Applications tab, set the Web Interface Address, and the Account Services Address to the Single FQDN.


  7. That’s all you need to implement Single FQDN. If you made changes to an existing StoreFront deployment, then you might have to remove accounts from Receiver, and re-add the account.

If you need email-based discovery, then here’s an example configuration for ICA Proxy NetScaler Gateway

DNS:

  • Sample DNS names:
    • Single FQDN = storefront.corp.com
    • Callback FQDN = callback.corp.com
    • Internal Beacon FQDN = internalbeacon.corp.com
  • External DNS:
    • storefront.corp.com resolves to a public IP, which is NAT’d to a NetScaler Gateway VIP on a DMZ NetScaler.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com. Create this SRV record in every email suffix DNS zone.
  • Internal DNS:
    • storefront.corp.com resolves to the Load Balancing VIP for StoreFront
    • callback.corp.com resolves to a NetScaler Gateway VIP on the same NetScaler that authenticated the user. Usually only needed for SmartAccess and/or SAML.
    • For the internal beacon, FQDN of any internal web server. Make sure this name is not resolvable externally.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com. Create this SRV record in every email suffix DNS zone.

Certificates:

  • External, publicly-signed certificate for NetScaler Gateway:
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com. If you more than one email suffix, then wildcard will not work.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • Callback.corp.com – for callback URL. Only accessed from internal.
        • Or you can create a separate internally-facing Gateway vServer for callback with a separate certificate.
      • If email-based discovery, discoverReceiver.email.suffix for each email suffix. If you have multiple email suffixes, you’ll need multiple SAN Names.
  • Internal certificate for StoreFront Load Balancing:
    • Publicly-signed certificate is recommended, especially for mobile devices and thin clients.
    • Since you have the same DNS name for internal and external, you can use the external certificate for internal StoreFront.
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com. If you have more than one email suffix, then wildcard will not work.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • If email-based discovery, discoverReceiver.email.suffix for every email suffix. If you have multiple email suffixes, then you will have multiple SAN names.

StoreFront Configuration:

  • Base URL = https://storefront.corp.com
  • Internal beacon = https://internalbeacon.corp.com. Make sure it’s not resolvable externally.
  • Gateway object:
    • Gateway URL = https://storefront.corp.com
    • Callback URL = https://callback.corp.com

Receiver for Web session policy:

  • Policy expression = REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver
  • Client Experience tab:
    • Clientless Access = Allow or Off
    • Plug-in Type = Java
    • Single Sign-on to Web Applications = checked
  • Security tab:
    • Default authorization = ALLOW
  • Published Applications tab:
    • ICA Proxy = On
    • Web Interface address = https://storefront.corp.com/Citrix/StoreWeb
    • Single Sign-on Domain = Corp

Receiver Self-Service session policy:

  • Policy expression = REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
  • Client Experience tab:
    • Clientless Access = Allow or Off
    • Plug-in Type = Java
    • Single Sign-on to Web Applications = checked
  • Security tab:
    • Default authorization = ALLOW
  • Published Applications tab:
    • ICA Proxy = On
    • Web Interface address = https://storefront.corp.com
    • Single Sign-on Domain = Corp
    • Account Services address = https://storefront.corp.com

Multiple Datacenters / Farms

Multi-datacenter NetScaler Gateway and StoreFront Design

HTTP vs ICA

There are two connections from every Citrix client:

  • HTTP (SSL required) – goes to StoreFront
    • HTTP is usually proxied through NetScaler load balancing
    • If external, HTTP is proxied through NetScaler Gateway, which proxies it through NetScaler load balancing.
    • HTTP traffic is initiated by either a web browser, or by Receiver Self-Service
  • ICA (SSL optional) – goes to Virtual Delivery Agent
    • ICA can go direct (internal) to a VDA
    • Or ICA can be proxied through NetScaler Gateway ICA Proxy
    • ICA traffic is handled by Receiver’s ICA engine – either locally installed Receiver, or HTML5 Receiver

The FQDN for the HTTP connection can be the same or different than the FQDN for the ICA connection.

The HTTP connection is easily handled by GSLB, HTTP/SSL load balancing, etc.

  1. DNS name – Users connect to a DNS name that resolves to StoreFront and/or NetScaler Gateway.
    1. StoreFront is usually proxied through NetScaler Load Balancing.
    2. If NetScaler Gateway, the HTTP connection is proxied to StoreFront, usually through Load Balancing.
  2. Separate VIP per datacenter – For multiple datacenters, each datacenter has its own StoreFront and/or NetScaler Gateway VIP.
  3. GSLB resolves the DNS name to one of the datacenter VIPs.
    1. This can be active/active, or active/passive.
  4. Proximity and persistence – For active/active, since StoreFront traffic (HTTP) is so minimal, it usually doesn’t matter which datacenter is selected. But you can optionally enable one of the Proximity GSLB load balancing algorithms so the closest datacenter is selected.
    1. Enable one of the GSLB Service cookie-based persistence methods. Connection Proxy is the easiest to configure.

The ICA connection is dictated by StoreFront.

  1. .ica file – When a user clicks an icon in StoreFront, StoreFront generates an .ica file containing an address.
    1. If the user is internal, then the .ica file usually contains the private IP address of the Virtual Delivery Agent. Receiver connects directly to the VDA’s private IP.
    2. If the user is connecting through NetScaler Gateway, or if HDX Optimal Routing is enabled, then the .ica file usually contains the FQDN of a NetScaler Gateway that can proxy the ICA connection.
  2. Receiver engine for ICA protocol – The StoreFront provided .ica file is given to a Receiver engine. Receiver engine (locally installed Receiver, or HTML5 Receiver), uses ICA protocol to connect to the address contained inside the .ica file.
  3. One public IP – For external users, an advantage of NetScaler Gateway is that you only have to expose one public IP address per datacenter no matter how many VDAs you have.
  4. FQDN for Gateway – For NetScaler Gateway, StoreFront inserts a FQDN into the .ica file. This FQDN can be one of the following:
    1. Active/active GSLB
    2. Datacenter-specific – If you have two datacenters, each datacenter has a unique FQDN that resolves to a specific NetScaler Gateway VIP in a specific datacenter. GSLB active/passive handles failover if the datacenter-specific VIP is down.
  5. ICA Routing – ICA traffic is heavier and more latency sensitive than StoreFront. Thus you typically want to control which datacenter is used for the ICA connection. There are two common designs:
    1. Proxy ICA traffic through a NetScaler Gateway that’s in the same datacenter as the VDA.
    2. Proxy ICA traffic through the NetScaler Gateway that’s closest to the user. The idea here is that back haul WAN connections are faster than Internet connection to a remote datacenter.
  6. HDX Optimal Routing – For proxying ICA through NetScaler Gateway in the same datacenter as the VDA, StoreFront has two methods for identifying the NetScaler Gateway that’s closest to the VDA:
    1. Different XenDesktop site/farm in each datacenter. If a VDA is launched from a particular site/farm, then provide the NetScaler Gateway FQDN that is associated with that site/farm. This is configured using HDX Optimal Routing.
    2. Different XenDesktop zone per datacenter. If the VDA is launched from a particular zone, then provide the NetScaler Gateway FQDN that is associated with that zone. This is configured using HDX Optimal Routing.
  7. Proximity and Persistence – For proxying ICA through a NetScaler Gateway that is closest to the user, StoreFront returns an FQDN that is GSLB Active/Active load balanced using a Proximity load balancing algorithm.
    1. ICA is usually a long-lived TCP connection to the NetScaler Gateway VIP.
    2. You can enable Source IP persistence on the active/active GSLB Virtual Server.
    3. Another method of proximity load balancing ICA is to configure NetScaler to insert a header to StoreFront indicating the XenDesktop zone the user is connecting from. See the GSLB Powered Zone Preference whitepaper.

Internal NetScaler Gateway ICA Proxy? – Internal users typically have direct connectivity to VDA Private IP addresses, so you usually don’t need to use NetScaler Gateway ICA Proxy internally. However, an advantage of using NetScaler Gateway ICA Proxy internally is that now all ICA traffic is going through a NetScaler, which makes it easy to enable AppFlow (HDX Insight) reporting to NetScaler MAS.

  • ICA Proxy through NetScaler Gateway wraps ICA traffic in SSL, increasing the packet size.
  • SSL-Encrypted ICA packets cannot be optimized by normal WAN optimization products.

StoreFront and Multiple Sites/Farms

A XenDesktop Site/Farm is a collection of XenDesktop Controllers that share a single Site SQL Database. Multiple XenDesktop Sites/Farms implies multiple Site SQL databases, each configured separately. Note: farm is the old name for XenDesktop Site.

  • If you stretch a single XenDesktop Site/Farm across datacenters, then you have to deal with replication and recovery of the single SQL database.
  • XenDesktop Zones and Local Host Cache make it more feasible to stretch a farm. See XenDesktop Site Failover – how do you do it? at CUGC for an excellent discussion on multi-datacenter zone design.
  • VDAs can only register with one XenDesktop Site.

Multiple XenDesktop Sites/Farms – StoreFront can enumerate icons from multiple XenDesktop Sites/Farms. If there are identical icons in multiple farms, then the icons can be aggregated so that only a single icon is displayed to the user. When the user clicks the icon, StoreFront then needs to select a site/farm.

  • Sites/Farms can be prioritized (active/passive) for different Active Directory groups. This allows you to specify a “home” site for specific users. Typically you set the preferred site/farm to be in the same datacenter that contains the user’s home directory and roaming profile.
  • Or sites/farms can be active/active load balanced. This works best for applications that have synchronized active/active back-end data.

Icon aggregation – There are two methods of configuring icon aggregation in StoreFront:

  • StoreFront Console GUI – The most common multi-site/farm configurations can be done in the StoreFront Console GUI, including configuration of “Home Sites” (different AD groups prioritizing different sites/farms).
  • XML files – for more complex multi-site configurations. See Citrix Docs – Set up highly available multi-site store configurations

Note: if you have existing subscriptions/favorites, then enabling icon aggregation will cause the existing subscriptions to be ignored. You can migrate the existing subscriptions by exporting, modifying, and importing. See Subscriptions Missing after Enabling Aggregation at Citrix Discussions.

StoreFront in Multiple Datacenters

Stretching – Citrix does not support stretching a single StoreFront Server Group across multiple datacenters. Each datacenter is expected be a different StoreFront Server Group.

  • Citrix provides scaling guidance for up to 6 servers in a single StoreFront Server Group.

Management – Each StoreFront Server Group is managed separately.

  • Subscriptions/Favorites can be replicated between the two StoreFront Sever Groups.

Receiver Roaming – When Citrix Receiver switches between different StoreFront Server Groups in multiple datacenters, it’s possible for each datacenter to be treated as a separate Store, causing multiple Store entries in Receiver. This can be prevented by ensuring the following configurations are identical in both datacenters. Source = Juan Zevallos at Citrix Discussions:

  • Match the SRID – in StoreFront, if you use the same Base URL in the 2 separate installations, then the SRID should end up being identical. If the Base URL is changed after the initial setup, the SRID doesn’t change. The SRID can be safely edited in the \inetpub\wwwroot\Citrix\Roaming\web.config file. It will be replicated into the discovery servicerecord entry in the Store web.config, which can be edited as well, or refreshed from the admin console by going into Remote Access setup for the store, and hitting OK. Make sure to propagate changes to other servers in the group.
  • Match the Base URL
  • Match the Delivery Controller names under “Manage Delivery Controllers” – The XML brokers can be different, but the actual name of the Delivery Controller/Farms must be identical.

Typical Multi-Datacenter Configuration

Here’s a typical active/active XenApp/XenDesktop configuration using separate sites/farms in each datacenter. Another option is zones.

  • XenDesktop Sites/Farms: Separate XenApp/XenDesktop sites/farms in each datacenter.
    • The Controllers for each site/farm point to a SQL database in the local datacenter. There usually is no need to enable SQL failover across datacenters.
    • Each datacenter is managed separately. But Citrix Policies in a GPO can apply to both sites/farms.
    • An advantage of separate sites/farms is that you can upgrade one datacenter before upgrading the other.
  • StoreFront Server Groups: Separate StoreFront Server Groups in each datacenter.
    • Citrix doesn’t support stretching a single StoreFront Server Group across a WAN link.
    • Each Server Group is configured identically. You can export the config from one Server Group, and import it to the other. Or configure each of them separately, but identically. Identical means: same Base URL, same farms (Manage Delivery Controllers), same SRID, same Gateways, and same Beacons.
    • If subscriptions/favorites are enabled, use PowerShell commands to configure subscription replication between the two Server Groups.
  • StoreFront Load Balancing: Separate StoreFront load balancing VIP in each datacenter
    • Each Load Balancing VIP can be active/passive. Active = the StoreFront servers in the local datacenter. Passive = the StoreFront servers in the remote datacenter.
      • Create two Load Balancing vServers: one for local StoreFront, one for remote StoreFront. In the Active (local) Load Balancing vServer, add the Protection section, and configure the Backup (remote) vServer.
      • When the active StoreFront is down, NetScaler Gateway will use StoreFront in the remote datacenter. However, the remote datacenter has its own NetScaler Gateway, thus there will be two different NetScaler Gateways connecting to one StoreFront Server Group. If you use SmartAccess or SAML and need the Callback URL, then you’ll need a special StoreFront configuration to handle the Callback URL from multiple Gateway appliances.
  • Icon aggregation: Configure StoreFront to aggregate icons from the two farms.
    • Use AD groups to specify a user’s home datacenter, which contains the user’s roaming profile and home directory.
    • Configure farm priority based on AD groups. For an aggregated icon, the AD group and farm priority determines which farm the icon is launched from.
  • External NetScaler Gateways: Externally-accessible NetScaler Gateway ICA Proxy VIPs in both datacenters.
    • The main NetScaler Gateway DNS name is active/active GSLB. For example: citrix.company.com)
    • Each datacenter has a datacenter-specific GSLB active/passive DNS name for NetScaler Gateway. For example: citrix-a.company.com, and citrix-b.company.com
    • The Gateway SSL certificate needs to match all three DNS names: the main active/active DNS name, and the two datacenter-specific active/passive DNS names.
  • Internal NetScaler Gateways: Internally-accessible NetScaler Gateway ICA Proxy VIPs in both datacenters for AppFlow reporting.
    • For AppFlow/Insight reporting, NetScaler Gateway ICA Proxy is typically used internally too. If you don’t need AppFlow, then you don’t need internal NetScaler Gateway.
    • To handle Single Sign-on from Receiver, internal Receivers will connect HTTP directly to StoreFront Load Balancing instead of proxied through NetScaler Gateway.
      • This implies that you have separate DNS names for StoreFront and NetScaler Gateway.
    • HDX Optimal Routing will force the ICA connection to go through NetScaler Gateway instead of directly to the VDA.
    • HDX Optimal Routing is a global setting that applies to both internal and external users. The DNS name used by HDX Optimal Routing must be valid for both internal and external. If this is not the case, then you can deploy separate StoreFront servers for internal and external.
    • DNS:
      • The main NetScaler Gateway DNS name is active/active GSLB. For example: citrix.company.com.
      • Each datacenter has a datacenter-specific GSLB active/passive DNS name for NetScaler Gateway. For example: citrix-a.company.com, and citrix-b.company.com
      • The Gateway SSL certificate needs to match all three DNS names – the main active/active DNS name, and the two datacenter-specific active/passive DNS names.
  • Main StoreFront and Gateway FQDNs: separate FQDNs for StoreFront and NetScaler Gateway.
    • Externally,  citrix.company.com resolves to a NetScaler Gateway VIP.
    • Internally,  storefront.company.com resolves to a StoreFront Load balancing VIP.
    • Single FQDN usually causes more problems than it’s worth. If you don’t do Single FQDN, then you can hide the StoreFront DNS name by pushing the store configuration to Receiver using Group Policy. Browser users would only need to know the NetScaler Gateway DNS name.
  • DNS Delegation for GSLB: multiple DNS names are delegated from internal DNS and public DNS to NetScaler ADNS (internal and external) for GSLB.
    • Internal GSLB and public GSLB need to resolve citrix.company.com differently. Public GSLB should resolve it to public IPs. Internal GSLB should resolve it to internal IPs.
    • Combining internal and public GSLB on the same NetScaler is not recommended. Public GSLB should be handled by DMZ NetScaler appliances. Internal GSLB should be handled by Internal NetScaler appliances.
    • If you only have one NetScaler appliance for both internal and public, then see One appliance resolving a single DNS name differently for internal and public at GSLB Planning.
    • citrix.company.com is configured as Active/Active GSLB with Proximity Load Balancing, and Site Persistence equal or greater than StoreFront RfWeb timeout.
    • citrix-a.company.com is configured as Active/Passive GSLB with Datacenter A as the Active service.
    • citrix-b.company.com is configured as Active/Passive GSLB with Datacenter B as the Active service.
    • storefront.company.com is configured as Active/Active GSLB with Proximity Load Balancing, and Site Persistence equal or greater than StoreFront RfWeb timeout.
  • HDX Optimal Routing: Use HDX Optimal Routing to route ICA traffic through the NetScaler Gateway that is closest to the destination farm. This requires datacenter-specific DNS names (e.g. citrix-a.company.com, citrix-b.company.com)
    • You can use one of these DNS names to connect to StoreFront in a specific datacenter, which is helpful for testing.
  • STAs: each StoreFront Server Group uses STAs in the local datacenter. Since ICA Traffic could end up on either NetScaler, all STAs must be added to all NetScaler Gateways.
  • Beacons: the internal beacon is critical. If the internal beacon is down then Receiver Self-service won’t be able to determine if the client device is internal or not. GSLB can be used for the internal beacon DNS name.
  • Roaming Profiles: If you are running XenApp / XenDesktop in multiple datacenters, you must design roaming profiles and home directories correctly.

Icon Aggregation and Home Sites

To configure icon aggregation using the StoreFront Console:

  1. In StoreFront Console, go to Stores.
  2. In the middle, right-click your Store, and click Manage Delivery Controllers.
  3. Add multiple sites/farms. Typically, each datacenter is a separate farm.
  4. After adding multiple farms, the Configure button becomes available. Click it.
  5. If you are publishing identical resources from multiple farms, click the link to Aggregate resources.
  6. In the Aggregate Resources dialog box, do the following:
    1. Select the farms with identical resources that you want to aggregate.
    2. Notice the checkboxes on the bottom. If your goal is to configure home sites, then make sure you uncheck Load balance resources across controllers.
    3. Click the Aggregate button to move them up to the Aggregated section.
    4. Note: if you have existing subscriptions/favorites, then enabling icon aggregation will cause the existing subscriptions to be ignored. You can migrate the existing subscriptions/favorites by exporting, modifying, and importing. See Subscriptions Missing after Enabling Aggregation at Citrix Discussions.
    5. Click OK when done.
  7. Back in the Configure User Mapping and Multi-Site Aggregation window, click Map users to controllers.
  8. In the Create User Mapping wizard, do the following:
    1. If you want the same farm failover order (active/passive) or farm load balancing settings for everyone, then leave the User Groups page set to Everyone. Or if you intend to have different home sites for different users, add a user group that contains the users that will be homed to a particular datacenter. You can run this wizard multiple times to specify different home sites for different user groups. Click Next.
    2. In the Controllers page, click Add.
    3. Select the farms that these users will have access to, and click OK.
    4. If you configured farm aggregation without load balancing, then use the up and down arrow buttons to put the active site/farm for this group of users on top. The lower priority sites will only be accessed if the primary site is down. You can run this wizard multiple times to specify different active sites for different users.
    5. If farm aggregation is configured for load balancing, then there are no arrows to prioritize the farms.
    6. Click Create.
  9. You can click Add to add more user mappings. If you add multiple user groups, you can assign different primary sites/farms to each Active Directory group. This is how you configure “home sites”. Click OK twice when done.

Shaun Ritchie Citrix StoreFront High Availability and Aggregation – A dual site Active Active design has a sample multi-site configuration using XML Notepad and explains how to use the Primary and Secondary keywords to override farm priority order.

Citrix Blogs StoreFront Multi-Site Settings: Some Examples has example XML configurations for various multi-datacenter Load Balancing and failover scenarios.

HDX Optimal Routing

The Optimal Gateway feature lets you control the NetScaler Gateway used for ICA connections. Here are some scenarios where this would be useful:

  • Multi-site Load Balancing. If the icon selected by the user is published from XenApp/XenDesktop in Datacenter A, then you probably want the ICA connection to go through a NetScaler Gateway Virtual Server in Datacenter A.
    • If the main DNS name for accessing NetScaler Gateway is GSLB load balanced across datacenters, then you need additional datacenter-specific DNS names so you can control which datacenter the ICA connection goes through.
    • Note: Optimal Gateway is configured at the farm/site level, or zone level.
  • NetScaler Gateway for internal connections (AppFlow). If you want to force internal ICA connections to go through NetScaler Gateway so AppFlow data can be sent to NetScaler MAS, then you can do that using HDX Optimal Gateway, even if the user originally connected directly to the StoreFront server. See CTX200129 How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront for more information.
  • The NetScaler Gateway Virtual Server requires user certificates. If ICA traffic goes through a NetScaler Gateway Virtual Server that requires user certificates (e.g. Smart Card), then each session launch will result in a PIN prompt. To prevent these extra prompts, build a separate NetScaler Gateway Virtual Server that doesn’t have user certificates as Mandatory. Use Optimal Gateway to force ICA connections through the other NetScaler Gateway Virtual Server. Note: SmartAccess Callback URL also cannot use a NetScaler Gateway Virtual Server where client certificates are set to Mandatory, so the extra NetScaler Gateway Virtual Server would be useful for that scenario too.

HDX Optimal Gateway can be configured in the StoreFront Console:

  1. Right-click the Stores node, and click Manage NetScaler Gateways.
  2. Add more NetScaler Gateways: one for each datacenter.
  3. When adding a Gateway, you can designate a Usage or role.
    1. The Gateway accessed through the active/active GSLB DNS name must be set to Authentication and HDX routing.
    2. The Gateways for Optimal Routing could be set to HDX routing only. Or if test users will use these datacenter-specific DNS names to connect to Gateways in specific datacenters, leave them set to Authentication and HDX routing. There’s no harm in leaving all of the Gateways set to Authentication and HDX routing.
  4. Go to Stores, right-click your store in the middle pane, and click Configure Store Settings.
  5. Go to the Optimal HDX Routing page.
  6. Highlight one of the datacenter-specific Gateways, and click Manage Delivery Controllers.
  7. Select the farms that should use this gateway, and click OK.
  8. Repeat for the other datacenter-specific Gateways.
  9. The Gateway for the active/active GSLB-enabled DNS name doesn’t need any farms associated with it.
  10. If you want to use NetScaler Gateway internally for AppFlow reporting, then uncheck the External only checkbox.

    1. Another option for Optimal Gateway selection is zones. In XenApp/XenDesktop 7.7 and newer, you can stretch a farm across datacenters (zones), and use a different Gateway for each zone. Highlight a Gateway. Click Manage Zones, and add the zone name. This assumes the zone name has also been specified in the Manage Delivery Controllers dialog box > Advanced Settings.
  11. Click OK when done.
  12. In summary, users will connect to the active/active GSLB-enabled Gateway and login. After clicking an icon, HDX will be routed through one of the datacenter-specific Gateways based on the farm the icon was launched from.

Multiple Gateways (GSLB) to One StoreFront Server Group

This section applies to SmartAccess, or SAML, and the Callback URL. If you don’t need the Callback URL for SmartAccess or SAML, then skip this section.

The Callback URL must go to the same NetScaler appliance that authenticated the user. If you have multiple NetScaler appliance pairs communicating with a single StoreFront server, then StoreFront needs to identify which NetScaler appliance pair the request came from, so it can perform a callback to that particular appliance pair.

If each of the NetScaler Gateways uses the same DNS name (GSLB), then you can’t use the DNS name to distinguish one appliance from the other. Instead, StoreFront can use the Gateway VIP to distinguish appliances so the callback goes to the correct appliance.

  1. Create datacenter-specific callback DNS names. For example: callback-a.corp.com and callback-b.corp.com.
  2. The datacenter-specific callback DNS name must match the certificate on the NetScaler Gateway Virtual Server that is handling the callback. Here are some options to handle the certificate requirement:
    • On the main NetScaler Gateway Virtual Server, assign a wildcard certificate that matches both the GSLB name, and the datacenter-specific callback name.
    • On the main NetScaler Gateway Virtual Server, assign an SSL certificate with Subject Alternative Names for both the GSLB name, and the datacenter-specific callback name.
    • Create an additional NetScaler Gateway Virtual Server on the appliance. Bind a certificate that matches the datacenter-specific callback name.
  3. In the StoreFront console, create multiple NetScaler Gateway appliances, one for each datacenter.
  4. Give each of the gateway objects unique Display names. You can’t have two Gateway objects with the same display name.
  5. Enter the same NetScaler Gateway URL in all of the gateway appliances.

  6. In the Authentication Settings page, in the VServer IP address field, enter the Gateway VIP for this particular appliance pair. StoreFront will use this VIP to distinguish one NetScaler appliance from another.
    • When users use HTTP to connect to a NetScaler Gateway for authentication and icon enumeration, when NetScaler Gateway communicates with StoreFront, NetScaler Gateway inserts its VIP into a HTTP Header field named X-Citrix-Via-VIP. StoreFront reads this VIP header, and compares it to the Gateway objects bound to the Store. If there’s a match, StoreFront uses the Callback URL configured for that Gateway object.
  7. The callback URL must be unique for each NetScaler appliance pair (e.g. callback-a.corp.com). The callback URL must resolve to a NetScaler Gateway VIP on the same appliance pair that authenticated the user.

  8. When enabling Remote Access on the store, select both Gateway appliances. Select one as the default appliance. It shouldn’t matter which one is default.

Related Pages

StoreFront 3.5 through 3.13 – Basic Configuration

Last Modified: Jan 4, 2018 @ 5:28 pm

Navigation

This article applies to StoreFront versions 3.5, 3.6, 3.7, 3.8, 3.9, 3.11, 3.12.1000, and 3.13.

💡 = Recently Updated

Changelog

StoreFront Versions

The most recent StoreFront Current Release is version 3.13. Current Releases are only supported for 6 months from release date and are expected to be upgraded every 3-6 months.

The most recent StoreFront Long Term Service Release (LTSR) is version 3.12.1000. LTSR versions are supported for 5 years from release date. Cumulative Updates are released periodically.

StoreFront Installation / Upgrade

The XenDesktop Delivery Controller Metainstaller has an option for installing StoreFront on the Delivery Controller machine. Or you can install StoreFront on separate dedicated servers.

  • If StoreFront will pull icons from multiple XenDesktop sites/farms, then StoreFront should be installed on its own machines.
  • For small environments, it might be OK to install StoreFront on the Delivery Controller machines. But usually they are separate machines.

Citrix Blog Post StoreFront 3.0 Scalability recommends StoreFront servers to be sized with 4 vCPU and 8 GB RAM.

  1. If upgrading do the following before beginning the upgrade:
    1. Other Users – Use Task Manager > Users tab to logoff any other user currently logged into the machine.
    2. Export the StoreFront configuration so you can restore it if something goes wrong.
    3. Stop the World Wide Web Publishing Service.
    4. Stop all StoreFront services.
    5. Close all PowerShell and StoreFront consoles.
    6. Citrix CTX226419 StoreFront upgrade fails to keep the setting in default ICA file. Take a backup of default.ica and usernamepassword.tfrm from C:\inetpub\wwwroot\Citrix\StoreName\App_Data. After upgrading StoreFront, replace the new default.ica and usernamepassword.tfrm with the old default.ica and usernamepassword.tfrm files to ensure you retain the old settings.
    7. If the Citrix SCOM Agent for StoreFront is installed, stop the Citrix MPSF Agent service. Citrix CTX220935 Cannot Perform a StoreFront Upgrade if Citrix SCOM Management Pack Agent Service is Running.
    8. See Patrick van den Born Avoid 1603 errors when upgrading Citrix StoreFront 2.x to Citrix StoreFront 3.5
  2. Go to the downloaded Citrix StoreFront and run CitrixStoreFront-x64.exe.

    1. You can find the standalone StoreFront installer on the XenApp/XenDesktop ISO under the \x64\StoreFront folder.
    2. Or you can install from the XenApp/XenDesktop ISO by running AutoSelect.exe.
    3. It’s on the bottom left of the splash screen.

  3. If installing from the standalone installer, in the License Agreement page, check the box next to I accept the terms, and click Next.
  4. In the Review prerequisites page, click Next.
  5. In the Ready to install page, click Install.
  6. In the Successfully installed StoreFront page, click Finish.

If this is a new install, skip to the Initial Configuration.

After upgrading from StoreFront 2.6 or older, do the following to enable the Receiver X1 theme:

  1. In the StoreFront Console, on the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Receiver Experience page select Disable classic experience.
  5. Once classic experience is disabled, you can now make changes on the Customize Appearance and Featured App Groups pages. Click OK and Close when done.

  6. Go to Stores. In the middle, right-click your Store, and click Configure Unified Experience.
  7. Check the box next to Set the unified Receiver experience as the default for this store, and click OK.
  8. When you propagate changes, the default web page might not be replicated to the other nodes. Copy C:\inetpub\wwwroot\web.config manually to each node.

If you are upgrading to StoreFront 3.9 or newer, do the following to add SAML Authentication as an option. This feature lets you perform SAML against StoreFront without needing NetScaler Gateway. If you did a fresh deployment of 3.9 or newer, then SAML is already added.

  1. Right-click your Store, and click Manage Authentication Methods.
  2. On the bottom, click the Advanced button, and click Install or uninstall authentication methods.
  3. Check the box next to SAML Authentication, and click OK.
  4. If you don’t want to configure SAML at this time, then uncheck the authentication method. See the Federated Authentication Service article for SAML details.

Initial Configuration

In StoreFront 3.8 and newer, you can create multiple stores in different IIS websites. This functionality is not exposed in the GUI and instead the entire StoreFront configuration must be performed using PowerShell. See Citrix Blog Post StoreFront 3.8 is Available NOW! for sample PowerShell commands to create the stores.

You can also use PowerShell to create a store and configure it as detailed at CTX206009 How to configure a Store via Powershell.

If this is a new deployment of StoreFront, do the following to perform the initial configuration:

  1. In PowerShell, run Set-ExecutionPolicy RemoteSigned.
  2. The management console should launch automatically. If not, launch Citrix StoreFront from the Start Menu.
  3. In the middle, click Create a new deployment.
  4. In the Base URL page, if you installed an SSL certificate on the StoreFront server, then the Hostname should already be filled in. For now, you can leave it set to the server name and then change it later once you setup SSL and load balancing. Click Next.
  5. In the Getting Started page, click Next.
  6. In the Store Name page, enter a name for the store. Note: the name entered here is part of the URL path.
  7. Check the box next to Set this Receiver for Web site as IIS default and click Next.
  8. In the Delivery Controllers page, click Add.
  9. Enter a descriptive name for the XenApp/XenDesktop farm. This name does not need to match the actual farm name. (If StoreFront 3.5, don’t put spaces or periods in the farm name)
  10. Change the Type to XenDesktop.
  11. Add the two XenDesktop Controllers. Change the Transport Type to HTTP. Click OK.
  12. If you have multiple XenDesktop sites/farms, feel free to add them now. Or you can add older XenApp farms. (If StoreFront 3.5, don’t put spaces or periods in the farm name) Click Next when done.
  13. In the Remote Access page, don’t check the box, and click Next. You can set this up later.
  14. In the Authentication Methods page, check the boxes next to Domain pass-through and Pass-through from NetScaler Gateway. Click Next. Note: if you want Domain pass-through for browser users, you also need to enable it for Receiver for Web as detailed later in this topic.
  15. In the XenApp Services URL page, click Create.
  16. In the Summary page, click Finish.

Second StoreFront Server

After the server group is created, NT SERVICE\CitrixConfigurationReplication and NT SERVICE\CitrixClusterService must remain in the Administrators group on both StoreFront servers or propagation will fail.

  1. Install StoreFront on the second server.
  2. Create/Import the SSL certificate, and bind it to the Default Web Site.
  3. Login to the first StoreFront server. In the StoreFront management console, right-click Server Group, and click Add Server.
  4. Copy the Authorization code. Note: the Please wait message means it is waiting on you to add the 2nd server. You don’t actually have to wait.
  5. Login to the second StoreFront server and launch the management console. In the middle, click Join existing server group.
  6. In the Join Server Group page, enter the name of the first StoreFront server and enter the Authorization code copied earlier. Click Join.
  7. Then click OK.
  8. Go back to the first server. Click OK.
  9. Notice this message. It is good advice.
  10. All changes made on one StoreFront server must be manually propagated to the other StoreFront server. You do that by right-clicking Server Group, and clicking Propagate Changes.
  11. When you propagate changes, the default web page might not be replicated to the other nodes. Copy C:\inetpub\wwwroot\web.config manually to each node.

Customer Experience Improvement Program

StoreFront 3.9 and newer enable Customer Experience Improvement Program (CEIP) by default. To disable it, create the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Telemetry\CEIP\Enabled (DWORD) and set it to 0 (zero). Also see CEIP at Install, set up, upgrade, and uninstall at Citrix Docs.

See http://www.carlstalhood.com/delivery-controller-7-15-ltsr-and-licensing/#ceip for additional places where CEIP is enabled.

Store Name – Rename

If you installed StoreFront on your Delivery Controller, it will have a default store named Store. If you don’t like the default Store Name (/Citrix/Store) then you will need to remove the store and re-add it.

Note: Some at Citrix Discussions (A protocol error occured while communicating with the Authentication Service) have reported authentication issues after following this procedure. It’s probably cleaner to uninstall StoreFront and reinstall it.

  1. In the StoreFront console, on the left, click Stores.
  2. Right-click your store, and click Remove Store.
  3. Click Yes.
  4. On the left, right-click Stores, and click Create Store.
  5. In the Getting Started page, click Next.
  6. In the Store Name page, enter a name for the store. Note: the name entered here is part of the URL path.
  7. Check the box next to Set this Receiver for Web site as IIS default and click Next.
  8. In the Delivery Controllers page, click Add.
  9. Enter a descriptive name for the XenApp/XenDesktop farm. This name does not need to match the actual farm name. (If StoreFront 3.5, don’t put spaces or periods in the farm name)
  10. Change the Type to XenDesktop.
  11. Add the two XenDesktop Controllers.
  12. Change the Transport Type to HTTP. Click OK.
  13. If you have multiple XenDesktop farms, feel free to add them now. Or you can add older XenApp farms. (If StoreFront 3.5, don’t put spaces or periods in the farm name) Or later, you can add farms in Store > Manage Delivery Controllers. Click Next when done.
  14. In the Remote Access page, don’t check the box and click Next. You can set this up later.
  15. In the Authentication Methods page, check the boxes next to Domain pass-through and Pass-through from NetScaler Gateway. Click Next.
  16. In the XenApp Services URL page, click Create.
  17. In the Created Successfully page, click Finish.

SSL Certificate

StoreFront requires SSL. You will save yourself much heartache if you install valid, trusted certificates. There are two options for StoreFront SSL.

  • SSL Offload: Use NetScaler to do SSL Offload and load balancing. In this scenario, install the SSL certificate on the load balancer. You can leave the StoreFront servers listening on HTTP and no IIS server certificate. The SSL certificate on the NetScaler must match the DNS name that resolves to the load balancing VIP.
  • SSL End-to-end: Install an SSL certificate on each StoreFront server and bind to IIS. This allows you to use SSL protocol between the load balancer and the StoreFront servers.

If your load balancer cannot terminate SSL, then the StoreFront IIS certificate must match the DNS name that resolves to the load balancing VIP.

For load balancers that can terminate SSL (e.g. NetScaler), the StoreFront IIS server certificate should match the StoreFront server name. If StoreFront is installed on the Delivery Controllers, with server-specific certificates you can later enable HTTPS in the StoreFront Store Delivery Controller configuration.

Another option is to create an SSL certificate with Subject Alternative Names for the load balanced DNS name and each of the StoreFront server FQDNs. Then import this one certificate on all StoreFront servers. Or a wildcard certificate could match all of these names.

In either case, be aware that Email-based discovery in Citrix Receiver requires the certificate to not only match the StoreFront load balanced DNS name but the certificate must also match discoverReceiver.email.suffix for every email domain. Usually the only option to match multiple email domains is with Subject Alternative Names. If you have multiple email suffixes then you will need multiple Subject Alternative Names, each beginning with discoverReceiver. If you don’t plan on implementing email-based discovery, then you don’t have to worry about these discoverReceiver Subject Alternative Names.

If the certificate does not match discoverReceiver.email.suffix, then users will see this message when attempting to use email discovery in Citrix Receiver.

When adding Subject Alternative Names to a certificate, the first Subject Alternative Name should be the same as the Load Balancing FQDN. The remaining Subject Alternative Names should be discoverReceiver.email.suffix for every email domain.

When you view a Subject Alternative Name certificate, on the Details tab, click Subject Alternative Name to verify that all names are listed, including the DNS name that resolves to the load balancing VIP.

There are several methods of creating a certificate for StoreFront.

  • If you are implementing Single FQDN for internal and external users, then the certificate for external NetScaler Gateway can also be used for internal StoreFront. Note: Single FQDN has additional Subject Alternative Name certificate requirements including: Internal Beacon FQDN and Callback FQDN.
  • If you will support non-domain-joined machines (e.g. iPads, thin clients) connecting to your internal StoreFront, then the StoreFront certificate should be signed by a public Certificate Authority. You can use IIS to request the certificate. You can then export the certificate from IIS and import it to NetScaler (for Load Balancing and NetScaler Gateway). Public Certificate Authorities (e.g. GoDaddy, Digicert, etc.) let you enter additional Subject Alternative Names when you purchase the certificate.

  • If all internal machines are domain-joined, then you can use an internal Certificate Authority to create the StoreFront certificate. The Certificates MMC snap-in can be used to create an internal certificate signed by a Microsoft Certificate Authority. The MMC method allows you to specify Subject Alternative Names.

Once the certificate is created or imported, you need to bind it to IIS:

  1. In IIS Manager, right-click the Default Web Site, and click Edit Bindings.
  2. Click Add.
  3. Change the Type to https, and select the SSL certificate. Do NOT put anything in the Host name field. Click OK, and then click Close.

Delivery Controllers – SSL

Delivery Controllers can be SSL enabled by using one of two methods:

Once SSL certificates are installed on the Delivery Controller servers, then you can configure the Store to use SSL when communicating with the Delivery Controllers.

  1. In the StoreFront Console, on the left click Stores.
  2. In the middle, right-click your store, and click Manage Delivery Controllers.
  3. Highlight the deployment and click Edit.
  4. The Servers list must contain FQDNs that match the certificates installed on those servers.
  5. Change the Transport type to HTTPS.
  6. Click OK twice.

Socket Pooling

Socket pooling is disabled by default in stores. When socket pooling is enabled, StoreFront maintains a pool of sockets, rather than creating a socket each time one is needed and returning it to the operating system when the connection is closed. Enabling socket pooling enhances performance, particularly for Secure Sockets Layer (SSL) connections. To enable socket pooling:

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Configure Store Settings.
  3. On the Advanced Settings page, check the box for Enable socket pooling.

HOSTS File

Edit the HOSTS file (C:\Windows\System32\Drivers\Etc\HOSTS) on each StoreFront server with the following entries:

  • StoreFront Load Balancing FQDN (e.g. storefront.corp.com) = Load Balancing VIP in the local datacenter.
  • NetScaler Gateway Callback FQDN (e.g. callback.corp.com) = NetScaler Gateway VIP in the local datacenter.

Base URL – Change

  1. Configure load balancing of the StoreFront servers, including SSL certificate.
  2. In the Citrix StoreFront console, right-click Server Group, and click Change Base URL.
  3. Enter the StoreFront Load Balancing FQDN as the new Base URL in https://storefront.corp.com format. Note: Receiver requires that the Base URL is https. It won’t accept http. Click OK.
    Note: if you want the StoreFront Base URL to be the same as your Gateway FQDN, then see the Single FQDN instructions.

If the Base URL is https, but you don’t have certificates installed on your StoreFront servers (aka SSL Offload), then you’ll need to do the following:

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Advanced Settings page, change Enable loopback communication to OnUsingHttp. Click OK, and then click Close.

Default Web Page

After changing the Base URL, you’ll need to update the IIS Default Website.

  1. On the left, right-click Stores, and click Set Default Website.
  2. Check the box next to Set a Receiver for Web site as the default page in IIS, and click OK.
  3. Click Yes to overwrite.
  4. If you go to C:\inetpub\wwwroot and edit the file web.config, you’ll see the redirect.

Authentication Configuration

  1. In the Citrix StoreFront console, on the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Authentication Methods.
  3. Check the boxes next to Domain pass-through and Pass-through from NetScaler Gateway.
  4. If you intend to enable pass-through authentication from Receiver Self-Service or from Receiver for Web, go to a XenDesktop Controller, and run the command
    Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $True from a Windows PowerShell command prompt. Run asnp citrix.* first. In XenApp 6.5, this is a Citrix Policy > Computer > Trust XML Requests.
  5. Click the top gear icon, and then click Configure Trusted Domains.
  6. Select Trusted domains only, click Add, and enter the domain names in DNS format. The DNS suffix is needed if doing userPrincipalName authentication from NetScaler Gateway.
    1. Also see CTX223551 Log on delay when user is not in the same domain as Storefront Server for RPC firewall rules.
  7. Select one of the domains as the default.
  8. If desired, check the box next to Show domains list in logon page. Click OK.
  9. Click the top gear icon, and then click Manage Password Options.
  10. Make your selection, and click OK.
  11. Be careful with password changes. Any time somebody changes their password through StoreFront, a profile will be created for that user on the StoreFront server. Use a tool like delprof2.exe to periodically delete these local profiles.
  12. Or see Citrix Blog Post Delete Local User Profile Folders on StoreFront Servers for a script to delete local profiles.
  13. If you have XenApp/XenDesktop Platinum Edition and installed Self-Service Password Reset, you can integrate SSPR with StoreFront 3.7 or newer by clicking the top gear icon and clicking Configure Account Self-Service. This option is only available if your Base URL is https (encrypted). See the following for detailed implementation guides.
  14. Change the selection to Citrix SSPR, and click Configure.
  15. Check both boxes and enter the URL of the SSPR server using the displayed example (with /MPMService on the end). Click OK three times.
  16. With SSPR enabled, a new Tasks tab lets users enroll with SSPR.
  17. The logon page also has an Account Self-Service link.

  18. If StoreFront is not in the same domain (or trusted domain) as the users, then you can configure StoreFront to delegate authentication to the Delivery Controllers. See XML service-based authentication at Citrix Docs. Note: StoreFront 3.6 and newer can be workgroup members without joining a domain.

Citrix Online (3.11 and older)

This is only configurable in StoreFront 3.5 through 3.11. This feature was removed from StoreFront 3.12.

  1. StoreFront might be configured to add the Citrix Online icons. To remove them, on the left, click the Stores node.
  2. In the middle, right-click your store, and click Configure Store Settings.
  3. On the Citrix Online Integration page, uncheck all three boxes, and click OK. Note: This page is not available in StoreFront 3.12.

Unified Receiver Experience

If you did a clean install of StoreFront 3.5 or newer, then the newer UI will already be enabled, but Unified Experience might not be. If you upgraded from a StoreFront 2.6 or older, then you can disable the Classic UI to enable the newer UI.

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Receiver Experience page, select Disable classic experience. Click OK, and click Close.
  5. On the left, click Stores. In the middle, right-click your store, and click Configure Unified Experience.
  6. Check the box next to Set the unified Receiver experience as the default for this store and click OK.

Customize Receiver Appearance

If the Unified Receiver appearance is enabled, you can go to Stores > Manage Receiver for Web Sites > Configure > Customize Appearance to change logos and colors. Additional customization can be performed using the SDK.

You can also Manage Featured App Groups.

These Featured App Groups are displayed at the top of the Apps > All page.

By default, Featured App Groups are displayed with continual horizontal scrolling. This is OK if you have several Featured App Groups but doesn’t look right if you only have one Featured App Group.

Michael Bednarek has posted some code at Citrix Discussions to disable the continuous horizontal scrolling.

If you want to display more than 3 apps per group, see  Michael Bednarek at Modify Receiver for Web site at Citrix Discussions.

Receiver for Web Pass-through Authentication

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Authentication Methods page, if desired, check the box next to Domain pass-through. Click OK.
  5. If the StoreFront URL is in the browser’s Local Intranet zone, then you’ll see a prompt to automatically Log On. This only appears once.

Receiver for HTML5 2.6

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Deploy Citrix Receiver page, change the drop-down to Use Receiver for HTML5 if local Receiver is unavailable.
  5. By default, the HTML5 session opens in a new tab. You can optionally enable Launch applications in the same tab as Receiver for Web. See Configure Citrix Receiver for HTML5 use of browser tabs at Citrix Docs for more information.
  6. Click OK, and then click Close.
  7. Download the latest Receiver for HTML5 (version 2.6.1.4005) and install it on one of the StoreFront servers. It installs silently. When you propagate changes, the Receiver for HTML5 will be copied to the other server.

  8. To see the installed version of HTML5 Receiver, click the Stores node on the left. In the middle pane, in the bottom half, switch to the Receiver for Web Sites tab.
  9. To configure HTML5 Receiver, edit the file “C:\Program Files\Citrix\Receiver StoreFront\HTML5Client\configuration.js”.

    1. Customer Experience Improvement Program (CEIP) is enabled by default. To disable it, search for the ceip section, and change it to false.
  10. In the StoreFront console, on the left, right-click Server Group, and click Propagate Changes.
  11. For VDA 7.15 and older, optionally, install Citrix PDF Printer on the VDAs. The PDF printer is in the Additional Components section of the HTML5 Receiver download page. This PDF printer is only used with Receiver for HTML5, and not with regular Receiver. Note: in VDA 7.16 and newer, the PDF Printer is included with the VDA installation.
  12. Note: as of Receiver for HTML 2.0, it’s no longer necessary to install App Switcher on the VDAs.

Other HTML5 Receiver configurations you can change by editing C:\Program Files\Citrix\Receiver StoreFront\HTML5Client\configuration.js:

  • When printing from HTML5 Receiver to the Citrix PDF Printer, user must click Continue to show the PDF. You can get rid of this prompt in 2.5.1 and newer. In the configuration.js file, scroll down to the line containing printDialog and set it to true.

  • From About Citrix Receiver for Chrome 2.0 at Citrix Docs: The new toolbar can be disabled or customized by editing the file C:\Program Files\Citrix\Receiver StoreFront\HTML5Client\configuration.js.

 

From Michael Bednarek at Citrix Discussions: There was a functionality change between StoreFront 3.0 and StoreFront 3.5 which affects the default client used for iPads. In SF 3.5, we default to using the native Receiver to launch apps on an iPad, as we expect this to be the majority use case. Unfortunately, on an iPad we are unable to actually tell whether you have the Receiver app installed or not, so we can’t do anything more intelligent out of the box.

There are two ways around this. Firstly, any iPad user can change between using native Receiver and using the HTML5 Receiver by going to the dropdown menu after logging on, and choosing “Change Receiver”. This will give you the chance to choose the HTML5 Receiver (“Use light version”) and your choice will be remembered for the next time you log on.

If this is no good, you can use a JavaScript customization to get back the old behaviour and make sure that iPad users default to HTML5.  See the forum post Cannot access citrix apps from ipad using HTML5 receiver post upgrade to SF 3.5 for the Javascript code.

 

If HTML5 Receiver is enabled, Chrome and Edge users have the option of selecting either native or HTML5 by clicking “Change Citrix Receiver“. To enable this option in IE or Firefox, see Emin Huseynov Citrix StoreFront 3.0 and HTML5 client.

 

From About Citrix Receiver for Chrome 1.9 at Citrix Docs: To enable enhanced clipboard support, on every VDA set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\Virtual Clipboard\Additional Formats\HTML Format\Name=”HTML Format”. Create any missing registry keys. This applies to both virtual desktops and Remote Desktop Session Hosts.

 

Citrix Blog Post Receiver for HTML5 and Chrome File Transfer Explained:

  • How to use the toolbar to transfer files
  • Citrix Policy settings to enable/disable file transfer
  • VDA registry settings to control file transfer
  • HTML5Client\Configuration.js settings for client-side configuration
  • How to view HTML5Client log file

Deploy Citrix Receivers

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Deploy Citrix Receiver page, check the box next to Allow users to download HDX engine (plug in).
  5. Change both source drop-downs to Local files on the StoreFront server.
  6. Click both Browse buttons and browse to the downloaded Receiver for Windows (version 4.10.1 (Current Release), version 4.9.1000 (LTSR), or version 4.4.5000 (LTSR)) and Receiver for Mac 12.8.
  7. You can optionally enable Upgrade plug-in at logon.
  8. Click OK when done, and Close when done.
  9. When users connect to Receiver for Web, they will be prompted to install or upgrade. Note: this only applies to Receiver for Web. Receiver Self-Service will not receive this prompt.

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

Receiver for Web Timeout

  1. On the left, click the Stores node.
  2. In the middle, right-click your store, and click Manage Receiver for Web Sites.
  3. Click Configure.
  4. On the Session Settings page, set the Session timeout as desired, and click OK.
  5. If you are using a NetScaler, you will need to change the Global Session Timeout located at NetScaler Gateway => Global Settings => Change Global Settings => Client Experience => Session Time-out (mins). I changed mine to 720, there is a screenshot below for you to reference:


  6. From CTX215701 Storefront page session time-out: If you increase the session timeout for RfWeb to be more than 1 hour, you have to also increase the maxLifetime appropriately in c:\inetpub\wwwroot\Citrix\Authentication\Web.config.
  7. If your desired timeout value is greater than 8 hours, you should also edit tokenLifeTime in c:\inetpub\wwwroot\Citrix\StoreWeb\web.config.

Default Tab

  1. By default, when a user logs in to StoreFront, the Favorites tab is selected. Users can go to other tabs to add icons to the list of Favorites.



  2. Trentent Tye has a simple customization for C:\inetpub\wwwroot\Citrix\StoreWeb\custom.js to default to the Apps tab if the user doesn’t have any favorites. See Citrix Storefront – Adventures in customization – Default to “Store” view if you have no favourited app’s.
    CTXS.Extensions.afterDisplayHomeScreen = function (callback) {
     /* If the user has no favorited apps, set the view to the apps view */
     if (CTXS.Store.getMyApps().length == 0) {
     CTXS.ExtensionAPI.changeView("store")
     }
    };
  3. You can completely remove the Favorites tab by going to Stores > Configure Store Settings > User Subscriptions, and choose Disable User Subscriptions (Mandatory Store).

  4. You can change the default tab and tab visibility by going to the Stores > Manage Receiver for Web Sites > Configure > Client Interface Settings page.
  5. When publishing applications in Citrix Studio, specify an Application category so the applications are organized into folders.
  6. If you change the default tab to Applications, then you might also want to default to the Categories view instead of the All view.
  7. You can do this by adding the following code to C:\Inetpub\wwwroot\Citrix\StoreWeb\custom\script.js. More details at Storefront 3.0 – change default view at Citrix Discussions.
    CTXS.Extensions.afterDisplayHomeScreen = function (callback) {
         CTXS.ExtensionAPI.navigateToFolder('/');
    };
    
    CTXS.Extensions.onViewChange = function (viewName) {
      if (viewName == 'store') {
        window.setTimeout(function () {
        CTXS.ExtensionAPI.navigateToFolder('\\');
        }, 0);
      }
    };
    

  8. Then when you login to StoreFront you’ll see Apps > Categories as the default view. This works in Receiver too.

Beacons

  1. On the left, right-click Stores, and click Manage Beacons.
  2. Configure an Internal Beacon. Receiver Self-Service tries to connect to the Internal Beacon to determine if Receiver is currently internal or not. If the Internal Beacon is reachable then Receiver Self-Service assumes it is internal, and thus connects to the StoreFront Base URL. If the Internal Beacon is not reachable, then Receiver Self-Service assumes it is external and thus connects to NetScaler Gateway. For this to work properly, the Internal Beacon must not be resolvable externally.
    If you are not doing Single FQDN, then the Internal Beacon can be the StoreFront FQDN since the StoreFront FQDN is usually only available internally.
    If you are doing Single FQDN, then you can’t use the StoreFront FQDN. Instead, you must use a different internal website for the beacon. If you need to support internal iPads, due to differences in how iPads determine location, the Internal Beacon should be a new FQDN that resolves to the StoreFront Load Balancing VIP thus requiring the StoreFront certificate to match both the Internal Beacon and the Base URL. If internal iPads are not needed, then the Internal Beacon can be any internal website.
    If you want to force internal Receiver Self-Service users to connect through NetScaler Gateway (for AppFlow reporting), you can set the Internal Beacon to a fake URL. Since the Internal Beacon is never resolvable, Receiver Self-Service always uses NetScaler Gateway. Or you can use Optimal Gateway to achieve the same goal.
  3. The External beacons are used by Receiver Self-Service to determine if the Receiver Self-Service has Internet access or not. You can use any reliable Internet DNS name. Click OK when done.

Propagate Changes

Any time you make a change on one StoreFront server, you must propagate the changes to the other StoreFront server.

  1. In the StoreFront console, on the left, right-click Server Group, and click Propagate Changes.
  2. You might see a message saying that you made changes on the wrong server.
  3. Click Yes when asked to propagate changes.
  4. Click OK when done.
  5. When you propagate changes, the default web page is not replicated to the other nodes. Copy C:\inetpub\wwwroot\web.config manually to each node.

Export/Import StoreFront Configuration

Use the following PowerShell cmdlets to export StoreFront Configuration into a .zip file (encryption optional) and import to a different StoreFront server group:

  • Export-STFConfiguration
  • Import-STFConfiguration

See Export and import the StoreFront configuration at Citrix Docs for details.

Auto-Favorite

To force a published application to be favorited (subscribed), use one of the following keywords in the published application description:

  • KEYWORDS: Auto = the application is automatically subscribed. But users can remove the favorite.
  • KEYWORDS: Mandatory = the application is automatically subscribed and users cannot remove the favorite.

With Mandatory applications there is no option to remove the application from Favorites.

Logon Simulator

ControlUp has a free Logon Simulator for StoreFront and NetScaler Gateway. You can run it on any machine to periodically test app launches from StoreFront.

The tool creates entries in the Application Log in Event Viewer. The events can be consumed by your monitoring tool.

Related Pages

StoreFront Tweaks

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

Navigation

Here is a collection of optional StoreFront configurations.

CRL Checking – Disable

When the StoreFront server checks certificate revocation for its locally signed files, a delay can occur before the StoreFront logon page is displayed.

  1. Run the following PowerShell commands:
    Add-PSSnapin Citrix.DeliveryServices.Framework.Commands
    Set-DSAssemblyVerification $false
  2. Another potential tweak to speed up StoreFront is to disable NetBIOS. Right-click the Start Menu and click Network Connections.
  3. Right-click the NIC and click Properties.
  4. Highlight Internet Protocol Version 4 and click Properties.
  5. Click Advanced.
  6. On the WINS tab, change the selection to Disable NetBIOS over TCP/IP and click OK twice and Close once.
  7. Repeat on the other StoreFront servers.

Note: According to Microsoft, it is no longer necessary to configure generatePublisherEvidence in C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config.

Receiver Shortcuts

You can use StoreFront to control placement of shortcuts on Receiver machines.

  1. Run Notepad elevated (as administrator).
  2. Edit the file C:\inetpub\wwwroot\Citrix\Roaming\web.config.
  3. Search for <account. Find the Store name in the name attribute.
  4. Scroll down to the first <properties> section located under <annotatedServices>.
  5. See Using StoreFront account settings to customize app shortcut locations at docs.citrix.com for a list of properties. Add the properties as detailed at docs.citrix.com. The properties should be added after the clear tag.
  6. Note: if subscriptions are enabled in StoreFront then only Favorites are added to the Start Menu and Desktop. If subscriptions are disabled then all applications are placed on the Start Menu or Desktop.
  7. Close and save the file.
  8. Then Propagate Changes.

PNAgent Authentication

Single Sign-on

From Configure authentication for XenApp Services URLs at docs.citrix.com: XenApp Services URLs support explicit, domain pass-through, and pass-through with smart card authentication. Explicit authentication is enabled by default. You can change the authentication method, but only one authentication method can be configured for each XenApp Services URL. To enable multiple authentication methods, create separate stores, each with a XenApp Services URL, for each authentication method. To change the authentication method for a XenApp Services URL, you run a Windows PowerShell script.

  1. On the primary StoreFront server in your deployment, use an account with local administrator permissions to start Windows PowerShell.
  2. At a command prompt, type the following command to configure the user authentication method for users accessing the store through the XenApp Services URL.
    & "C:\Program Files\Citrix\Receiver StoreFront\Scripts\EnablePnaForStore.ps1" –SiteId 1 -ResourcesVirtualPath /Citrix/Store –LogonMethod sson
  3. Propagate changes.

Remember my password

If you leave PNAgent authentication set to Prompt, you can enable the Remember my password box by doing the following:

  1. Run Notepad as Administrator and edit the file C:\inetpub\wwwroot\Citrix\Store\Views\PnaConfig\Config.aspx.
  2. Near line 74 is EnableSavePassword. Change it to true.
  3. When PNAgent connects, there should now be a Remember my password checkbox.

Hide Applications

Hide applications from Receiver – http://blogs.citrix.com/2014/03/27/hiding-applications-in-citrix-storefront/. Note: each StoreFront Store has its own filter configuration.

Open PowerShell and run:

$dsInstallProp = Get-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DeliveryServicesManagement -Name InstallDir
$dsInstallDir = $dsInstallProp.InstallDir
& $dsInstallDir\..\Scripts\ImportModules.ps1

To filter by type, run:

Set-DSResourceFilterType -SiteId 1 -VirtualPath "/Citrix/Store" ?IncludeTypes @("Applications")

Default type filters = @(“Applications”,”Desktops”,”Documents”)

To filter by keyword, run:

Set-DSResourceFilterKeyword -SiteId 1 -VirtualPath "/Citrix/Store" -ExcludeKeywords @("Hidden")

Once the ExcludeKeyword has been defined, add the keyword to a published application description and that application will no longer display in Receiver. This works for both Receiver for Web and Receiver Self-Service (non-browser).

StoreFront web.config GUI Assistant

Jake Rutski Citrix Storefront Configurator is a GUI tool to modify the web.config files in StoreFront 3.0.

The tool offers a GUI to ease configuration of the StoreFront 1.2/2.0/2.1/2.5 “Receiver for Web”.

Run the tool, the below interface will be shown

Click on Browse to open the web.config file

The tool will switch to the Server Settings tab and the Save button will appear.

The StoreFront version is shown in the GUI

Change the parameters within the different tabs exposed in the GUI and click on the “Save” button to validate the changes.

When clicking “Save”, a backup copy will be created (web.config.bak) at the target location. If the tool is launched from a StoreFront server, a replication process to the other StoreFront servers can be initiated.

Desktop Autolaunch

By default, if only a single desktop is published to the user, Receiver for Web will auto-launch it. You can change this behavior by editing the Receiver for Web site configuration file or by using the GUI Assistant:

  1. On the StoreFront server, use a text editor to open the web.config file for the Receiver for Web site, which is typically located in the C:\inetpub\wwwroot\Citrix\storenameWeb\ directory, where storename is the name specified for the store when it was created.
  2. Search for autoLaunchDesktop near line 58.
  3. Change the value of the autoLaunchDesktopattribute to false to prevent Receiver for Web from automatically starting and accessing a desktop when a user logs on to the site and only a single desktop is available for that user.

Note: The Receiver Self-Service interface does not auto-launch desktops.

Full Screen Desktop

Citrix CTX139762 How to Configure StoreFront to Start Published Desktops in Full Screen Mode: This article describes how to configure StoreFront to start published desktops in Full Screen Mode.

  1. Open the file C:\inetpub\wwwroot\Citrix\Store\App_Data\default.ica on the StoreFront server(s) with notepad (as Administrator)
  2. Add the line:
    [Application]
    DesktopViewer-ForceFullScreenStartup=On
  3. In older versions of StoreFront, it should be true instead of On.
  4. Save the file
  5. Open the command prompt (cmd) and run iisreset.

Autolaunch Application

For StoreFront 3.0, see the script.js code posted by Michael Bednarek at discussions.citrix.com.

For StoreFront 2.6, see the custom.script.js code posted by Kyle Woodbury at discussions.citrix.com.

Store for Anonymous

If you intend to publish applications to anonymous users then you can create a StoreFront store that does not require authentication. Note: anonymous stores only work internally (no NetScaler Gateway).

  1. On the VDAs, create and configure anonymous accounts.
  2. In Citrix Studio, configure a Delivery Group to accept unauthenticated (anonymous) users.
  3. In the StoreFront Console, on the left, click Stores. On the right, click Create Store for Unauthenticated Users.
  4. In the Information page, click Next.
  5. In the Store Name page, enter a new store name and click Next.
  6. In the Delivery Controllers page, click Add.
  7. Enter the name of your XenApp farm (e.g. CorpSite).
  8. Add all of your XenApp Controllers.
  9. Change the Transport type to HTTP. Click Add.
  10. Click Create when you are done creating deployments.
  11. Click Finish.

Workspace Control

Workspace Control reconnects user sessions. It can be disabled. Or configure various reconnection options.

Citrix Blog Post Workspace Control: When You DON’T Want to Roam details complete session reconnection configuration instructions for XenApp, Remote Desktop Services, StoreFront, and Receiver.  💡

Receiver for Web

To edit Workspace Control in Receiver for Web, edit the file C:\inetpub\wwwroot\Citrix\StoreWeb\web.config and edit the attributes of the following line:

<workspaceControl enabled="true" autoReconnectAtLogon="true" logoffAction="disconnect" showReconnectButton="false" showDisconnectButton="false" />

Receiver Self-Service

Citrix Blog Post – How to Disable Workspace Control Reconnect: For Receiver for Windows, workspace control can be managed on client devices by modifying the registry. Please see this Knowledgebase Article for how to implement it. This can also be done for domain-joined client devices using Group Policy.

StoreFront 2.6 introduces a configuration to disable workspace control reconnect in the Store Service for all receivers. This can be managed by using PowerShell or by editing web.config.

Using PowerShell

Make sure that you close the Admin Console. Run the following code snippet to import the StoreFront PowerShell modules:

& C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1

Workspace control reconnect can then be turned on/off by the PowerShell command Set-DSAllowSessionReconnect. For example, if you would like turn off workspace control reconnect for a store in /Citrix/Store, the following command will configure the store appropriately:

Set-DSAllowSessionReconnect -SiteId 1 -VirtualPath /Citrix/Store -IsAllowed $false

Editing web.config

Open C:\inetpub\wwwroot\Citrix\Store\web.config in a text editor. Locate the line that looks like:

<resourcesService id="f01f7dc4-7f28-4bc1-b8fb-7c0db9570d20" storeLockedDown="false" anonymousStore="false" allowSessionReconnect="true" />

Change the value of allowSessionReconnect to false to disable workspace control reconnect or true to enable it.

Treat Desktops as Applications

From Treating All Desktops as Applications at Citrix Blog Post What’s New in StoreFront 3.0: Desktops are treated differently from applications in StoreFront/Receivers. They are placed in a separate Desktop tab and in the case of Receiver for Web, they are not reconnected with workspace control. In some use cases, it is desirable to treat desktops as applications so that they are placed together with applications and get reconnected as part of workspace control. With StoreFront 2.x, you have to add the TreatAsApp keyword to all published desktops to achieve this effect. StoreFront 3.0 enables you to configure treating all desktops as applications at the store level without the need of adding the TreatAsApp keyword to all the published desktops. This is configurable using a PowerShell cmdlet.

& "C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"

Set-EnhancedEnumerationOptions -siteId 1 -storeVirtualPath /Citrix/Store `
-treatDesktopsAsApps $true

Special Folder Redirection

From Configure special folder redirection at docs.citrix.com: With Special Folder Redirection configured, users can map Windows special folders for the server to those on their local computers. Special folders refer to standard Windows folders, such as \Documents and \Desktop.

  1. Open PowerShell as administrator (elevated).
  2. Run & “C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\AdminServiceLoader.ps1″ to load the modules.
  3. Run the following command:
    Set-DSClientSettings -SiteId 1 -VirtualPath /Citrix/Store -SpecialFolderRedirectionAllowed $true

Receiver Self-service – Disable “Remember My Password”

By default, when Receiver Self-Service connects internally to StoreFront, the user is able to check the box next to Remember my password. Note: When connecting through NetScaler Gateway, this checkbox is never available.

This can be disabled by making a change on the StoreFront server. This procedure is documented by John Ashman at Citrix Discussions and Prevent Citrix Receiver for Windows from caching passwords and usernames at docs.citrix.com.

  1. Note that this procedure seems to prevent Receiver for iOS from adding accounts.
  2. On the StoreFront server, run a text editor elevated (as administrator).
  3. Open the file C:\inetpub\wwwroot\Citrix\Authentication\App_Data\Templates\UsernamePassword.tfrm.

  4. Go to line 20, which should start with @SaveCredential.
  5. To comment out the line, wrap it in @* and *@. Save the file when done.

  6. Now the Remember My Password checkbox is gone.

“Activate” Option in Web Page – Disable

From Citrix Discussions: to disable the “activate…”; function for Citrix receiver for windows that is visible when a user clicks their username in the upper right hand corner of Receiver for Web:

  1. Browse to C:\inetpub\wwwroot\Citrix\”NameoftheStoreWeb”\
  2. Open config
  3. Locate the following line.
    <receiverConfiguration enabled=”true” downloadURL=”ServiceRecord/GetDocument/receiverconfig.cr” />
  4. Change the true to false

HTML5 Receiver Getting Started Tour

The first time a user connects to HTML5 Receiver, the user is prompted to tour the interface.

The Getting Started Tour can be disabled by doing the following:

  1. Edit the file C:\Inetpub\wwwroot\Citrix\StoreWeb\custom\script.js.
  2. At the bottom of the file, add Feng Huang’s code from First time user tutorial at discussions.citrix.com. Make sure the quotes are straight quotes and not curly quotes.
    localStorage["showFtu"] = false;

Customize Receiver UI in StoreFront 3.0

StoreFront 3.0 customizations are visible in both Receiver for Web and in Receiver Self-Service.

If you are load balancing StoreFront and want to put the server name on the webpage, see Nicolas Ignoto Display server name with Citrix StoreFront 3.
Server name is displayed

Nicolas Ignoto Lab: Part 22 – Ultimate StoreFront 3 customization guide contains many StoreFront customizations including:  💡

  • Add disclaimer
  • Change logo/background
  • Add header
  • Add text
  • Change colors
  • Etc.

Citrix Blog Post Citrix Customization Cookbook contains a collection of customizations including:

  • Add Static or dynamic (read from file) text to the header and/or footer of the login page.
  • Click-through disclaimer before or after login page
  • Footer for every page
  • Default to Folder view when visiting the Apps tab
  • Change default text
  • Change background images for featured categories
  • Background image

Citrix Blog Post Storefront 3 Web Customization: Branding Your Deployment describes the following how to modify CSS to customize the appearance of StoreFront 3.0:

  • Background images
  • Logon button
  • Colors for page and text
  • How to view the mobile version of the page
  • CSS for mobile pages

Jason Samuel Upgrading Citrix StoreFront 2.6 to StoreFront 3.0 – Things to Know details how to change the StoreFront logo to a Receiver logo.

Citrix Blog Post StoreFront 3.0: Message Customization describes how to add a scrolling message to the top of the screen. This is displayed in both Browsers and Receivers.

Migrate Web Interface features to StoreFront at Docs.citrix.com details how to configure Web Interface features in StoreFront. This includes:

  • Enable return to last folder
  • Header logo
  • Pre-logon welcome message
  • Logon screen customization
  • Footer text

StoreFront 3.0 Receiver Customization APIs are detailed at Citrix Developer. Use the Receiver Customization API to brand or customize your end users’ app and desktop selection experience beyond capabilities provided in the StoreFront admin console. Customizations apply to latest Web, Chrome, Windows, Mac and Linux clients, and will be extended to mobile devices in future releases.

An example use case for the StoreFront 3.0 APIs is Citrix Blog Post Citrix Recipe Box: StoreFront Approvals. This is code for StoreFront that requires workflow approval when a user subscribes to an app.

Citrix Blog Post Receiver X1 APIs describes the following:

  • Overview of the CSS classes that can be customized.
  • Override Citrix’s JavaScript functions to modify behavior – exclude or restyle apps, change a sort order, add a warning message etc.
  • How to force X1 UI to display in either phone or larger mode.

Citrix Blog Post X1 Customization: Going deeper with CSS describes the following:

  • Use CSS (/custom/style.css) to style the three custom regions (#customTop, #customBottom, #customScrollTop). Shown below in red, blue, and pink.
  • Marker classes for showing/hiding or highlighting parts of the UI: large display, small display, high DPI, Favorites view, Desktops view, Apps view, appinfo view.

Citrix Blog Post Scripting X1 describes the following:

  • JavaScript code to display an Acceptance dialog box before users can login.
  • Use JQuery to add HTML code to custom regions (e.g. #customScrollTop) including using CSS to hide the HTML code unless a specific tab is selected by the user.

Citrix Blog Post – Rewriting the Session ClientName from StoreFront: I would like to offer the following customisation DLL which can apply client name rewrites based on a template. The customisation template can be any string, but where that string contains a particular token, the token will be replaced by some information from the User Context. If the intent was just to replace the ClientName with the user name, the template is then just “$U”. More details and the .dll file are in the blog post.

StoreFront Store Customization SDK at Citrix Developer: The Store Customization SDK allows you to apply custom logic to the process of displaying resources to users and to adjust launch parameters. For example, you can use the SDK to control which apps and desktops are displayed to users, to change ICA virtual channel parameters, or to modify access conditions through XenApp and XenDesktop policy selection. Key Customization Points:

  • Post-Enumeration
  • Post-Launch ICA File
  • Post-Session Enumeration
  • Access Conditions (pre-launch and pre-enumeration)
  • Provider List
  • Device information

Citrix Blog Post Adding a Language to StoreFront 3.0: A new language pack is comprised of a culture definition file, a string bundle file and a custom string bundle file. See the Blog Post for more details.

To change the StoreFront page title, see Sam Jacobs How to Change the Page Title in Citrix Receiver 3.x at mycugc.org.  💡

Customize Receiver for Web in StoreFront 2.6

These customizations apply to Receiver for Web only. They do not apply to Receiver Self-Service or NetScaler Gateway.

Citrix Blog post Receiver for Web UI Themes: White Theme and Dark Theme.

The Citrix blog post Customizing Receiver for Web 2.5 applies to StoreFront 2.6 except for the changes detailed in the blog post Customizing Receiver for Web 2.6. Here are some customizations detailed in these blog posts:

  • Hyperlink in the Footer Area – for example, contact the help desk
  • Pre-login (Disclaimer) and Post-login (Announcement) Messages
  • Display Client IP Address
  • Display StoreFront server name

Citrix blog post – How to Add a Custom Banner to the Logon Page of StoreFront 2.x, Director 7.x, or Citrix License Server 11.x: Some customers require that all levels of authentication (all logon pages) display security banners which outline the rights to privacy (or lack thereof) when accessing their sites.  In this case, a simple change to the web page code results in the addition of text – a security banner – near the authentication fields which is visible each time a user logs onto the site. This article contains information about the customization of the logon page of StoreFront, Director, and Citrix License Server web pages.

From Citrix Discussions: Just realized that you probably should not modify the original files. All StoreFront modifications are done by adding CSS/Javascript into the /contrib directory, which overrides the default values. You would simply create a file called *custom.wrstrings.en.js* (for English) in that directory, replacing just the values that you wish to override.

More customizations are detailed Citrix Knowledgebase article Customizing the Receiver for Web User Interface including:

  • Language strings and Language Pack
  • CSS Customization
  • Javascript Customization

From Daniel Ruiz – Customizing Citrix StoreFront 2.6 including Pre-Login message page: The following customizations include the following:

  • Pre-Login message page
  • Front Page with custom logo and title header
  • App/Desktop page with custom logo, user client IP
  • Apps/Desktop Tab on top with Disable user multiclick
  • Page footer

From Czerno blog – Redirect Citrix Storefront to a different page at log off: To make Storefront redirect to a different page rather than just sit at the “You have logged off successfully” page, edit the “custom.wrstrings.en.js” file in the contrib folder of the Web Store. By default this will be located at “C:\inetpub\wwwroot\Citrix\<StoreName>Web\contrib”. If you have not created any customizations, select everything in the file and replace with the following:

(function ($) {
$.localization.customStringBundle('en', {
YouAreLoggedOff: 'You have logged off successfully. <br>'
+'You are being redirected to <Enter your web page here or delete this line>'
+'<script type="text/javascript">'
+'window.location.replace("http://www.czerno.com");'
+'</script>'
});
})(jQuery);

StoreFront SDK

Use the Store Customization SDK to apply custom logic to the process of displaying resources to users and to adjust launch parameters.  For example, you can use the SDK to control which apps and desktops are displayed to users, to change ICA virtual channel parameters, or to modify access conditions through XenApp and XenDesktop policy selection.

Requires Visual Studio to create .dll files that replace the ones bundled with StoreFront.

https://www.citrix.com/downloads/storefront-web-interface/sdks/storefront-customization-software-development-kit

StoreFront 3.0 Theme for NetScaler 10.5

You can make the NetScaler Gateway 10.5 logon page look like the Receiver for Web in StoreFront 3.0. Daniel Ruiz NetScaler Gateway front page à la StoreFront 3.0 has instructions for manually editing the NetScaler Gateway theme to match StoreFront 3.0. Or visit Citrix Blog Post X1 Skin for NetScaler Gateway for an already developed theme package.

  1. Download the theme from the Citrix Blog post.
  2. WinSCP to the NetScaler and switch to /var/netscaler/gui/themes.
    1. On the right, rename the existing receivertheme.tar.gz file.

  3. Upload the theme that was downloaded from the Citrix Blog post.
  4. In NetScaler GUI, go to NetScaler Gateway > Global Settings > Change Global Settings.
  5. Switch to the Client Experience tab.
  6. At the bottom, if the current UI Theme is Green Bubble, change it to Default. Then go back into the screen and change it back to Green Bubble. This causes the theme to reload. Click OK.
  7. The logon page should now look more like Receiver for Web in StoreFront 3.0.

StoreFront 3.0 Portal Theme for NetScaler 11

See NetScaler Gateway 11 > Portal Themes. Build 62 and newer have a built-in X1 theme.

Related Pages

StoreFront Favorites/Subscriptions

Last Modified: Aug 14, 2017 @ 7:40 pm

Navigation

This page contains the following topics:

Favorites/Subscriptions Overview

By default, StoreFront allows users to select applications as their Favorites. These subscribed applications are then displayed in the Favorites view of Receiver. Administrators can also use KEYWORDS in published application descriptions to auto-favorite an application.

The Favorites (subscriptions) are stored in a file database on each StoreFront server and are automatically replicated to every StoreFront server in a local Server Group. For StoreFront servers in multiple datacenters, you can configure replication of subscriptions between Server Groups. This provides a consistent user interface no matter which datacenter the user connects to.

Multi-datacenter – Favorites/Subscriptions Replication

If you have different StoreFront clusters (server groups) in multiple datacenters, you probably want to replicate subscriptions between them. For more information, see What Subscriptions and Server Groups Mean for StoreFront Designs

  1. The store names must be identical in each StoreFront server group.
  2. When adding farms (Manage Delivery Controllers) to StoreFront, make sure the farm names are identical in each StoreFront cluster (server group).
  3. Load balance TCP 808 for each StoreFront cluster. Use the same VIP you created for SSL Load Balancing of StoreFront. Each datacenter has its own VIP.
  4. Run the PowerShell commands detailed at Configure subscription synchronization at Citrix Docs. When adding the remote cluster, enter the TCP 808 Load Balancing VIP in the other datacenter. Run these commands on both StoreFront clusters.
  5. Don’t forget to add the StoreFront server computer accounts to the local group CitrixSubscriptionSyncUsers on each StoreFront server.

Share Favorites/Subscriptions with Multiple Stores

Docs.citrix.com – Configure two StoreFront stores to share a common subscription datastore: It is common for administrators to configure StoreFront with two distinct stores; one for external access to resources using Netscaler Gateway and another for internal access using the corporate LAN. You can configure both “external” and “internal” stores to share a common subscription datastore by making a simple change to the store web.config file.

For two stores to share a subscription datastore, you need only point one store to the subscription service end point of the other store. Note: The XenApp, XenDesktop and AppC controllers configured on each store must match exactly; otherwise, an inconsistent set of resource subscriptions on one store might occur. Sharing a datastore is supported only when the two stores reside on the same StoreFront server or server group deployment.

Open the external store web.config file (C:\Inetpub\wwwroot\Citrix\ExternalStore\web.config) using Notepad and search for the clientEndpoint. For example:

<subscriptionsStoreClient enabled="true">
<clientEndpoint uri="net.pipe://localhost/Citrix/Subscriptions/1__Citrix_External" authenticationMode="windows" transferMode="Streamed">
<clientCertificate thumbprint="0" />
</clientEndpoint>
</subscriptionsStoreClient>

Change the external to match the internal store endpoint. Then Propagate Changes.

<subscriptionsStoreClient enabled="true">
<clientEndpoint uri="net.pipe://localhost/Citrix/Subscriptions/1__Citrix_Internal" authenticationMode="windows" transferMode="Streamed">
<clientCertificate thumbprint="0" />
</clientEndpoint>
</subscriptionsStoreClient>

Delete Favorites/Subscriptions

From Citrix Discussions: You can delete subscriptions using the subscription store PowerShell API and some file editing:

  1. If StoreFront 3.5 or newer, run the following (from Citrix CTX216295 How to Export and Import StoreFront Subscription Database on Storefront 3.6):
    $store = Get-STFStoreService
    Export-STFStoreSubscriptions -Store $store -FilePath "$env:userprofile\desktop\subscriptions.txt"
    1. If StoreFront 3.0.1 or older, run the following PowerShell (using ‘Run As Administrator’ when opening the PowerShell Console and not missing the ‘. ‘ (i.e. dot space) at the start of the first command):
      . 'C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1'
      Export-DSStoreSubscriptions -StoreName MyStore -FilePath .\subscriptions.txt
  2. Stop the “Citrix Subscriptions Store” Service on all StoreFront servers in the deployment.
  3. Find the subscription store database folder: “C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Citrix\SubscriptionsStore\1__Citrix_Store” on each StoreFront server. Delete the contents of this folder (do not delete the folder itself). Note: If UAC is enabled then you might have to go to C:\Windows\ServiceProfiles\NetworkService first and then drill down into the remaining folders. AppData is a hidden folder.
  4. Restart the “Citrix Subscriptions Store” Service on all StoreFront servers in the deployment. Open Event Viewer and, in the left pane, navigate to Applications and Services Logs > Citrix Delivery Services. Search for events logged by the Citrix Subscriptions Store Service with an Event ID of 3 and a Task Category of 2901. Ensure that an entry is logged for each store on every server in the deployment before continuing.
  5. Backup subscriptions.txt, then edit to remove any entries you want to delete.
  6. If StoreFront 3.5 or newer, run the following PowerShell commands to restore your subscriptions:
    $store = Get-STFStoreService
    Import-STFStoreSubscriptions -Store $store -FilePath "$env:userprofile\desktop\subscriptions.txt"
    1. If StoreFront 3.0.1 or older, run the following PowerShell:
      Import-DSStoreSubscriptions -StoreName MyStore -FilePath .\subscriptions.txt

Each row of the exported subscriptions file is a tab-separated list of user-sid, resource-id, subscription-id, subscription-status followed by zero or more subscription-property name-value pairs.

To delete all subscriptions for a particular user, you will need to find the user’s SID and then delete all rows starting with that value.

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

StoreFront Basic Configuration

Last Modified: Aug 20, 2017 @ 8:12 am

Navigation:

💡 = Recently Updated

Installation / Upgrade

StoreFront Versions – All three versions have very similar configurations:

  • The XenApp/XenDesktop 7.6.0 ISO comes with StoreFront 2.6. If you installed StoreFront on your Delivery Controllers, then it is version 2.6, and you can upgrade it to 3.0.4000.
  • XenApp/XenDesktop 7.7 ISO comes with StoreFront 3.0.1. You can upgrade it from the 7.6 LTSR CU3 media.
  • XenApp/XenDesktop 7.6.1000 (LTSR CU1) comes with StoreFront 3.0.1000.
  • XenApp/XenDesktop 7.6.2000 (LTSR CU2) comes with StoreFront 3.0.2000.
  • XenApp/XenDesktop 7.6.3000 (LTSR CU3) comes with StoreFront 3.0.3000.
  • XenApp/XenDesktop 7.6.4000 (LTSR CU3) comes with StoreFront 3.0.4000

Server Selection – StoreFront can be installed directly on your Delivery Controllers. When installing Delivery Controller, simply leave the box checked to install StoreFront. If you let Delivery Controller install StoreFront, it will create a default store named /Citrix/Store. See below to rename this store.

Or you can install StoreFront 3.0.1000 on separate servers. You can even install StoreFront on your existing Web Interface servers (make sure Web Interface is installed first).

Citrix Blog Post StoreFront 3.0 Scalability recommends StoreFront servers to be sized with 4 vCPU and 8 GB RAM.

After installation, NT SERVICE\CitrixConfigurationReplication and NT SERVICE\CitrixClusterService must remain in the Administrators group on both StoreFront servers or propagation will fail.

Install / Upgrade StoreFront 3.0.4000

StoreFront 3.0.4000 is available on the XenApp/XenDesktop 7.6 LTSR CU4 ISO, or you can download StoreFront 3.0.4000 separately.

  1. For new installs, there’s no need to install prerequisites (e.g. IIS) since the StoreFront installer will do it for you.
  2. If upgrading from older StoreFront:
    1. Other Users – Use Task Manager > Users tab to logoff any other user currently logged into the machine.
    2. Close all MMC and PowerShell consoles.
    3. Stop the World Wide Web Publishing Service.
    4. Stop all StoreFront services.
  3. Go to the XenApp/XenDesktop 7.6 LTSR CU4 ISO and run \x64\StoreFront\CitrixStoreFront-x64.exe. You can also install StoreFront from the AutoSelect.exe program on the same ISO.
  4. In the License Agreement page, check the box next to I accept the terms, and click Next.
  5. In the Review prerequisites page, click Next.
  6. In the Ready to install page, click Install.
  7. In the Successfully installed StoreFront page, click Finish.
  8. If this is a new install, skip to the next section (Initial Configuration).
  9. After upgrading, in StoreFront Console, go to Receiver for Web and Disable Classic Receiver Experience.

  10. Click Disable.
  11. Go to Stores and on the right, click Set Unified Experience as Default.
  12. Check the box next to Set the unified Receiver experience as the default for this store and click OK.
  13. Go back to Receiver for Web and use the Configure Receiver Appearance and Manage Featured App Groups links to customize the webpage.

Initial Configuration

If this is a new install of StoreFront, do the following:

  1. In PowerShell, run Set-ExecutionPolicy Unrestricted.
  2. The management console should launch automatically. If not, launch Citrix StoreFront from the Start Menu.
  3. In the middle, click Create a new deployment.
  4. In the Base URL page, if you installed an SSL certificate on the StoreFront server, then the Hostname should already be filled in. If SSL is not configured yet then you can leave it set to the server name and change it later once you setup SSL and load balancing. Click Next.
  5. In the Store Name page, enter a name for the store and click Next. The Store name entered here is part of the URL path. And users see this name in their local Receiver Accounts list.
  6. In the Delivery Controllers page, you can one set of Delivery Controllers per XenApp farm or XenDesktop site. Click Add.
  7. Change the Type to XenDesktop.
  8. Enter a descriptive name for the XenApp/XenDesktop 7.6 or newer site/farm. This name does not need to match the actual site/farm name. And users don’t see this name.
  9. Add the two Controllers. Change the Transport Type to HTTP. Click OK. It’s also possible to set the Transport type to HTTPS if certificates are installed on your Delivery Controllers.
  10. If you have multiple XenDesktop sites/farms feel free to add them now. Or you can add older XenApp farms. Click Next when done.
  11. In the Remote Access page, select None and click Create. You can configure StoreFront to use NetScaler Gateway later.
  12. In the Created Successfully page, click Finish.

Second StoreFront Server

After installation of the second server, NT SERVICE\CitrixConfigurationReplication and NT SERVICE\CitrixClusterService must remain in the Administrators group on both StoreFront servers or propagation will fail.

  1. Install StoreFront 3.0.4000 on the second server.
  2. On the 2nd server, create/import the SSL certificate and bind it to the Default Web Site.
  3. Login to the first StoreFront server. In the StoreFront management console, right-click Server Group, and click Add Server.
  4. Copy the Authorization code.
  5. Login to the second StoreFront server and launch the StoreFront Console. In the middle, click Join existing server group.
  6. In the Join Server Group page, enter the name of the first StoreFront server and enter the Authorization code copied earlier. Click Join.
  7. Then click OK.
  8. Go back to the first server. Click OK.
  9. All changes made on one StoreFront server must be propagated to the other StoreFront server. When changing StoreFront web.config files, change them on one StoreFront server use the StoreFront Console to Propagate Changes to the other StoreFront servers.

Store Name – Rename

When you install XenDesktop Delivery Controller, you are given the option of installing StoreFront on the same server. If you let the Delivery Controller installer also install StoreFront then the StoreFront on the Controller will have a default store name of /Citrix/Store. If you don’t like the default Store Name then you will need to remove the store and re-add it.

  1. In the StoreFront console, on the left click Stores.
  2. Highlight the store and on the bottom right click Remove Store.
  3. Click Remove.
  4. On the left, right-click Stores and click Create Store.
  5. In the Store Name page, enter a name. This name becomes part of the path (/Citrix/StoreName) and is displayed in Receiver. Click Next.
  6. In the Delivery Controllers page, add farms and click Next.
  7. In the Remote Access page, leave it set to None and click Create.
  8. In the Created Successfully page, click Finish.

HOSTS File

StoreFront 3.0 is smart enough to do a loopback connection to the local StoreFront server instead of sending traffic through the load balancer. For more information see No More Editing of Hosts File at Citrix Blog Post What’s New in StoreFront 3.0.

However, if you have StoreFront servers in multiple datacenters then you are probably using GSLB-enabled DNS names and StoreFront needs to resolve these names to VIPs in the local datacenter. Edit the HOSTS file (C:\Windows\System32\Drivers\Etc\HOSTS) on each StoreFront server with the following entries:

  • StoreFront Load Balancing FQDN (e.g. Citrix.corp.com) = Load Balancing VIP in the local datacenter.
  • NetScaler Gateway Callback FQDN (e.g. CitrixCB.corp.com) = NetScaler Gateway VIP in the local datacenter.

SSL Certificate

StoreFront requires SSL. You will save yourself much heartache if you install valid, trusted certificates. There are two options for StoreFront SSL:

  • SSL Offload: Use NetScaler to do SSL Offload and load balancing. In this scenario NetScaler does SSL encryption on the client side but uses clear-text HTTP on the StoreFront side and thus there is no need for certificates on the StoreFront servers. The SSL certificate on the NetScaler must match the DNS name that resolves to the load balancing VIP for StoreFront.
  • SSL End-to-end: In this scenario, NetScaler does encryption on the client-side but also re-encrypts before sending traffic to the StoreFront servers. This requires certificates on the StoreFront servers.

NetScaler usually does not verify server-side certificates so it doesn’t matter what name is in the cert that is installed on the StoreFront servers. However, some other load balancers do verify the cert and thus the cert on the StoreFront servers should match the FQDN of the StoreFront server.

If StoreFront is installed on your Delivery Controllers then both functions share the same IIS website and the same SSL certificate. If you want to enable SSL for the Delivery Controller (XML) connection, then the cert name on each server must match the FQDN of the Delivery Controller. One option is to create an SSL certificate with the following Subject Alternative Names: the StoreFront load balanced DNS name and each of the Delivery Controller FQDNs. Then import this one certificate on all StoreFront/Delivery Controllers servers and load balancers. Or a wildcard certificate could match all of these names.

In any case, be aware of the Subject Alternative Name requirements for email-based discovery in Citrix Receiver. Email discovery in Citrix Receiver requires the certificate to not only match the StoreFront load balanced DNS name but the certificate must also match discoverReceiver.email.suffix. Usually the only option to match both names is with Subject Alternative Names. If you have multiple email suffixes then you will need multiple Subject Alternative Names, each beginning with discoverReceiver.email.suffix. If you configure Subject Alternative Names, don’t forget to add the load balanced name as one of the Subject Alternative Names.

When you view a Subject Alternative Name certificate, on the Details tab, click Subject Alternative Name to verify that all names are listed, including the DNS name that resolves to the load balancing VIP.

When attempting email discovery in Receiver, if the certificate does not match discoverReceiver.email.suffix then users will see this message:

  1. The Certificates MMC snap-in can be used to create an internal certificate signed by a Microsoft Certificate Authority. The MMC method allows you to specify Subject Alternative Names.

  2. Or use the Server Certificates feature in IIS Manager to create or import a certificate.
  3. After the certificate has been created/imported on the StoreFront Server, in IIS Manager, right-click the Default Web Site and click Edit Bindings.
  4. Click Add.
  5. Change the Type to https and select the SSL certificate. Click OK and then click Close.
  6. Next step: change the Base URL inside StoreFront Console.

Delivery Controllers – SSL

Delivery Controllers can be SSL enabled by using one of two methods:

Once SSL certificates are installed on the Delivery Controller servers, then you can configure the Store to use SSL when communicating with the Delivery Controllers.

  1. In the StoreFront Console, on the left click Stores.
  2. On the bottom-right, click Manage Delivery Controllers.
  3. Highlight the deployment and click Edit.
  4. Change the Transport type to HTTPS.
  5. Make sure the Delivery Controller servers are entered using their FQDNs. These FQDNs must match the certificates installed on those servers.
  6. Click OK twice.

Base URL – Change

The StoreFront Base URL should point to a URL with a FQDN that resolves to a load balancing VIP that load balances the StoreFront servers. Receiver uses this Base URL to connect to StoreFront. If remote, Receiver will first connect to NetScaler Gateway and then use Gateway to proxy a connection to the Base URL.

If you are not following the Single FQDN procedure then the FQDN used for load balancing of StoreFront (Base URL) must be different than the FQDN used for NetScaler Gateway.

The StoreFront Base URL must be https. Receivers will not accept clear-text http URLs. This is true even for remote connections that are proxied through NetScaler Gateway.

  1. Configure load balancing of the StoreFront servers, including SSL certificate.
  2. In the Citrix StoreFront console, right-click Server Group and click Change Base URL.
  3. Enter the new Base URL in https://citrix.corp.com format. This must be https. Receivers will not accept http URLs.
  4. If the Base URL is https but you don’t have certificates installed on your StoreFront servers (aka SSL Offload) then you’ll need to run the following commands on the StoreFront servers. See No More Editing of Hosts File at Citrix Blog Post What’s New in StoreFront 3.0.
    & "C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"
    
    Set-DSLoopback -SiteId 1 -VirtualPath /Citrix/StoreWeb -Loopback OnUsingHttp

Authentication Configuration

If StoreFront is not in the same domain (or trusted domain) as the users, then you can configure StoreFront 3.0 to push authentication to the Delivery Controllers. See XML service-based authentication at docs.citrix.com. Note: StoreFront must still be a member of domain but the particular domain doesn’t matter.

  1. In the Citrix StoreFront console, on the left, right-click Authentication and click Add/Remove Methods.
  2. Check the boxes next to Domain pass-through and Pass-through from NetScaler Gateway. Click OK.
  3. If you intend to enable pass-through authentication from Receiver Self-Service or from Receiver for Web, run the command
    Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $True from a Windows PowerShell command prompt on a Controller.

    In XenApp 6.5, this is a Citrix Policy > Computer > Trust XML Requests.
  4. With User name and password highlighted in the middle, click Configure Trusted Domains on the bottom-right.
  5. Select Trusted domains only, click Add, and enter the domain names (NetBIOS and DNS). The DNS suffix is needed if doing userPrincipalName authentication.
  6. Select one of the domains as the default.
  7. If desired, check the box next to Show domains list in logon page. Click OK.
  8. With User name and password highlighted in the middle, click Manage Password Options in the bottom right.
  9. Make your selection and click OK.
  10. From Feng Huang at discussions.citrix.com: you can change the password expiration warning period by editing /Citrix/Authentication/web.config. Set showPasswordExpiryWarning to Custom and set passwordExpiryWarningPeriod to your desired number of days.
  11. Be careful with password changes. Any time somebody changes their password through StoreFront, a profile will be created for that user on the StoreFront server. Use a tool like delprof2.exe to periodically delete these local profiles.

Citrix Online Integration

  1. StoreFront might be configured to add the Citrix Online icons to Receiver. To remove them, on the left click Stores and on the right click Integrate with Citrix Online.
  2. Uncheck all three boxes and click OK.

Receiver for HTML5 – Enable and Upgrade

By default, Receiver for HTML5 is not enabled.

  1. In the StoreFront console, on the left, click Receiver for Web.
  2. On the bottom right, click Deploy Citrix Receiver.
  3. Change the option to Use Receiver for HTML5 if local install fails, and then click OK.
  4. To see the installed version of HTML5 Receiver, click the Receiver for Web node on the left. The version is displayed in the middle pane, in the bottom half.
  5. Download the latest Receiver for HTML5 and install it on one of the StoreFront servers. It installs silently. When you propagate changes, the Receiver for HTML5 should be copied to the other server.

  6. Customer Experience Improvement Program (CEIP) is enabled by default. To disable it, edit the file “C:\Program Files\Citrix\Receiver StoreFront\HTML5Client\configuration.js”.
  7. Search for the ceip section and change it to false.
  8. From About Citrix Receiver for Chrome 2.0 at Citrix Docs: The new toolbar can be disabled or customized by editing the file C:\Program Files\Citrix\Receiver StoreFront\HTML5Client\configuration.js.
  9. From About Citrix Receiver for Chrome 1.9 at Citrix Docs: To enable enhanced clipboard support, on every VDA set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\Virtual Clipboard\Additional Formats\HTML Format\Name=”HTML Format”. Create any missing registry keys. This applies to both virtual desktops and Remote Desktop Session Hosts.
  10. Citrix Blog Post Receiver for HTML5 and Chrome File Transfer Explained:
    • How to use the toolbar to transfer files
    • Citrix Policy settings to enable/disable file transfer
    • VDA registry settings to control file transfer
    • HTML5Client\Configuration.js settings for client-side configuration
    • How to view HTML5Client log file
  11. In the StoreFront console, on the left, right-click Server Group, and click Propagate Changes.
  12. Optionally, install Citrix PDF Printer on the VDAs. The PDF printer is in the Additional Components section of the HTML5 Receiver download page. This PDF printer is only used with Receiver for HTML5, and not with regular Receiver.

    1. Note: as of Receiver for HTML 2.0, it’s no longer necessary to install App Switcher on the VDAs.
  13. StoreFront can be configured to launch HTML5 applications in the same Receiver for Web tab instead of creating a new tab. See Configure Citrix Receiver for HTML5 use of browser tabs at Citrix Docs for more information.

Receiver for Web Timeout

  1. On the left, click Receiver for Web.
  2. On the right, click Set Session Timeout

  3. Set the timeout as desired and click OK.
  4. The session timeout in StoreFront 3.0 is not being reset correctly when a user launches an application. See Michael Bednarek’s code at discussions.citrix.com that fixes the problem.
  5. If you are using a NetScaler, you will need to change the Global Session Timeout located at NetScaler Gateway > Global Settings > Change Global Settings > Client Experience > Session Time-out (mins).

Receiver for Web Pass-through Authentication

If you enabled Pass-through auth in the Authentication node it does not enable it from Receiver for Web. If you enable it in Receiver for Web, additional configuration is required on the Receiver side to fully enable pass-through auth.

  1. On the left, click Receiver for Web
  2. On the right, click Choose Authentication Methods.

  3. If desired, check the box next to Domain pass-through. Click OK.
  4. If the StoreFront URL is in the browser’s Local Intranet zone then you’ll see a prompt to automatically Log On. This only appears once.
  5. If you try to launch an icon it will ask you to login to Windows. To fix this, you must also enable pass-through authentication on the client side (Receiver).

Unified Receiver Experience

If you did a clean install of StoreFront 3.0 or newer then the newer Receiver UI will already be enabled and you can skip this section.

If you upgraded from an older StoreFront then you can disable the Classic UI to enable the newer UI.

  1. On the left, click Receiver for Web.
  2. On the right, click Disable Classic Receiver Experience.
  3. Click Disable.
  4. On the left, click Stores. On the right, click Set Unified Experience as Default.
  5. Check the box next to Set the unified Receiver experience as the default for this store and click OK.

Customize Receiver Appearance

If the Unified Receiver appearance is enabled, you can go to Receiver for Web > Customize Receiver Appearance to change logos and colors. Additional customization can be performed using the SDK.

You can also Manage Featured App Groups.

These Featured App Groups are displayed at the top of the Apps > All page.

By default, Featured App Groups are displayed with continual horizontal scrolling. This is OK if you have several Featured App Groups but doesn’t look right if you only have one Featured App Group.

Michael Bednarek has posted some code at Citrix Discussions to disable the continuous horizontal scrolling. Also see CTX202415 StoreFront Featured Apps Group Appears More Than Once.

Additional StoreFront and Receiver customizations are available through the StoreFront APIs.

Default Tab

  1. By default, when a user logs in to StoreFront, the Favorites tab is selected. Users can go to other tabs to add icons to the list of Favorites.



  2. You can change the default tab to something other than Favorites by editing C:\inetpub\wwwroot\Citrix\StoreWeb\web.config in an elevated text editor.
  3. Search for defaultView or scroll to line 61. Change the defaultView to apps or desktops, or leave it set to the default of auto. Auto will select a tab in the following priority order depending on which tabs (views) are enabled: Favorites > Apps > Desktops.
  4. If you change it to default to the Apps view, then you might also want to default to the Categories view instead of the All view.
  5. You can do this by adding the following code to C:\Inetpub\wwwroot\Citrix\StoreWeb\custom\script.js. More details at discussions.citrix.com.
    CTXS.Extensions.afterDisplayHomeScreen = function (callback) {
         CTXS.ExtensionAPI.navigateToFolder('/');
    };
    
    CTXS.Extensions.onViewChange = function (viewName) {
      if (viewName == 'store') {
        window.setTimeout(function () {
        CTXS.ExtensionAPI.navigateToFolder('\\');
        }, 0);
      }
    };
    

  6. Then when you login to StoreFront you’ll see Apps > Categories as the default view. This works in Receiver too.
  7. To completely remove the Favorites tab, in the StoreFront Console, go to Stores > Disable User Subscriptions.
  8. When publishing applications in Studio, specify a Category so the applications are organized into folders.

Propagate Changes

Any time you make a change on one StoreFront server, you must propagate the changes to the other StoreFront server.

  1. In the StoreFront console, on the left, right-click Server Group and click Propagate Changes.
  2. You might see a message saying that you made changes on the wrong server.
  3. Click OK when asked to propagate changes.
  4. Click OK when done.

IIS Default Web Page

Citrix CTX133903 How to Make Storefront the Default Page within the IIS Site. To make a Storefront Web site the default page within the IIS site, complete the following procedure:

  1. Open Notepad and paste the following text:
    <script type="text/javascript">
    <!--
    window.location="/Citrix/StoreWeb";
    // -->
    </script>

    Note: Replace /Citrix/StoreWeb to the correct path to your Store’s Web site, if required. You can also put https://StoreFrontFQDN in the location field.

  2. Select File > Save As and browse to the IIS folder, by default the C:\inetpub\wwwroot is the IIS folder.
  3. Select the Save as type to All types.
  4. Type a file name with an html extension, and select Save.
  5. Open IIS Manager.
  6. Select the SERVERNAME node (top-level) and double-click Default Document, as shown in the following screen shot:
  7. Select Add…,
  8. And enter the file name of the .html file provided in Step 4.
  9. Ensure the .html file is located at the top of the list, as shown in the following screen shot:
  10. Repeat these steps on every StoreFront server.

Deploy Citrix Receiver from StoreFront

If you performed a standalone install of StoreFront, then it is configured to tell users to pull Receivers from Citrix’s website. Follow this section to configure StoreFront to download Receivers directly from the StoreFront server.

Or if you installed StoreFront 2.6 using the XenApp/XenDesktop 7.6 autoselect.exe and later upgraded it to StoreFront 3.0.4000, then StoreFront will probably have local Receiver clients that need to be upgraded. Both procedures are covered in this section.

  1. Go to C:\Program Files\Citrix\Receiver StoreFront\Receiver Clients\. Create a Windows folder if it doesn’t exist.
  2. In the Windows folder, paste the downloaded Receiver 4.8 for Windows (or Receiver 4.4.5000 LTSR), overwriting the existing file if one exists. Rename the file the CitrixReceiver.exe if it isn’t already. Do this on both StoreFront servers.
  3. Go back up to the Receiver Clients folder and create a Mac folder if one doesn’t exist.
  4. Copy the downloaded Receiver for Mac 12.6 to C:\Program Files\Citrix\Receiver StoreFront\Receiver Clients\Mac. Overwrite the existing file if one exists. Rename the file to CitrixReceiver.dmg.
  5. Go to C:\inetpub\wwwroot\Citrix\StoreWeb and edit the file Web.config. If UAC is enabled you’ll need to run your text editor elevated.
  6. Scroll down to the pluginAssistant section (line 52). If desired, change upgradeAtLogin to true. This will enable StoreFront to check the installed version of Receiver and offer to upgrade.
  7. If the win32 and macOS paths point to downloadplugins.citrix.com, you can change the paths to a local folder so that the Receiver is downloaded directly from StoreFront instead of from Citrix.com. Simply change http://downloadplugins.citrix.com to clients. Also, change the file names so they match the ones on your StoreFront servers.
  8. Close and save the file.
  9. Propagate Changes to the other StoreFront servers.
  10. When users connect to Receiver for Web, they will be prompted to install or upgrade. Note: this only applies to Receiver for Web. Receiver Self-Service will not receive this prompt.

Auto-Favorite

To force a published application to be favorited (subscribed), use one of the following keywords in the published application description:

  • KEYWORDS: Auto = the application is automatically subscribed. But users can remove the favorite.
  • KEYWORDS: Mandatory = the application is automatically subscribed and users cannot remove the favorite.

With Mandatory applications there is no option to remove the application from Favorites.

Related Topics

StoreFront Subscriptions – disable, control, replicate, etc.

StoreFront Tweaks – customize RFWeb, SSON for PNAgent, etc.

Install and Configure Citrix Receiver

Receiver for Windows 4.10.1

Last Modified: Jan 14, 2018 @ 9:56 am

Navigation

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

💡 = Recently Updated

Changelog

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.10.1 (Current Release), or version 4.9.1000 (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 auto-update at Citrix Docs.
  • See George Spiers Citrix Receiver for Windows Auto-Update.

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

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 – enables Receiver auto-update notifications
    CitrixReceiver.exe /AutoUpdateCheck=auto
  • /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.

Registry value at HKLM\Software\Wow6432Node\Citrix\AuthManager on the Receiver machine:

  • ConnectionSecurityMode = Any. Only if using http (instead of https) to connect to StoreFront.

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 = 0 (DWORD)

To enable foreground progress bar, set:

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

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|.
    • Enable or Disable AutoUpdate
  • 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 prevent the window from opening. This causes all icons to be placed on the Start Menu.
    • Enable Manage App Shortcut and configure it as desired.
    • 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.10.1 (Current Release), version 4.9.1000 (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.
    1. You can also download the ADMX files from one of the Receiver download pages (version 4.10.1 (Current Release), version 4.9.1000 (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 AutoUpdate can be configured using group policy. See Configuring auto-update 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 – Shortcuts

Here is a summary of steps to use Receiver to control shortcuts on a published desktop. The source of this complexity is that there is no session sharing between published apps and published desktop, so instead we must use some other means of creating shortcuts.

  1. Make sure Receiver (version 4.10.1 (Current Release), version 4.9.1000 (LTSR), or version 4.4.5000 (LTSR)) is installed on the VDA.
  2. 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 server 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.
  3. 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 separate Self-Service GUI and assumes all icons are subscribed.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\PutShortcutsOnDesktop = True to place icons on the desktop.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\StartMenuDir to place published applications in a sub-folder.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\DesktopDir to place published applications in a sub-folder on the desktop.
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle\UseCategoryAsStartMenuPath = True.
    • 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.
  4. 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 zone.
    3. Make sure ssonsvr.exe is running after you login to the VDA. If not, troubleshoot it.
  5. When configuring Citrix Profile Management, make sure !ctx_startmenu! is not excluded. You can do one of the following: edit the Studio policy, edit the GPO, or edit the .ini file.
  6. In 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 published application and on the Delivery tab specify a category. This will become the Start Menu folder name.
    2. If Receiver Self Service Mode 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.
    3. Another option is to go to the StoreFront Console, click Stores on the left, and on the right click Disable User Subscriptions. This causes all apps to appear on the Start Menu and/or Desktop depending on Receiver configuration.
    4. 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 session.  See Ralph Jansen Citrix Receiver 4.1 Prefer keyword examples
    5. 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.
  7. The default Windows 2012 Start Menu has limitations for nested folders, duplicate icons, etc. Consider installing a Start Menu Replacement.
  8. In Studio, create a StoreFront object with a URL 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. In Studio, assign the StoreFront object to the delivery group from which the desktop is published.
    2. Instead of Studio, you could use group policy to define the Store.
  9. On your Delivery Controller, in PowerShell, run set-brokersite -TrustRequestsSentToTheXmlServicePort $true
  10. 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.

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.

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.