The solution to this problem is quite simple actually.

First delete the hidden transfer VM in Xencenter (you need to enable hidden objects in view)

If there are multiple transfer VM’s, do not worry about deleting them all, we will add the right one back.

Then open a console on the poolmaster (any memberserver will also do)

Type the following command  ”/opt/xensource/packages/files/transfer-vm/install-transfer-vm.sh”

And voila ! the transfer VM is back and this time it works fine !

The pool upgrade did not work out for me (another story), so I decided to setup a fresh installation.
In Xenserver 6.1 the xstools used in Windows virtual machines has changed.

There is now the possibility to install the “normal” (installwizard.msi) version and the “legacy” (xenlegacy.exe) version.
By default you will install the normal version provided by the autorun when the ISO is activated in the VM.

When using the normal drivers some functionality has been removed, this is where the problem begins for Citrix Provisioning Services.

The driver lacks support for VSS and PVS !

So when you create a new VM that should be hosted by PVS, you must install the legacy driver.
Also you need to “switch” the VM to a different supported mode by Xenserver.
This is not done automatically
To do this you need the UUID of the VM and use the CLI of Xenserver to enter the following command:

xe vm-param-set uuid=platform:device_id=0001

Failure in entering this command will result in a BSOD !

If you already installed the “normal” xstools, you really have to be carefull in removing them before installing the legacy client .

Removing the “normal” client the “wrong” way will result in a BSOD !

The correct way to remove the client is explained in the following Citrix article: CTX135099

My personal experience with removal of the client has almost always resulted in a BSOD on reboot. So make sure you create a snapshot before trying this stuff !

So what about already existing Xenapp en Xendesktop images with the older XSTOOLS ?
We all know it is a pain to remove and reinstall them in combination with PVS.

In my case I had a Xenapp image with older xstools from Xenserver 6.0.2.

Well they should work normally, but you also need to switch the VM to the supported mode with the CLI command:
xe vm-param-set uuid= platform:device_id=0001

How to query the current platform id ?
Type the following command:

xe vm-param-get uuid=param-name=platform

and you will get something like

A default VM does not have the value device_id=0001 but device_id=0002

So i guess it cannot hurt to switch this parameter back if you change the legacy tools for the original tools.
The documentation does not give any information about this.

So to be sure i made a little diagram:

This post is password protected. To view it please enter your password below:

Password:

Snapshots did not get created anymore, now my backup system is depending on this, so i took some time to dive into this issue.

I found a forum post on the citrix forums from 19 October 2012 describing the same issue. (http://forums.citrix.com/thread.jspa?threadID=295713&start=0&tstart=0)

Errors are like this:
Error code: SR_BACKEND_FAILURE_181
Error parameters: , Error in Metadata volume operation for SR. opterr=VDI delete operation failed for parameters: /dev/VG_XenStorage-

Now i am not going into the time it takes Citrix to fix this, but i guess anyone with Xenserver 6.0 and Xenserver 6.0.2 can get this issue.
After looking into the forum on Page 3 i found a practical workaround that fixes the problem for now.

My temporary FIX until Citrix published a real hotfix, continue at own risk !
See Official Citrix article regarding this issue here: http://support.citrix.com/article/CTX131660

First you need to exactly know what you are doing, because if done wrong YOU CAN LOOSE VM’S

Tools needed (if on a windows machine):
-Xencenter
-WinSCP
-Good nerves

Open up a winscp session to your Xenserver host (if in a pool, the pool master)
Open the file /opt/xensource/sm/srmetadata.py (backup this file first!)

Change the file according to the post on the forum:

go to line 472
add
sr_info = sr_info.replace(‘&’,'+’)
go to line 492
add this line:
vdi_info = vdi_info.replace(‘&’,'+’)

Now in Xenserver 6.0.2 i did this somewhat different

go to line 472
replace all text with
sr_info = sr_info.replace(‘&’,'+’)

go to line 491
replace all text with
vdi_info = vdi_info.replace(‘&’,'+’)

Save the file and it should then be possible to make snapshots again.

CitrixReceiverEnterprise

For Webmail:

https://webmail.r2dtop.com/owa

For logging in:

https://portal.r2dtop.com

The server console could not be accessed from XenCenter, there was only a blank whitescreen and when the VM was being forced to shutdown it complained about “Another operation involving the object is currently in progress class: VM”.

There’s some discussion in the Citrix forums regarding this problem on this thread.

Feeling a bit worried that Xenserver was not able to (force) shutdown this Virtual Machine and all other options like restarting the toolstack on all Xenservers did not help. Even forcing the Xenserver to reboot on the CLI did not work, because the Xenserver wants to shutdown all VM’s before doing the reboot.

Finally i resorted in the method described below:

1 – “xe vm-list” to get the uuid of the VM that is hung
2 – “list_domains” to list the domain uuid’s so you can determine the domain # of the VM above by matching the uuids from this output with the uuid for your VM from the previous command.
3 – “/opt/xensource/debug/destroy_domain -domid XX” where XX is the domain number from the previous command
4 – “xe vm-reboot uuid=XXXX –force” where XXXX is the uuid from the first vm-list command for your VM. (name-label may work but didn’t work this time for me so I used the uuid)

Well that did the trick !

Steeds meer bedrijven schakelen steeds vaker over op “het nieuwe werken”, waardoor het niet meer van belang zou moeten zijn waar de werknemer zich bevind, maar wel dat hij zijn werkzaamheden kan doen. Beschikking hebben over applicaties en databases is dan wel een minimum.

Het lastige van een vaste computer is het feit dat hij niet (echt) vervoerbaar is. Bovendien zit deze computer vaak “vast” aan een eigen gebouwd netwerk en heeft daardoor niet alle gegevens bij zich als je hem toch zou meenemen. Een gedeeltelijke oplossing werd gevonden in het vervangen van deze desktop voor een laptop. immers deze is wel vervoerbaar en makkelijk in te zetten, maar de beschikking over alle data bleef een probleem.

Maar door het gebruik van laptops kwam er in feite een andere uitdaging bij, namelijk die van decentralisatie van data. Men nam namelijk ineens de belangrijke bestanden mee op de laptop. Een ware nachtmerrie voor systeembeheerders, immers is er geen controle meer over de data en zaken als backup en beveiliging van de data werden onzichtbaar.

Het veilig stellen van deze vaak essentiele informatie die op een harddisk staat was ineens een uitdaging geworden. Denk hierbij bijvoorbeeld aan diefstal / beschadiging / eigen fouten.

Gelukkig zijn er voor deze uitdaging ook goede oplossingen te verzinnen. Een van de oplossingen die steeds vaker toegepast wordt is het blijven werken op een overal benaderbare desktop. Deze desktop wordt dan aangeboden vanuit een centrale omgeving waar alles goed geregeld is.

Meer weten ?

neem contact op met ons bedrijf via info@r2dtop.com

To get Flash Redirection working again in Internet Explorer 9 you need to add a registry key in:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\HdxMediaStreamForFlash\Server\PseudoServer

add a value IEBrowserMaximumMajorVersion=dword:00000009 and it works again !

Other things to check:

Check flashversions on server and on client
Policy to enable flash

The new HDX monitor 2.0 (downloadable at http://hdx.citrix.com/hdx-monitor) still will say that IE9 is not supported. (even when it works..)