Managing published XenDesktop applications with RES ONE Workspace

Introduction
For a while now RES has supported the management of published applications from Citrix XenApp. This was quite easy to do. Before the release of XenDesktop 7 there wasn’t really a difference between a Data Collector and a Session Host. Both had the same XenApp installation and if was just a matter of configuration as to which role the server had. You would need the RES Workspace Manager Console on one of the XenApp servers and you could simply select Enable Citrix XenApp Application Publishing, define your preferred options and servers and you were good to go.

In XenApp/XenDesktop 7.x this is a bit different. Since the session hosts only contain the Virtual Delivery Agent the requirements are a bit different. You need a machine with the full installation of RES ONE Workspace (Agent + Console) and the Citrix Studio. I will try to define and explain each step from the publishing to the application shortcuts.

Before you can publish anything you need to configure which delivery controller is contacted when publishing the application. You can do this from the RES ONE Workspace console under Setup -> Application Virtualization -> Citrix XenApp Publishing.

Supply your site name and the Delivery Controller of choice. On the Defaults tab you can do a refresh of the available Delivery Groups (of the Application or Desktop/Application type). Keep in mind that the refresh button will only be shown on machine that also has the Citrix Studio installed. You are now ready to publish the applications in the same way as when you were still running XenApp 6.x.

However, most of the time you want these applications to be visible in the start menu like any other RES ONE Workspace managed application (Program Neighborhood Agent-style). This way you can start these applications the same way as you would a local application.
But to get this working isn’t as easy as it was a with the previous XenApp versions. ROW basically leans on the native Citrix Receiver, which should be correctly configured to make these applications visible in the start menu.
For a customer I made a list of all the required steps to achieve this, so here we go:

1. Configure Citrix XenApp Publishing in RES ONE Workspace:

Setup -> Application Virtualization -> Citrix XenApp Publishing.

Supply the site/farm name and the Delivery Controller which can be used for publishing.

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 1
Don’t forget to press Save Settings!

2. Create a XenDesktop Delivery Group that is configured for Applications (or Desktop & Applications):

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 2

3. Enable publishing on the chosen application(s):
You can do this from the Publishing tab in the application settings. You also need to specify which Delivery Group should be used for publishing (Server tab). As mentioned before, the machine on which you perform this action should have the Citrix Studio installed and of course the RES ONE Workspace Console.

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 3

4. Make sure Citrix Receiver is installed on your ROW-managed devices/desktops with the correct components:
The Authentication Manager and SelfService components need to be installed on the Citrix Receiver.
I’m guessing (and also hoping) everyone does this unattended in their builds, so with that in mind you need to add the following to the /ADDLOCAL part of your installation:
AM,SELFSERVICE

So on my current setup (Receiver 4.5) it looks like this:
CitrixReceiver.exe /silent /includeSSON ENABLE_SSON=YES /ALLOWADDSTORE=N /ADDLOCAL=ReceiverInside,ICA_Client,SSON,DesktopViewer,
AM,SELFSERVICE
/EnableCEIP=false

(Check the following site for a detailed explanation of all the options and switches: https://docs.citrix.com/en-us/receiver/windows/4-5/install/receiver-windows-cfg-command-line-42.html)

5. Add your StoreFront deployment to your XenDesktop 7.x site:
In the Citrix Studio at Configuration -> StoreFront, you need to add the StoreFront deployment. It will ask for a name, a description and a URL. Name and description is just that, so think something up to your liking. The URL should be the one of your store (not the web store) with /discovery appended to it. So basically it looks like this:
https://[StoreFront-Base-URL]/Citrix/[Store-Name]/discovery

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 4

6. Enable Receiver configuration in the Delivery Groups
For each Delivery Group (that contain desktops in which the published applications should be presented in the start menu) you need to specify which StoreFront configuration should be applied to the Citrix Receiver in the desktop.
Edit the Delivery Group and go to the StoreFront page. Select the option Automatically, using the StoreFront servers selected below and the Receiver StoreFront URL that you would like to use (multiple URLs are also possible).

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 5

5 & 6 (Alternate). Use a Group Policy Object to configure the Receiver:
You can also use a Group Policy Object to configure the correct StoreFront URL. Create a GPO and enable and configure the following setting (with the Receiver.ADMX template):

Computer Configuration -> Policies -> Administrative Templates -> Citrix Components -> Citrix Receiver -> Storefront -> NetScaler Gateway URL/StoreFront Accounts List

Add a line in the following syntax:

[Store-Display-Name];https://[StoreFront-Base-URL]/Citrix/[Store-Name]/discovery;[Store-State (On-Off)];[Store-Description]

Example from my lab setup:

SF1;https://storefront.local.lan/Citrix/Store/Discovery;On;StoreFront

Apply the GPO to your session hosts and devices.

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 6

FYI: You can also define the store in the Receiver unattended installation command, but this would make future alterations more difficult.

7. Use a Group Policy Object to enable Single Sign On for the Citrix Receiver:
Next task is to enable Single Sign On for the Citrix Receiver. You can do this with a local Group Policy setting or with a domain GPO. Personally I prefer the latter.
Enable and configure the following setting:

Computer Configuration -> Policies -> Administrative Templates -> Citrix Components -> Citrix Receiver -> User authentication -> Local user name and password

Make sure the following options are selected:

Enable pass-through authentication
Allow pass-through authentication for all ICA connections

Apply the GPO to your session hosts and devices.

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 7

8. Use a Group Policy Object to disable the application shortcuts:
Since you are running RES ONE Workspace, the published application shortcuts will be provided by the Composer. But Receiver will also create application shortcuts. This would mean that every published application is shown twice in the start menu. To solve this you can disable the ones from Receiver with a GPO.
So create a GPO (or use the one from the previous step) and enable and configure the following settings:

Computer Configuration -> Policies -> Administrative Templates -> Citrix Components -> Citrix Receiver -> SelfService -> Manage App shortcut

Select the following option:

Disable Startmenu Shortcut

Apply the GPO to your session hosts and devices.

You can also configure these settings in the registry. Check the following URL for more information: https://docs.citrix.com/en-us/receiver/windows/4-3/ica-overview-receiver-config/receiver-windows-configure-app-delivery-wrapper.html

Managing published XenDesktop applications with RES ONE Workspace - Screenshot 8

9. Add the StoreFront site to the intranet or trusted zone on your clients/vitual desktops:
To make sure a Single Sign On to the defined StoreFront site is possible the site needs to be added to the Local intranet or Trusted sites zone on your clients/virtual desktop. Your main goal is actually that the Automatic logon is allowed. You can find this setting in the User Authentication section after clicking on Custom level in the Security tab in your Internet Options.

You first need to find out in which zone the StoreFront site currently is. You can do this by browsing to the web version of it and opening the properties of the page. It should show the current zone. This probably will show Internet. If it shows Local intranet and your security level for that zone is still default, then you are good to go.
But if it isn’t then you would need to do one of the following:

– Add StoreFront site to Local Intranet zone and set the Security Settings for logon to Automatic logon only in Intranet zone.
– Add StoreFront site to Trusted Sites zone and set the Security Settings for logon to Automatic logon with current user name and password.

Now a GPO could do this with the settings under Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page. But this wouldn’t be my first choice since it will block the user from making any other adjustments to the specific zone.
My suggestion would be to just add the relevant registry keys through RES ONE Workspace or a GPO.
The registry keys for when going for the Local Intranet lab setup are as follows:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\local.lan\storefront]
"https"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1A00"=dword:00020000

So you would create a key for your domain, a sub-key for your sub-domain and a value for https (and http if you want) with in the data field the number of the chosen zone. After that you would need to change the 1A00 value in the chosen zone to the correct data.

Zone numbers:
0 My Computer
1 Local Intranet Zone
2 Trusted sites Zone
3 Internet Zone
4 Restricted Sites Zone

Logon values:
0x00000000 Automatically logon with current username and password
0x00010000 Prompt for user name and password
0x00020000 Automatic logon only in the Intranet zone
0x00030000 Anonymous logon

Choose the correct number and value for your chosen solution and add them through RES ONE Workspace or GPO.

Footnote:

These were all the steps that you need to do the have the ‘RES ONE Workspace published Citrix XenDesktop applications’ perform in a ‘Program Neighborhood Agent-style’. Of course you can also use this guide if you don’t use ROW and want the start menu shortcuts managed by Citrix Receiver. Just ignore all the RES steps and don’t do step 8.

Feel free to comment or point out things I got wrong. 😉

1,971 total views, 1 views today

2 thoughts on “Managing published XenDesktop applications with RES ONE Workspace

  1. Jason McCutcheon

    Hi,

    Really nice write-up here; and puts it in a way that those not familiar with RES (such as myself) in to an easier to understand context.

    Two probably very daft questions -:

    1) I assume that when you publish into RES – it automatically updates Studio to then in turn update Receiver.

    2) If you have the RES One Agent installed on an XenApp host and use this method to publish the applications; does it check the server your logged in on and validate if the application is installed against that XenApp Server (basically Session Sharing in old Citrix terms) rather than launching a new session to another XenApp Host?

    Thanks for any input you have on these queries.

    Jason

    Reply
    1. Chris Jeucken Post author

      Jason,

      Thanks for the compliments.
      And no question is ever really daft. 😉

      1: The RES ONE Workspace Console uses the PowerShell snapins that are installed along with Citrix Studio and basically performs the exact same commands as when you would use the Studio itself. So it updates the farm itself. Studio is just a management shell and in itself doesn’t contain any config. Receiver in turn connects to the farm and ‘sees’ all the published resources (including the new application).

      2. Not by default. You can enable the option Do not passthrough if application is available on local computer on the Behavior-tab of the Instant passthrough settings. With that enabled it should check if the application is available on the current host.

      Please let me know if this helps. 😉

      Greetings,
      Chris

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *