You really don’t want to change your ADM file settings because that will break functionality for other things. The best way around this is to add these two lines to your ICA file:

UseLocalUserAndPassword=Off
AutoLogonAllowed=Off

Once you do that, launching the ICA file will work correctly and will show the domain the server is a member of:

Disabling passthrough authentication in ICA files when using Citrix Receiver Enterprise is a post from: JasonSamuel.com

More of my posts you might like:

1. How to fix pass-through authentication & the Windows 2008 logon screen on XenApp 6.5/Web Interface 5.4 using Citrix Receiver
2. How to fix the TABCTL32.OCX is not registered error when using the Citrix Quick Launch tool
3. How to Deploy Citrix Receiver or Online Web Plugin for XenApp 6.5 on Web Interface 5.4

In this example, I want users sitting inside the building with their iPads connected to the corporate WiFi direct access to XenApp and XenDesktop. I want anyone external to have to come in through the Access Gateway to get access. So I need to make sure I have 2 Services sites on my web interface:

The default site is PNAgent (which is a reference to the old legacy Program Neighborhood). This services site is setup for Direct access and will service all my internal iPads and other devices that need it. The second site is the one I created manually called “AccessGateway”. This one is setup as Gateway Direct mode. This is the site that will be handling traffic from the CAG (Citrix Access Gateway):

When you are setting up the site, just add the farms as you would any other site. Nothing is different. In my case, I am using port 8080 as the XML Service port:

Under Secure Access, hit Next:

Here you need to type in the FQDN that your iPads and other devices are all pointed to. You need to type in the actual name, not the IP. So in my example, I want my users to hit this URL in Citrix Receiver:

http:\\receiver.company.com

so in this box, I would type:

receiver.company.com

This is presented to your iPad and other devices through the Web Interface in the form of an ICA file later so it needs to be the same. Also make sure to disable Session Reliability. Session Reliability is not supported on iPad and other devices using Citrix Receiver. So this means all ICA traffic will be on port 1494, not 2598. So keep that in mind when opening up firewall ports:

The last page is to add the STAs (Secure Ticket Authorities). You DO NOT need to add an STA from every farm you are connecting to. Just 2-3 STAs for redundancies sake is enough. It won’t be a whole lot of traffic. All it will be used for is to pull the ticket hash value when a client hits the web interface and then later to validate that ticket. In my case, I am using port 8080 for the XML Service port so that needs to reflect here in my STA URLs. You may be using port 80 so you would not to enter the port. In my example, it is:

http://servername:8080/scripts/ctxsta.dll

The ctxsta.dll is an ISAPI extension for IIS that will take the ticket request, process it, and send back the generated ticket. When a user hits the Access Gateway and comes in through the web interface, the web interface will send this request to the STA. Once the web interface gets the ticket (a random 32 character hash value) from the STA, it builds the ICA file to present back to the client and this value will be included. Then validation occurs just before the actual ICA session is launched and the STA needs to validate the ticket.

So now that the web interface config is complete, it’s time to configure the Netscaler. Go to the Access Gateway section and expand the Policies section. Then click Session and click the Profiles tab at the top. We are going to create a session profile first. I will call the profile “CitrixReceiver_Profile”:

I don’t really needs to change anything in this profile except on the last tab, Published Applications. Under Web Interface Address, I type in the URL to the web interface “Access Gateway” site I had create in the steps above earlier on the web interface. But I need to make sure I point directly at the config.xml file which has all the configuration information in it for the Access Gateway to read. So in my case, the URL is:

http://receiver.company.com/Citrix/AccessGateway/config.xml

Hit OK, and click the Policies tab. Create a new session policy to filter out traffic and only allow Citrix Receiver traffic. I will call my policy “CitrixReceiver_Policy”:

The actual policy will look like this, notice how it looks at the TCP User-Agent header for “CitrixReceiver”. For any other traffic, like a web browser for example, it will drop the packet. Don’t forget to choose the “CitrixReceiver_Profile” you created so that it knows to pass Citrix Receiver traffic to your new “AccessGateway” services site:

Hit OK and you are done setting up policies. Now go to Authentication under Policies and setup your Active Directory authentication. For better security, I recommend RADIUS. You will need to setup the policy and the back end server here:

Then go to your SSL certs and make you have a valid 3rd party SSL cert for your “http://receiver.company.com” website. Traffic will be SSL encrypted and Citrix Receiver does not support self signed certs. Make sure your intermediate and root certs are there and everything is linked properly. Otherwsie your SSL chain will be broken which will lead to issues:

Now that we have all the pieces in place, it’s finally time to configure our Access Gateway virtual server. So go to Access Gateway > Virtual Servers > and hit Add. Give it a name, IP address, leave it on port 443, leave the protocol as SSL, and add your SSL cert over to the column in the right. It should look something like this. And yes, Down State Flush is unchecked meaning if the vserver goes down, TCP sockets will remain active and won’t immediately be disconnected. You don’t have to uncheck it though:

Now click the Authentication tab, and add your Authentication Policy:

Now click on Policies and add your Citrix Receiver policy. By default, the priority will be 0 which is actually last. Doesn’t matter if you only have 1 policy but if you add more, you might forget to change it then. So just set it as 10 for now:

Now lastly, you need to add your STAs under the Published Applications tab. The same exact STAs you specified in your web interface several steps above. Again, I am using port 8080 for my XML Service so I have specified it here after each server name. Once you are done, press OK and then immediately open the virtual server again, go to the Published Applications tab, and you will see the green arrow and the word “UP” next to each STA. You will also see it has pulled the identifier down:

And now you’re done with the config! Don’t forget to open up firewall ports. In the DMZ, you will need 443 to come through and hit the Access Gateway URL (receiver.company.com in my case). From the Netscaler SNIP (subnet IP), not the Access Gateway virtual server IP, you need the XML Service port (8080 in my case but 80 if you left it default) open to all the STA servers you specified. You also need ICA (port 1494) open to all your XenApp application servers or XenDesktop VMs open from the SNIP as well. Lastly, you need to open up port 80 from the Netscaler SNIP to your web interface for HTTP traffic. Just remember, the SNIP is the one communicating to your internal servers, not the Access Gateway VIP so don’t get confused when adding your firewall rules. The only exception would be authentication (LDAP, RADIUS, etc.). This traffic comes from the NSIP (Netscaler management IP), not the SNIP or MIP. So take this into consideration when opening your ports.

Now to test! Open up Receiver in your iPad and type the URL, in my case “receiver.company.com”. Set your credentials and connect. If you did everything right, it should enumerate all the apps on all the farms you had specified on your “AccessGateway” services site. Click an app and it should launch just fine.

You can do an nstrace (packet capture) on the Netscaler itself to verify and also as a troubleshooting step if something isn’t working as expected. Pull the capture file over and use Wireshark to read and filter it. Remember above when you were setting up your services site and had the type the FQDN name and I mentioned this is important because it is passed back to the iPad in the ICA file? Well here it is, the red arrow is where it appears under “SSLProxyHost”:

And don’t forget to apply your CAG licenses. You might have only licensed the appliance itself and said to yourself you would apply the CAG licenses later…yes I’m guilty of this. By default you can only have 5 simultaneous CAG users so don’t forget to apply the license before releasing to production. You need to also make a decision of SmartAccess/CCU/Universal licenses vs basic licenses. If using basic licenses, you can set it up for up to 10,000 concurrent users, here is a great KB from Citrix on how to do this:

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

And what if nothing works after going through all these steps? Well it can be any number of reasons. Citrix has an excellent troubleshooting PDF available here called “Citrix Receiver for Mobile Devices Troubleshooting Guide” with plenty of screenshots. It is extremely helpful:

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

Try flipping through it and if you can’t figure it out, post here and I can see if I can help.

***UPDATE***
One last bit of info. If you want to only allow mobile devices with Citrix Receiver installed and have regular browser traffic (IE, Chrome, Firefox, etc.) redirected somewhere else, it’s pretty easy to do. For your port 80 traffic, you need to create a load balanced virtual server on the same IP as your Access Gateway virtual server. The effective state will be down since you will not add any services or service groups to it. Under the Advanced tab, set a Redirect URL to the site you want to redirect your PC browser users to.

Now for port 443 traffic, the Access Gateway virtual server will be servicing that traffic. Unfortunately Access Gateway vservers do not support Responder policies. The quick way of getting around this is creating a Responder policy and binding it globally instead. In my case, I created the following Responder policy to redirect any traffic that is not detected to be from Citrix Receiver:

HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).REGEX_MATCH(re/CitrixReceiver/).NOT

and if it can’t figure out the User Agent, it will drop the packet per the Undefined Result action:

For the action, I set it to redirect to the URL I want browser users to end up on:

And then you can bind it globally:

Now all my Citrix Receiver SSL traffic will hit the Access Gateway vserver and regular browser based SSL traffic will be redirected to the URL I specified. What’s cool about this is that as you test it, the hit count should increase on the policy. Just be careful binding a policy like this globally since it will impact every vserver on your Netscaler. It works fine in my scenario because this particular appliance is dedicated for Access Gateway connections only.

How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver is a post from: JasonSamuel.com

More of my posts you might like:

1. How to Deploy Citrix Receiver or Online Web Plugin for XenApp 6.5 on Web Interface 5.4
2. How to fix pass-through authentication & the Windows 2008 logon screen on XenApp 6.5/Web Interface 5.4 using Citrix Receiver
3. How to monitor realtime traffic stats accurately on a Citrix Netscaler

Symantec has a great KB article here that addresses this:

http://www.symantec.com/business/support/index?page=content&id=TECH105060

You can disable SmcGui to prevent multiple instances of it running by adding following DWORD registry value on your Citrix server:

HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\LaunchSmcGui

and setting the value to 0. You can also disable ccAPP by deleting the ccApp entry at the following keys:

32 bit:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

64 bit:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

I didn’t want to go to each Citrix server and verify and/or make these changes manually so I created this little bat script I can execute remotely on each Server 2008 R2 box (you’ll want to modify for 32 bit boxes):

:: Disable SmcGui
reg add "HKEY_LOCAL_MACHINE\Software\Symantec\Symantec Endpoint Protection\SMC"
 /v LaunchSmcGui /t reg_dword /d 0x0 /f

:: Disable ccApp
reg delete "HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows
\CurrentVersion\Run" /v ccApp /f

Now when building a new XenApp server (i.e. not from a template), I wanted to use this same script as a “post-install script” after installing XenApp but with a few other things included. One thing I wanted is to set the Terminal Server roaming profile path (assuming you are not doing it with GPO already). So I add this to the script:

:: Set TSProf to our TS profile shares
setx tsprof \\fileservername\tsprofiles$ -m

I also want to install my EdgeSight agent at this time. I wrote a a few installs script for this already in my post here:

http://www.jasonsamuel.com/2011/09/13/how-to-deploy-edgesight-5-4-xenapp-agents-using-install-scripts-to-all-your-citrix-farms/

so I will call on these bat scripts from the script I am writing now. But I want it to pause and let me verify that the Symantec changes happened successfully. So I add this first:

@ECHO OFF
ECHO Script is paused before EdgeSight install begins, verify all the 
things above executed successfully.  Press any key to begin EdgeSight
 agent install...
@ECHO ON
pause

then finally I call on the EdgeSight agent install script (which will reboot your system after installing automatically). I have it shared off my EdgeSight server under the “XENAPP_AGENT” share so my script looks like:

:: Kick off EdgeSight agent install
call "\\edgesightservername\XENAPP_AGENT\2008 R2 XA6Plus agent install 
script.bat"

So my final script will look like this screenshot:

Hope this helps. Let me know if there is anything that any of you would like to see added.

Script to make your Citrix XenApp servers run better with SEP antivirus is a post from: JasonSamuel.com

More of my posts you might like:

1. How to deploy EdgeSight 5.4 XenApp agents using install scripts to all your Citrix Farms
2. How to fix pass-through authentication & the Windows 2008 logon screen on XenApp 6.5/Web Interface 5.4 using Citrix Receiver
3. How to fix the Error 30105 Citrix servers do not trust the server message in XenDesktop 5.5

You can find more info on HP’s website here:
http://h18004.www1.hp.com/products/servers/management/ilo/mobile/index.html

Apple App Store download link:
http://itunes.apple.com/gb/app/hp-ilo-mobile-toolbox/id497560256?mt=8&ign-mpt=uo%3D2

Android Market download link:
https://market.android.com/details?id=com.hp.essn.iss.ilo.iec.spa&feature=search_result

What I really love about it is that it saves your connection info and even pulls down the type of hardware the server is so for future use, all of it is in the app already for you. I hope they give you an option to import a list of servers in bulk at some point. Or maybe synch the iLO connection list across multiple devices.

Here are the features from HP’s website:

Connect:
Supported Servers
• ProLiant G7 Servers (iLO 3 Advanced)
Supported Mobile OS’s
• iOS 4.3 or greater
• Android 2.2 or greater

Manage:
• Operate the server power switch.
• Use the Remote Console to interact with the operating system, including BIOS and ROM configuration changes.
• Mount an ISO CD/DVD image. The disk image is available on the server as a USB CD/DVD drive. You can boot from the disk image and deploy an operating system.
• Launch HP iLO scripts and monitor their progress.
• Access the iLO web interface.
• Store the list of servers you want to manage.

Here’s my “Sys Admin” iPad with the iLO console open connected to a G7 Blade. How cool is this?

Here’s a few other shots from the user guide and app store screen shots:

Here’s a shot launching an iLO RIBCL script:

HP iLO Mobile App for iOS & Android released is a post from: JasonSamuel.com

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.

Changing SQL account name, password, or database server name in XenApp 6.5 is a post from: JasonSamuel.com

More of my posts you might like:

1. Getting admin access on a SQL Server when you don’t know the SA account password
2. How to reset the root user account for a MySQL database
3. Changing the host header for an already existing Sharepoint site/application

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.

Citrix XenServer and StorageLink SSL cert error caused by expired SSL certificate is a post from: JasonSamuel.com

More of my posts you might like:

1. How to create and link an SSL certificate chain for a Citrix Netscaler
2. How to properly use SSL redirects without getting certificate error messages
3. How to install an SSL cert chain on a Cisco Wireless Lan Controller (WLC)

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.

How to fix the Error 30105 Citrix servers do not trust the server message in XenDesktop 5.5 is a post from: JasonSamuel.com

More of my posts you might like:

1. How to fix the TABCTL32.OCX is not registered error when using the Citrix Quick Launch tool
2. How to fix pass-through authentication & the Windows 2008 logon screen on XenApp 6.5/Web Interface 5.4 using Citrix Receiver
3. How to force an uninstall of Citrix XenApp or Presentation Server via command line

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.

How to fix pass-through authentication & the Windows 2008 logon screen on XenApp 6.5/Web Interface 5.4 using Citrix Receiver is a post from: JasonSamuel.com

More of my posts you might like:

1. How to Deploy Citrix Receiver or Online Web Plugin for XenApp 6.5 on Web Interface 5.4
2. How to deploy EdgeSight 5.4 XenApp agents using install scripts to all your Citrix Farms
3. Getting Java web applications to work on Citrix XenApp

This is all a pretty good sign the XAPI service on the host is hung up. XAPI is the XenServer management toolstack which pretty much controls everything on the XenServer host. If the “XenAPI” toolstack is hosed, XenCenter can’t talk to the host and you probably won’t be able to pass any xe commands. The Xen API is what controls everything at the host layer. Quick way to troubleshoot this:

1. SSH into the host with the issue.

2. Type:

df -h

which will show the disk space usage on the file system. The “-h” switch will display it in gigabytes. Much easier to read. We need to check the root partition and see if it is full. This is typically 4 GB and can be filled up by logs which may cause the XAPI service to stop. If the XenServer root disk is full, you will probably see it drop out of XenCenter because XAPI is stopped. You won’t be able to restart the XAPI service until you free up some space. Here is an example of the root being 100% full:

Extra tip, once you log in to one XenServer host, you can check other hosts remotely without having to SSH into each one in a different terminal. Just type:

ssh <RemoteXenServerIPorName> df -h

3. If the root is full like above, type:

cd /var/log

then

ls

to list the logs. Type:

du –ksh *.*

to list the logs with the sizes. If you find one that is too big, delete it:

rm <logname>.log

From here you can skip ahead below to step 6 and try restarting XAPI.

Also, you might want to consider moving your logs off to a different volume. If you fill your dom0 root, you’re basically hosing the XenServer. Citrix has a good article on how to move the /var/log directory to a different volume here:

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

or retain fewer logs by editing logrotate.conf here:

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

4. If your root is not full, the next thing you probably want to do is disable HA. You can do this in the XenCenter console or you can just type:

xe pool-ha-disable

or if you want to disable HA on a host (you’ll have to run this on each host though):

host-emergency-ha-disable force=true

5. After disabling HA, restart the toolstack:

xe-toolstack-restart

This will disconnect all the hosts in the pool in XenCenter but don’t panic. Give it 10-20 seconds, once the toolstack is restarted the hosts will all reconnect to XenCenter. All pending actions like reboots, migrations, etc. will all stop when restarting the tool stack so you have a clean slate.

6. You should be able to console into your host with the issues now. Type:

service xapi status

and see if it is running. If you want to see how taxed XAPI is, type:

top

to see all the running processing. If XAPI is taking up 40% CPU or more, that is a good indication something is hung up on it.

If XAPI is not running or is very taxed, type:

service xapi restart

if it hangs at “Stopping xapi” or “Starting xapi”, you may need to kill the process.

Type:

kill <pid>

using the process ID from when you ran “service xapi status” or “top”. Then service xapi status to verify all xapi processes have stopped. Then you can type:

service xapi restart

again if it didn’t automatically try and start already. Eventually it will say:

Starting xapi: ....start-of-day complete.                  [  OK  ]

and you should see the host pop back in your XenCenter console. If you go back and run top, xapi should be taking up around 1% or less CPU.

You can type:

xe task-list

to see all the running tasks which shouldn’t be much at this point. Don’t forget to re-enable HA after you’re done. Hope this helps someone.

Can’t console to frozen XenServer host but VMs are still running is a post from: JasonSamuel.com

More of my posts you might like:

1. Running Open Solaris on Citrix XenServer 5.5 shows no IP address associated with the VM
2. How to use an external USB drive as a storage repository in XenServer 5.6

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.

Getting Java web applications to work on Citrix XenApp is a post from: JasonSamuel.com

More of my posts you might like:

1. How to Deploy Citrix Receiver or Online Web Plugin for XenApp 6.5 on Web Interface 5.4
2. How to force an uninstall of Citrix XenApp or Presentation Server via command line
3. How to deploy EdgeSight 5.4 XenApp agents using install scripts to all your Citrix Farms