When using the Citrix XenDesktop Setup Wizard on your Provisioning Services server, you may encounter this error when creating new virtual desktops from a template.

Unable to create the desktop DESKTOPNAME.
Unable to clone the virtual machine for this desktop.
Exception thrown : SR_BACKEND_FAILURE_44
Unable to provision a vDisk for the desktop.

This error often appears when there is no longer sufficient space on your Storage Repository to clone the VM Template. To resolve this, either remove the storage requirement from your template (if it’s not needed) or add additional space to the desired storage repository.

While XenServer 5.5 has a pretty decent GUI, there are still a few tasks that we have to use the command line for. Resizing Storage Repositories would be one of those tasks. In my environment, we use a Fibre Channel SR in our main XenServer resource pool, so I can vouch that these steps will work for that type of environment.

Before starting with these steps, make sure you have actually resized the LUN using whatever software provided by your SAN vendor. This process is simply getting XenServer to recognize the change.

1. Open the console of your XenServer Resource Pool Master.
2. Run xe sr-list
3. Find the UUID associated with the name of the SR you wish to resize. Make note of the UUID (I just copy it).
4. Next, find the device name. To do this, run pvscan | grep <uuid> - The device name will look like /dev/sdb – Make note of this as well.
5. Run pvresize <devname>
6. Run xe sr-scan <uuid>
7. Verify that the SR shows the new size in XenCenter.

It’s a simple process, though I forget how to do it every time. Now it’s written down for all to see!

As an administrator of both XenDesktop and XenApp environments, I’m absolutely sick of multiple consoles. I’ve finally managed to easily integrate XenDesktop and XenApp administration into a single console (AMC). Unfortunately, we’re unable to integrate the “Presentation Server Console” that is still used for manging policies.

While alternative methods may exist, I know the following steps will work.

1. On your XenDesktop 3.0 Media, run autorun.exe
2. Select Install Optional Components.
3. Install Management Consoles.
4. Install XDE300AMC004 (Download here).
5. Open the Access Management Console, you should see Desktop Delivery Controller in the left pane. If you do, you may continue.
6. On your XenApp Media (I’m using 4.5 media) navigate to Administration\Access Management Console\Setup\
7. Run ASC_PresentationServer.msi
8. After following the prompts, you should now have Presentation Server as an option in the left tree below Desktop Delivery Controller.

If you also want other snap-ins you can find them on your media under Administration\Access Management Console\Setup\. There are snap-ins for Web Interface, etc. as well.

Citrix has released a new version of the Virtual Desktop Agent for XenDesktop 3.0 (Not Feature Pack 1). In this new version, the file copy process between target and endpoint device has been improved. Time last Modified and Accessed will be properly updated when copying between devices. Also, mapped network drives on the endpoint device will now be properly mapped on the target device (A fix welcome by all).

For those who use Registry-based Desktop Delivery Controller Discovery on their target devices, registration should now complete properly and consistently.

Other fixes and the download can be found on the Citrix Knowledge Center, here.

Citrix Virtual Desktop Agent, Version 3.0.3075 (XDE300VDA004), CTX122134

When configuring your vDisks in Citrix Provisioning Server, you’re able to define which mode you would like your vDisk to be in. While many people know the basic differences, not everyone understands how to leverage them in their environment.

Private Mode

Private mode puts the vDisk into a volatile state where a target device can make permanent changes to the vDisk. Changes are not stored in a write cache file, they are changed immediately. When a target device connects to the vDisk, it gains exclusivity and no other device may connect to that vDisk.

This mode is best used when a single user needs application install capabilities which need to persist through reboots and updates. This is idea for streaming an operating system to a physical target device in order to move their hard disk to the datacenter for data consolidation. This mode is also used to make changes to a vDisk that is otherwise in Standard or Difference mode.

Standard Mode

Standard Mode is the bread and butter of Provisioning Server. It allows for changes made by the user, but they do no persist through reboots. They are stored in a write cache file and cleared upon graceful shutdown. The location of the write cache file is defined on a per vDisk basis and can be placed on the Provisioning Server Disks, in the target device’s RAM or local disk – with options for encryption and maximum size (when placed in RAM).

Standard Mode is usually used when leveraging XenDesktop so that users receive a standardized desktop which they can make temporary changes to without affecting the experience of other users. This can also be used when streaming an OS to a desktop to turn it into a pseudo thin client.

Difference Mode

Difference Mode is an interesting mode. It’s not often used, as far as I know. It’s essentially a hybrid standard-private vDisk. The base of the image is standard, but the user can make changes which are stored in a write cache file just like standard, but they persist through reboots. When the target device is booted, it boots to the standard image and then the write cache file is applied like a delta file. The main issue with this is when a change is made to the standard base, it destroys the delta write cache files.

Possible uses include tech labs and classes where a standard environment must exist for all users, but users need to make changes as part of the curriculum. The instructor can then remove the write cache files and “reset” the environment. A serious time saver in that case.

Conclusion

I only listed a few short use cases in this post. I’m really curious how everyone leverages these modes in their environment – please share!

Citrix Provisioning Services (PVS) is a great tool that is what our local Citrix Sales Engineer calls “the Secret Sauce” behind XenDesktop. For those who are new around these parts, PVS is software that allows us to stream an Operating System to a PC, physical or virtual, ESX or Hyper-V or XenServer – anything that can PXE boot pretty much (including Thin Clients!).

Once you’ve made the plunge and start deploying or planning your PVS infrastructure, High Availability and Redundancy is going to be a top concern. Here are a few guidelines to help you plan. Let’s assume we have a single farm, single site, with 2 Provisioning Servers.

Shared storage is your friend with Provisioning Server HA.

vDisk Storage

Ideally, this should be on shared storage. Server should be able to communicate with the SAN/NAS/etc at high speed. Fibre Channel works great here (4Gbps). Alternatively, you can have identical vDisks available via the same drive letter on each of the servers.

Write Cache Location & Storage

The two types of write cache locations that are in play: Stored on PVS Disk and Stored on Client HD (ignore Encryption, it’s not really relevant here). Storing the Write Cache on the Client’s Hard Drive is fastest, and is what I would recommend, as the file is available independent of the provisioning server. Alternatively, you can store the write cache on shared storage that can be accessed by each server so that the target device can continue to function.

TFTP Server

This is the tricky part. The best way to handle this is with hardware load balancers, but for the sake of this article, I’ll give you some “rigging” solutions. You can run the TFTP service on both servers and use “round-robin” settings on your DHCP server. Also, you can use the Bootable Image tool included with PVS to create a Bootable CD that contains the bootstrap file (the same one that it can get via PXE). If you have a NetScaler in your environment, you can use it to ensure HA of TFTP (Thanks Bart Groot Zevert). I’m sure there are other ways as well, feel free to comment with suggestions.

Conclusion

As mentioned before, these are just some guidelines and tips to get you started on the right path. I’ll be more than happy to assist should you need assistance.

Only 5 days after Citrix released XDE310VDA003, VDA004 was released. It fixes a total of 28 issues, many of which have plagued XenDesktop users. This recent trend of hot fixing is comforting and worrysome – so many issues with XenDesktop, but on the other hand, Citrix is fixing them relatively quickly.

Some fix examples:

Disconnecting from an RDP session can cause a Virtual Desktop Agent running on Windows XP to become unresponsive or to restart.

After installing Version 3.1 (Build 3231) of the virtual desktop agent on Windows XP, the Citrix Audio Service fails to start.

After installing Version 3.1 (Build 3231) of the virtual desktop agent, logon times might take in excess of one minute.

Attempts to register Virtual Desktop Agents in large Active Directory domains might time out. The issue occurs because Active Directory searches are conducted on FQDNs, which are not indexed. With this fix, searches are conducted using NameProperty to find the matching FQDNs.

Citrix Virtual Desktop Agent, Version 3.1.3242 (XDE310VDA004) can be found at the following location:

http://support.citrix.com/article/CTX122445

Installation consists of running a .MSI and upgrading the previous version of the Virtual Desktop Agent.

On Saturday Citrix released a new version of the Citrix Virtual Desktop Agent (VDA) for XenDesktop 3.0 Feature Pack 1. It upgrades version 3.1.3236 to 3.1.3241 via XDE310VDA003.

All in all there are 22 fixes in this release; 7 fixes for the previous hotfix, and 15 new fixes. Usually I would recommend waiting a while before applying a hotfix unless you experience one of the issues addressed, but most XenDesktop environments will suffer from at least one of these.

• Virtual Desktop Agents fail to register with Desktop Delivery Controllers located in separate Active Directory farms. This fix extends Active Directory searches from farms to forests.
• After configuring XenDesktop according to Knowledge Center Article CTX118976 (Configuring XenDesktop to Function Properly Without an Organizational Unit in Active Directory), the virtual desktop agent fails to register.
• After installing Version 3.1 (Build 3231) of the virtual desktop agent, logon times might take in excess of one minute.

You can download the hotfix and see the full list of fixes here: http://support.citrix.com/article/CTX122136

While I’m sure many are still struggling to get XenDesktop working properly with a VMWare ESX hosting infrastructure and vSphere 4, Citrix is still hard at work pumping out fixes for it.

Yesterday, Citrix released a hotfix for Citrix Pool Management which updates it to 3.0.3068 using hotfix XDE300PM002.

The Citrix Pool manager can now reconnect to ESX after losing network connectivity or if Virtual Center restarts. It also fixes an issue with the previous hotfix where you could not import virtual machines through pool management if using vSphere 4.

Get the hotfix and read the release notes here: http://support.citrix.com/article/CTX122378

On Thursday, Citrix released a hotfix that resolved an issue where Virtual Machines would crash when migrated on Intel Nehalem processors. If you are using Intel Hardware with EPT support, you should install this hotfix.

You can download Hotfix XS55E002, CTX122348 at the link below.

http://support.citrix.com/article/CTX122348