Category Archives: XenApp 5

XenApp session not closing correctly

Sometimes when you close a XenApp application, the session on the server may not close correctly or remain active, thus creating problems such as :

· Profiles corruption

· Increased servers’ resources usage

· Increased number of disconnected sessions, and so on…

This behavior can be caused by locked files (have a look at this for an example) or by processes that may have been launched during the sessions and that are not correctly closed upon user’s logoff.

For instance, if you publish an instance of Internet Explorer that in turn launches a Java process in order to run a web application, this java process may not be recognized by Citrix as being part of the user’s session, thus ignoring it upon user’s logoff and leaving an active session on the server.

A registry key can be modified on the server in order to instruct XenApp to consider other processes to be part of a user’s session ; the key is :

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI]

and the value to configure is :  LogoffCheckSysModules 

For example, you configure such value like the following if you want XenApp to recognize the two processes “Java.exe” and “Javaw.exe” :

“LogoffCheckSysModules”=”java.exe,javaw.exe”

I experienced this on XenApp 5 and Presentation Server 4 and the solution works correctly. I never faced this on XenApp 6.5.

For more information about this : http://support.citrix.com/article/CTX891671

Citrix XenApp and Web Interface – from authentication to application launching (yes, yet another one)

One of the most frequent questions that colleagues and customers ask me is ‘Hey… but… wait a minute, who does authenticate the user? Is that the Web Interface or something else? ’

Yes, it’s true, there is plenty of documentation out there that explains how the XenApp logon process works, but I always struggled to find a document concise and clear enough that explains in details (but not too many) how the authentication process works and what are the services and components involved.

One great document available on line is the ‘The Excruciating Detail of the XenApp Logon Process’ published on brianmadden.com, that’s a very detailed document, but sometimes it’s a bit ‘difficult’ to read for people who need a quick answer or for non-so-technical people.

In this article I wanted to summarize the logon and application launching process by focusing on four main phases:

Phase 1: User Authentication

Phase 2: Resource Enumeration

Phase 3: Resource Resolution

Phase 4: Resource Launching

This document is not meant to be ‘an official guide’ about how it works (there are plenty of Citrix documents that do that), it is just meant to help whoever needs to have a quick and detailed overview of such process. There may be errors in it, so feel free to add any comments or correct me if I’m wrong.

The majority of the information contained here comes from this great Citrix video: Web Interface Logon and Application Launch Process for XenApp

 

Phase 1: User Authentication

User Authentication

1. User launches web browser and types in the WI URL

2. Then he connects to web interface

3. Web interface returns a logon page

4. User types his credentials

5. The credentials are forwarded to the XML service (in the http or HTTPS format)

6. Then to the IMA service

7. The IMA service then forwards the credentials to the ‘Local Security Authority Service (Lsass.exe), which in turn encrypts these credentials and passes them to the domain controller

8. The Domain Controller returns the user’s SID and a list of groups’ SIDs back to the Lsass service, and then back to IMA

 

Phase 2: Resource Enumeration

Resource Enumeration

9. IMA uses these SIDs to look into the Local Host Cache on the server for a list of application and the ‘worker group preference’ policy for this authenticated user

10. Then the list of applications, along with the ‘worker group preference’ policies are returned by the IMA service to the Web Interface (through the XML service)

11. Web interfaces then uses its java objects to create a web page that contains the application list for the user ; the user’s ‘worker group preference’ policy is cached in the web interface’s memory

12. The web page is then presented to the user’s browser, thus completing the ‘Resource Enumeration ’ phase

 

Phase 3: Resource Resolution

Resource Resolution

13. Then the user selects a particular application from the applications list

14. The selected application’s data is passed back to the web interface, which in turns passes these information to the XML and IMA services along with the ‘worker group preference’ policy

15. These information are then forwarded to the zone data collector’s IMA service, which then :

a. tries to find the least loaded server according to the ‘worker group preference’ policy

b. when it finds a server sends a query to the ‘Citrix Services Manager’ of that server to verify whether or not such server has the requested application installed

c. if the answer is yes, it forwards that server’ host ID to the XML broker

16. The XML broker then translate this host ID into its IP address by searching the server’s ‘local host cache’, the IP address is then provided to the Web Interface, thus completing the Application Resolution phase

 

Phase 4: Resource Launching

Resource Launching

17. The web interface will then take this IP address and creates an ICA file, which is then returned to the users’ web browser

18. Then the Citrix plugin, located on the client, uses the information included in the ICA file to launch an ICA connection on the least loaded server

19. The server then launches the application, which is then presented to the user through the ICA channel

 

More information can be found here:

http://support.citrix.com/article/CTX129589  (Web Interface Logon and Application Launch Process for XenApp)

http://support.citrix.com/article/CTX134979 (High Availability for Citrix XenDesktop and Citrix XenApp – Planning Guide)

http://www.brianmadden.com/blogs/gabeknuth/archive/2008/08/14/briforum-video-the-excruciating-detail-of-the-xenapp-logon-process.aspx (The Excruciating Detail of the XenApp Logon Process)

Getting rid of the ‘Internet Explorer Enhanced Security Configuration is enabled’ page when publishing IE through XenApp

Environment: Citrix XenApp 6.5, Windows Server 2008 R2, Internet Explorer 8.

Scenario: you published IE as a XenApp application, you turned IESEC off through GPOs (or through the Server Manager) and you configured a default home page for all users through a GPOs.

Problem description: at their first logon, your users get the ‘res://iesetup.dll/HardAdmin.htm’ start page which says something like ‘Internet Explorer Enhanced Security Configuration is enabled’. You don’t understand why this happens as you are sure you correctly set the default home page and disabled IESEC. Anyway, when users log on a second time they see their correct home page. This problem might be very annoying when every user has a local profile which is deleted and then needs to be recreated each time.

Problem cause: this problem happens if you disable IESEC after installing XenApp and enabling Remote Desktop Services, in fact, when you do so, the NTUSER.DAT file located in the Default User folder retains some settings that bring you to the ‘res://iesetup.dll/HardAdmin.htm’ on your first logon.

Problem resolution: to avoid this problem disable IESEC before installing XenApp. If it’s too late and you have already installed XenApp without disabling IESEC first, you can replace the NTUSER.DAT file located in the Default User folder with a correct one; to do so follow step #4 described in this Microsoft article: http://support.microsoft.com/kb/933991

Acrobat Reader 9 script pop-up removal

Environment:  Windows Server 2003 Service Pack 2, Citrix XenApp 5 Roll Up Pack 7, Citrix User Profile Management 3.2, VMware ESX 4.0.

Problem description: every time an application tries to open, through a script, a pdf file with Acrobat Reader (from version 9 on), a pop-up alert notifies the user of the action. This pop-up can be annoying when multiple pdf files need to be open during a session. The pop-up can be acknowledged and avoided for future uses, but usually users tend to ignore its content and click on “ok”.

Problem cause: the pop-up alert is a security feature introduced by Adobe since Acrobat Reader version 9.

Problem solution: when the “do not show this message again” check box is checked, a new registry key is created into the registry. To discover the key created by the process I used a free tool called “RegFromApp.exe”. The key is:

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader
\9.0\AVAlert\cCheckbox\cAcrobat]"iWarnScriptPrintAll"=dword:00000001

To solve the problem I created an ADM template which I’ve imported and enabled through the GPO management console. The template is the following (please note that it modifies also another registry key: …\9.0\AdobeViewer]”EULA”= dword:00000001, which is useful to avoid the adobe contract to appear each time a new user opens acrobat reader):

;template creato da Sebastiano Ingallo
;per disabilitare il pop-up di alert
;di acrobat reader e la
;visualizzazione del contratto al primo avvio
CLASS USER
CATEGORY !!Reader
        POLICY !!DisAlert
            KEYNAME "Software\Adobe\Acrobat Reader\9.0\
                     AVAlert\cCheckbox\cAcrobat"
           EXPLAIN !!DisAlertExplain
                VALUENAME "iWarnScriptPrintAll"
                    VALUEON NUMERIC 1
                    VALUEOFF NUMERIC 0
        END POLICY
       POLICY !!DonotdisplayEULA
            KEYNAME "Software\Adobe\Acrobat Reader\9.0\AdobeViewer"
           EXPLAIN !!DonotdisplayEULAexplain
                VALUENAME "EULA"
                    VALUEON NUMERIC 1
                    VALUEOFF NUMERIC 0
        END POLICY
END CATEGORY
[strings]
Reader="Adobe Reader 9.0"
DisAlert="Disabilita Alert Stampa"
DisAlertExplain="Se abilitato non visualizza l'alert
durante la stampa inziata da uno script"
DonotdisplayEULA="Non visualizzare contratto"
DonotdisplayEULAexplain="Se abilitato non fa
visualizzare il contratto al primo avvio"

 

PS: comments are written in Italian.

Support Articlesfrickelsoft.net; nirsoft.net

 

 

VMware ESX hgfs.dat file causes Terminal Services to duplicate users’ profiles

Environment:  Windows Server 2003 Service Pack 2, Citrix XenApp 5 Roll Up Pack 7, Citrix User Profile Management 3.2, VMware ESX 4.0.

Problem description: in some situation, when using Terminal Server roaming profiles or Citrix UPM, users connecting to a Terminal Server may have their profile duplicated in the form of user.domain.001, user.domain.002, user.domain.003 and so on.

Problem cause: the problem is caused by a bug in the VMware tools “shared folder” feature. Such feature is installed when VMware tools are installed with the “Complete” option. When a user logs off, the Terminal Server tries to copy the hgfs.dat file back to the profiles folder but the operation fails because VMware keeps the file locked with exclusive access. When the user logs in again, a new and duplicated user profile folder is created.

Problem solution: the “shared folder” feature can be disabled by modifying a registry key (the feature is not used by ESX and GSX  Server).

  1. Disable users logons on the server;
  2. When all users are logged off delete the profiles folders in c:\Documents and Settings\;
  3. Open the registry editor: regedit;
  4. Find the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\
  5. Open the “ProviderOrder” key and delete the the words “hgfs” or “vmhgs” or “vmhgfs” present in the string ;
  6. Reboot the server.
Support Articles: http://kb.vmware.com/

Application written with GUPTA 5.2 and published through XenApp 5 returns “Empty Array” error

System Version: XenApp 5 for Windows 2003 – GUPTA 5.2 Application (ported from GUPTA 4.1)

Problem Summary: after an undefined amount of time the application starts to show pop-ups with the following alert: “Empty Array” and then it becomes unusable. OR The application get stuck and becomes unusable.


 

Cause: the problem occurs when using applications (through ICA) written with GUPTA version x .x  and then ported to a new version of GUPTA. In my case the application has been ported from GUPTA version 4.1 to GUPTA version 5.2. The problem is caused by the XenApp’s Seamless Engine, in fact, if the application is not published in seamless mode the problem doesn’t occur.

 The XenApp seamless engine sends some messages to the application called “WM_QUERYDRAGICON”, such messages are used to acquire information about icons associated to the application’s window, but, with some GUPTA applications they bring about unexpected results .In this particular case, the sending of this messages causes the GUPTA application to continually create GDI objects (about 4 per second) without removing them, exhausting quickly the memory space given to the application instance.

 The “Empty Array” message is displayed when the number of GDI objects created by the application reaches 9.999. This value is controlled by the following registry key:

[HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Windows]“ GDIProcessHandleQuota”dword 10000

In my case I set the value at 20.000 for testing purposes (that’s why the task manager in the picture shows 19.999 GDI objects), but the default value is 10.000, allowing then for 9.999 GDI objects.

Please note: if the application is written in GUPTA 5.2 from scratch the problem doesn’t occur.

 

Solution: to solve the problem you need to create the following key:

 [HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Citrix/wfshell/TWI]”SeamlessFlags”= dword 0x200 hex

Such key prevents XenApp to send WM_QUERYDRAGICON messages.

 

Support Articlessupport.citrix.com and support.unify.com