Settings

Log In

XenApp

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:

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.

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

What an interesting start of the week, today Citrix’s desktop CTO Harry Labana wrote a blog post accusing VMware of lying while refering to a Gartner Report about the TCO of SBC comparing to (un)managed desktops. In this article about VMware’s View, the company refers tho the report and insinuates that VMWare View incorporates SBC technology (which it doesn’t).

As you might know, one of the big differences between VMware’s and Citrix’s desktop virtualization solutions is that Citrix XenDesktop incorporates VDI/Desktop virtualization capabilities but also includes XenApp which delivers shared Terminal Server-based desktops and applications. While VMware View only incorporates VDI/desktop virtualization.

Therefore their press release is inaccurate and subject to rectification, in my opinion.

Stay tuned for more….

UPDATE: Brian Madden also picked up the story and has some background information, he also responds to the reaction from VMWare.

The recent joint announcement between Wyse and VMware, on February 9, featured a quote by Gartner looking at the TCO benefits associated with server-based computing (SBC). The Wyse portfolio of thin, zero and cloud PC client solutions supports both SBC and VDI. It is appropriate for Wyse to choose the feature this when talking about their products. VMware’s portion of the announcement featured customer momentum and results related to our portfolio of desktop and application virtualization technologies.

Who knows if it was on purpose or an oversight? They’ll claim it was a mistake. The conspiracy theorists will believe otherwise. If you asked me over a beer I’d tell you that I don’t believe they did it on purpose, but that it was not wise to respond with the statement they used. Instead they should have put a new quote with VDI-specific data in it and reissued the press release. Then they’d be done. But now we’re left with a release where TS is doing the heavy lifting to power the “success” of the TCO savings of VDI. And that’s exactly what I accused them of doing three years ago, which I wish was a thing of the past.

Fundamentally VMware is trying to defend an inaccurate press release. After a history of getting away with elastic facts, getting caught twice, the appropriate thing to do would be to retract the statement and claims of SBC having anything to do with VMware.

When I was drawing an architectual document in visio, I needed some stencils after a quick search on google I found some and bundled them for my convinience hopefully you like them as well. [download id=”2″]

Yesterday I was asked to implement a time-out on active citrix sessions. The purpose for the script was to limit the maximum active session time for the user. The HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\ICA-TCP\MaxActiveSession registry key was not flexible enough and I couldn’t find a ready made solution. I decided to develop my own script based on information in the XenApp Management SDK and on CDN. After some time of scripting I found the following script working and flexible enough to meet the demands of the customer. Basically you schedule the command with the following parameter “cscript <filename.wsf> min <time-out in minutes>”

XX minutes before the session if logged off the user is send an message, the XX minutes is defined by the WarnThreshold value in the script. the Message can be customized by editing the strMsg + strTitle value.

The script can be easily adjusted to be used for a flexible Idle Time-out . the only property that has to be adjusted is Session.LogonTime into Session.LastInputTime

All warnings are logged to a logfile which you can set in the script. Make sure the account used for running the script is a XenApp Administrator.

In a hunt for complete best practices guide I found the following considerations:

ePo Agent recommendations:

Delete the Agent GUID for McAfee EPO agent; otherwise all machines deployed came up in EPO server as the same computer. So, if you are going to use the Provisioning Services image in Shared Image mode, Citrix recommends stopping the McAfee framework service and deleting the following registry key, just before your create your Provisioning Services image.

Additional registry keys may need to be cleared or deleted before rolling out an image in Standard Image mode. To run McAfee 8.5i and EPO on a vDisk in Standard Image mode, the values for the following registry keys must be deleted before imaging the Master Target Device (this could also be done after building the image by putting the image back into Private Image Mode):

Associates\ePolicy Orchestrator\Agent\AgentGUID

Associates\ePolicy Orchestrator\Agent\MACADDRESS

(if using Host Intrusion)

Make sure there is not a policy applied to this PC on EPO that restarts the framework service after X seconds…. (Otherwise this key might be recreated before you start the Provisioning Services image creation process).

The problem here is that each time a PC restarts in Shared Image Mode, a different GUID is recreated. It might be necessary to set EPO to delete stale entries from its Asset database. The results might also not provide a true reflection in reports of a particular PCs infection history, as it will have a new record in the EPO database each time a reboot occurs. This is preferable over having lots of PCs with only one of them having updated antivirus at a time.

The “%ProgramFiles%\Citrix” folder contains many configuration and log files that are always changing, especially the Local Host Cache (imalhc.mdb) and Resource Manager Local Database (RMLocalDatabase.mdb). You could exclude the whole folder. More specifically, the main ones are:

“%ProgramFiles%\Citrix\Citrix Resource Manager\LocalDB”

“%ProgramFiles%\Citrix\Citrix Resource Manager\SummaryFiles”

“%ProgramFiles%\Citrix\Independent Management Architecture”

“%ProgramFiles%\Citrix\logs”

Exclude the Print Spooler (%SystemRoot%\System32\spool\PRINTERS) folder. Note that in our deployments we typically place these folders on the non-System Drive.

We would recommend excluding as much of the user’s profile (%UserProfile%) as possible. In fact, the only folder that is of major concern is the Temporary Internet Cache (”%UserProfile%\Local Settings\Temporary Internet Files”).

If you do not exclude the Profiles, then exclude the user‘s Presentation Server Client bitmap cache (”%UserProfile%\Application Data\ICAClient\Cache” or “%AppData%\ICAClient\Cache”) used for ICA pass-through connections by the locally installed PNClassic and PNAgent.

Exclude .dat and .tmp files.

Disable the heuristics mode of scanning, this setting can be very intensive on the system

Limit antivirus definition updates to the Target Device. Create a plan to upgrade the vDisk periodically using manual, automatic or automated techniques such as Automatic vDisk updates or by using something like WorkFlow Studio.

Avoid scanning your disk write cache location if that write cache is hosted on the Provisioning Services server. In limited testing it has been observed that most scanners cannot detect a virus within this location because of their inherit design and the methods used to determine a virus.

Do not scan your Targets I/O stream in real-time. This can cause excessive retries when the Target expects it’s I/O and that process is delayed by real-time scanning, there is good potential for a second and maybe more requests for the same packet fragment.

Avoid scanning the BNDevice.exe process on the Target. There are a few drivers that should be excluded from scanning, as well, in the <systemroot>\windows\system32\drivers directory you can exclude BNNS.sys, BNNF.sys, BNPort.sys, and bnistack.sys