About Virtualization, VDI, SBC, Application Compatibility and anything else I feel like
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:
Yesterday I was asked to investigate a problem with a presentation pc. Even though the volume was set maximal there was not audio output.
The machine was used to connect to a Citrix XenApp desktop and RES Workspace Extender was used to integrate local applications in the XenApp desktop.
The local sound volume control was published as a subscribed application so I launched that and verified that the volume was set to Maximum:
I decided to launch the local explorer shell and noticed that there were two volume control icons in the Traybar:
.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 VSAE Windows PE Wordpress XenApp