Download Citrix Receiver Msi Package
Heidi Blessing
nicoctx thanks very much, this solved my issue. I was unable to install the receiver Debian package in software centre, it just sat there with the install button without completing. Looks like icaclient 13.10.0.20 amd64 inherits the same problems. Spot on with the dependancies. Thanks again
Seems there's tons of ways for this receiver installer to break. the cleanup utility might have worked better for previous versions, but it might be missing registry keys for the current version. doesn't seem to clean up installer registry keys correctly anymore. it needs an update.
You can customize the Citrix Workspace app installer by specifying different command-line options. The installer package self-extracts to the system temp directory before launching the setup program. The space requirement includes program files, user data, and temp directories after launching several applications.
Citrix does not recommend extracting the Receiver (Enterprise) .msi files instead of running the installer packages. However, there might be times when you have to extract the .msi files from CitrixReceiver.exe or CitrixReceiverEnterprise.exe manually, rather than running the installer package (for example, company policy prohibits the usage of .exe files). If you use the extracted .msi files for your installation, using the .exe installer package to upgrade or uninstall and reinstall might not work properly.
During the execution of each of these msi packages, the following command line parameters need to specified:
REBOOT=ReallySuppress MSIDISABLERMRESTART=0 MSIRESTARTMANAGERCONTROL=0 NEED_RECEIVER=n TROLLEYINSTALL=1 ALLUSERS=1
Trying to create a package for the new Citrix Receiver. Ran it through the normal snapshot Composer setup and get the attached. Citrix Receiver App in Applications folder has a line thru it. Any ideas why? App shows fine in the Applications folder on my build machine. Will this affect my Receiver package?
@tthurman are you deploying the app to computers that already have a version of the app installed? I'm wondering if that might be an issue for you. I'm deploying the Citrix provided .pkg file at imaging time with no issues. I remember having some issues a year or so ago when I tried to deploy a newer version over the top of an existing version. I believe I had to uninstall the old version then run the Citrix provided package to get around the issue.
I got this as well. On machines with a earlier version installed i see Failed and then check and the applications folder and the and Receiver is there. Checked the /Library/Internet Plugins and the citrix plug in is there. However, when i go to our citrix site and launch an app Citrix Viewer does not start. Another tab opens up in Safari and tries to connect, ends up just spinning and spinning. Anyone else seen this?
When you start citrix, an error about missing certificates will pop up. If using firefox(iceweasel) you can make citrix happy by adding a symlink to the firefox certificates:$ sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts
Where i believe this can be addressed is to have the x86 "Program Files" path available in "Common Paths". Doing some research with packages i had created using SCUP, which has this feature and I used it heavily, prior to having procured Patch Manager, i was able to determine that this value is the equivalent of 'CSIDL="42"'
The reason you want to use commonPath in this way is because hardcoding the path at the root of C: then assumes that %ProgramFiles% is always on drive C:. It might not be, and your package would fail detection. By using the commonPath value in this way, your package is portable for when %ProgramFiles% exists on a different volumeID. (e.g. drive D:)
The third fourth variable at work is whether the Software Distribution Package (SDP) schema supports the value. While the CSIDL may be passed directly to the shell, there still has to be a definition for it in the XML schema declaration so that SCUP, and other third party package tool developers, know that it's an authorizied value for use.
EDIT - I am surprised as to how there are no COPRs for an application as popular as Citrix, that the users are recommended to get RPM packages from a third-party website. There must be one I think but sourcing RPMs from a third-party website is just as much as looked down upon as adding unsolicited repositories.
Yeah that makes sense. Even if one could be tempted to put their big bad compiled output of a file inside an RPM and shellscript to execute it, COPR states that the contents packaged should be allowed.
I used to use Citrix client, so I made a package out of it: if anyone wants to take over maintenance, let me know: ICAClient.spec master Greysector / RPMs / ICAClient GitLab . Latest version I packaged was 19.6.0. One of the changes probably required for F34+ is changing Recommends: alsa-plugins-pulseaudio to pipewire-alsa. This could be added to RPMFusion nonfree repo if someone obtained permission from Citrix to distribute the binaries.
Fortunately, distribution rights do not apply for internal use. With any edition of Chocolatey (including the free open source edition), you can host your own packages and cache or internalize existing community packages.
In cases where actual malware is found, the packages are subject to removal. Software sometimes has false positives. Moderators do not necessarily validate the safety of the underlying software, only that a package retrieves software from the official distribution point and/or validate embedded software against official distribution point (where distribution rights allow redistribution).
Hopefully it can be useful to someone in future. After I did two actions, I am able to start Citrix Receiver:1 - I follow the recommendation: 8. Configure Firefox In Firefox, go to Tools -> Add-ons -> Plugins, and make sure the "Citrix Receiver for Linux" plugin is set to "Always Activate". 2 - In Firefox, on Add-ons Manager session, I looked for the most recent Citrix Receiver and then I choose "Full Package (Self-Service Support)" in -receiver/linux/receiver-for-linux-latest.html
So, once again the good old problem of installing Citrix receiver on a new installed Fedora 22 (KDE). This time I was surprised getting a really new Citrix receiver dated 30.6.2015 (today is the 1st of July). And surprise: No rpm-package ?
First you need to download the Citrix receiver from [1] (My testing was down with Receiver version 13.5). Choose Debian Packages and download the web package (the full package instructions are below). Next install the .deb file you just downloaded either with the software manager or by navigating to the file in the terminal and running something like this sudo dpkg -i icaclientWeb_13.5.0.10185126_amd64.deb
Finally you need to restart you browser and navigate to CAEDM Citrix web interface. Ignore the Install by clicking skip to log on because if you look above the install button will give you the receiver for red hat which won't work for Debian-based linux.
Similar to the Web Receiver you need to download the Citrix receiver from [2] (My testing was down with Receiver version 13.5). Choose Debian Packages and download the full package receiver. Next install the .deb file you just downloaded either with the software manager or by navigating to the file in the terminal and running something like this sudo dpkg -i icaclient_13.5.0.10185126_amd64.deb
Next you need to add more SSL certificates. By default, Citrix Receiver only trusts a few root CA certificates, which causes connections to many Citrix servers to fail with an SSL error. The 'ca-certificates' package (already installed on most Ubuntu systems) provides additional CA certificates in /usr/share/ca-certificates/mozilla/ that can be conveniently added to Citrix Receiver to avoid these errors:
Finally launch the citrix receiver by searching for it in the application menu. After you agree to the EULA it will prompt to you to add a server enter and you should prompted to log in. Use your caedm username and password and et.byu.edu as the domain.
Use the Java client for tech podiums, internet cafes, or any computer where it is not possible to install the Citrix client, but Java is installed. The Java client is slower to react to user input and may not produce the best user experience compared to the Citrix receiver as explained above. The Java client displays a desktop with a start menu in a browser instead of individual applications in their own windows.
Citrix will connect to the J Drive, to USB on the local machine, and to the files on the local drive (Windows only). It will automatically capture USB devices when they are plugged in, and is configured to use the J Drive as its primary source. Because of the difference in infrastructure and file system types, the Citrix client will only be able to access Local Hard Disks in Windows. Linux and Mac will not connect. In Windows, a pop-up will appear querying whether to allow a program access to the local personal files. Check that it is the Citrix receiver making the request, then allow it. The local drive will appear in the places menu as Local Disk (C: on localhostname).
Works very well on Arch XFCE and Manjaro XFCE. I use this to get to Cerner at my hospital when I am on call. This package makes it possible for me to look at xrays from home without having to drive in. This is faster and safer for my patients. A big thank you to all who make this icaclient possible.
f448fe82f3