Tag 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

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