JasonSamuel.com

If you ever wanted to force an uninstall of XenApp or Presentation Server, you can do it with just one command. There are many scenarios where you might have to do this. Forcing an uninstall should always be a last resort though. You just navigate to your setup files to where mps.msi is located and run the following. In this example, I have copied the XenApp 6.5 install files to my D: drive:

D:\InstallFiles\XenApp6.5\XenApp Server\w2k8x64

and type the following command:

msiexec /x MPS.msi CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=YES

This will bring up the following prompt:

and then you just run through the uninstaller and reboot when it prompts you.

Now if you don’t have mps.msi on your server and don’t have time to find the media and copy the install files over, here is a nice trick. Open regedit to edit your registry and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Now find the key with the Display Name of Citrix Presentation Server or XenApp, here is a screenshot from a Presentation Server 4.5 box for example:

Right on the key and copy the key name:

Paste it into Notepad. It will be the full path of the key but just copy the key part only:

Then open up a command prompt and type the following but with the key you saw on your server. Here is mine for example::

msiexec /x {44412985-02EE-4824-9EA5-B2AF6D98924E} CTX_MF_FORCE_SUBSYSTEM_UNINSTALL=YES

Once you hit enter, it will pop up with the uninstall dialog and you can run through it to complete your uninstall:

Just keep in mind that the force uninstall switch only uninstalls XenApp/Presentation Server. It will not uninstall all of the little plugins and other modules that were install when you original setup your Citrix server:

BEFORE:

AFTER:

EdgeSight Agents for XenApp can be deployed and configured to all of your XenApp servers easily via command line scripts/batch files. Here are the 3 .bat scripts I have written for the 3 different agent flavors, 5.3 for 32 bit and 64 bit 2003 OSes and 5.4 for 2008 XenApp 6.0, 6.5, etc. OSes. It also writes a very verbose log file to the C: drive so you can troubleshoot if the agent fails to install. Keep in mind I have the “XENAPP_AGENT” folder shared out on the EdgeSight server in these examples but you can stick it on a network share and modify the path accordingly:

2003 32 bit agent install:
start /wait Msiexec /i "\\edgesightservername\XENAPP_AGENT\EDGESIGHTXAAGENT.MSI" /l*v "c:\edgesightinstall.log" /qn SERVER_NAME=edgesightservername COMPANY=yourcompanyname ALLOWSERVEROS=1 INSTALLROOT="D:\Program Files\Citrix\System Monitoring\" DATA_DIR="D:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data\" REMOTE_SECURITY=0 FUNCTIONALITY_MODE=1 SHOW_SERVICES_TAB=1

2003 64 bit agent install:
start /wait Msiexec /i "\\edgesightservername\XENAPP_AGENT\EDGESIGHTXAAGENTX64.MSI" /l*v "c:\edgesightinstall.log" /qn SERVER_NAME=edgesightservername COMPANY=yourcompanyname ALLOWSERVEROS=1 INSTALLROOT="D:\Program Files (x86)\Citrix\System Monitoring\" DATA_DIR="D:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data\" REMOTE_SECURITY=0 FUNCTIONALITY_MODE=1 SHOW_SERVICES_TAB=1

2008 64 bit XA6+ agent install:
start /wait Msiexec /i "\\edgesightservername\XENAPP_AGENT\EDGESIGHTXA6AGENTX64.MSI" /l*v "c:\edgesightinstall.log" /qn SERVER_NAME=edgesightservername COMPANY=yourcompanyname ALLOWSERVEROS=1 INSTALLROOT="D:\Program Files (x86)\Citrix\System Monitoring\" DATA_DIR="D:\ProgramData\Citrix\System Monitoring\Data\" REMOTE_SECURITY=0 FUNCTIONALITY_MODE=1 SHOW_SERVICES_TAB=1

Now let me go over what each of these switches does. Keep in mind some of these values are ideal for my current environment, but you may need to edit these scripts for yours:

-SERVER_NAME = the EdgeSight server name

-COMPANY = the company you created in EdgeSight. You can also use “DEPARTMENT” to further breakdown but that is for Endpoint agents. XenApp agents will use the Citrix farm name to break down so you don’t need to worry about this value.

-ALLOWSERVEROS = I set it to 1 which means go ahead and install on Server OSes but this is really an EdgeSight for Endpoints setting and not for EdgeSight for Xenapp. I just leave it to maintain consistency with my VDI install script. Doesn’t hurt anything.

-INSTALLROOT = is where the Edgesight agent will be installed. I am installing on the D: drive instead of the default C: drive as you can see. The directory will vary depending on your OS so please pay close attention to this. Inside this directory are the various agent related files like rscorsvc.exe, Firebird files (including Fbserver.exe), etc. are located.

-DATA_DIR = is the EdgeSight working directory and will contain important logs like SYS_EVENT_TXT.txt and all the Worker logs. Again, I tell it to install on D: drive because I don’t want my C: drive to ever fill up with logs. Slim chance with EdgeSight but I try to follow best practice whenever I can. Also note the Firebird database (RSDATR.FDB) is also located in this directory. If anything, that is the file that will be growing the fastest.

-REMOTE_SECURITY = So if you ever use the Monitor or Troubleshoot tabs in the EdgeSight web console and click on a server, your desktop is actually connecting to the EdgeSight agent on that server over port 9035 using the credentials you are logged into your desktop with, not the EdgeSight web console.

So let’s say you are using your domain user account to login to your desktop, but use a server administrator account to login to the EdgeSight web console. When you click on a server under Monitor, your desktop immediately opens a connection on 9035 to that server. If your domain user account is not a local administrator on that server, EdgeSight will display a message like this:

Real time information is unavailable.
There was an error connecting to the remote Citrix System Monitoring Agent database. The Citrix System Monitoring Agent may not be running on the specified machine. Please try again.

OR

Real time information is unavailable.
Access denied: You do not have permission to access this resource.

Naturally if you are using a regular domain user account and another administrative account for server administration, you are probably not going to have the domain user account as a local admin on the server. So the EdgeSight agent allows you a couple of options to work around this. Namely, allowing anyone to connect over the EdgeSight web console or limiting it to a certain AD security group. Unfortunately, both these options have to be set in the registry, it’s not something you can set in the EdgeSight agent GUI. The location of these keys are:

32 bit OS:
HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurity

64 bit OS:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurity

By default, RemoteSecurity is set to “1″ meaning you have to be a local admin on the server. Setting it to “0″ allows you to specify the AD security group that should have access to the EdgeSight agent. This security group should contain all the domain user accounts that will be using the EdgeSight web console. To actually specify the group, you need to drop the security group name into one of the following keys:

32 bit OS:
HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurityGroup

64 bit OS:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurityGroup

The last option and the one I have used in my scripts above is setting RemoteSecurity to “0″. This lets anyone using the EdgeSight web console to connect to a server to view realtime info. The reason is if you have several network segments with Citrix farms and they are all on different domains with no trust, you can’t specify all those different AD security groups in the registry unless you create a custom EdgeSight install script for each domain specifying the RemoteSecurityGroup value. This gets a little cumbersome to manage if you have a lot of domains. Even then, getting it to pass these credentials from your desktop to the XenApp server in question gets a little hairy. So just keep in mind, “0″ is a workaround but really the best practice is to use “1″ and specify a RemoteSecurityGroup if you can. My reasoning is “0″ is okay since I already control who has access to the EdgeSight web console and I want all my console users (which are all server admins) to have access to realtime reports.

BTW, just add “REMOTE_SECURITY_GROUP=yourADsecuritygroupname” to the install scripts above if you want to specify this value for your EdgeSight agents.

-FUNCTIONALITY_MODE = I set this to “1″ to set the agent to Advanced mode. If you set it to “2″ it will install in Basic mode. So if your environment consists of a bunch of Enterprise Citrix servers and you don’t have any Platinum servers or an actual EdgeSight for XenApp monitoring license, then you may want to use the value of “2″ to just pull basic EdgeSight data. Otherwise you will begin getting errors on your EdgeSight server like:

EdgeSight – Grace Period license violations detected on YourServerName
The device YourServerName at xxx.xxx.xxx.xxx has reported Grace Period violations
EdgeSight has detected license violations in the payload for the device YourServerName at xxx.xxx.xxx.xxx. This device is still within the 14-day licensing grace period.
Please take corrective action to prevent future violations.

I don’t really recommend the Basic mode. It will likely defeat the purpose of you deploying EdgeSight in your environment in the first place. Here is a good comparison of the EdgeSight Advanced vs. Basic agents:

http://support.citrix.com/proddocs/topic/edgesight54/es-feature-by-agent-type.html

As you can see, you lose some key monitoring metrics like:

-Network Performance
-XenApp User Summary
-Launch Summary for a Farm
-Summary for a Farm
-Users Summary for a Farm
-Application Errors
-Session Performance
-Active Application Monitoring (if you use application monitoring scripts)

In my opinion, you aren’t really getting key performance metrics on your Citrix farms unless you are running in Advanced mode. I heavily depend on the above reports to monitor farm health.

-SHOW_SERVICES_TAB = This is actualling meant for the EdgeSight for Endpoint agents but I do it for XenApp agents too to maintain consistency with my VDI install scripts. Setting the value to 0 will prevent users from being to to disable Citrix System Monitoring Services because it hides the Services tab under Control Panel > Citrix System Monitoring Agent. Setting it to 1 allows the tab to be displayed. It doesn’t really apply to server OSes since they display but default but it doesn’t hurt leaving the value as 1.

Here’s how XenApp agent vs. XenDesktop/Endpoint agent will look if you specify the value as 1:

A few other points. DO NOT run one of these install scripts against your License servers. License servers do not use EdgeSight agents, they are polled directly. You specify that in the EdgeSight web console under Configure > License Monitor Configuration > License Servers. They are polled every 15 min by default.

If you are trying to monitor a published application that launches using a script, like a .cmd extension for example, it may not register in EdgeSight as a launch. You need to install Citrix hotfix EUEM100W001 on your XenApp server to fix this:

http://support.citrix.com/article/CTX126997

By default, EdgeSight agents for XenApp upload performance data twice a day to the EdgeSight server. This means app launches, users, errors, etc. This can be configured to upload more frequently if you like. The default times are 5 AM and 7 PM. You can adjust it under Configure > Agents > XenApp Default > then expand the Performance Upload section.

I guess the only other thing I really want to stress is to make sure to double check your antivirus settings and also to verify ports 80, 443, and 9035 are open to every XenApp server you want to monitor. AV settings can be tricky with the various OSes in your environment, I may type up a quick guide on what to white list/set exceptions on if anyone needs it.

After your install XenApp 6.5 and setup your web interface site under Web Interface 5.4, you may notice that going to the web interface will show you a plugin install page like this if you don’t have the right web plugin installed on your system:

The problem is when you click on this install button, it takes the user to:

http://www.citrix.com/site/SS/downloads/index.asp

where they have to dig around and find the proper plugin. This is a horrible end user experience because they don’t know what to download and can get confused and frustrated.

So instead, you can host the web plugins for the different OSes on your web interface server itself just like previous editions of Web Interface. Here are the steps to do this. I installed on XenApp 6.5 and Web Interface 5.4 on a Server 2008 R2 for this example so these are 64 bit paths. Just edit the path below to regular “Program Files” if you are using a 32 bit OS.

1. Go to:

c:\Program Files (x86)\Citrix\Web Interface\5.4.0\Clients

you will notice it is empty like below:

2. Now go to your XenApp 6.5 media/install files and drill down to the Windows clients folder:

Citrix Receiver and Plug-ins\Windows

3. Copy the “Windows” folder into the “c:\Program Files (x86)\Citrix\Web Interface\5.4.0\Clients” folder. You can also copy over the Java, Linux, and Mac folders if you support those clients but in this example, I am only copying over the Windows clients.

4. Once everything is copied, go into the Windows folder and you will see all the clients listed:

5. Now go to the Web Interface console and click Client Deployment on your XenApp website. Make sure “Offer upgrades for clients” is checked if you want users to be prompted to upgrade their clients when they hit the WI and are detected to be running an old version. By default this is unchecked and that is fine if you don’t want to give them an option to update just yet.

7. Now the fun part, go to:

c:\inetpub\wwwroot\Citrix\XenApp\conf

and open the WebInterface.conf file in Notepad. Scroll down till you get to the ICA clients section which is commented out by default.

8. Since Citrix Receiver 3.0 that is currently shipping with XenApp 6.5 has the Online Plugin version 13.0.0.6684 embeded, you can uncomment this line and instead of “CitrixOnlinePluginWeb.exe” type “CitrixReceiver.exe”. This will give users the option to install the Citrix Receiver instead of a legacy Online Plugin:

9. You don’t have to do an iisreset as the change should be instant but for good measure, you can:

10. Now when you go to the web interface in your browser, you will notice the green Install button is there but there is also a little check box underneath that says “I agree with the Citrix license agreement”. This means the install file is being hosted on the web interface server now. Check the box and hit Install:

11. Save or Open the file depending on what your browser prompts you with (I am using Firefox):

12. Run the file to install the Citrix Receiver:

13. It will prompt when complete unlike some older Online Plugin versions:

14. Click Continue on the Web Interface once the installation is complete:

15. Now you can logon. If you have passthrough authentication enabled, it should log you in automatically if using Internet Explorer. In Firefox, make sure to enable NTLM passthrough for the URL and it will do the same. Here is my article I wrote a while back on how to do this targeted at Sharepoint admins but the same steps will work for your web interface URLs:

http://www.jasonsamuel.com/2010/02/08/getting-firefox-to-pass-active-directory-credentials-to-sharepoint-2007/

Otherwise it will give you the Explicit logon prompt:

15. Now you may not want to deploy Citrix Receiver to your end users and just want to remain on a legacy version of Online Plugin. This is fine too. All you have to do is manually create a “Online Plug-in” folder under:

c:\Program Files (x86)\Citrix\Web Interface\5.4.0\Clients

and drop your legacy plugin executable in there:

and then make sure your WebInterface.conf is uncommented and says “CitrixOnlinePluginWeb.exe”:

16. If you want to force your users to run a minimum version of the Online Plugin or otherwise get the “Install the latest plugin” screen, you can append the version number to the end of the string. In this example, I only want to let users connect and bypass the Install screen who are using 11.2 or greater so I typed:

ClientIcaWin32=Filename:CitrixOnlinePluginWeb.exe,Directory:Windows,Mui:Yes,ClassID:238f6f83-b8b4-11cf-8771-00a024541ee3,Version:11.2.0

A few things to note on client detection and Firefox vs. Internet Explorer. IE can detect the difference between lets say version 11.2.0.31560 vs. 12.0.3.6. But Firefox cannot. Firefox can only detect if a client is installed or not, it cannot detect version numbers. So if you specify in your WebInterface.conf that only 12.0 clients can connect without the update screen and the user connects using 11.2 with Firefox, they will not get the update screen. If you run a manual client detection under Settings > Run Client Detection, it will say “The preferred client is already available on your computer.”

In IE, it detects the client version just fine. To test, make sure a legacy online web plugin is installed on your system such as 11.2.0.31560 for example. Edit your WebInterface.conf like above and set the version to “11.2.0.31560″. Hit the web interface and you will passthrough with no issue. Now edit the string again and change it to “11.2.0.31561″. Try going to the web interface and you will now get a prompt asking you to update.

So please keep the browser client detection issues in mind if you do allow your users to run browsers other than Internet Explorer. There are better ways to rollout a client update to your user base that are more controlled and less “error prone” if browser flavor is a concern in your environment.

By default, Firefox stores it’s profile cache in "C:\Documents and Settings\yourusername\Application Data\Mozilla\Firefox\Profiles". This can be problematic when using roaming profiles with a limited amount of profile storage space due to quotas. As you add extensions, it grows even bigger. This is a big problem in XenApp/XenDesktop/View and other VDI environments using roaming profiles. You’ll soon start getting errors saying you are almost out of profile storage space or that you have exceeded your profile storage space. Something like this (note I just grabbed this screenshot from a Google Image Search, you would normally see a bunch of Mozilla Firefox related files in there eating up the space):

The solution is to move the profile out of the user folder and into another local folder or onto a network drive/home folder, thus reclaiming the profile storage space. For example, I created "c:\FireFoxProfile" to house the profile. Here is what you need to do to begin using this folder:

1. Edit "C:\Documents and Settings\yourusername\Application Data\Mozilla\Firefox\profiles.ini" in Notepad and change:

IsRelative=1

to

IsRelative=0

What this does is allow you to use an explicit path that you specify for the profile.

2. Change the next line from:

Path=Profiles/xxxxxxx.default

to

Path=c:\FireFoxProfile\xxxxxxx.default

3. Save profile.ini and restart Firefox. You will notice that immediately, the new profile folder is populated. Keep in mind when you open Firefox for the first time, it will be like a brand new install and you will lose all of your bookmarks, extensions, customizations, etc. unless you restore them from the old path.

4. You can delete everything in your old profile path once you have Firefox working in the new profile path. This will immediately reclaim your roaming profile storage space.

NOTE: If deploying to the entire corporation, there are other methods to centrally manage Firefox and control the deployment. This solution is good for the one off users though.