At the beginning of December 2014 Citrix released the Receiver 4.2. One of the biggest (and most mentioned) improvements is the better start menu integration (If you want to know how to configure it read this blog article).

The question now is: Is Receiver 4.2 a valid replacement for Receiver 3.x Enterprise?

To make it short – from my point of view it can be a replacement if you plan to use it on your fat clients and can live with some limitations – but not on published (RDS) desktops (or you need to live with bigger limitations). Let’s have a more detailed look why I think Citrix really needs to update / optimize the Receiver as soon as possible.

Fat Clients

Most of the users prefer to start their applications from the start menu – independent if it’s installed locally or published. The ideal world would look like this:
You install the Receiver, configure a GPO and the applications are directly published to the start menu – the user doesn’t need to open the Receiver and is happy. On fat clients this is working with some limitations with Receiver 4.2.

Startup Time / App Enumeration

After logging in the Receiver needs some time to start completely. Furthermore the app enumeration can take really long. There are some optimizations to speed up the App Enumeration a little bit – but only if you remove shortcuts at logoff or exit – it won’t help you if the user logs on for the first time. One way is to create the following registry key:

HKLM\Software\Citrix\Dazzle
Name = ReuseStubs
Type = REG_SZ
Value = true

Application Refresh

In the default configuration the automatic refresh (after logging) in is not always working – with Receiver 3.x Enterprise the user logged on and a refresh of the published applications happened.
To activate the same refresh under Receiver 4.2 you need to configure the following registry keys (see CTX140244):

HKLM\SOFTWARE\Wow6432Node\Citrix\Dazzle\
Name: InitialRefreshMinMs
Type: REG_SZ
Value: 1

HKLM\SOFTWARE\Wow6432Node\Citrix\Dazzle\
Name: InitialRefreshMaxMs
Type: REG_SZ
Value: 1

Shorcut Removal

As known from Receiver Enterprise 3.x the Receiver 4.2 can automatically remove the created application shortcuts. The configuration for this has moved from the Webinterface to the Receiver. The easiest way to configure this is to create a GPO with the Receiver ADM files and configure the following settings:

Computer Configuration => Policies => Administrative Templates => Classic Administrative Templates (ADM) => Citrix Components => Citrix Receiver => SelfService => Manage App shortcut

Sounds easy or? It is – it’s only sometimes just not working. This means if someone exits or logs off Receiver the created shortcuts are not removed.

Warning of Removed Applications

Another thing is that the user always receives a notification if an application is no longer available for him. So if you remove the assignment of an application the user receives the following message:

After clicking on this message the following is shown (if SelfServiceMode is disabled – otherwise the Receiver is shown and the removed application is greyed out):

In CTX140244 you can find the following registry:

HKLM\SOFTWARE\Wow6432Node\Citrix\Dazzle\DontWarnOfRemovedResources
Type: REG_SZ
Value: True

After reading the description I thought that this would help me to prevent the above mentioned messages:

To prevent dialog boxes when resources are removed from the server, use the following command syntax:

Well – the setting disables a message – but only the second one so that the user doesn’t need to confirm the removal. The first message is still displayed.

 

XenApp (RDS) Desktop

 

All of the above things are also valid if you use the Receiver on a published desktop – but there is one more thing….

If you have a lot of Thin Clients (and I know a lot of environments where that is the case) you usually publish a full Desktop. Some of the assigned applications are installed on the same server while others are installed on different ones. The start menu is cleared. The user only sees the applications assigned to him (published through Receiver) and not all of the installed applications.
In the past the Receiver (3.x) checked if the application is installed locally and then starts it directly while the other are started remotely (also called remoting). This was easy to handle: Install application, clear start menu, publish application.

With Receiver 4.2 this isn’t working any longer – the application is always started remotely – even if it’s installed on the local server. To fix this some configurations need to be done:

1. Create a folder on the Server with a shortcut for every application that is installed locally (of course only for the ones you plan to publish)
2. Create the following Registry-Key
   • HKLM\SOFTWARE\Wow6432Node\Citrix\Dazzle
   • Type: REG_SZ
   • Name: PreferTemplateDirectory
   • Value PATH TO CREATED FOLDER
3. Change the application properties of every application that is installed on the published desktop and add the following description:
   • KEYWORDS:prefer=SHORTCUTNAME
   • Replace SHORTCUTNAME with the name of the local saved shortcut (Step 1).

Though you can see it’s a lot more to do until you have the same behavior like with Receiver 3.x Enterprise.

Furthermore you need to know that if the Receiver detects a local shortcut it copies and renames this one to the Start Menu – it’s not a new Shortcut created with the settings of the published applications. This means if you change an application property (e.g. parameters) you always need to change this in the published application and in the local saved shortcut. Not nice…

During the last tests and implementations I figured out that after configuring the above mentioned settings – to prevent remoting – only some of the applications are published from the receiver to the start menu. After checking the edocs I saw the following statement:

Before installing an application on a user’s computer, Receiver searches for the specified patterns to determine if the application is installed locally. If it is, Receiver subscribes the application and does not create a shortcut. When the user starts the application from the Receiver window, Receiver starts the locally installed (preferred) application.

Interestingly in this blog post Thomas Fuhrmann says shortcuts are automatically created:

When using such a template directory (which can also be a network share) Citrix Receiver first checks in thatdesignated folder for a matching shortcut and then copies this shortcut to the start menu.

Sounds like even Citrix doesn’t know if shortcuts are copied – or not. During my tests shortcuts were only copied to the start menu when no application category was configured. As soon as this was configured – to structure the applications into folders – the shortcut was not longer published.

Until now I only found one solution for this; Remove the shortcut creation (on the published desktop) from the receiver and replace it with a simple script – until Citrix publishes a Receiver version which is working in all conditions. I am not a PowerShell Guru – so if you know how to make it better – just send me an information and I will update the script. The script first checks for existing shortcut and removes them to make sure that if an application is no longer assigned to a user it’s not visible any more. Then it creates the folders and shortcuts.

#Get Current User Informations and configure path to start menu
$CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$WindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($CurrentUser)
$StartMenuFolder = PATH TO USER STARTMENU

#Remove Existing Shortcut Folders
if (Test-Path "$StartMenuFolder\Programs\FOLDERNAME\" -PathType Container)
{
    Remove-Item "$StartMenuFolder\Programs\FOLDERNAME\" -Recurse
}

#Create Application Shortcut Example
if ($WindowsPrincipal.IsInRole("GROUP NAME") -eq "True")
{   
    if (!(Test-Path "$StartMenuFolder\Programs\FOLDERNAME\" -PathType Container))
    {
        New-Item -ItemType directory -Path "$StartMenuFolder\Programs\FOLDERNAME\"
    }
    Copy-Item "C:\SHORTCUTPATH\SHORTCUTNAME.lnk" -Destination "$StartMenuFolder\Programs\FOLDERNAME\SHORTCUTNAME.lnk"
}

Conclusion

As you can see Citrix made some improvements (compared to the first 4.X releases) to get the receiver as good as it was before – but there are still a lot of things left. Hopefully Citrix will release a nice, fast and easy configurable Receiver in the near feature (and you know – the hope dies last). Actually I don’t understand why such an important component in the whole Citrix universe doesn’t get more attention.