Citrix is a great way to serve up clients to your ever-growing sea of CygNet users. We know of many CygNet installations that utilize Citrix, but more recently we’ve run into some interesting issues revolving around the Citrix, Microsoft, and CygNet relationship. Some recent reports have come in with the mistaken impression that CygNet and Citrix aren’t compatible, and that installing CygNet clients will destroy your Citrix instance.
First, let’s discuss the reported problem:
“I installed CygNet clients on my pristine Citrix environment and now I can no longer access Citrix.”
As a CygNet Administrator or CygNet Support agent, how are we supposed to handle this investigation? Well, the report states that the clients are breaking access to the Citrix environment. If that’s the case, we need to become acquainted with the CygNet client installation process since that’s all that is occurring on the affected system.
When installing CygNet clients, there are lots of DLLs and other files that are copied over to the machine and registered. The most interesting aspect to me in this specific scenario is the use of Microsoft Visual C++ Redistributables (also known as “Redists”). CygNet clients (and services) utilize several of these Redists to operate properly since there is shared code provided by Microsoft contained therein. Not only does Microsoft author these packages, they also maintain them and provide updated versions as patches. How nice of Microsoft to maintain them!
Next, let’s get a baseline of the Redists installed in the environment:
Here I see that there are a couple of 2013 and 2008 Redists installed. Now that we have an idea of a potential problem area, and know what’s presently on the system, what do we look at next?
Well, let’s verify if the VCRedists are causing any issues with Citrix:
This is a pretty easy step actually. The CygNet documentation calls out (in our System Requirements document on the CD Image) what VCRedist packages are required for the product:
Look at that footnote! It states that we include the Microsoft redistributable so you don’t have to download them! Now that we know what redistributables are needed, we can do a quick test to see what’s going on in the Citrix environment!
Since we’re running 32bit client applications, we should start with the 2013 (x86) VCRedist. Let’s look at its properties to see what version is packaged on the CygNet CD Image:
Interesting! We have something to dig into here. The XenApp installation includes an older version of the Redistributable! So to recap, what we know thusfar:
XenApp had installed the following 2013 Redists:
CygNet had included a more recent Redist, but only the 32-bit version:
Alright! We know what to do now. The next step is to install the updated x86 VCRedist. After installing the CygNet shipped Redist, checking the list of installed packages produces a shorter list:
Windows removed the x64 2013 Redist!? Will XenApp work with the x64 installation missing? A quick test of launching the Citrix application produces the following error dialog:
“…MSVCR120.dll is missing…”? This XenApp launcher must be a 64-bit application! So that must be what is causing the issue! It appears that installing an updated 32-bit VCRedist will cause windows to remove the 64-bit version if the versions don’t match. To test the theory that this is the root of the problem, I tried manually installing the 64-bit version of the 2013 Redist and checking for to see if XenApp has restored functionality. Sure enough, XenApp is now working properly!
Now that we know this, what can you do?
As a Citrix administrator, you can solve this by ensuring that you’re not missing these Redists, or as a CygNet admin, you can simply add the additional Redists into your client version management as part of the RSQ files.
Whatever you choose to do, you now know how Client version management works and the issues that can arise from VCRedist package installations!
**Update – Feb 13th**
I recieved a direct email asking for any details surrounding the versions of XenApps that this issue was found against. This particular issue was in relation to Citrix XenApp 7.6 VDA running on Server 2012. Honestly I’m not a Citrix guy, so I don’t have a good way of knowing how many versions of XenApp are affected by this configuration. I’d think it would be any version that was published BEFORE the most recent VCRedists were made available.