Your network is killing your file copy performance

We’ve all been there before, rush hour traffic.

You know how it goes. You slowly increase speed to 5mph, then 10, then 15. Excitement is building because you are now going 20mph. Then, out of nowhere, you slam on the brakes and your speed immediately drops back to 0mph. We eventually start over again, 5, 10, 15mph before we slam our foot on the brakes again bringing us to a complete stop.

At this point it is OK to yell “SERENITY NOW!!!

Unfortunately, this is how packets are being sent across the LAN/WAN. This is how TCP functions via the AIMD (Additive Increments, Multiplicative Decrements) congestion control algorithm. TCP slowly increases transmission speed and then drastically falls back when a re-transmission is required due to a timeout, collision or packet loss.

This works fine on a LAN where bandwidth is high, packet loss is low and latency is low. But as latency and packet loss increases, as is common with a WAN environment, TCP is never able to get up to full speed. We are left with only partial utilization of our WAN link.

We see this all of the time when we try to copy a file. On a LAN, the speed of the file copy remains fairly constant, but on a WAN, the bandwidth utilization slowly increases before dropping back to 0, just like rush hour traffic.

Look at what Citrix did!

Adaptive Transport is able to overcome WAN latency and packet loss. It makes a simple task, like file copying, twice as fast as a traditional Windows 10 PC and 3 times as fast as a VMware Horizon desktop.

Adaptive Transport is an alternative to traditional TCP. And it is more than simply a switch to UDP. Adaptive Transport is a newly developed Citrix enlightened data transport optimized for WAN environments by overcoming high latency and packet loss resulting in faster file copying.


If the network supports the new transport, HDX will use it. If it does not, HDX falls back to TCP.

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.6 VDI Handbook
XenApp Best Practices
XenApp Videos


How Do I Create ICA Files

In older versions of XenApp (6.5 and earlier), we could create ICA files, which were essentially shortcuts, and email them to users or place them on a static web page.

With XenApp 7.x, ICA files are no longer available.  However, StoreFront provides an alternative with a little option called “Website Shortcuts”.

It is a feature I was unaware of until I needed it for a project.

After you setup your environment with StoreFront servers, Delivery controllers and VDI resources, you do the following:

  1. Launch the StoreFront console
  2. Select “Stores”
  3. Select your store
  4. Select “Manage Receiver for Websites”
  5. Select “Configure”
  6. Select “Website Shortcuts”

This should give you a screen like the following

websiteshortcutIf you plan to host the resource links from an internal web site, you want to add the website’s URL into the websites section. This will trust launches from that location only.  (note: A URL must be entered or the resource will not start)

Once the trusted websites are defined, selecting the “Get Shortcuts” link will send the admin to StoreFront, where each resource will contain a unique shortcut.  Those shortcuts can be added into the web site.


But what if you want to email the link to users?

Those same links can be used, but because they are not on the trusted list of websites, users will receive a warning message they must acknowledge.


This prompt can be disabled by going to “Advanced Settings” and deselecting “Prompt for untrusted shortcuts”.  (Note: A URL must still be added to the list of websites or else the resource will not launch.  Any URL can be used).

trustconfigAdditional options:

  1. Pass through authentication: If users must use their domain credentials to launch the resource, it might be worthwhile to setup pass through authentication so the users are not subjected to authentication challenges.
  2. Unauthenticated users: If the application incorporates its own authentication, it might be worthwhile to enable unauthenticated user access to the resource.

Daniel (Follow on Twitter @djfeller)
Citrix XenApp and XenDesktop 7.6 LTSR Handbook
XenApp Best Practices
XenApp Videos

A better application layering solution with UniDesk

UniDesk is now part of Citrix!

Are you wondering why?

I could try to bury you with a list of features, but I want to focus on one fundamental difference that I think explains why.

Let’s first look at the promise of application layering.

Traditionally, administrators would install an application into an image.  The same application might be installed across multiple images for different departments.  When the application requires an update, the administrator is forced to update the application multiple times, once for each image that contains the application.

Application layering tries to simplify this approach by creating a layer for each application.  Multiple applications layers are attached to a virtual machine, resulting in a complete desktop for the user.

I said “Application layering tries“, because there is a major limitation with many application layering technologies.

Most application layering solutions simply attaches each application layer’s virtual disk to the operating system image disk at startup or at logon.  Those virtual disks are seamlessly integrated so the user only sees a single drive within Windows Explorer.  However, as the number of attached virtual disks increases, the system performance decreases. This performance degradation results in a slow performing desktop and a bad user experience.

To combat this well-known issue, many application layering solutions recommend that the number of layers assigned to a single VM should be limited to 8-10 layers.  In order to achieve this, while still providing the users with the correct applications, we have to create application layers with multiple applications.


Do you see the problem with this recommendation?

The promise of application layering is that application management is simplified because each application is deployed within a single layer, meaning we only have to manage an application once.  But because of the limitations with application layering technologies, we have to create layers with multiple applications, resulting in a single application being part of multiple layers. This means we now have to managing the same application multiple times.

How is this  approach any better than managing our images like we did traditionally, with the operating system and applications installed natively?

This is one area with UniDesk is unique.

With UniDesk, each application layer contains one application, but UniDesk does not incur a performance hit like other application layering solutions.  UniDesk overcomes the application layering performance hit by merging all assigned layers into a single, complete image that gets deployed to users.

This might sound minor, but it is huge.  Instead of deploying a blank OS image and attaching application layers at startup or at logon, UniDesk creates an image where the OS and application layers are already merged. When you look at the details of the VM, you only see a single virtual disk.

This “small” difference overcomes the performance hit experienced by other layering technologies.

You might be asking if unidesk allows layers to be added elastically at logon. Yes it can.  But you wouldn’t do it for every app. Why would you?  There is a time and a place for both options (more on that in future blogs).