Adventures with Receiver 4.1

Posted: February 19, 2014 in Citrix

I’m currently preparing to rollout Receiver 4.1 in our environment.  The primary driver has been the need for some of the fixes that have not been backdated to the 3.4 Receiver, and the fact that Citrix is pushing all the development on this new version.  Since we are migrating to XenDesktop 7.1, this is an important step in laying out that ground work.

I have spent weeks and weeks with the installation working on automating as much of user process as possible.  We’re working with our terminals joined to the domain (needed for the biometric authentication). The users log in to their terminals with the domain accounts.  Currently with the 3.4 version, the Receiver connects and populates shortcuts on the desktop and the start menu.  I am working on duplicating as much that same functionality with the 4.1 Receiver.

Out of the box, there are a number of features that are not installed by default, and it requires a command line installation to get them installed properly. (I suspect that last part is not entirely true, but I’ll discuss that later).  When you install the Receiver, by default, it does not install the pieces to do pass through authentication, and likely does not necessarily install the USB pieces, the Flash redirection, etc.  Well, our goal is to have people automatically logged in, and not add a 2nd login for this.  Overall, this is really a step backward.. you cannot control the passthrough login feature from the StoreFront server like you could in Web Interface.  So, on to Citrix eDocs (as you will recognize from my previous post.. not my favorite place have to go).  I looked up the directions and they are remarkably similar to Receiver 3.4.  That was definitely helpful.. I already had working scripts for that.

The 2 sets of directions are here: for the 3.4 Receiver, and for the 4.x Receiver.   I’ll cover the various switches for the 4.x installation here and what they mean.

/silent and /noreboot are pretty self-explanatory; they make the installation completely silent, and tell it to not reboot the system.  The /noreboot is important in that if you use it, the 4.x Receiver is not fully usable until the system has been rebooted.  This is not terrible in and of itself, but it’s good to know.

/includeSSON – this tells the Receiver to install the single signon.  This is *not* the same as Citrix Single Sign-on (the old Password Manager which is being dropped).  This is the piece that does the passthrough authentication for the Receiver.  If you are not using other options in the installations this is supposed to be enough to get it working according to Citrix technical support.  (I have not verified this).  A key point to this is that it installs the ssonsvr.exe.  This process is what does the credential passthrough to the client.  (I’ll be discussing this more later).

There are several other options that can be used.  These are the same between 3.4 and 4.x. I believe these are used to pass to the internal MSI file, and they probably have to be capitalized because of it.

  • INSTALLDIR – tell it where to install the client to.  I’ve never seen it installed to an alternate location, but it is good to know that it is available.  By default, it installs to (x64 systems) c:\program files (x86)\Citrix\ICA Client and to (x86) c:\program files\Citrix\ICA Client.
  • CLIENT_NAME – this allows you to override the CLIENTNAME used by the XenApp server or by the VDA.  It overrides the default of %computername%.   I’m not sure why someone would want to do this, but again, it’s a nice to have option.
  • ENABLE_DYNAMIC_CLIENT_NAME – this tells it to allow the client name to be set dynamically.  This is the default.. it sets that name on the fly.  But to use the manual override from CLIENT_NAME, then you have to use this option and set it to No.  I’m not sure why you’d have to have multiple options to do the same thing, but you do.  My thought would be if you have CLIENT_NAME set, then it would automatically eliminate the dynamic clientname.
  • ADDLOCAL – this lets you customize the pieces that will be installed.   Again, we have several suboptions to this that are the same between them.
    • ReceiverInside – this is the piece that causes the plugins to appear inside of the Receiver. Currently, there still are not many actual plugins to handle, but they do exist.
    • ICA_Client – this is of course the ICA Client. It is a plugin, and is obviously necessary to do anything useful. I’m not sure this should even be an option?
    • SSON – this is the passthrough authentication piece. If you specify components, you need to add this for it to work. In my experience, even if you use the /includeSSON, you must still use SSON here.
    • USB – this enables the USB redirection capability. This obviously depends on your needs.
    • Flash – this enables Flash redirection. Currently, I don’t use this option since we are using terminals. With the terminals,the Flash movie is downloaded to the temp directory and executes from there (assuming flash is installed on the client). With the terminals, the temp directory is on a RAM drive and is limited to 100MB by default. With even a couple of flash items, or a semi-large video it will run out of space and crash. Therefore, I leave it out. If we had more PC’s in the environment, I’d probably mix the two installations.
    • DesktopViewer – this is piece that provides the Connection Bar inside of desktop sessions. Supposedly, if you connect to a published app with this enabled, it can cause issues. I use this option regularly, and I haven’t run into this.
    • Vd3d – this enables HDX 3d Pro. We don’t use any 3d apps, so this isn’t needed for our environment
  • ENABLE_SSON – this is needed to activate the Single Sign On. Again, I’m not sure why this would be needed if you already have the option installed, and another flag already set? But, it’s still required per Citrix.

This is where the similarities stop.  Here are the options for Receiver 4.x (I’m not covering the Receiver 3.4 in this article).

    • AM – Authentication Manager. This is necessary to work with SSON to get the passthrough working. According to Citrix, it must be listed before the SSON item.
    • SelfService – this is the portion that supports the portion where the user can subscribe to applications
  • ALLOWADDSTORE – this setting controls whether the user is allow to add a store not predefined by the administrator
  • ALLOWSAVEPWD – this setting controls whether the user can save their password in the Receiver. I’m not sure how this would work if combined with stores from multiple domains. My guess would be that it would be saved on a per-account basis, but I have not had the chance to look into this.
  • AM_CERTIFICATESELECTIONMODE – This is used to configure SmartCard options.
  • AM_SMARTCARDPINENTRY – This sets the usage of the PIN option of the SmartCard
  • ENABLE_KERBEROS – this controls the use of Kerberos for pass through authentication
  • LEGACYFTAICONS – this is used exclusively for XenApp and is the equivalent of the old file-type association icons generated through the XA farm. It allows the Receiver to configure local icons to use the published applications.
  • ENABLEPRELAUNCH – this is used exclusively for XenApp on the backend of the Store. It allows the receiver to cause a user session to launch when the receiver logs in, without an application being launched
  • STARTMENUDIR – this allows you to place the icons generated under the specified subfolder in the Start Menu. It may work with XenDesktop? I haven’t tested it.
  • STORE0..STORE9 – this allows you to predefine up to 10 stores for the clients. Each STORE# entry is a separate Store (account)
  • ALLOW_CLIENTHOSTEDAPPSURL – this is for the new XenDesktop 7.x capability. It allows applications on the local system to be projected into an ICA connected desktop and appear as part of that desktop. It is the reverse of Seamless Applications. I plan to use this in my XD 7.x environment. This is a really exciting capability.

Based on that, I went through several iterations of the client install trying to reach my goal. In the end, I ended up with this command line:

CitrixReceiver.exe /silent /includeSSON ADDLOCAL="ReceiverInside,ICA_Client,AM,SSON,USB,DesktopViewer,SELFSERVICE" ALLOWADDSTORE=S ALLOWSAVEPWD=S ENABLE_SSON=Yes STORE0="StoreName;;On;Published Desktops" ALLOW_CLIENTHOSTEDAPPSURL=1
[Edited 11/23/2015 to correct the order for AM & SSON in the ADDLOCAL part of the statement]

Most of this is fairly obvious. but some of the things that came out during my call with Citrix:

  • That the StoreName has to match the actual name in the interface in the StoreFront console.  It is also case-sensitive (again, per Citrix).
  • The AM needs to precede the SSON in the ADDLOCAL option.
  • The On in the Store description determines whether the account is activated within the console itself.  The eDocs says that it is to determine if you are delivering disabled stores, but that does not seem to be quite the case.  It seems to deliver all the stores, but then it leaves the ones marked as Off to be included, but the check mark within the Receiver not marked.   This could just be confusing wording in the eDocs..
  • In the Store definition on the command line the name provided must match the name in the StoreFront console (including case-sensitivity).  I really don’t understand why you need to put the name of the store when you are already providing the full URL to the store itself, and much of the information comes from the discovery sub-path. 
  • The 4.x Receivers do not create desktop icons.  (This is old news from Receiver 3.4 (non-Enterprise) but I still wanted to confirm it here for anyone reading.

So, now I have a stable script that installs the Receiver.  But on the first test, the passthrough piece didn’t work correctly.  I had my StoreFront configured correctly to add the passthrough authentication, but it still didn’t work.  I uninstalled it and reinstalled it multiple times, and a couple of times, the passthrough worked, but on most of them it didn’t.  That made no sense.. back to the phones with Citrix.  It turns out one of the “troubleshooting” steps is to change the Network Provider order and move the Citrix Single Signon service to the top of the stack.  That made me take a step back.. I hadn’t had to deal with the Network Provider order since the last time I had to integrate Citrix with Novell, years ago.  Because we’ll be imaging the terminals this won’t be much of an issue, but if it is really needed, then to me, Citrix should automate that as part of the install. It is handled by a simple registry value.  HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder = REG_SZ.  I will likely create a script to help automate that process as part of a wrapper for the install.

Now, I have my passthrough working.  At this point, this represents a lot of work.. uninstalling, reinstalling, playing with options, etc. But, another wrinkle came up today as I am finalizing the process for rolling this out.  I discovered an article last weekend that even the Citrix Receiver Team did not know about.  This article is It specifically addresses the icon refresh for the Receiver.  I noticed that the initial build of the icons is substantially slower in 4.1 compared to 3.4.  I figured I would test this out.  I deleted my shortcuts from the start menu, I set the registry entries according to the article, rebooted and logged back in.  Bang.. no icons.  I waited.. restarted the Receiver a few times, rebooted again.. no dice.  I simply had no shortcuts to the published desktops.  Yet another call to Citrix to understand what was happening.

It turns out, those registry entries only apply to Stores connecting to XenApp, and even then, only to the XenApp connection.  (I am currently planning on a store that talks to both XenDesktop & XenApp, although I am reconsidering that scenario).  It turns out that the problem has to do with how the Receiver handles its functionality.  When it connects to XenApp, it creates shortcuts in the Start menu directory (by default, this is %appdata%\microsoft\windows\start menu\programs).  These registry entries tell the Receiver to initially create the shortcuts in a substantially faster time than the default. However.. when it connects to XenDesktop, the process is completely different. It actually creates small executables for each of the “subscribed” desktops in %appdata%\Citrix\SelfService.  It then creates shortcuts to these executables in the Start Menu directory above.  These executables actually initiate the connection to the desktops.  And, to top it off.. these executables are encrypted with Citrix’ built in encryption routines.  So, they are *not* portable between users.  (I have not tested if they are portable between systems for the same users, but the fact that they use %appdata% instead of %localappdata% says that they probably are system portable.).  Right now, the Receiver Team at Citrix is recommending that users use the 3.4 Receiver if they can.  That team was not aware of this functionality.. they had to go talk to some people while I was on hold to find out.  The other downside of this is that these executables cannot be recreated!  The only way to get them back is to either uninstall the Receiver and clean it up with the utility, or to reset the profile completely.  I’m sure there is a somewhat easier answer, but no one knows what that is at this point.

Through my own digging around, it also turns out that Citrix is creating .net config files for these executables.  Each of the .exe’s will have a .config file with it that contains an XML entry to disable CRL checking.  That tells me that Citrix is fully aware of how slow these would be if they were doing the checking! (this is the default any .Net executables).  The code looks like this:
<?xml version=”1.0″ encoding=”utf-8″?>
<generatePublisherEvidence enabled=”false”/>

Currently, the initial login to the Receiver by the user is slow.. taking up to 30 seconds to login.. I am really hoping that Citrix will address these issues in Receiver 4.2, and go back to the actual shortcut architecture used by Receiver 3.4.

David F.

  1. Nawir says:

    Excellent article.
    1. in STORE0=”store;https://sf.domain.local/Citrix/store/discovery;On;store
    Because I am using netscaler as storefront loadbalancer. Can I point it to netscaler vip of storefront there
    2. Beside changing into
    Have you change
    3. If SSON working. How many times user login. In my theory is only 1.
    a. user login to their own domain pc
    b. Receiver will autologin and ssonsvr.exe process running
    c. user click storefront VDIWIN7 icon
    d. user accessing VDIWIN7 desktop without login needed (am I correct here)


    • 1. Absolutely. That is what I’m doing. Due to the need to control which applications are seen where, I’m currently building up my Netscaler with a VIP for straight load balancing to be used by my internal users, and a VIP for my external users. Each VIP will have policies assigning different stores based on group membership. (We have apps that are univerally available internally, but only have limited visibility externally).
      2. I have not.
      3. Correct. The SSON server process (ssonsvr.exe) actually collects the credentials and forwards it *if* your StoreFront is configured to allow it. And of course, you have to disable the Ctrl-Alt-Del requirements for your virtual machines.

      David F.

    • Based on what you are describing, I don’t think it’s a Citrix problem per-se, if I understand this correctly.
      From what you posted, you are:
      1. Uninstalling the online plugin
      2. doing several cleanups; reboots, etc.
      3. Install the new receiver
      4. Reboot again
      5. Login – directory either starts to clear out or is cleared out.

      Assuming this is correct, it sounds like the system is turning around and uninstalling it after it’s completed or something is forcibly removing it.
      I think your idea of running a procmon trace is excellent.
      I’d also turn on auditing for that directory and pull as much info about it as possible. I’m not an SCCM guy.. but I’d check it’s logs and see if it thinks it needs to uninstall it?

      In our case, we’re rolling it out to thin clients and PC’s. It’s a low enough number of PC’s that we’re just doing them by hand, and with the thin clients we’re deploying full images for them. (We have several other upgrades going in at the same time on the thin clients, so it was just easier to do them by hand).

      Another good test would be to use a new account that has never used the online plugin (or get an account with a brand new profile) and then run your process, and the last login needs to be your clean account. That will eliminate any “profile trash” from being an issue. I’d also do a clean OU with inheritance blocked for the user and the machine so that (in theory) no policies are applied.

      Good luck! (If I think of anything else, I’ll put it up here).

      David F.

  2. Nawir says:

    1. Are you sure you need to disable the Ctrl-Alt-Del requirements. Because that creating security hole. If not mistaken, I didn’t do that in my XD5.6 implementation.
    2. Since XD7.1 can’t do WebSSON
    How you do SSON in thinclient.
    Because thinclient usually read only and not member of domain

    • 1. The disable Ctrl-Alt-Del is normal for XD. It prevents the system from having to authenticate a 2nd time. From a security perspective it’s pretty minor? Because it is VDI, there really is not significant security risk. The user’s don’t have access to the console, and the network connections (including RDP) don’t use the Ctrl-Alt-Del. They actually require the network authentication before establishing the connection. I’ve never tried it without it, so I am curious 🙂
      2. In our case, our thin clients *are* part of the domain, and we’re using the regular Receivers (mix of 3.4CU3 & 4.1). As far as I know. that’s your only way to do SSON from the client.. there has to be some sort of trust. However, there are a few other ways to simplify the login proces from a non-domain machine (like a kiosk based biometric setup, etc.).


  3. Nawir says:

    1. So you disable Ctrl+Alt+Del using this GPO
    [Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options: Interactive logon: Do not require CTRL + ALT + DEL]
    That mean admin can see other user WIN7VDI without login is it?
    2. If I am using HP Linux thinclient, that mean I can’t be member of domain.

    • Nawir says:

      Your thinclient part of domain.
      If let say my thinclient is Windows then I can do.
      How about Native Receiver from factory thinclient.
      Does it already configured with /includeSSON
      I am asking this because that mean if I have 100 thinclient. I need to do
      1. join domain
      2. reinstall Receiver with /includeSSON 1by1.
      Unless I use WebSSON which will eliminate those.
      Since XD7.1 didn’t support WebSSON, that mean I need to switch back to XD5.6FP1 or maybe new XD7.5

      • In our case, we join it to the domain, we disable the secure channel password changes, we also use the file based write filter with several exceptions.
        I do not know about the native receiver that HP ships. it’s always several revs behind, and doesn’t have several fixes that we require.

        I’m not sure what you mean about XD7.1 not supporting WebSSON? Are you talking about StoreFront 2.1? With the 4.1, we don’t use the StoreFront page, although I am working on the Receiver for Web,and it does not support passthrough authentication. We have a biometric system in place, so I have configure the biometrics to handle that for them.

        David F.

    • 1. Yes, in the VM’s. The thin clients are required to login.
      2. In theory you could, but since you have no policies per se, then it doesn’t do you much good. Although, I have heard of a 3rd party company that sells a Group Policy engine for Linux.

      David F.

  4. Dan says:

    Hi David. I’m having one heck of a time with installing Receiver 4.1 properly. I was wondering if you might take the time to view my post on the Citrix Discussion board and maybe see if you have any thoughts. I’m at my wits end with this thing.

    Thanks in advance for your consideration.

  5. It’s an awesome paragraph for all the web visitors; they will
    obtain advantage from it I am sure.

  6. NyleL says:

    Thank you this was very helpful in locating a solution for connecting to an existing system that did not support SSL correctly. We were able to use A instead of S and set up the 4.2 receiver to connect to this server just as the older receivers would do without issue. We now have a batch file to install the latest Receiver and access this older server.

    I appreciate your time in creating this post.

  7. Excellent 🙂 I’m always glad when something I post can help someone.

  8. […] for the Receiver are slow (I referred to this at the end of my post about Receiver 4.1 – Talking to my TRM, I found out something that affects Receiver 4.2 and very likely affects any […]

  9. Joe P says:

    Thanks for this helpful info; it’s too bad Citrix keeps us guessing with each new iteration, with undocumented changes that make little intuitive sense.
    If you’re still updating this page, can you clarify?: you state twice that “AM” must appear before “SSON”, but your command line example shows it after. Which is correct?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s