About Virtualization, VDI, SBC, Application Compatibility and anything else I feel like
There has long been a debate about how to accurately view the size of your Citrix Provisioning Services ram cache size. SO much so that even Citrix clarified on how to view this detail using yet another tool
The thing is, this is all fine and well, but it’s a bit of a pig to actually get this data when you need it, or in an automated way. Wouldn’t it be better if we could have something easier?
Lately, Andrew Morgan and I decided to sit down and create an easy to use, Windows performance counter for the key metrics in a PVS cache and provide them to the community for use.
These counters turned out to be fascinating, as they really show how the cache works.
Our latest counters (which can be downloaded below) provide the following counters for easy access:
* As there is no accurate way to detect how much ram is assigned to cache via Citrix Provisioning services, this value must be provided or this performance counter is missing.
As Helge Klein wrote in his excellent article "Configuring Citrix ShareFile Sync from PowerShell" this is simply a GUI restriction and not a restriction in the actual ShareFile sync engine.
Helge describes that you can easily do this in PowerShell with the following example:
Add-SyncJob -ApplicationId 1 -ApplicationName "PowerShell" -Account helgeklein.sharefile.com
-RemoteFolderName "foc86c19-d904-434a-9d67-xxxxxxxxxxxx" -LocalFolderPath "D:\Daten\Sync to ShareFile"
-AuthType 4 -UserName firstname.lastname@example.org -SyncDirection 2 -Password "MY SHAREFILE PASSWORD"
While the command was accepted, nothing was synchronized.
I wanted to run a virtual Citrix License server in my LAB.
Unfortunately Citrix only provides the VPX License Server in XenServer format (.xva). If you want to run the VPX on VMware ESX or Microsoft Hyper-V you need to convert it first.
The option to convert a Xen Virtual Appliance to OVF format was removed in XenConvert 2.4.1. So for a conversion you need version 2.3.1.
Here are the direct download links:
However when I tried to convert the downloaded VPX (Citrix_License_Server_VPX_v11.10.0_Build_12002.xva) I got the error "Failed to decode tar header record":
A while ago I was doing some research for Magic Filter when I stumbled upon something interesting within Receiver.
Inside wfica32.exe is a function called _Eng_RunExecutableOnExit. That name caught my interest, I’ve made it a little more readable with Ida Pro:
Some time ago I wrote about the PNAgent data that is stored in the registry in XML format.
After that post Andrew Morgan asked me if I could extract the PNAgent icons from the XML data.
That got me interested so let’s look at this data!
If you look at XML from PNAgent the icondata as in the AppData.Details.Icon node you’ll see something like this:
Seems like the icon data is stored/encrypted in a proprietary format.
ClickOnce is a Microsoft technology that enables an end user to install an application from the web without administrative permissions.
That’s great isn’t it?
While ClickOnce may sound great to developers it’s actually a nightmare for Enterprise administrators because they try to prevent users from installing software themselves.
ClickOnce also incorporates an Automatic Updates mechanism which means that users might run different or not tested/approved versions…
It get’s even worse in virtual environments such as VDI and SBC where machines are often non-persistent. Each time the users starts the application they will see a screen similar to the one below while they actually download and install it over and over again:
If the environment is persistent, it’s not guaranteed that the user works on the same machine each day. This means that the application will be installed on every box the user ever logs onto…
How does it work?
In order to understand how we can best treat ClickOnce applications we need to understand how they work since MSDN documentation does not describe this in detail.
Yesterday I was troubleshooting an application that was migrated to Citrix XenApp.
The application is able to use a high precision scale which is attached to the client pc’s com port. This com port is redirected to XenApp.
While testing users reported several issues, let’s have a look at them.
Error configuring COM Port
Within the application the comport to which the scale is connected must be configured:
After pressing "Registreer" to register the new com port the following error message was shown
Today’s blog is about an application that was migrated to Citrix XenApp. During testing the users reported that several application menu’s were missing.
An example is the settings menu where the System tab is missing:
I suspected a permissions issue so I added the account to the Local Administrator group to verify that. And indeed the System tab was visible.
I removed the account from the Administrators group and fired up Process Monitor. I set a filter on the process name (ra60.exe) and on Result (ACCESS DENIED):
If you start the tool without parameters you will get the GUI, just like before:
To use the COM interface you first need to register the executable with the /regserver switch:
After the registration you can call it using any language that supports COM. To get you started I wrote a few examples
This application reads data from an external device called SECUTEST.
The device is connected to a COM port which is redirected to the XenApp session. In contrast to Microsoft Remote Desktop Services COM ports are not automatically redirected in XenApp but need to be mapped via eg a logonscript (NET USE COM1: \\Client\COM1:) or using UEM.
In my case the COM port was mapped with RES Workspace Manager:
.NET .NET FrameWork Active Directory Altiris Apple Automation Manager Citrix Dell Delphi Excel Exchange Exchange2003 Exchange2010 Hack HP iOS Java LinkedIn Linux Lync MSI Office Office 2010 Passat Password PowerPoint PowerShell RES RNS510 SasLibEx SCOM Security Terminal Server ThinApp TSAdminEx VBS VCDS Visual Basic Visual Studio VMWare Volkswagen VW Windows PE Wordpress XenApp