XenApp

Solution

Solved: VDA client unattended install failure.

When you’re solving the same problem after a couple of months it’s probably a good idea to write a post about it so the solution is close at hand. When you perform an unattended install of VDA client from the 7.x XenApp/XenDesktop media the installation may fail, after this first failure all other attempts will fail instantly.

Like every other self respecting IT engineer I always deploy my servers unattended, for this I like to use a product like RES One Automation 2015. When installing the VDA Client for the first time the installation failed, when examining the log file I noticed following lines:

  • XenDesktopSetup:Starting synchronous process ‘C:\Windows\TEMP\wisE4BD.tmp\Support\DotNet451\NDP451-KB2858728-x86-x64-AllOS-ENU.exe’ with args ‘ /norestart /quiet /q:a’

  • XenDesktopSetup:Process completed with error code 3010

  • XenDesktopSetup:Reboot level increased on behalf of ‘Microsoft .NET Framework 4.5.1’ from NoReboot to ImmediateReboot

  • XenDesktopSetup:InstallComponent: Exit (return False)

  • XenDesktopSetup:Install tasks for this session have finished.

  • XenDesktopSetup:Installation partially complete, reboot is required

  • XenDesktopSetup:Installation Manager returned PartialSuccessAndRebootNeeded

So the installation failed because it installed some dependencies from the support folder, and needed a reboot.

After rebooting the machine, I launched the installation again. Surprisingly it fail instantly and each and other try I did the result was the same. when examining the log file again I noticed the following error.

  • XenDesktopSetup:VerifyCDRoot: Failed to find the MediaID file at ‘C:\Windows\TEMP\wisE4BD.tmp\MediaId_F8D0A1D9-128F-4a86-842D-C61294BA0A02_x64’

  • XenDesktopSetup:VerifyCDRoot: Failed to find the MediaID file at ‘C:\Windows\TEMP\wisE4BD.tmp\x64\x64\MediaId_F8D0A1D9-128F-4a86-842D-C61294BA0A02_x64’

  • XenDesktopSetup:OleSafeThread: Install media not found at ‘C:\Windows\TEMP\wisE4BD.tmp\x64’. Exiting.

  • XenDesktopSetup:Installation media cannot be found

I know the wisxxxx.tmp folder is being automatically generated by RES One Automation, and changes each time. So I copied the source files to a fixed location and launched the installation again but still the log file states the same error message, when look up in the logfile I noticed the line

  • CDRoot = C:\Windows\TEMP\wisE4BD.tmp\x64

So the old CDRoot information is saved somewhere and causes the problem, after some search I found out the after the first installation a Citrix folder was created in the %programdata% location. In this location are some files I did not need. So I deleted this folder and tried again. Now the installation succeeded.

 

 

 

 

Solution

Windows 2012 R2: Black logonscreen after App-V 5 (SP2) Client installation

While I was building a proof of concept for my customer I ran into some issues that where seemingly unrelated. I was building a brand new Windows 2012 R2 / XenApp 7.5 environment including RES Automation Manager, RES Workspace Manager and App-V 5 (SP2). After installing and testing the core XenApp infrastructure, I started to configure the XenApp (Worker/Application Servers) this is when I ran into problems. After installing the App-V (SP2) client and rebooting the server I was no longer able to logon to the Published Desktop I’ve created and successfully tested earlier.

The Citrix receiver keeps hanging on a black logon screen (did not launch pfwsmgr.exe) and after a while the session was ended. I knew there was an issue on Windows 2008 R2 that resulted in a black screen only this was merely a cosmetic issue, because in Windows 2008 logon succeeded and a desktop was presented. To solve this issue you had to create the registry key:

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon
Name: DisableStatus
Type: REG_DWORD
Value: 00000001

Source

As I was not sure if this still applies to Windows Server 2012 R2 I decided to add this registry key to the application server. After logging on Windows revealed its error message that was not show before (User profile service). The EventVwr error message corresponding to this visual error contains:

Windows cannot copy file \C:\Users\Default\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\Control Panel.lnk to location \?\C:\Users[userid]\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\Control Panel.lnk. This error may be caused by network problems or insufficient security rights.

DETAIL – The process cannot access the file because it is being used by another process.

This error led me to following knowledge base document: 2985344

This document addresses problems that some may experience after installation of hotfix KB2919355. The document also links to  hotfix 5 for App-V 5 (SP2) Client after installing this hotfix all was working again.

Powershell

SCRIPT: Check ICA Listener response

Last week I was troubleshooting at a customer which was experiencing some “random” periods in which end users could not login at all. When looking at the Load Evaluator I noticed the least loaded server in those periods were the same. When trying to logon to the server through ICA, the server sits forever at connecting…

Instantly I opened a DOS prompt and did a telnet to the servers ICA port (1494).  The server responded and a connection was made, but when I was expecting to see the ICA heartbeat the telnet session stayed blank, this told me the ICA listener is corrupted. I rebooted the server and I came up perfectly. Problem solved you think, not quiet yet.

The infrastructure consisted of 100+ XenApp servers which are provisioned by Citrix Provisioning Services. So potentially more XenApp servers were having a corrupted ICA listener. But entering a telnet session for each server manually was not an option. and scripting a powershell script which launches an external (telnet) process did was not sufficient either. (because is does not report, the telnet output back to powershell). That’s why I searched the internet how to read a “telnet” sessions output. while searching I stumbled upon a blog that needed to do some telnet magic on Cisco devices. I decided to adapt the script for my own needs

After some alteration I ended up with a script that connects to the ICA port (1494) and reports it’s output. I’ve tested it and it work really fine, but you might have to change the TimeOut settings. When a server reports a potential issue you can test it against a manual telnet session.

  •  Test a Single Computer
  • Test-ICA -ComputerName <your computername here> -TimeOut <Time Out in ms>
  •  Test Multiple Computers
  •  101..190 |% {.\Test-ICA.ps1 -ComputerName CTX$_ -TimeOut <Time Out in ms>}

You can also filter output for your needs. Let me know if you appreciate the script.

Download Test-ICA (2301)

 

Solution

Send Message to User Limitations

Today I received a question from a customer who wanted to send “Large” message to all XenApp users in the farm. They asked me what the maximum number of characters was that you can send to a user. I honestly did not have a clue and answered to the client that I was not aware of any limitation but that I did not have any problems even with longer messages. The customer was happy with my answer and did send its “Large” message to their XenApp 6 sessions.

The question got stuck in my mind and I decided I had to find out if there were limitations. So I prepared a 1000 character sentence and send it with Citrix Delivery Console, result was the message popped up to the session as it supposed to. So I tried a 5000 character message and it did not pop-up.

  • 1000 characters,No problems both CDC as Send-XASessionMessage cmdlet
  • 2000 characters,No problems both CDC as Send-XASessionMessage cmdlet
  • 3000 characters,No problems both CDC as Send-XASessionMessage cmdlet
  • 4000 characters,No problems both CDC as Send-XASessionMessage cmdlet
  • 5000 characters, both CDC as Send-XASessionMessage cmdlet the message did not arrive.

After some narrowing down,  the maximum character in a message send with:

  • Citrix Delivery Console   = 4055
  • Send-XASessionMessage= 4094

I’m not sure why the limit is not the same, but that the conclusion I ended up with. So if you send a message to your user, Keep it short 😉

Cheerio!

 

Solution

SOLVED: Adobe Reader X hangs after opening a PDF file

Some time ago i noticed that when I opened a PDF file, Adobe Reader X stopped responding for sometime. I noticed it happens on Windows 2003, Windows 7 and Windows 2008. after some investigation I found a solution in disabling Adobe’s “new” Protected Mode feature.

  1. Open Adobe Reader X
  2. navigate to Edit->Preferences->General
  3. clear the check-mark at “Enable Protected Mode at startup”
  4. Click OK to save the changes (acknowledge the warning)
  5. Shutdown Adobe Reader X

You can also disable protected mode through a registry key

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockDown]

“bProtectedMode”=dword:00000000

EDIT: In Acrobat Reader XI the location hast changed to: Edit->Preferences->Security (Enhanced)

 

Solution

Solved: XenApp 5 HRP 7 results in 0x000000CF BSOD

While installing a new Citrix XenApp  farm for a customer I upgraded the servers to Hotfix Rollup Pack 7 (HRP7, PSE450W2K3R07). The XenApp 5 farm is build as virtual servers on a  VMWare vSphere 4.1 cluster. Installing Hotfix Rollup Pack 7 via RDP console session (mstsc /console) succeeded  with no error and the farm booted nicely after installing the HRP.

The troubles started when I tried to connect to the farm via an ICA connection, only few seconds after initiating the connection the selected server crashed with an 0x000000CF (TERMINAL_SERVER_DRIVER_MADE_INCORRECT_MEMORY_REFERENCE)BSOD. After the BSOD the server rebooted nicely but an ICA connection was never setup.

Investigating this problem led me to some specific solutions to the problem like:

  • Copying an older version of twexport.sys to “C:\Program Files\Citrix\Drivers” and “C:\Windows\System32\Drivers” [Source]
  • Installing hotfix PSE450R07W2K3011

but none of them solved my solved the problem. Eventually the problem was solved by installing HRP7 NOT via RDP BUT via the VMWare console

Solution

Solved: 0x0000007B BSOD after unattended install of PVS Target Device

While building a deployment sequence for a XenApp 6 farm using SCCM, I ran into the problem that the unattended install of the PVS Target Device (5.6 SP1)  succeeds but after after creating a VHD file using “XenConvert P2VHD” and booting the newly created vDisk the Provisioned Server crashes with a BSOD 0x0000007b (inaccessible boot device).

After some investigation on the source machine I noticed the “Citrix Virtual Hard Disk Enumerator PVS”  device did not install correctly and displayed an yellow exclamation mark in Device Manager (devmgmt.msc).  After searching the citrix forums I ran into a thread in which the others experienced the same problem.

Unfortunatly a real solution is not provided in within the thread (other than a manual installation). So digging down the internet I found the solution for this problem. Somehow the drivers files are not transferred to the “%windir%\System32\Driver” folder during unattended (SCCM/Wisdom) installation.  Copy CFsDep2*.* files from “C:\Program Files\Citrix\Provisioning Services\drivers”  to “%windir%\System32\Driver”  afterwards you can install you can install the PVS Target Device client unattended by running “PVS_Device_x64.exe /S /v /qn

After the installation the exclamation mark has disappeared, a newly created vDisk booted successfully.

 

Error 1046: This Version of Citrix Receiver does not support the selected encryption

When starting a ICA session with RES VDX enabled you may receive the error message:

Error: This Version of Citrix Receiver does not support the selected encryption, when starting RES VDX session

After some searching I ended up at the RES support site which tells you:

Q203290 Error: This Version of Citrix Receiver does not support the selected encryption, when starting RES VDX session

When starting a Citrix XenApp session with RES VDX enabled the following error might occur:
“This Version of Citrix Receiver does not support the selected encryption. [Error 1046] The Virtual Driver is not loaded”.
The second logon attempt runs without any problems. This issue only occurs when using the Citrix Receiver. When using earlier ICA client versions , this error will not occur.

Cause 1 – RES VDX tries to initialize the ICA virtual channel when the Citrix Receiver is not ready yet. 95% probability.
In Citrix Receiver 3.0 and higher, Citrix implemented a timeout in their software. Due to this timeout an error is generated by the Citrix Receiver when RES VDX tries to open the ICA virtual channel. At the seccond logon attempt the timeout is expired and the logon process continues without any problems.
Solution 1.1 – Solved in a FixPack based on RES VDX SR2

To request the fixpack please consult RES Support

Solution

SOLVED: Citrix Receiver Error 61 on OS X

In my test environment I have installed all Citrix components (required) to access applications from remote locations.

Setup:

  • Citrix Access Gateway (VPX) Express
  • Self-Signed certificate. (Generated by CAG)
  • Citrix Webinterface (configured Services Site)
  • XenApp 6

This setup works for the following device OS’es:

  • Windows 7
  • IOS 5
  • Android 2.2
Only when trying to connect an OS X machine to the published application (via Citrix Receiver 11.4.3 It did not work.

After importing the self-signed certificate (crt/cer) to the keystore (login or system) I try to setup up a connection to the published application.  After some time the connection failed with I receive the following error:

Citrix ICA SSL Error 61: You have not chosen to trust FQDN, the issuer of the server’s security certificate.
Error number183

After trying some stuff, like importing it in different formats I eventually found the solution while doing the following steps:
  1. Export your self-signed certificate to a convenient location.
  2. Open Terminal and enter :
  3. Enter:
    Sudo su
  4. Enter your admin user password
  5. Enter:
    mkdir /var/CTXScert
  6. And:
    mkdir /var/CTXScert/cacerts
  7. Now copy your certificate to the just created folder, cp <your location> /var/CTXScert/cacerts/
  8. quit Terminal.
Instantly after connecting again I was presented the Published application, the error had disappeared.

Desktop starts instead of a Published Application

Within my current project we ran in to a situation, where we build a Xenapp 6 farm. When we started an published desktop everything was fine. But after publishing an application and starting it did not start the published application, but the whole desktop was presented.

After some troubleshooting we discovered that newly created users were not affected by this problem so I started to look for differences between our existing test user accounts and and new created ones. In the end I concluded that it had to be the script that ran the other day. That script was executed by the AD guy’s to set some user account attributes (HomeDrive, TS Profile Path, etc). So I ordered the AD guy’s to reset the settings that were changed. After the user account changes had been reset, It still did not work.

While searching some forums I found these documents which outline the exact problem and deliver some “solutions” and workarounds.

CTX120831
KB969851

Basically there is a bug within the Windows 2008 “Active Directory Users and Computers” console which cripples the user account when changing the “Profile Path” on the “Remote Desktop Services Profile” tab. Even when changing back the Profile Path to the default. The user account is still affected by the bug. To fix the user account you have to run this vbs script

Const ADS_PROPERTY_CLEAR = 1
Set objUser = GetObject _
(“LDAP://cn=MyUser,ou=MyOU,dc=MyDomain,dc=com”)
objUser.PutEx ADS_PROPERTY_CLEAR, “userParameters”, 0
objUser.SetInfo

The bug it self is resolved within a Microsoft hotfix and can be downloaded here

 

TIP: To easily  discover the user LDAP path you can use:  dsquery user -samid “UserLogonName”.

After clearing the existing user attributes I was able to start a seamless published application  and no longer the whole desktop was displayed. This BUG also appears when connecting to a Published Application that is hosted on Windows 2003 (running XenApp)