I came across a problem recently where users were having problems opening links to certain SharePoint sites from within a Citrix XenApp environment. For some reason, the XenApp hosted sessions were asking for authentication when hitting the SharePoint front end. Whilst this certainly indicated some sort of misconfiguration within the environment itself – client desktop sessions, for instance, had no problem accessing the links through single sign-on – we decided to use XenApp host-to-client redirection to solve it. Not only would it address the issue at hand whilst further investigation of the root cause took place, it would also achieve one of our other goals, which was to offload browser traffic, where possible, away from the XenApp environment. Users were to continue to use Office applications such as Outlook from within XenApp, but browser sessions would ideally be sent back to the local machine for processing.
Host-to-client redirection is exactly what it says on the tin – redirection of content (URLs) from the XenApp host back to the Citrix client. The host-to-client redirection process only works on server VDAs, not on desktop VDAs. In a lot of situations, host-to-client redirection is not commonly used – the VDA already optimizes multimedia, and both multimedia and Flash redirection can be configured individually through policies where necessary. However, in certain situations, host-to-client redirection can be used to get around problems with performance, compliance or compatibility. It is supported on Citrix Receiver for Windows, Receiver for Mac, Receiver for Linux, Receiver for HTML5, and Receiver for Chrome.
An example of host-to-client redirection that I used previously to this was to open up a search engine on the client rather than in a hosted app, as the search engine in question used geolocation for some particular features, and the users were in India, whereas their hosted applications were in a European datacenter. Redirecting the link to the search engine back to the client browser allowed the site to geolocate properly.
XenApp 7.13 and higher introduces a policy for “URL redirection” with accompanying whitelists and blacklists, but if you’re on an older version this is not an option. In this situation you need to use host-to-client content redirection, which is a type of server FTA (File Type Association) redirection. This FTA redirects certain protocols to the client, such as http, https, rtsp, or mms. For example, if you only open embedded links with http, the links directly open with the client application. There is no URL blacklist or whitelist support as with the newer URL redirection policy (although you can configure some level of control using Registry keys, which we will show in this article).
Considerations
It is important to understand which particular situations will trigger host-to-client redirection to function. It activates when URLs are:-
Embedded as hyperlinks in an application (for example, in an email message or document, as in my example)
Selected through a VDA application’s menus or dialogs, provided that the application uses the Windows ShellExecuteEx API
Entered in the Windows Run dialog
It does not activate for URLs entered into a web browser, links clicked within a web browser, standard Windows shortcuts, browser Favourites or Bookmarks, or URLs passed as a parameter to an application command line. If you wish to work with URLs entered in the web browser, then URL redirection is the preferred method. I will do an article on “bidirectional content redirection” (to give it the correct name) as a follow-up to this one, but as mentioned earlier that requires version 7.13 or above.
The default application on the client for the URL type specified is used to open the link. If there is no default app available, then the link will be redirected back to the host again.
The final consideration is that when users have their URLs redirected locally, they may not have access to environmental features that they get in the hosted application, such as drive mappings and printers. It is important to think about how users may try to use the redirected site and ensure that the expected functions are available to them.
Configuration
The host-to-client redirection is done with a Citrix policy, whether on 6.5 or 7.x
You can filter the policy in any way you require, using standard Citrix methods 
Once the policy is applied, this will attempt to redirect all of the following URL types that are launched in the above-mentioned fashions (specifically, http, https, rtsp, rtspu, pnm and mms). I did wonder if the RTSP protocol redirection would affect App-V 4.x applications being launched that use the RTSP protocol. Fortunately, it does not seem to affect these, although I would advise testing if you use links to RTSP App-V applications from within your published resources.
If you wish to restrict or extend the particular URL types that are launched, you can set Registry values that allow you to customize the URL types that are redirected.
To restrict the URL types use these two values:-
Key: HKLM\Software\Wow6432Node\Citrix\SFTA
Name: DisableServerFTA
Type: REG_DWORD
Data: 1
Name: NoRedirectClasses
Type: REG_MULTI_SZ
Data: Specify any combination of the values: http, https, rtsp, rtspu, pnm, or mms. Enter multiple values on separate lines. For example:
http
https
rtsp
To extend the URL types, use this value:-
Key: HKLM\Software\Wow6432Node\Citrix\SFTA
Name: ExtraURLProtocols
Type: REG_MULTI_SZ
Data: Specify any combination of URL types. Each URL type must include the :// suffix; separate multiple values with semicolons as the delimiter. For example:
customtype1://;customtype2://
Combining these Registry values will allow you to produce specific sets of URL types to be processed.
However, if you wish to use specific sites instead of URL types, you can use a different Registry value (this is the method I prefer). This will only redirect the sites you specify in the Registry value. This works great for the example I had, in which I want to redirect Sharepoint sites back to the local browser. The Registry value is:-
Key: HKLM\Software\Wow6432Node\Citrix\SFTA
Name: ValidSites
Type: REG_MULTI_SZ
Data: Specify any combination of fully-qualified domain names (FQDNs). Enter multiple FQDNs on separate lines. An FQDN may include a wildcard in the leftmost position only. This matches a single level of domain, which is consistent with the rules in RFC 6125. For example, we used this:-
*.microsoftonline.com
*.sharepoint.com
www.office.com
When using this value, it is important to remember that it’s not where the link points that is compared to the Registry settings, it is the actual destination page. For instance, redirecting *.google.com does not work when clicking on the www.google.com URL if the actual page is redirected to www.google.co.uk.
In the same vein, www.yahoo.co.uk could be whitelisted, but this redirects to http://uk.yahoo.com so would not work unless you specifically added uk.yahoo.com or *.yahoo.com to the Registry value.
If you’re using a version of Windows on the server end prior to 2012, then this is all the configuration you need to do, so for XenApp 6.5, you’d be ready to deploy right now.
However, Server 2012 and upwards introduce some very annoying changes to how FTAs are handled (which is essentially what URL types translate to). For host-to-client redirection to work on these platforms you will need to follow these steps.
First, create an XML file with the following content:-
<?xml version=”1.0″ encoding=”UTF-8″?>
<DefaultAssociations>
<Association Identifier=”http” ProgId=”ServerFTAHTML” ApplicationName=”ServerFTA” />
<Association Identifier=”https” ProgId=”ServerFTAHTML” ApplicationName=”ServerFTA” />
</DefaultAssociations>
Save this file in a network location that the VDAs can access.
Next, configure the GPO for Computer Config | Admin Templates | Windows Components | File Explorer | Set a default associations configuration file to Enabled, and point the setting to the file you created above. The downloadable example GPO below contains this setting, but obviously you must point it to the right path!
Note – if you are on Server 2016, make sure that the OS is fully patched. There was a bug in Server 2016 whereby a default associations file, as above, would not apply until second logon. The bug is fixed by the latest patches for the OS.
Next, you need to set a whole bunch of Registry values on your VDA machines. The easiest way to configure this is through Group Policy Preferences, although you can use many different ways to do this. The downloadable example GPO below contains all of these settings ready for you.
Downloadable GPO with settings
The settings are listed here also:-
Note that the GPO above also contains a setting for ValidSitesList, so you will need to change this as well if you wish to use it for the sites you require, or remove it.
Once you’ve applied the Registry values and the GPO for file type associations with the XML file provided, you can now deploy it to machines running XenApp 7.x.
If you’ve configured everything correctly, you should see that for the sites and/or URL types you have specified (or all of them), you will now be redirected out of your XenApp application or session and back to the local client browser.
I will be recording a video on this, I will post the link here as soon as it is uploaded.
Summary
So, that’s how to configure host-to-client redirection on XenApp. Ideally, this method is best for situations requiring simple URL redirection of embedded links from published applications, or on older XenApp versions such as 6.5. You can use the provided Registry values to filter it as necessary to your needs.
Share
