Description

The Receiver Clean-Up utility is designed to assist with the following scenarios:

• When errors occur during upgrade from an earlier version of Receiver or Online Plug-in
• When unexpected behavior or performance is experienced after upgrade from an earlier Receiver or Online Plug-in
• If Receiver upgrade is not possible due to feature incompatibility and/or a clean uninstall is required
• The Receiver Clean-Up Utility removes components, files, and registry values of Online Plug-in 11.x, 12.x, and Receiver for Windows 3.x, 4.x (Online Plugin-in 13.x, 14.x). This includes the Offline Plug-in component if installed and HDX RealTime Media Engine if installed.

Table of Contents

How to Use the Citrix Clean-Up Utility

The Receiver Clean-Up Utility is a standalone executable file and does not require installation.

Although the Receiver Clean-Up Utility will backup Receiver registry keys before deleting them, it is recommended to back up the registry before running this tool. Go to Microsoft article How to backup and restore the Registry in Windows for backing up the registry.

Caution: Always back up the registry.

1. Run the Receiver Clean-Up Utility with administrator privileges.
2. Restart the machine when the utility finishes.

Note: The Receiver Clean-Up Utility can be run in unattended mode if desired using the /silent command line option.

C:/> ReceiverCleanupUtility.exe /silent

ReceiverLogs folder is created in the location where the utility is run and tracks all uninstall actions and results.

NOTE: In order to improve the Citrix Receiver experience, anonymous uninstall data will be sent to Citrix. To disable the collection of uninstall data, please use /disableCEIP command line parameter.

Data Modified by Receiver Clean-Up Utility

The utility terminates all Receiver processes prior to running the uninstall process. Refer to the ReadMe file included with the tool for a list of items that will be removed during the clean-up process.

How to Undo the Changes Made by Receiver Clean-Up Utility

The Receiver Clean-Up Utility creates a backup of all Citrix registry keys in the file ReceiverLogsRegBackup.reg before running any clean-up and deletion process.

To undo the changes:

1. Reinstall Receiver for Windows
2. Import the RegBackup.reg file to restore settings and customizations in the registry.

Uninstalling Receiver Clean-Up Utility

Citrix Workspace Force Installation

Delete the downloaded executable and config.xml files from the current directory, and if desired delete the files in the ReceiverLogs folder.

Prerequisites

Required Security Permissions

Read, write, and modify access permissions are required for the following:

• Local machine registry (HKLM)
• Local user registry (HKCU)
• Default user profile on computer
• %programfiles%citrix on 32-bit systems or %programfiles(x86)%citrix on 64-bit systems

Known Issues

The Receiver Clean-Up Utility does not support non-Administrator users with roaming profile.

If Receiver is not installed at the default location, the Receiver Clean-Up Utility might not work properly.

Contact Information

Questions? Concerns? Send any feedback for this tool to supporttools@citrix.com.

Additional Information

CTX325140 - How to Remove Client Files Remaining on System after Uninstalling Receiver for Windows
CTX134237 - How to Remove Files Remaining on System after Uninstalling Receiver for Mac
Downloads - Citrix Receiver for Windows

Disclaimer

These software applications are provided to you as is with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.

I don’t like working with Citrix receiver. They drive me crazy. One version doesn’t work with the other and so on and so forth. Then finding the one you need is a pain. Thankfully, the workspace is a little better at this process. Many of my clients have recently updated their back end so the new workspace will work for them. It only took a while. So, I built a script that automatically downloads the newest version and installs it accordingly. It wasn’t until later did I realize someone else did this already. But the one I made is a little better as it doesn’t run into the conflict of pulling the version number, at least in my humble opinion. This time we will start off with the script for us lazy admins. If you want to learn how it works, keep reading on.

Lets break this guy down. The first part is we are testing if the c:temp folder exists. If it doesn’t then we will create it. Then we test if the Citrix folder exists, if it doesn’t, once again, we create it. We do this with the Test-Path for testing and the New-Item cmdlets.

Now we have the folders we will be using created, we need to move to creating the first log entry. We want this log to have a timestamp on it that matches the downloaded installer. To do this, we need to get the datetime first. While doing that we will create the filename of the log and the file name of the download path. This way it’s easier to work with later on in the script. We do this by using the Get-Date cmdlet. Normally the Get-Date cmdlet outputs is an object. Which isn’t very useful in a file name since it contains forbidden characters. (Not forbidden like slifer the sky dragon). A translation is required. We do this with the .tostring() method. Notice the way we format it.

• y = year
• M = Month
• d = day
• h = hour
• m = minute
• s = seconds

We then use the $StartTime variable inside the log name and the download pathname. This is done by a string with the variable inside of it. Next will be to create the log. We do this with a simple > which means out and create. >> means out and append. Notice in the example below we $($StartTime) we do this because the next character is a :. Inside PowerShell, you can do things like $Global:Var which tells the shell to keep that var in memory for other functions to use. This means the : is a command character. This is why we wrap the start time variable inside a $(). Powershell will only print what is inside the $(). Finally, take note of the > $Logname. We will be using $Logname more inside this script. This is why we created the variable.

Now we have the start of the log. It’s time to get the installer. In the past, we would just go to the download link and add that to a download script. However, recently Citrix changed how they download. They have tacked on an additional piece of code. Everything past the GDA is that special code they have tacked on to stop direct downloading. However, we have PowerShell on our side.

The first thing we want to do is setup a try catch. This way we can catch errors and log them. Also we can break the script with an error message that is useful. This way if you are deploying out with something like continuum or PDQ your error message makes sense. Inside the try, we want to get the webpage itself. Then log that we grabbed information. The cmdlet to get the website is Invoke-webrequest. In the below example I am using the -usebasicparsing because it’s more compatible with websites and with systems. My goal is to launch this thing to 100+ machines. The -Uri is for the website itself and finally, we use the -sessionvariable as a websession. This allows us to grab data easier, especially if it’s auto-generated, like in this case.

After we grab the website, we have to log the event. We do the same thing we did with $StartTime and place it in the file we created a few moments ago.

If these commands fail for whatever reason, the website is down, the internet is blocking, anything, we need to know that the site can’t be reached. This is why we have a log. We create the same as the $logime but this time we also add a write-error and a break command. The write-error command will send an error to a deployment software, This way we know what’s going on. The break command breaks the script at that point and doesn’t continue.

Citrix Workspace Force Install

Lets put them together inside the try catch so you can see what it looks like.

Now we have the website itself inside a variable. It’s time to find what we need. The $CitrixPage contains different elements inside of it. Each item can give you information. The Rawcontent is just like it sounds, raw content of the page. While status code can give you information about if the site is up or what condition it is in. In this case, we will be looking at the links and status code. We check if the site has a good status of 200, if it doesn’t, then we don’t want to battle that battle. Thus we log and break like before. If it does, however, we want to take apart the links and find the one that contains the exe that we need. We do this with a where-object cmdlet. We search the .rel for the *CitrixWorkspaceApp.exe. Because the .links sometimes produces incomplete links, we have to build them. That’s the second step is to build the link. We will wrap the outcome inside an https: string.

Now we have the custom URL for the download, we need to download the file itself. Remember the $DownloadFullPath we created a while ago. It’s time to use it. We will be using the invoke-webrequest once again as well. This time we will use the -OutFile cmdlet. This cmdlet of invoke-webrequest will download the file as requested from the url provided. Of course, we want to wrap all of this inside of a try catch. This way we can log correctly and break as needed.

Now we have the installer to work with. The filename has the same time/date stamp as the log file so we can compare if the script doesn’t finish up correctly. Next we will start the process of another try catch to install the program. The command we will use is the Start-Process command. We start the $DownloadFullPath for the file name. We want this thing to be quiet and overwrite everything else there. Citrix, if given the /forceinstall will force the install by uninstalling the last version. Finally we tell it not to reboot with the /noreboot. Once we get past the arguments, we want to make sure we have the information from this thus we put the -passthru flag. This will allow us to store the information into a variable if we want to use that information later. The final part of the command is the -erroraction. We want this thing to stop if it hits an error. This way we know that something is broken. Then we log accordingly and catch accordingly like above.

We are almost done! This program takes an average of 5 minutes on older machines to install. Thus we sleep for 7 minutes. To do this we use the command Start-Sleep and set the -seconds to 420 seconds. We also make sure we log this information.

As we are not in a hurry, we use the PowerShell command Get-CimInstance to get the products and sort through that to find the Citrix Workplace Browser using the where-object cmdlet.

Finally we check to see if the install was successful or not. This is done with a simple $null -ne $something. We do it this way because we first load nothing and start to compare nothing to something. if something is there, then we know the statement is true and stop processing. Very simple concept. If $Citrix does contain something we log that the install was successful and remove the installer. If we find $Citrix is $null, then we log the error and error out once again.

With all good scripts, there is always room for improvement. The one that is blaring is the waiting for the install. This should really be a loop checking files or a registry key. If the file or key is not present, then continue to way 30 seconds. This would speed up the process as some computers process faster while others do not.

Citrix Workspace Removal Tool

The second is the get-ciminstance because this is a slow command. We can improve the speed of this command by targeting once again either a file or a registry key instead. This way we can prove it was installed without the 30 to 60 second wait for the get-ciminstance to do its thing.

Citrix Workspace App Command Line

As always, If you have any questions, feel free to ask.