Advertisements

XenApp 6.5 STAID (ctxsta.conf) not updating when using PVS

Been working on yet another XenApp 6.5 upgrade.  I started noticing  issues with the ctxsta.conf file normally located under C:\Program Files (x86)\Citrix\system32\, where the unique STAID does not update when using Citrix Provisioning Services after the host is rebooted on a XenApp 6.5FP1 host.

This could result in issues with applications failing to open when launched via Access Gateway . Please note I only saw this behavior when using the affected servers as a STA on the Access Gateway (in my case AGEE on NetScaler)

Environment:

  • Windows 2008 R2
  • Citrix XenApp 6.5 FP1
  • PVS 6.1.16
  • Citrix Receiver 13.4

Fix:

Install this limited hotfix from Citrix (XA650R01W2K8R2X64094) which is now part of  Hotfix Rollup Pack 2 for Citrix XenApp 6.5 for Microsoft Windows Server 2008 R2

Once this the patch is applied, the and the STA will get configured correctly with your provisioned XenApp 6.5FP1 targets.

This issue does not seem to occur if you don’t utilize PVS

 

Advertisements

XenApp 6.5 – Remote Desktop display settings can’t be changed

Not sure how I missed this one during my last XenApp 6.5 implementation.

The option of “Make text and other items larger or smaller” while in a Windows 2008 RDS session is no longer available as it was in a Windows 2003 TS session. This option is now greyed out and displays “The display settings can’t be changed from a remote session”.

Environment:

  • Windows 2008 R2
  • Citrix XenApp 6.5
  • PVS 6.1.16
  • Citrix Receiver 13.4

Fix:

If you want this option available during a session, download a hotfix from Microsoft that will re-enable this setting.

Note The DPI setting enables you to change the size of all fonts and other UI elements on the computer. For example, you change the setting to increase the legibility of the UI.

 

 

Hide Client Drive mappings for ICA sessions

Client Drive mappings is a great feature of XenApp / XenDesktop, although this presents a security concern depending on the environment, it is sometimes necessary to allow local file access for your XenApp and/or XenDesktop as part of the work flow.

While assisting an old coworker at my last company, he was presented with the challenge of allowing client drive mappings, however only allow to show specific drive.

Environment:

  • Windows 2003 SP3/Windows 2008 R2
  • Citrix XenApp 5.0 / 6.5
  • PVS 6.1.16
  • Citrix Receiver 13.x
  • Web Interface 5.4

Issue:

Disable specific Client Drive Mappings from enumerating within an ICA session.

Solution:

Registry:

  • Log on to a client machine with Receiver 13.x installed, as a user with administrative rights.
  • For 64bit operating systems, navigate to registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientDrive
  • For 32bit operating systems, navigate to registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientDrive
  • At the DisableDrives string value, add the value data as the Client Drive letter\s to be disabled. Do not add commas between drive letters while disabling multiple drives.

 

 

Web Interface Site

  • Navigate to C:\inetpub\wwwroot\Citrix\NAME OF SITE\conf.
  • Open default.ica with notepad.
  • Under the section [WFCLIENT] add DisableDrives=DriveLetter.
  • All ICA sessions launched from the corresponding Web Interface Browser Site has the specified Client Drive disabled.

 

PVS Gold image WMI issues fix

As part of a PVS image issue discovery project, I was able to determine that WMI was not working on several gold images which was causing several memory leaks, as well as event viewer complaining just about every 30 seconds.

Problems escalated whenXenApp hosts would completely run our of virtual memory which would end up affecting the overall user experience.

Environment:

  • Windows 2003 SP3
  • Citrix XenApp 5.0
  • PVS 6.1.16

Issue:

WMI not working on several Golden images.  My guess is this image was copied in a broken state and was replicated to many different images.

Fix:

Run the following in command line

  • Regsvr32 %SystemRoot%\System32\wbem\wmidcprv.dll
  • cd /d %windir%\system32\wbem
  • for %i in (*.dll) do RegSvr32 -s %i
  • for %i in (*.exe) do %i /RegServer

The Windows Management Instrumentation Tester window may appear, this is normal and we can go ahead to close it.

If it does not work, I also suggest you run the following commands to repair WMI namespace:

  • net stop winmgmt
  • wmic /NAMESPACE:\\root path “__namespace.name=’wmi'” delete
  • mofcomp %windir%\system32\wbem\wmi.mof
  • net start winmgmt

Restart the computer to check the result. If the issue persists, try the following steps:

  • winmgmt /verifyrepository
  • winmgmt /salvagerepository

XenApp 6.5 – Seamless applications always on top

I noticed that intermittently seamless XenApp 6.5 published applications would stay on top of other windows even when they were not active.  In my case I been utilizing the Citrix Receiver Enterprise 13.1.0.89 to take advantage of the Pre-Launch feature.

Was able to replicate the issue with all Receiver versions 3.x, even with the new 3.4 client which also works with the Pre-Launch feature of XenApp 6.5

I did not experience the same problem with legacy clients 11.2 and 12.1 (Don’t use these clients with XenApp 6.5)

Environment

  • Windows 2008 R2
  • XenApp 6.5
  • UPM 4.1
  • vSphere 4.0 <-  What the heck? I know, I know :P
  • Citrix Receiver 3.x

Cause:

The issue exact cause is unknown, but seems to be related to changes in the gain focus behavior of the new Citrix Receiver 3.x.  I contacted Citrix support on this one, and after they thought I was crazy, I was able to replicate the problem while on the phone.

It seems that a Seamless Application Window does not become the active window if you make a local window active while the seamless connection initiates.

Resolution:

After speaking to a senior Citrix support specialist, he directed me to an old Citrix article.  Applying the Registry key changes mentioned solves the issue (TWISeamlessFlag = 1)

For x86 systems:

1. Edit the registry:
HKEY_LOCAL_MACHINE\Software\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\WFClient

2. Create a string value, REG_SZ, called TWISeamlessFlag with a value data of 1.

For x64 Systems:

1. Edit the registry:
HKEY_LOCAL_MACHINE\Software\ Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\WFClient

2. Create a string value, REG_SZ, called TWISeamlessFlag with a value data of 1.

Provisioned XenApp servers halt when the license server is unavailable

Ever hear Citrix Engineers say, “If our Citrix License Server goes down, we still have 30 days to recover it?”  Well that is somewhat true.  However if you are running Citrix Provisioning and are not careful, Provisioned XenApp servers stop accepting connections if they are rebooted and the License Server is unavailable.  Read this previous article I wrote on how to HA your Citrix License server with the NetScalers.

You will notice this behavior on your farm by looking at the XenApp Server load and you see a load of 20000, even when there are no users connected.  You can check the load via PowerShell on XenApp 6.x hosts as it comes with the PSSnapin preinstalled or via some GUI tools.

Some examples on how to check your Farm’s Load via PS

A simple qfarm.exe /load” will display your current server load

simple_load

 

Another more complex way is to run the syntax below, which will allow you to see CPU/Memory utilization

Add-PSSnapin Citrix.XenApp.CommandsGet-XAZone | Get-XAServer -onlineonly | Get-XAServerLoad | format-table -auto

better_load

 

Some GUI options are:

  • Farm Nanny (Free) by Michel Stevelmans
  • Control Up (Paid) by the folks from SmartX which I highly recommend.

control_up

Now let’s fix this…

Environment

  • Windows 2008 R2
  • XenApp 6.5
  • UPM 4.1
  • vSphere 4.0 <-  What the heck? I know, I know :P
  • License Server 11.6.1 (or later)

Cause

The root cause for this problem is that the license server cache file MPS-WSXICA_MPS-WSXICA.ini is saved in the install directory \program files (x86)\Citrix\system32\cache, which could be unavailable when the server image is shut down.

Solution

Redirect the MPS-WSXICA_MPS-WSXICA.ini file to a network share. Read CTX131202 for additional instructions, please note this requires HRP01 for XenApp 6.5

  • On the XenApp Server Image, set the following registry value to a file share location with a UNC Path:
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Install\
    CacheLocation
  • Create the file share with the following NTFS permissions.
    Note
    : In this example the XA6LIC is the XenApp Server Computer Account not the Citrix License Server.

  • Set the following Share Permissions: 
    Note
    : In this example the XA6LIC is the Xenapp Server Computer Account not the Citrix License Server. If there are more than one computer, an active directory computer group can be used instead of specifying individual computer accounts.

 

Unable to Logoff XenApp 6.5 ICA session

While growing our XenApp 6.5 environment I noticed certain users were not be able to log off and would receive the message “Waiting for System Event Notification Service”.  Immediately when this occurred, other users would start seeing similar issues from the same XenApp server.

Environment:

  • Windows 2008 R2
  • XenApp 6.5
  • UPM 4.1
  • vSphere 4.0 <-  What the heck? I know, I know :P
  • Office Communicator 2007 R2

Cause

The screen remains unresponsive with the “Waiting for System Event Notification Service” pop-up. On the server user has a Communicator (OCS) running and one of the instances is pegging an entire core resulting in users unable to log off sessions.

This will occur when multiple users try to log off a terminal server at the same time while signed in to Office Communicator 2007 R2

Resolution

For an immediate fix, terminate the pegged OCS processes on the XenApp server(s) where users are not able to log off, this instantly fixes the issue for all other users logged on the server.

The permanent solution is to apply this fix (2755391) from Microsoft, however head over and read this article to get more information on the issue.

Original post at the Citrix knowledgebase.