JasonSamuel.com

If you have a Citrix XenApp environment and change your SQL server, you will need to edit your mf20.dsn with the new server name. Located at:

C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn

If you changed your SQL credentials, you will need to specify the new user name as well here. If you just change the password only and nothing else, you don’t need to edit your mf20.dsn file. But you will still need to set the new password or the IMA Service won’t start.

Once you make whatever changes you need to the mf20.dsn or not if it’s just a password change, do the following:

1. Go to Services and stop the IMA service (Citrix Independent Management Architecture) if it is still running.

2. Open command line and Navigate to:

C:\Program Files (x86)\Citrix\Independent Management Architecture

3. Type:

dsmaint config /user:yourdomain\youraccount /pwd:yourpassword /dsn:"C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"

4. Restart the IMA Service

5. You can also recreate the local host cache database (LHC database) if you have issues starting the IMA service after this. Type:

dsmaint recreatelhc

then restart the IMA Service. It will populate the cache immediately with info from the datastore.

When you try to start a VM in XenServer that talks to a StorageLink Gateway server, you get:

1/19/2012 x:xx:xx PM Error: Starting VM 'xxxxxx' - Storage assignment failed
(SSL_ERROR_SSL error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed)

in the XenCenter log. You can verify the SSL cert by opening up the following in a browser window and replacing the x’s below with your StorageLink server’s IP address:

https://xxx.xxx.xxx.xxx:21605

You will get a cert error message in your browser. Notice the Citrix CVSM SSL certificate issued on 1/19/2009 has expired today 1/19/2012 at 20:25:53 PM (GMT) which is 2:25 PM Central Standard Time. So basically any VM you try to turn on, reboot, or migrate after the cert expired will not work and return the SSL error above in the XenCenter log. Yeah, big problem.

I was the first to call in about this issue soon after the cert expired apparently. As I was on the phone troubleshooting this with the support engineer, others began calling in with the same problem. We have escalated it to the highest level at Citrix support and have been assured a workaround and a new cert are both being worked on and something should be available tomorrow morning. This is going to impact pretty much all StorageLink customers globally so trust me, they are working on it. Over the past several hours, I have tried numerous workarounds myself but been unable to get a full fix yet. I’ve tried self signed certs using OpenSSL, IIS & SelfSSL, etc. but to no avail so far. The StorageLink Gateway does not use a web server such as lighttpd, Apache, Tomcat, etc. either so I can’t force it to use another set of certs on that end. Apparently it uses API calls. When you restart the services, you will notice it copies the following SSL certs which are the culprits (into memory I’m guessing). I used Process Monitor to verify:

D:\Program Files (x86)\Citrix\StorageLink\Server\cacert.pem

D:\Program Files (x86)\Citrix\StorageLink\Server\server.pem

I actually did manage to get a little further than I thought on the handful of workarounds I tried, but nothing completely successful yet to regain functionality while we wait for a hotfix. If you want to try playing with the certs yourself, just remember to restart the StorageLink services after you swap out the certs each time so it pulls them in. XenCenter should see the SSL cert change and prompt you almost immediately with a warning message.

I will keep this post updated with the latest developments. Please post if you are having the same issue or come up with a temporary fix. In the meantime, call Citrix and open a case so you are in the loop when the fix is released.

UPDATE January, 24th, 2012 – Citrix has published the fix:

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

Apply the certs using the instructions in the KB. Shouldn’t take long at all.

When you login to your web interface and launch a new desktop, it might not launch and you might get this error in the application event log on the server:

Source: Citrix Web Interface
Event ID: 30105  
The Citrix servers do not trust the server. This message was reported from
the XML Service at address http://localhost/scripts/wpnbr.dll
[com.citrix.xml.NFuseProtocol.RequestAddress].
  [Unique Log ID: xxxxxxxx]

In previous versions of Presentation Server, the way to set the XML Trust was to go to your Access Management Console and edit the Properties of the each server. There would be an “XML Service” property near the bottom in the left navigation you could click on. Check the “Trust XML requests sent to the XML Service” box and hit OK. For the whole farm, open up the farm Properties and go to Farm-wide > XenApp > General and check the “XML Service DNS address resolution” check box and hit OK.

In previous versions of XenDesktop, you could go to your DDC and open up the Delivery Services console, right click on the farm properties go to Farm-wide > Desktop Delivery Controller > General and check the “XML Service DNS address resolution” and hit OK.

In XenApp 6.0, 6.5, etc. you need to open Delivery Services Console or AppCenter and go to Policies and hit the Computer tab. Edit the Unfiltered policy and find the XML Service near the bottom in the left hand navigation. When you click it, you will see “Trust XML requests”. Hit Add and set it to “Enabled” so the Citrix XML Service will trust requests sent to it and hit OK.

All this is from memory so if I missed something, let me know. I don’t have any consoles in front of me for the different environments at the moment except Desktop Studio or I would post screenshots for you. Let me know if you need them and I’ll take some screenshots this evening when I have a bit more time.

And now for the whole reason for this blog post. In XenDesktop 5.0, 5.5, etc., the Desktop Studio console does not have this option if you look in the Unfiltered policy under HDX Policy. That’s a totally different policy. You have to set the XML Trust via PowerShell now. So to set an XML Trusts policy, open up PowerShell and if you haven’t already, add the Citrix snapin which will give you the ability to use the Citrix cmdlets:

asnp citrix.*

Now enable the XML Trust:

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

Done, if everything goes well, you should see no confirmation or error messages like this:

Now if you logout of your web interface, log back in, then attempt to launch the desktop, it should come right up and there are no more errors in your application event log.

When you launch Internet Explorer and open your Citrix web interface page, you want it to pass through the user’s credentials and see all the available apps. When the user clicks on an app, it should launch immediately with no further prompts. Plain and simple.

But this is not always the case unfortunately. Sometimes pass-through authentication breaks. Symptoms I have seen are:

1. You get prompted for credentials at the Web Interface logon (an authentication error occurred error message) like this:

2. Passthrough at the web interface works fine but when launching an app, you get a Windows 2008 R2 logon screen from the XenApp server like this:

3. You get a combination of both issues above.

Don’t worry, there are a number of things you need to check that can resolve these issues for you. One or more of these factors may be the cause of errors in your environment. Just run through the bullet points below and verify everything:

1. You need to be using Citrix Receiver Enterprise if possible and not just the plain Citrix Receiver. The latest Citrix Receiver is 3.1 but 3.0 behaves the same way. It comes with Online Plugin 13.1.0.89 enabled out of the box. You can go to the “Receiver for Windows 3.1 – Admins” download page here:

https://www.citrix.com/English/ss/downloads/details.asp?downloadId=2319945&productId=1689163

You will need to download the 55.1 MB zip file. Inside you will see both “CitrixReceiver.exe” and “CitrixReceiverEnterprise.exe”. The one you want to install is the Enterprise version. This version will install with pass-through authentication support automatically for you as well as Single Sign On (SSO). You can always install and enable SSO with the standard Receiver using the “/includeSSON” and “ENABLE_SSON=Yes” command line switches and this actually will give you pass-through authentication features (more on this in bullet point 7 below). Receiver Enteprise will require administrator access to install on PCs unlike the standard/regular Citrix Receiver. The difference between the two versions is described here:

http://support.citrix.com/proddocs/topic/receiver-31-windows/ica-clients-deciding-v2.html

Note how Enterprise has “Single sign-on/pass-through authentication” but standard only has “Single sign-on”?

Now here’s a big problem. When an end user tries to download the Receiver off the Citrix website, it will not show Enterprise:

http://www.citrix.com/receiver

Go ahead and choose Windows in the drop down. The next page will show the download for Receiver. It does not specify if it is Standard or Enterprise. If you download the executable, it is just CitrixReceiver.exe which is the Standard version you had downloaded above.

So if you are troubleshooting pass-through authentication, the first thing you want to make sure of is go to Add/Remove programs on the user’s PC and verify it says “Citrix Receiver (Enterprise)” like below and not just “Citrix Receiver”:

I’m guessing Citrix only offers the standard version to end users so they are not confused on which one to download. The problem is if you are in an environment where Receiver Enterprise is not deployed centrally or if users take it upon themselves to install the latest Receiver from Citrix’s website (which does not require admin rights btw), they can cause a big mess and you are stuck troubleshooting it.

Another tip, you need to restart your PC for the pass-through authentication to work after you finish installing Receiver Enterprise 3.1. It will sometimes not start the Single Sign On process until you restart your PC. Or it will start it but it still not correctly passthrough credentials for whatever reason. So your best bet is to restart your PC to make sure everything is working correctly. Once you restart your PC, open Task Manager and verify “ssonsvr.exe” is running like below:

Here is another screenshot from Process Explorer which shows the dependency a bit better:

You can also go to the registry and under “HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\SSON” it should have a string value called “Enable” with a value data of “True” like this. This means SSO was installed. This key will be there if you installed Enterprise or forced the SSO install using Standard. Here is a Windows XP example:

Another thing you can do, and I’m on an XP 32 bit box right now, is navigate to “C:\Program Files\Citrix\ICA Client” and open up appsrv.ini in Notepad. You should see “SSOnUserSetting=On” at the very bottom which means that single signon is enabled.

Another check to verify for Enterprise installation, go to “HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PNAgent” in the registry and look for the DWORD value “EnablePassThrough”. It should have a value of “1″ meaning it is enabled. Standard Receiver doesn’t include the PNA plugin so you won’t even have this key if you were using it.

2. You need to verify the Citrix Receiver group policy allowing pass-through authentication has been applied to the PC you are working on. If you are just working on a test machine, you can apply this policy to just that PC for testing purposes instead of through AD. Just open up gpedit.msc on the PC, right click on “Administrative Templates” and then click “Add/Remove Templates…”. Click Add and choose the following file:

C:\Program Files\Citrix\ICA Client\Configuration\icaclient.adm

Once you have added it, navigate down to Computer Configuration > Administrative Templates > Citrix Components > Citrix Receiver > Authentication and you will see an option called “Local user name and password”. Double click on it and set it to Enabled. You need to have “Enable pass-through authentication” and “Allow pass-through authentication for all ICA connections” enabled. So it will look like this:

If you expand the User Configuration section, you will see the same settings under there as well. I usually have it set there as well but it is not necessary. In my testing, you can leave it enabled at the computer level and it will work. The changes should be instant from my testing but if they don’t take, try doing a “gpupdate /force”, restarting your browser, and/or rebooting your machine.

3. There is a known issue with XenApp 6.5 where pass-through authentication will not work. You need to apply Hotfix XA650W2K8R2X64001 to all your XenApp servers. You can get it here:

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

This will update your ccticket.dlls among other files that will fix the issue.

4. Verify on your XenApp servers that the RDP connection is set to not prompt for passwords. Under the Remote Desktop Session Host Configuration console, doubleclick on RDP-Tcp, then click the Log on Settings tab. Verify “Use client-provided log on information” is selected and “Always prompt for password” is NOT checked:

5. Verify in the Web Interface console that you have specified pass-through authentication for the XenApp site. Just open the Web Interface Management console, right click on your site, and click Authentication Methods. Pass-through should be checked here:

It should also be done on the XenApp Services site if you need it.

6. Pass-through authentication will not work in Firefox. I’ve added my web interface to the Trusted URIs config in FireFox but it won’t work. NTLM Passthrough authentication works fine on the web interface, but it won’t carry to the XenApp server when launching an app. You can add your WI to the list by typing this in the address bar in FireFox:

about:config

Then just type “NTLM” in the filter box. Add the URL (without the http:\\) in the “network.automatic-ntlm-auth.trusted-uris” box. If you do manage to somehow getting pass-through authentication to work in Firefox, please leave a comment below. I’m not a huge IE fan.

Quick note in IE, you do not need to add your WI URL to the Trusted Sites security zone for passthrough to work. Local Intranet is all you need from my experience. Sometimes you may get prompted at the web interface for credentials. Just make sure the site appears in Local Intranet and not Internet. I’ve seen issues where NTLM passthrough may not work in this scenario.

7. One final note, I did some additional testing using the Standard Receiver and command line installation. If you install Standard Receiver using command line with the following:

CitrixReceiver.exe /includeSSON ENABLE_SSON=Yes

You will see in Process Explorer or Task Manager that “ssonsvr.exe” is indeed running after the install. In my testing I was able to get it to actually pass-through but on certain XenApp 6.5 servers only. They had the pass-through hotfix I talk about below in bullet point 3 above applied. This was the only exception. And it only worked immediately after the Citrix Receiver install without rebooting the system. After rebooting the PC, it behaved like all other regular unpatched XenApp 6.5 and below farms. I would get the Server 2008 logon.

I then added the .adm template and configured it as described in bullet point 2 above and pass-through authentication worked fine with both patched and unpatched XenApp 6.5 servers. It even worked on XenApp 5 Feature Pack 3 farms with Web Interface 5.3 just fine.

If you check Process Explorer as you launch an app, the whole chain is there from the single sign on service to the connection manager down to the ICA client/Online Plugin:

So bottom line, you can get standard Receiver to work with passthrough but only if using these command line switches during install. I would just deploy Receiver Enterprise to begin with to avoid having issues down the road. It just seems to make more sense to me.

You might get a request to to publish an Internet Explorer URL/link in XenApp for whatever reason. Web applications that use Java Runtime Environment (JRE)/Java applets do not play nicely with Citrix XenApp. The main problem is the Java cache. It wants to write its cache to:

C:\Program Files\Java\Cache\username\Sun\Java\Deployment\cache

by default during a XenApp session but nothing ever gets populated past the “username” part. The directory underneath will be blank and your web application will never load the Java applet.

I’m not a Java expert and I’m not even going to claim the following is any kind of best practice. But this is what I have done in my environments to make the web apps work using XenApp. If you have a better way of doing it, please do comment in this post.

So a little background, I am using Windows Server 2008 R2 with IE9 with Java (JRE) 6 Update 26 installed because my web app requires that specific version of Java.

1. Go to “C:\WINDOWS\Sun\Java\Deployment” and create a file called “deployment.config” with the following:

deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties

2. Now create a file called “deployment.properties” in the same folder with your custom properties. What I do is generate a deployment file and then copy it over to this directory. To do this, open up Internet Explorer and go to your web app. Once Java is invoked, you will notice the Java icon in the notification bar in the bottom right.

Right click on it > Open Control Panel > Settings and you will see a path where temporary files are kept.

This is the default Java cache and will look like:

C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\cache

Navigate to:

C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\

and there will be a file called “deployment.properties” that was just generated for you. Just copy it over to the “C:\WINDOWS\Sun\Java\Deployment” folder as is.

Now you need to edit this file and specify the Java cache to be somewhere else. In my case, I want it to go to a folder on my D: drive called JavaCache. So all I add is this line (make sure the slashes are just like this, I know it’s a little odd):

deployment.user.cachedir=D\:\\JavaCache

So now my “deployment.properties” file will look like this:

#deployment.properties
#Mon Nov 28 13:17:40 CST 2011
deployment.javaws.cache.update=true
deployment.version=6.0
deployment.user.cachedir=D\:\\JavaCache
deployment.capture.mime.types=true
deployment.javapi.cache.update=true
deployment.browser.path=C\:\\Program Files (x86)\\Internet Explorer\\iexplore.exe
#Java Web Start jre's
#Mon Nov 28 13:17:40 CST 2011
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.6
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.6.0_26
deployment.javaws.jre.0.osarch=x86
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.args=

Yours will probably look different than mine depending on which version of JRE you have installed.

3. Make sure to create the location you specified above. It can be a blank folder and will be populated the first time someone invokes Java. So in my case, I created:

D:\JavaCache

4. Now publish IE and the URL like you normally would in the XenApp console. IMPORTANT NOTE: If you are using 32 bit IE and installed 32 bit Java, DO NOT publish 64 bit IE by accident. It will not be able to use the 32 bit Java. You will need to install 64 bit Java if you intend to use 64 bit IE.

Here is an example of how 32 bit IE should be published on Server 2008 R2 in XenApp 6.5:

Command line:
"C:\Program Files (x86)\Internet Explorer\iexplore.exe" "http://www.google.com"

Working directory:
C:\Program Files (x86)\Internet Explorer

5. That’s it, now launch your published IE web app from your desktop via the WI and it should load just fine. Once Java is invoked, verify your Java cache is pointed at the new location. Just look in your notification area for the Java icon, right click on it > Open Control Panel > Settings and you should see “D:\JavaCache”.

One interesting thing to note, older versions of Java pull their deployment configuration from a different location. So if putting everything in:

C:\WINDOWS\Sun\Java\Deployment

does not work for you, try copying them to:

C:\Program Files (x86)\Java\jre6\lib

and everything should work. Just make sure to edit your “deployment.config” accordingly with the new path to “deployment.properties”. An example, I have a web app that requires JRE 6 Update 11 and it pulls the deployment info from the lib folder and completely ignores the one in the Windows folder:

I also want to note that Oracle has pretty good documentation on configuring the deployment configuration file to your liking here:

http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/properties.html

You can do quite a bit of customization to it. Some of my web apps require certain things to be configured in Java such as suppressing certain warning messages and I have used this article to set those switches. Again, I’m not a Java expert so there may be an easier way of doing this but this is how I have been able to get my Java web apps to work with XenApp. Let me know of your experiences.

Citrix provides and awesome tool called Citrix QuickLaunch that can do many things including creating ICA files for your newer XenApp 6.5, XenApp 6, XenApp 5 farms, etc. It works great as an ICA file creator for XenApp 6.5 or any versions below it through PS 4.0. You can download it here:

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

I like the fact it talks about the TABCTL32.OCX not being registered error in the documentation:

“Run-time error ‘339’:
Component ‘tabctl32.ocx’ or one of its dependencies not
correctly registered: a file is missing or invalid”

Unfortunately it doesn’t tell you exactly where you can acquire the missing file. Instead of running around trying to fix it, I’ve hosted the TABCTL32.OCX here in zip format so you can download it and register it easily:

http://www.jasonsamuel.com/wp-content/uploads/2011/11/TABCTL32.zip

On an XP box, just unzip into c:\windows\system32 and then open command prompt. Type:

regsvr32 system32\TABCTL32.OCX

and it should pop up with a box saying “DllRegisterServer in system32\TABCTL32.OCX succeeded”.

Now you can launch CitrixQuickLaunch.exe and it will load right up. Weird thing I noticed today, the tool says “Citrix QuickLaunch Tool” but the CTX documentation says “Citrix Quick Launch”. So which is correct?

The screenshots in the article are very good. If you are using it just to create an ICA icon, make sure to click the “Options” button to expands the options and select “to a Published App”. Don’t forget to change the XML service port to 8080 instead of the default 80 or it will fail to connect to the XML Broker (granted you are using port 8080). Then just click “Write ICA File” and choose a location to save your ICA file.

Done! Double click your brand new ICA file and it should work fine. If you need to make any changes, use the tool to generate a new ICA icon or you can just open it in Notepad and edit by hand. You can remove the user name, password, and domain if you want. I typically just leave the domain only. I would NOT recommend storing passwords in plain text. Hope this helps.

I was able to attend a Desktop Virtualization seminar by Brian Madden several weeks ago. It was a small group of attendees so it was great to interact at a personal level with him and some of the other speakers and get some questions answered. What I loved the most about this seminar was that a lot of the discussion was vendor agnostic, so I didn’t have a ton of marketing pushed at me. That’s a welcome change because I don’t want to hear sales talk, I want to hear the raw facts from other engineers on what works, what doesn’t, and why.

A lot of what was covered is stuff most everyone working with VDI may already know. I’m not going to transcribe all my notes from the seminar. But some key takeaways that I felt were important were the following:

1. VDI projects and hardware refreshes are driven by different factors than last year this time. April 8, 2014 (End of Support, patches, hotfixes, etc. for Windows XP) is looming and many IT departments are concentrating more on hardware/Windows 7 migrations than they are on VDI projects. Last year many companies were trying to do both since these projects usually go hand in hand. Many companies that are still doing POCs or extending their testing phases are now starting to feel a time crunch. Because of this, many companies are giving priority to the refreshes and letting the VDI projects become a secondary project. That’s not to say VDI is not important, it’s just that many companies need to prioritize resources and personnel and choosing to allocate these at the refreshes. It’s funny because this has been happening all around me and to friends at their companies but I didn’t fully realize how industry wide this shift of priorities was until Brian said it out loud. So the takeaway is, get your refreshes completed first if you don’t have enough resources to handle both. You DO NOT want to get caught in 2014 with any XP machines on your network or something seriously needs to be reevaluated at your company. And it may end up being your job if you don’t drive the initiative to get your refreshes done well ahead of this date.

2. With all the different types of desktop technologies out there now:

DATA CENTER BASED INFRASTRUCTURE
-Remote Desktop Session Host (Terminal Server)
-VDI (Citrix XenDesktop, VMware View, etc)

CLIENT BASED INFRASTRUCTURE
-Client VM – Hypervisor on baremetal client (Citrix XenClient, VMware View Local Mode, Virtual Computer NxTop, MokaFive, Virtual Bridges VERDE, etc)
-Client VM – Hypervisor on existing OS (VMware Workstation, Virtual PC, Fusion, Parallels, XP Mode, etc.)
-OS Streaming
-Traditional desktops

Companies are having a hard time trying to decide what is best for their users. One of the slides shown showed the enumeration of these technologies into the environment and I swear, it was like a pack of Skittles. There are so many directions to go and for many different reasons but you really have to factor everything or you are going to have end up with one of these Skittles environments over time. The biggest take away here is that there is no ONE solution that is the BEST. Your infrastructure might be a few of these. But don’t let it run away from you, plan it well from the get go. Pretty much common sense to anyone working with VDI already.

3. So my co-worker asked how do you plan your VDI environment? How do you know what is best? Brian recommended a couple of products that can help you:

-LakeSide Solutions VMP – pulls stats on your environment and spits out a report that tells you which users are good candidates for VDI vs. Terminal Server vs. staying on a traditional desktop.

http://www.lakesidesoftware.com/systrack_vmp.aspx

-Liquidware Labs – does a lot of the same and comes with 30 day trial

http://liquidwarelabs.com/products/stratuspherefit.asp

Another really good tool he suggested that was good for looking at the app compatibility and testing closer was App-DNA AppTitude. It does automated testing against 68,000 data points. They were acquired by Citrix just a couple of weeks ago:

http://www.app-dna.com/about-apptitude/automated-application-testing/

ChangeBase offers something similar and they were acquired by Quest just a few weeks ago:

http://www.changebase.com/

4. User workspace management. Let’s face it, any large VDI deployment across all the different infrastructure technologies above + across all the different OSes is going to be a nightmare if you don’t have some way of managing the user workspace. Brian talked about the concept of layering hardware, OS, application, and users. Not unfamiliar to anyone that has worked with VDI. He talked about 3rd parties like AppSense, RES, LiquidWare Labs, etc. vs. what’s being offered from Citrix, Microsoft, and VMware. I’m not going to go too much into this because I plan on writing an article about user workspace management and a comparison of the different options soon. But just know that this is a big point that will break or make your VDI project.

These were some of my main takeaways from the seminar without going into too much detail. There was a lot of information covered and I have to thank Brian & TechTarget for putting this on. Doesn’t matter if you’re just in the planning stages of your VDI project or if it’s been running great for years, I guarantee you will learn something new or what’s coming down the pipe in the VDI world at one of these seminars. You can sign up for one in your city here:

http://events.techtarget.com/desktopvirtualization/

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.