What’s new in App-V Scheduler 2.3

It’s exactly a year ago that App-V Scheduler 2.0 was released in its current form and today we are very excited to announce the latest release of App-V Scheduler, version 2.3.
If you are reading about App-V Scheduler for the first time: App-V Scheduler is a purpose build App-V 5 deployment tool specially designed for virtual workloads like RDS\XenApp and VDI environments. The power of App-V Scheduler is the amount of fine grained control, instant package delivery and real-time visibility over your App-V 5 deployment. To name some advantages of App-V Scheduler :

  • Support for both persistent and non-persistent environments (Citrix PVS\MCS integration)
  • Advanced cache management (Cleanup, auto balance cache with source and selectively pre-cache packages)
  • Improve application launch time with virtual registry pre-staging and application pre-launch feature
  • Packages and Connection groups available at machine startup and ongoing through deploy cycle
  • Complete application life cycle management; from instantly deploying packages to draining and retire applications without touching your image
  • Real-Time (portable) remote management console (inventory, manage and central configuration)
  • No App-V full infra components needed (dramatically simplify your deployment)

In this blog post we will walk through the most important new features in App-V Scheduler 2.3, to read more about existing features click here.

What’s new in the App-V Scheduler agent
Let’s start with the new managed publishing mode which can be configured in the App-V Scheduler agent configuration window :

Publishing mode

When managed mode is enabled you can use App-V Scheduler Central View to create publishing tasks (see screenshots later on in this post). Both global and user publishing tasks are supported. Global publishing tasks are executed when the deploy cycle runs and user publishing tasks are executed when a user logs in to the machine, this is done directly by the App-V Scheduler agent service so no need to execute anything in the user context. Optionally user publishing tasks can also be refreshed when the deploy cycle runs allowing you to publish new applications while users are logged on to the machine. Multi domain environments are supported and there is also an option to enable nested group support.

In unmanaged mode, App-V Scheduler will publish all packages globally by default so you can use User Environment Management (UEM) tools for example to control access to the applications.

A new feature called pre-stage virtual registry is now added to the deploy cycle :

Pre-stage virtual registry

This option can invoke the staging of the virtual registry right after the package is added, normally this is done when the application is launched by the user for the first time causing launch delays and unnecessary CPU utilization. App-V Scheduler already logs the amount of time it took to add and publish a package and this is now also done for the registry pre-stage feature:

Pre-stage log

What’s new in App-V Scheduler Central View
Packages and connection groups are now displayed in the same overview making it easier to navigate and manage them. The per machine options are now all displayed in the group view :

Central View console

The Central View console is now multi-threaded, this means if you inventory multiple machines at the same time or remove packages on multiple machines at the same time this will go much quicker. All tasks and their status is shown in the background tasks window :

Background tasks

The package options window is now extended with the new publishing task options (used when App-V Scheduler agent is running in managed mode). You can create new or show existing publishing tasks of the selected package directly from here :

Package Options

When you create a new publishing task you can select the publishing type :

Publishing Type

User groups can easily be selected with the active directory object picker :

Object Picker

You can also show and manage all publishing tasks at once when clicking on the Show Publishing Tasks button in the Central View main window :

Show Publishing tasks

The create new connection group option is extended with the latest App-V 5 SP3 enhancements like the any version wildcard and possibility to set a package as optional :

SP3 Connection Group

App-V Scheduler 2.3 is now available on the App-V Scheduler website.
Thanks for reading! If you have any questions do not hesitate to contact us.


Extended App-V 5 integration in RES Workspace Manager 2014 SR2, how does it work?

With the release of Workspace Manager 2014 SR2 (WM from now on), RES has extended the App-V 5 integration making it possible to automatically Add and Publish a package inside the user context. WM does this with evaluated permissions since the user doesn’t have the permissions to add App-V 5 package itself, the add and publish is executed when the user clicks on the application for the first time making it a Just in Time (JIT) deployment method. I have been involved in the pre-stage of this feature and would like to discuss how it works and how it differentiates from App-V Scheduler.

How does it work?
The concept is pretty simple, there are a few options added in the console after you select the .appv file :

  • Package delivery mode
  • Always use the latest version of the package

Package delivery mode allows you to select 3 available options : None, Minimal and Full (both user publishing and global publishing can be selected).
Below you will find a screenshot of how the package delivery option looks like :

Package Delivery Mode Small

When you select None, WM will not add and publish the package and you can use another delivery method like App-V Scheduler or the App-V native infrastructure for example to take care of the deployment. This option still makes use of the App-V 5 integration options in WM like the version variable (to detect the latest package version) and inject\capture user settings.

When you select Minimal, WM will add and publish the App-V package when the user clicks on the application for the first time and will show the following message to the user  :

Prepared Message

WM will add the package without using the mount option, so the package will be streamed just like how it’s configured during sequencing.
After the package is added and published the following message is displayed :

Finished Message

After the user clicks yes the application is launched, depending on the streaming settings of the package you may see the App-V progress bar notifying the application is getting streamed :

When you select Full, the exact same process happens as with the minimal option, but the difference is the package gets 100% loaded (mounted in the background) when the application is launched.

The Always use the latest version of the package option will instruct WM to scan the .appv files in the folder of the package (and up to 2 subfolders below in the package folder), if WM finds a newer version of the package it will try to deploy it and will show the following message to the user :

Update Message

This update process also happens in the user context when the user clicks on the application.

In my opinion global publishing makes more sense in combination with UEM tools, because then you can manage the application the same way as they where installed natively (access and control etc) and you don’t have to publish the package for every user making it faster and less entries in the user registry.

I don’t know any UEM products that has such deep integration with App-V 5 as RES Workspace Manager, RES was one of the first to integrate with App-V 5 and with the extended integration in SR2 there is now also a very easy way to (optionally) add and publish a package. But one can ask itself if the user context is the right level to deploy the packages for their environment as it can take a while for the application to become available and it can cause numerous messages to your users that just want to launch the application as quickly as possible. Also it can be difficult to make use of new extension points in App-V 5 (like shell extensions and browser plugins) because the package isn’t deployed initially before it’s started for the first time.

How does this feature compare with App-V Scheduler
Because WM uses a just in time deploy method that runs in the user context and App-V Scheduler deploys directly when the machine boots and based on a configurable timer or centrally controlled by App-V Scheduler Central View they cannot be really compared with each other. Also the WM App-V 5 deployment option is only available in the silver\gold editions of Workspace Manager where App-V Scheduler is available in a free community edition and can also be used with other UEM tools or even without UEM tools as well. App-V Scheduler also addresses the following challenges which are out of the scope of the RES WM deployment option :

  • Cache management for non-persistent use cases (PVS\MCS)
  • Cache management for persistent use cases (automatic clean-up of older package versions to control cache size and remedation of applications)
  • Instant application access by adding and selectively mounting packages at machine start-up (to append to non-persistent images for example)
  • Support for connection groups
  • Support for deployment configuration files
  • Real-time central management of App-V 5 packages, connection groups and virtual processes on multiple machines
  • And more… Click here to read more about the App-V Scheduler features

Just like App-V Scheduler, this new WM feature reduces complexity (less scripting etc) and more granular control compared to other deployment options, but depending on your scenario keep above points in mind when deploying and managing App-V 5 applications.

What’s new in App-V Scheduler 2.2

About App-V Scheduler
In short: the vision of App-V Scheduler is to reduce complexity and give you visibility and control over your App-V 5 deployment. If you want to learn more about the history of App-V Scheduler, please read more about the previous releases here and here.

What’s new in App-V Scheduler 2.2
Today we are excited to announce the latest version of App-V Scheduler which adds a lot of new features and improvements, in this post we will walk through the new features in version 2.2.
Lets start with the updated service configuration window:

Configuration Window

As you can see the configuration is now grouped which makes it much more transparent and easier to understand how the service works. The configuration is split in 2 main events:

Machine boot event
Here you can configure what should happen when the machine (re)boots, for example if the App-V cache should be cleared to always start with a fresh cache or if App-V Scheduler should detect the image state to see if the image is in read-only or read\write mode. The deploy cycle will always be triggered directly when the machine boots to make sure all packages are present when the users log in to the system. The application pre-launch functionality allows you to start selected (virtual) applications to improve the initial launch time of applications for the first users logging in to the system.

Deploy cycle event
One of the main tasks of the deploy cycle is to handle the deployment of new packages and connection groups by comparing which ones are already present in the cache with the ones on the source share. The deploy cycle can be triggered in three ways:

Lets summarize the new features that are now part of the deploy cycle:

Exclude configured directories on the source share
You can now select certain directories from the content share which should be excluded by the deploy cycle, for example this allows you to archive your old package versions in a directory called archive. But this option is also very useful when you use multiple machine groups looking at the same content share. For example they can share the same folders with common packages and you can configure Machine group A to exclude Folder B and configure Machine group B to exclude Folder A. This allows you to create a very flexible App-V deployment structure. You can configure excluded directories in the general settings of App-V Scheduler (see the above service configuration screenshot).

Timing information
An important part of your App-V 5 deployment is a good understanding on how much time it takes to deploy packages so you can plan accordingly. For example if you use a non-persistent image technology like Citrix MCS\PVS and want to load all packages when the machine boots in read-only mode, it is important to know how much time this process takes. App-V Scheduler 2.2 will exactly tell you how long the deploy cycle took to finish, but will now also show you the timing information per package. For example you can see how long it took to deploy a package:

Deployed Package TimeAnd if you configured the package to mount (pre-cache) inside the cache, it will also show you the time this process took per package:

Mount Package Timing

Besides timing information, App-V Scheduler logs every action in it’s own event log source in a very readable manner, this will not only make troubleshooting easy but also gives you a good understanding on how your App-V deployment is operating.

Support for deployment configuration files
After you created (sequenced) the package and want to make certain modifications to the package configuration when it gets deployed, you can make use of the deployment configuration file. We recommend to use the ACE utility from Virtual Engine which makes it very easy and transparent to modify the deployment configuration file. After you modified the file save it in the same folder as the package with the “Save as App-V Scheduler configuration file” option in ACE. This will save the file with the .appd extension and App-V Scheduler will process the configuration automatically for you when the package is added to the machine.

Remove packages and connection groups from the cache that are no longer on the source share
The deploy cycle can now automatically remove packages and connection groups from the App-V cache that are no longer on the source share. For example when you remove or archive older versions of a package, App-V Scheduler makes sure it also gets removed from the cache on the App-V client. This feature will make sure your cache is always in balance with the content on the source and is especially useful in persistent use cases where you don’t flush the whole cache when the machine boots but want to keep control of the cache size. This feature also allows you to drain a package :

Drain and exclude package option
Maybe this sounds familiar: You want to remove a package from the source share but the moment you try to move or remove the .appv file you receive the message that the action cannot be completed because the file is currently in use. There are different reasons why this happens, for example you use SCS mode where the App-V client on the machine keeps the appv file on the share open because it directly reads data from it. But this can also happen when you use the default stream option in App-V 5 where the package is streamed to the client on-demand. This can be very annoying when you want to remove or archive old packages but it won’t allow you. With this new option you can now select a package and simply select the drain and exclude package option. When this option is selected 2 things will happen when the deploy cycle runs:

  1. The deploy cycle will skip the package to prevent it from deploying again
  2. The “remove packages that are no longer on the source share” feature will believe the package is no longer on the share and remove it from all the machines in the group

Now that the package is drained you can easily archive or move the package to another location, all by using only one click.
This feature also allows integration with other products like AmberReef, which can automate the whole packaging, test and release workflow for you. For more information about this integration check out the better2gether video.

New features in the App-V Scheduler Central View console
If you don’t know App-V Scheduler Central View yet, it’s the center piece of your App-V Scheduler deployment. Central View is a lightweight management console which gives you real-time insight and control in your App-V 5 deployment. Central View doesn’t need a dedicated server and can be very easily deployed as App-V package along side the rest of your management tool set. Lets run down the new features in Central View:

It’s now possible to create and manage connection groups directly from Central View :


Deploying a connection group is very easy : Select 2 or more packages and click on new connection group then optionally change the priority and the name and click on save. It will now be saved automatically to your content share where the deploy cycle will pick it up and deploy it for you. Below a screenshot of the new connection group window :
New Connection GroupCentral View allows you to control all machines in a machine group at once or on individual machines by clicking on the icons in the machine header. It’s for example very easy to invoke a deploy cycle on all machines at once or only a selected machine. This is also the case for connection groups, you can view the deployed connection groups on all machines in a single view or only the connection groups on a selected machine:

Connection Group Overview

You can also select and remove connection groups directly from here.

The update connection groups option, allows you to update existing connection groups on the source share so you don’t need to manually edit or create new ones. It is especially useful if you update a package which is part of an existing connection group, the only thing you have to do is deploy the updated package, select it and click on the update groups button:

Update Connection Groups

Central View now has real-time filters to quickly see all packages that are in use or to easily search for a package, for example if you type the first letter of a package the view is filtered in real-time:

CentralView Filters

The package options have been moved from the App-V Scheduler GUI on the machine itself to the Central View console to give a more central configuration experience. Simply select a package and click on package options :

Package Options

Here you can configure if the package should be fully mounted inside the cache, or if you want to drain and exclude the package. Also you can select an application entry from the package to pre-launch to make sure the virtual environment is already loaded one time before your users log in to the system improving the user experience. It also gives you a quick overview of the package details and access to the command line hook switch which you can use as parameter for native applications to run inside the virtual environment of the package.

A few examples of validated App-V Scheduler deployments
The following examples can give you some insight into how App-V Scheduler can be configured. This configurations are validated to work, but they are only intended to give you an idea of the possibilities. They can be used as guide line but are not written down here to serve as best practice or recommended configuration.

Example of App-V Scheduler deployment in combination with non-persistent machines (like MCS\PVS)

  • Move the App-V Cache to a persistent drive (for example the same one as the write-cache)
  • Configure App-V Scheduler to detect the image state (don’t deploy packages when in read\write mode)
  • Configure App-V Scheduler to clean the cache after reboot (needed because drive is persistent)
  • Configure App-V Scheduler to remove packages that are no longer on source share (keep cache in balance during run-time and easily allows draining of packages)
  • Use SCS mode in combination with the mount specific packages option (mount packages that either perform better when fully cached or if you want them to be higher available) the combination gives you the best of both worlds
  • Set the deploy cycle timer to manual and use Central View to invoke the deploy cycle remotely. You can do this on a test machine first. After tests are performed and application functionality is verified invoke the deploy cycle on the production machines (by selecting the invoke deploy cycle on all machines in the group option)

Example of App-V Scheduler deployment in combination with persistent machines

  • Keep the App-V cache on the default location
  • Don’t clean the cache at machine reboot
  • Configure App-V Scheduler to remove packages that are no longer on source share (keep cache in balance with source)
  • Use SCS mode in combination with the mount specific packages option (mount packages that either perform better when fully cached or if you want them to be higher available) the combination gives you the best of both worlds
  • Set the deploy cycle timer to manual and use Central View to invoke the deploy cycle remotely. You can do this on a test machine first. After tests are performed and application functionality is verified invoke the deploy cycle on the production machines (by selecting the invoke deploy cycle on all machines in the group option)

For more information about supported App-V 5 cache combinations with App-V Scheduler, please read the Administrator guide which is part of the download.

What’s next for App-V Scheduler
New features are added frequently to App-V Scheduler and feature requests are always welcome!
For the next release we are also adding user publishing support in App-V Scheduler. The current versions of App-V Scheduler are based on global deployment, this means the package is published on a machine level. When you use global publishing you need to manage application access for example with GPO’s or UEM tools just like they where installed natively on the machine. User publishing is also often used to control application access by only publishing an application to a group of users, this is a good way to separate application access if you don’t use UEM tools for example. App-V Scheduler will also support user publishing in combination with global publishing so you can get the best of both worlds.

App-V Scheduler 2.2 is now available on the App-V Scheduler website.

App-V Scheduler now more powerful than ever

This blogpost will highlight the new features in App-V Scheduler 2.1 and the new App-V Scheduler Central View management console. App-V Scheduler 2.1 is an update of the previously released App-V Scheduler 2.0 version, if you are reading about App-V Scheduler for the first time I would recommend to start with the previous blogpost.

What’s new in App-V Scheduler 2.1
App-V Scheduler 2.1 contains improvements and new enterprise features, let’s talk about the new features first:

  • Application Pre-Launch
  • Mount selected packages
  • App-V Scheduler Central View management console

Application Pre-launch
Application Pre-Launch allows you to start selected virtual applications one time after the machine is (re)booted, this feature will improve application launch time for the first users logging in to the machine. Especially when used in combination with Shared Content Store mode and bigger packages this feature can optimize the user experience. Application Pre-Launch can be used for virtual applications and natively installed applications.

This is how it works :
You select the application which you want to Pre-Launch in the package details window in App-V Scheduler :

App-V Scheduler 2.1 Package Details Application Pre-Launch

App-V Scheduler will store this application in a XML file on the package source location. There is no need to configure this on every machine or inside your image. You can also directly edit the XML file if you like. When the machine boots the App-V Scheduler service will deploy all packages to your machine and after that read the XML file for applications to pre-launch. If there are applications found, App-V Scheduler will launch them all together and keep them open for 60 seconds. After that the applications are closed. When the first users log in to the machine and launch the application, it will open much quicker because application assets are already present in memory.

Mount selected packages
Besides the option to mount all packages, App-V Scheduler can also mount only selected packages. This means you can use Shared Content Store mode for all your packages but select specific packages which should be fully mounted inside the cache so they are always available or to reduce network load to the content share.

This mechanism works much in the same way as the application Pre-Launch feature, when you open the package details window you only have to select the “Mount this package” check box :

App-V Scheduler 2.1 Package Details Mount Selected package

After you select this option, the package will also be saved in the XML file on the package source location. So also no need to change this on multiple machines or inside the image. App-V Scheduler will mount the selected packages automatically the next time the machine starts.

Other improvements in App-V Scheduler 2.1

  • It’s now possible to set the deployment timer to manual, if you want to use Central View for example to initiate the deploy whenever you like on multiple machines at the same time
  • Improved clean cache mechanism
  • Scenario options removed, settings are now directly available in the configuration window to make the configuration more transparent
  • Option to use RES Workspace Manager variables, if you enable this option App-V Scheduler will use the version variable of RES Workspace Manager when generating the Command Line Hook switch for example. The version variable is used by Workspace Manager to detect the latest version of the package so you don’t have to change the version GUID after deploying a new package
  • The App-V Scheduler event log will now show how long it took to load all packages, this gives you insight in the machine boot time especially handy in non-persistent environments where all packages are loaded to the machine at start up

App-V Scheduler Central View real-time management console
Part of the Enterprise license is also a lightweight portable central management console called App-V Scheduler Central View. This console allows you to centrally manage packages on multiple machines. You can see which packages are currently deployed, compare machines and update packages by invoking a remote deploy process. You can remove packages on the fly or clean the whole cache remotely. Central View leverages Windows Remote Management (WinRM) so no need to open any exotic ports. Below you will find a print screen of the console :

App-V Scheduler Central View Not Maximized

You can change the layout to easily sort on package name or you can sort all in use packages for example. It’s possible to invoke a deploy new packages procedure on all the machines in the group or to individual machines by selecting the icon in the group view. You can also refresh individual machines from here to immediately reflect the changes. It’s also possible to view and control all running virtual processes remotely, this is handy if you want to understand virtual application usage or want to quickly see which process keeps the package in use.

For troubleshooting purposes Central View has the option to open the App-V Scheduler or App-V 5 Client event log directly on the remote machine.

Central View uses an Active Directory group to read machines from and for remote management it uses integrated windows authentication or you can specify a custom account if you want to delegate the console to accounts that doesn’t have the permissions to make remote management connections.
The inventory accounts password is stored encrypted and cannot be retrieved from the console. Below you will find an screenshot of the Central View settings dialog :

App-V Scheduler Central View Configuration Window

The Central View console can easily be sequenced and deployed in your environment as part of your management tool set, you don’t need a dedicated server for it. You can also use Central View without App-V Scheduler on the machine, when you use another deployment method for example, but it will add value when used in combination with each other.

What’s next for App-V Scheduler?
We are working on the following features for the next release of App-V Scheduler :

  • Fail over package source location, configure a backup source location which App-V Scheduler can use when the primary location isn’t available
  • Further improving App-V Scheduler Central View with new capabilities
  • Support for Deployment Config XML file and connection with the App-V Configuration Editor (ACE) from Virtual Engine
  • And more…

Big thanks for everybody providing feedback and supporting the App-V Scheduler project. Especially Kees Baggerman, Andrew Morgan and Nathan Sperry for providing valuable feedback in the last months.

Suggestions and feature requests are always welcome!

App-V Scheduler 2.1 is available on the App-V Scheduler website, you will also find the pricelist and the feature comparison there.

App-V Scheduler 2.0 Release

app-v-5-scheduler-logoApp-V Scheduler

You may have heard about the App-V 5 Scheduler project, if not you can read more on how everything started in this previous blogpost. In short the vision of App-V Scheduler is to reduce complexity and make the deployment and management of App-V 5 packages in RDS & Citrix environments easy. No need for complex PowerShell scripts with limited functionality and visibility, also no need for full infrastructure components like App-V Management and Publishing servers or System Center Configuration Manager.

App-V Schedulers goal is to deploy App-V 5 packages on a machine level and manage them the same way we do with natively installed applications and this is where user environment tools like RES Workspace Manager comes to play. The power of such tools is that we can control application access and configuration from one single console, without having to configure application access and settings on multiple levels and in multiple consoles. I will explain the powerful combination of App-V Scheduler and RES Workspace Manager later on in this blog post. First let’s have a look at the new App-V Scheduler 2.0 version.

App-V Scheduler Editions
To start with App-V Scheduler is now available in 2 editions : Community and Enterprise edition.

Community Edition
Community edition provides the same functionality as the previous 1.3 version, this means automatically deployment of packages and connection groups, multiple cache options, aware of single image management technology like MCS\PVS and with this new release the community edition also comes with the redesigned GUI :


As you can see you have a very clear view on which packages and which versions are deployed on the machine, the package size is displayed in a readable format and on the bottom left you can see the total size of all packages currently loaded. When you select a package you can remove it manually, or launch CMD\Regedit inside the virtual environment for troubleshooting purposes. You can also directly launch the application from here to test its functionality. There is an administrator guide attached to the download which goes further into technical details, be sure to read it before installing.

Enterprise Edition
Enterprise edition will add the following features on top of community edition :

Pending Tasks support
When an updated package is deployed while the previous version is in use, the App-V client will create a pending task. For global publishing this means the pending task will be processed when the machine reboots. This is not desirable when you want to deploy a new version during the day. App-V Scheduler detects pending tasks and will process the pending task automatically when the package is no longer in use. You only have to ask the user to close the application. All of the processing is automatically done by the App-V Scheduler service, no need to leave the GUI open, you will get an overview of pending tasks by clicking on the Pending Tasks button :


Virtual Process overview
Quickly get an overview of all virtual processes on a machine, also native processes started inside a virtual environment are shown here. You can see which user(s) are associated with the virtual process and the path where the executable is started from. You can also end virtual processes from here. Virtual process overview is very handy in combination with pending tasks, it allows you to easily see which users\processes keeps the package in use.


Package Details
Package details gives you a clear view on which extension points are registered for a given package. The output is filtered so you will only see the information that is applicable to the selected package. With the blink of an eye you can see which shortcuts, file type associations, services, ActiveX and other com objects are registered in a readable and understandable format. Also extension points like browser plugins and shell extensions are shown here. App-V 5 comes with a lot more extension points than its predecessor, its important to know how a package is integrated in the OS to understand the behaviour of the application. The auto generated commandline hook switch can be used as a parameter for native processes to launch them inside the virtual environment of the package, think of Excel addins etc. In the RES Workspace Manager part I will give you an example on how to configure this.


There is also a details button to zoom further into the extension point details like this :


Central management console
Part of Enterprise edition is also a lightweight (portable) central management console called Central View where you can centrally manage packages on multiple machines. For example you can see which packages are currently deployed and in use, you can also update packages by invoking a remote deploy process and view pending tasks remotely. The central management console will form a great combination together with App-V Scheduler but can also be used without it, for example if you decide to deploy packages in another way.


Support and software assurance
Part of Enterprise licensing is free support and upgrades to the latest versions for the first year, the subscription can be renewed on an annual basis for a fraction of the price. App-V Scheduler is being actively developed and new features are added frequently. Compatibility with future App-V 5 releases and service packs will also be assured.


App-V Scheduler in combination with RES Workspace Manager
After App-V Scheduler deployed a new package, we can configure the application in the RES Workspace Manager console by leveraging the App-V 5 integration. All we have to do is select the .appv file and the integration will take care of :

  1. Dynamically locate the package installation root (App-V Cache location, which can be configured directly in App-V Scheduler)
  2. Dynamically select the latest version of a package that is deployed, so you never have to worry about changing paths after a version upgrade
  3. Load application settings inside the virtual environment (think of registry values, files and folders, etc)

Below you will find a screenshot of the App-V 5 integration in RES Workspace Manager :


As you can see it’s really easy to integrate App-V 5 applications in RES Workspace Manager, but how can we integrate a natively installed application with a virtual application? We could use great new App-V 5 technics like run virtual or dynamic virtualization. But if we want to do this more selectively? let’s say an Excel addin for a group of users? This is where the command line hook switch comes in handy which App-V Scheduler automatically generates when you open up the package details. All you have to do is hit the copy to clipboard button and paste it in the parameters field of the native application :


Finally configure access to a select group of people and that’s it. You can open the virtual process overview to check if Excel runs virtualized.

Conclusion and availability
App-V 5 Scheduler, in combination with an User Environment Management tool like RES Workspace Manager, is a powerful and simple way to deliver packages to your machines without the need for a full App-V 5 infrastructure model or complex scripting. Just place the package on a share and App-V 5 Scheduler will do the rest for you.
Community edition already gives you a good starting point to simplify the App-V 5 deployment in your environment, Enterprise edition features will make the management of App-V 5 packages a breeze and there are more features to come.

How to get Enterprise Edition ?

Thank you! It would be great if you consider to upgrade to Enterprise edition, besides the additional features, this will also support the further development of App-V Scheduler.

App-V Scheduler 2.1 released!

Please visit the App-V Scheduler 2.1 release blog post for the availability and more information about the new version.

Finetuning a Citrix StoreFront deployment

Finetuning a Citrix StoreFront deploymentFinetune

In this short blogpost I gathered some fine tuning tips I came across with when migrating a Webinterface deployment to Storefront with Netscaler Gateway. The deployment had the following main goals :

  1. Access from Receiver for Web and all the Native Receiver versions (Windows, IOS, Android, etc)
  2. Security on the client side is important, access takes place from unmanaged and public devices
  3. Performance needs to be comparable with the Webinterface deployment
  4. Customized branding for each Netscaler VIP

In this blogpost I will cover the following :

  • Prevent users from saving passwords
  • Shorten the login token lifetime
  • Increase performance (page load times, etc)
  • Modified homepage for different VIPs on the Netscaler
  • Workspace Control in combination with XenApp published desktops

Prevent users from saving passwords
Saved passwords may give users easy access to the environment, but it decreases the security of the environment, especially on unmanaged and public devices where it’s unknown how the devices are used and by who. To turn password saving off :

For Receiver for Web :
This is done automatically by the login page from Netscaler by telling the browser not to use the autocomplete feature. Most browsers respect this setting but IE 11 ignores it, you can read more about this here. It is recommended to always use 2-Factor authentication for external access when possible. To expensive? Take a look at SMS2, it’s free and the RADIUS extension works pretty neat in combination with Netscaler Gateway.

For Native Receivers :
Open the Authenticate.aspx file (default location : C:\inetpub\wwwroot\Citrix\Authentication\Views\ExplicitForms) and comment the SaveCredentialsRequirement statement like this :

SaveCredentialsRequirementThis will prevent the save password option from showing in the Native Receivers.

Shorten the login token lifetime
When a user logs on through the Native Receiver, the credential wallet service of Storefront will keep your token alive for 20 hours by default. When a user closes his application or desktop but doesn’t logoff the Receiver, it’s possible that someone else can click on the icon to log back on within this time period. This is not really secure when users are sharing devices or leave them unattendant. Receiver for Web is somewhat resticter, by default the page will timeout after 20 minutes idle time.
If you only publish a desktop and your users doesn’t need to click on published application icons the whole day, you can make the life time as short as possible without affecting the user experience. In the following example I will change the token life time to 5 minutes for both Native Receiver and Receiver for Web.

For Receiver for Web :
Open the web.config file in the Receiver for Web site folder (default location : C:\inetpub\wwwroot\Citrix\yourwebstore) and search for the session state timeout.
The value is in minutes :


For Native Receivers :
Open the web.config file in the authentication folder (default location : C:\inetpub\wwwroot\Citrix\Authentication) and search the maxLifetime values till you found the correct one, see this example :


After making this changes, users have to authenticate again after 5 minutes idle time.

Increase performance (page load times, etc) 
After some tweaking the Storefront performance is good and acceptable, but it will not be as quick as Webinterface. I also think this isn’t possible because of the design differences. I changed 2 things to speed up Storefront : Enable socketpooling and disable signature verification (the latter will lower the security a bit).
On Marius Sandbu’s and Richard Egenas blog you can read more Storefront performance tips.

Modified homepage for different VIPs on the Netscaler
This deployment needed a customized branding for each Netscaler VIP, I will not go into detail how to configure this because there is already a very detailed article from Citrix here. It comes down to redirecting users based on the entered FQDN with Responder policies, while this works great the article doesn’t mention that it will break the access from the Native Receivers to the VIP where the responder policy is active. To prevent this change the responder policy expression to include :


When you create this exclusion, the Responder policy will not kick in when the User-Agent contains CitrixReceiver, allowing the Native Receivers to successfully connect.

Workspace Control for XenApp published desktops
When you publish a desktop through XenApp you will notice that Workspace Control isn’t working like expected in Storefront. This is because the desktop is shown on the Desktop tab and Workspace Control isn’t enabled there. Instead autolaunch is enabled which is also killing for single session control. If you want to use Workspace Control you need to treat the desktop as application by using the TreatAsApp keyword. You can read more about Workspace Control in combination with Storefront in great detail in a previous blog post : Deeper look into Workspace Control and it’s challenges.

I must say I like Storefront, it’s stable (talking about the latest versions of course), looks good and gives users an unified login experience, but I have some wishes left so in case someone from Citrix read this, here are my feature requests for Storefront :

  • More options in the GUI, manual editing the web.config files feels a little silly and can be error prone. If the goal is to keep the console simple, then I would suggest an option to switch to advanced view
  • More informative messages for the users, for example Webinterface shows when a Desktop is (re)starting and cleaner messages when applications are disabled etc
  • Redirect users to a specific Store (when using Native Receiver), now the user gets a popup to select a store but it will be nice to control this in a session policy or directly in Storefront

Please note that the information in this blog is provided as is without warranty of any kind.

IE11 ignores Autocomplete=Off setting used by Netscaler Gateway and put users at risk

IE-Red-smallSince Microsoft is pushing Internet Explorer 11 through Windows Update as an important update for Windows 7, a lot of users are starting to use it as their default browser. Also users on Windows 8.1 are already using Internet Explorer 11 by default.

Internet Explorer 11 brought some issues for customers using Netscaler Gateway, for example the login fields in combination with the Green Bubble theme weren’t displayed correctly and this prevented users from logging in correctly. Citrix released new maintenance releases for Netscaler Gateway which will fix this layout issues.

But there is more : Microsoft decided to ignore the Autocomplete=Off setting used by Netscaler Gateway (and a lot of other login pages), this setting tells the browser not to use the store password option and will protect the user from accidently saving their username and password on their machine (or worse a public machine!). Below a screenshot from the login.js file where you can find the autocomplete=off setting on the Netscaler :


Up till Internet Explorer 10 and every other major browser like Chrome and Firefox respect this setting and will not bother the user to store the credentials, but Microsoft decided to ignore this setting (by default!) in IE11 because they want to give this control back to the user, you can read more about it here and here. Below a screenshot of the message users get when logging in through IE11 on Netscaler Gateway :


I think it’s a wrong choice of Microsoft to ignore the autocomplete=off setting, but even more wrong to ignore it by default, because they forget that a lot of people don’t know how to use a password manager wisely and just click OK on every message they see without thinking about the risks. When users click on Yes, everyone with access to their computer can simple hit the first letter of their username and the rest is auto filled so it’s very easy to make abuse of this :


Of course users can always bypass the autocomplete=off setting by installing\enabling a password manager themselves (also in other browsers) but in this way, they are conscious what they are doing. This default setting will put a lot of users (the ones we all know and hit Yes on everything on their way) at risk, without they even know it.

Possible workarounds when using Internet Explorer 11 :

  • When machines are managed (through GPO or tools like Thinkiosk) disable Autocomplete in the browser completely or only for certain websites
  • Change the password field on the Netscaler Gateway from type Password to type Text, this will prevent autocomplete from kicking in but will lower the security when people are typing in their password
  • Don’t allow IE11 : Block the login page from showing (through EPA scan or some code in the index page) and notify the users to use another browser
  • Don’t use Receiver for Web \ Netscaler Gateway Portal and only use the native Citrix Receivers

Of course 2-way factor authentication is a life saver here, but the security is already lowered when username and passwords are already stored on the machine. People with bad intentions only need the phone or token as an extra step to get access from a machine with prefilled username and password.
Please let me know if you have other ways to work around this default behaviour of Internet Explorer 11.

App-V 5 Scheduler, an easy way to deploy App-V 5 applications to your machines


Please note : App-V Scheduler 2.0 has been released, read more about it here


I think it didn’t escape you but Citrix is leaving the application virtualization space, they announced that they will not further enhance and support their streaming technology on newer platforms (that is XenDesktop 7 and Windows 2012\8). A lot of customers are starting to look at App-V 5 as a replacement, but also new and customers currently on App-V 4.X are looking to benefit from the latest improvements in the App-V product. App-V 5 can be deployed and managed in the following 3 ways:

  • App-V 5 Full infrastructure (Management, Publishing and optional a report server)
  • System Center Configuration Manager (SSCM) integration
  • Standalone

The first 2 have their place and advantages, no doubt about that, but they also come with their prerequisites (like full SQL etc) and need to fit in the customers environment. Most customers I work with are using UEM (User Environment Management) tools and most of them from RES Software (Workspace manager). They want a simple method to deploy and upgrade their virtual applications and manage them with RES Workspace manager. They don’t want an extra management layer, that overlaps in functionality and adds complexity, that’s why I often used the streaming only method in App-V 4.x and with Citrix application streaming (while it had its limitations) it was even more simple : just place the profiled application on a share and import it in RES Workspace Manager, that’s it.

With this in mind I created App-V 5 Scheduler, which extends the standalone deployment method by allowing you to automatically deploy packages and connection groups on machine level with a configurable time interval. But it can do more, I will dig deeper in App-V 5 Scheduler in a sec, but first I want to note you on another great tool that’s build around the App-V 5 standalone method by well-known App-V guru Tim Mangan. This tool is called App-V Self Service and provides users with a self-service portal where they can select and deploy packages (without needing admin rights), App-V Self Service can also deploy packages automatically at user login based on AD group membership.
If you are looking for a solution to deploy packages to users and don’t want to implement the App-V 5 full infrastructure, I would highly recommend looking at this tool.

App-V 5 Scheduler takes a slightly different approach, where App-V Self Service uses deployment based on users and is triggered when a user logs in, App-V 5 Scheduler uses machine level deployment and therefore fits best in environments that uses UEM products like RES Workspace Manager to control and manage the applications and the users workspace.

App-V 5 Scheduler can also remove packages on machine start-up to keep the package installation root clean and in case you use Citrix Provisioning Server (PVS) or Machine Creation Services (MCS) it can detect when the image is in private mode so it will not deploy packages filling up your image accidently.
To keep it simple I made App-V 5 Scheduler scenario driven, it’s only necessary to select the scenario that fits your environment best. I will explain the scenarios later on but first a quick look at the base of App-V 5 Scheduler, App-V 5 Scheduler consists of 2 components : 

The App-V 5 Scheduler GUI

The GUI will allow you to see which packages and connection groups are currently deployed to the machine, it will also allow you as an admin to do some troubleshooting steps like opening CMD or Regedit inside the virtual application context (or bubble or sandbox, whatever you like to call it ;). The GUI also displays basic information about the App-V client configuration and will allow you to configure the App-V 5 Scheduler Service. Below is a screenshot of how the App-V 5 Scheduler GUI looks like:

App-V 5 Scheduler GUIThe App-V 5 Scheduler Service

The service will deploy new packages and connection groups which are added after the last system start-up based on a configurable time interval. Depending on the selected scenario the service can detect when the image is in read\write mode to prevent the deployment of packages. Below is a screenshot of the App-V 5 Scheduler Service configuration dialog :

App-V 5 Scheduler Service dialog

Scenario 1 : Non-Persistent image with shared content store mode enabled

Select this scenario if you use Citrix Provisioning Services (PVS) or Citrix Machine creation Service (MCS) for single image management and you want to leverage the Shared Content Store (SCS) functionality of App-V 5 to lower the storage needed for package content. This scenario will configure the service to do the following :

  • Remove packages and connection groups at machine start-up to keep the package root clean
  • Deploy packages and connection groups after machine start-up
  • Deploy only new packages and connection groups based on the configured time interval
  • Publish packages and connection groups globally on the machine
  • Don’t remove or deploy packages when the image is in private mode

In this scenario you can redirect the App-V package root location outside the image (write cache disk for example), but since you are leveraging the App-V Shared Content store mode, a minimal amount of storage will be used in the package root so you could decide to keep it in the primary location.

Scenario 2 : Non-Persistent image with shared content store mode disabled

Select this scenario if you use Citrix Provisioning Services (PVS) or Citrix Machine creation Service (MCS) for single image management and you want to deploy the packages in its full size to the App-V package root location. This scenario will configure the service to do the following :

  • Remove packages and connection groups at machine start-up to keep the package root clean
  • Deploy packages and connection groups after machine start-up
  • Deploy only new packages and connection groups based on the configured time interval
  • Publish the packages and connection groups globally on the machine
  • Pre-Cache (mount) the package inside the package root location
  • Don’t remove or deploy packages when the image is in private mode

In this scenario you can also redirect the App-V package root location to another location (outside the image for example), this is advisable if your write cache location is limited and you want to keep it small.

Scenario3 : Persistent image mode

This scenario is very similar to scenario 2 only it will not check if the image is in private mode or not, select this scenario if you have persistent machines where you want to deploy App-V 5 packages to.

This scenario will configure the service to do the following :

  • Remove packages and connection groups at machine start-up to keep the package root clean
  • Deploy packages and connection groups after machine start-up
  • Deploy only new packages and connection groups based on the configured timer interval
  • Publish the packages and connection groups globally on the machine
  • Pre-Cache (mount) the package inside the package root location

Which scenario is best depends on your environment, key factors are the size of your packages and the amount of storage you have available. Scenario 2 and 3 will give you the best overall performance because the applications are fully mounted to the machines lowering bandwidth consumption and eliminating network bottlenecks. That’s why I would recommend this scenarios when you use a shared platform (RDS\XenApp). Besides better performance it will also make the virtual application higher available since they don’t rely on the content share after being deployed. Since scenario 2 and 3 mounts the package there is no load time at all when users start the application.

Below you will find a high level UML diagram of the App-V 5 Scheduler Service :


Deploying connection groups with App-V 5 Scheduler

Connection groups are basically XML files filled with information of which packages that can connect to each other, Tim Mangan created a very useful tool to create connection groups called App-V DefconGroups. With this tool you can easily select packages that you want to connected to each other. You can save the output file (with the AppG extension) somewhere on the package source location and App-V 5 Scheduler will deploy it to the machine (globally) for you.


App-V 5 Scheduler Service logs its actions in the event viewer and will give you information about the packages that are removed or deployed and the status of the service. For troubleshooting purposes it’s the place to look at because all other operational events are logged there as well. Below is an example message in the event viewer when private mode is detected :



App-V 5 Scheduler, in combination with an User Environment Management tool like RES Workspace Manager, is a powerful and simple way to deliver packages to your machines without the need for a full App-V 5 infrastructure model. Just place the package on a share and App-V 5 Scheduler will do the rest for you. If you use the App-V 5 integration in RES Workspace Manager and you have imported the application once, it will look up the newest version of the package automatically. You only have to place the updated package on the share and after App-V 5 Scheduler deployed the new version to the machine it’s immediately available to your users, they only need to close and reopen the application to get the latest version. App-V 5 Scheduler GUI will give administrators an overview of the current deployed packages on the machine and allow them to open CMD or Regedit to perform basic troubleshooting steps inside a virtual application.

What’s coming

To complement App-V 5 Scheduler, I will also release a tool called App-V 5 Central View. This tool allows you to select an Active Directory group (with machine accounts) and it will give you an overview of the currently deployed applications on that machines. In combination with some basic management tasks, this tool will give a central point of view of which applications are deployed through your environment. App-V 5 Central View is in depended of App-V 5 Scheduler and can also be used without it, but will form a great combination together.


App-V Scheduler 2.0 has been released and has a lot more features and enhancements, click here to read more.

UDadmin GUI a free tool to manage XenDesktop User\Device Licenses

UDadmin_GUI_logoPlease note: This tool isn’t available anymore

Since the new licensing model for Citrix XenDesktop, which is based on named users and devices, I have customers asking questions like :

  • We are running out of licenses but how do we know which users or devices claimed them?
    XD Usage overview
  • We have a tight budget and don’t want to buy any more licenses then strictly necessary, how can we get better control and insight in the current usage?
  • What is the balance between User licenses and Device licenses?
  • We created some temporary accounts for testing purposes, how can we release them?

UDadmin commandline tool
Citrix provides a command line tool named UDadmin to control the license usage, it’s part of the Citrix Licensing server software and installed by default. You can find it in the LS directory of your license server installation directory. With this tool you can view and reclaim licenses, but it’s not really user friendly mainly because it runs in a cmd box and it requires the right parameters. To provide something easier to this customers I created a GUI around UDadmin :

UDadmin GUI
UDadmin GUI is a lightweight .NET application that visualizes the output of UDadmin, and provides an easy way to release single- or multiple licenses at once, just select them and hit release. I also added some additional features like exporting the current usage to PDF for reporting purposes. When you launch UDadmin GUI it determines the licensed feature for you, no configuration is required at all. Below is a screenshot of UDadmin GUI in action :
UDadminGUI The XenDesktop named license usage is updated every 15 minutes, in UDadmin GUI you can see when the next update schedule occurs (in blue). So after releasing licenses the changes are reflected when the next update schedule runs. If you don’t want to wait that long there is also an option in UDadmin GUI to restart the Citrix Licensing service to reflect the updated usage directly afterwards :
UDadminGUI_restart_ls Prerequisites
There are only 2 prerequisites

  • Microsoft .NET Framework 3.5
  • Citrix License Server installed (UDadmin GUI is tested with version 11.10 and 11.11, but every edition which supports the new licensing model should work)

In other words, you need to run UDadmin GUI on the same machine as where Citrix License Server is running, this is because Citrix doesn’t support running UDadmin remotely. UDadmin GUI works with XenDesktop Enterprise and Platinum edition, support for App edition will be included in a future version (very soon!).

Just like the UDadmin command line tool, UDadmin GUI needs administrative privileges to run properly. But don’t worry UDadmin GUI is UAC aware and will prompt you when necessary.

UDadmin GUI isn’t available and supported anymore at the moment. Sorry for the inconvenience.

Version history

= 1.0 =
– Initial version

= 1.1 =
– Multiple fixes and enhancements

= 1.2 =
– Added an option to restart the Citrix licensing service and refresh usage afterwards

= 1.3 =
– Added export to PDF functionality

= 1.4 =
– Changed the window layout so UDadmin GUI also looks good on lower screen resolutions
– Added support for multiple license files and SA dates

– Added support for mixed XenDesktop Editions (both Enterprise and Platinum on same license server), if UDadmin GUI detects multiple editions a Combobox is visible to switch between editions :
Edition selection
= 1.5 =
– Added support for XenDesktop VDI Edition
– Fixed an issue with releasing user\device licenses which contains whitespaces

= 1.6=
– Added support for XenApp Advanced Edition (named licensing model)
– This version can only release one license at a time to be compliant with Citrix licensing terms
– This version is portable, just place and run the executable on your Citrix license server

A graphical deep dive into XenDesktop 7

Make sure to also check this blogpost about a very handy tool named Remote Display Analyzer

A graphical deep dive into XenDesktop 7graphics


A while ago I wrote an article about Adaptive Display and how it can be fine tuned. Well Adaptive Display as we know it hasn’t seen the light for a very long time because a lot has been changed in XenDesktop 7. In this blog post I will describe this changes and dig deeper in the configurable options related to graphics in XenDesktop 7.

Adaptive Display First generation = Legacy Graphics mode

In a short time frame a lot have changed in the delivery of graphics, users are demanding more media content, higher frame rates and a fluid user experience. While Progressive display did a very good job for a long time, it required a lot of manual tuning to accommodate different use cases, because of this it was often misconfigured resulting in a degraded user experience. To overcome this problem Citrix developed the first generation of Adaptive Display, it was still based on settings around progressive display but it was now auto tuning according to the available bandwidth and the capabilities of the client device. The concept of this first generation was simple : use a different compression algorithm for moving images and still images and tune it on the fly.

Adaptive Display Second generation, the new standard in XenDesktop 7

Well this concept is pretty much the same in the second generation of Adaptive Display but it’s now based on different codecs, the SuperCodec as Citrix calls it can dynamically decide which compression is used for different parts of the screen. The most important codec that is used in the second generation of Adaptive Display is the H.264 deep compression codec which we also know from HDX 3D Pro, together with features like Desktop Composition Redirection it forms the base of Adaptive Display second generation, before I go on let’s summarize the most important new graphics settings in XenDesktop 7 :


Default setting


Legacy Graphics Mode Off Revert to Adaptive Display first generation
Target Frame rate 30 Sets the maximum frames send to the client (now up to 60 FPs can be configured!)
Visual Quality Medium Sets the level of compression for the new codecs, besides low, medium and high also build to lossless or always lossless can be selected
Desktop Composition   Redirection Enabled Render Windows Desktop Manager (WDM) generated graphics on the client
Desktop Composition   Redirection Quality Medium Sets the default level of compression for Desktop Composition Redirection

I think the above settings are the most important changes in XenDesktop 7 according to graphics, besides that there are a lot of windows media related policies added. There is nothing really arranged what’s current and what’s legacy so it’s easy to get lost if you don’t know where Citrix came from with Adaptive Display first generation and beyond. You can only see on what kind of OS it applies but that’s about it.

I tried every combination of the above policies and made an UML diagram of my findings, the diagram shows the descisions made from the moment the session is launched (click to enlarge) :

Graphics UML XD7

H.264 Deep Compression codec

Citrix was the first vendor to use H.264 compression for delivering graphics through their remote display protocol (ICA), it was targeted for a specific use case : 3D modelling and graphics designers. At the beginning the first version of this codec was only available when combined with Nvidia GPU cards that had enough Cuda cores, as the codec was designed to leverage the Cuda cores for compression and encoding.

Later the codec have evolved and Citrix made it also possible to encode completely in CPU. The new version, called the Deep Compression V2 codec, uses even less bandwidth then it’s predecessor and since it’s CPU based it can be used for a lot more use cases. There is one downside though, since it’s CPU based (default setting) the load on the host side increases and can affect the scalability of the total solution, when CPU resources are limited or scalability is a concern in your environment you have the following options in XenDesktop 7 (please note that it’s about finding the right mix between server scalability, bandwidth usage and user experience. What’s best for your environment depends on the use case and of course the amount of $$$ you can spend) :

Option 1 : Leverage the new Desktop Composition Redirection feature to offload the host CPU

Citrix extended the aero redirection feature (known from XD 5) and made it possible to remote Desktop Window Manager (DWM) DirectX commands to the client to be rendered there. This also means that graphics generated from application like Internet Explorer, Office 2010 and other modern applications are offloaded to the client. You will also notice when installing the XenDesktop 7 VDA on Windows 7 that the Aero theme is enabled by default, even when you disable Desktop Composition Redirection the Aero theme can still be used completely rendered on the new WDDM driver on the host side. The quality of Desktop Composition Redirection can be configured in the following policy :


While this feature is awesome, since it leverages the clients capabilities and thus lowering the resources needed on the host side, there are some attention points when using Desktop Composition Redirection:

–          On the host side you need a Desktop OS (Windows 7 or Windows 8)
–          On the client side you need a compatible Windows client with a moderate GPU
–          Doesn’t work in legacy graphics mode (Adaptive Display first generation)
–          Increased bandwidth when using server rendered video

Desktop Composition redirection together with the new compression codecs forms the base of Adaptive Display second generation. It’s a combination that’s default enabled when connecting from a windows Client. If you use this combination you have to keep them both in mind when fine tuning the user experience. For example you configure the visual quality to always lossless to prevent lossy data send to the client (for medical purposes for example).  You will still see lossy artefacts like the below example in Wordpad.

Desktop Composition Redirection wordpad example

To get a really lossless experience you have to either disable Desktop Composition Redirection or set the graphics quality of Desktop Composition also to lossless, increased bandwidth consumption needs to be taken into account of course.

Option 2 : Turn on the legacy graphics mode policy

When you use the default graphics settings in XenDesktop 7 and you open HDX Monitor, you will see under Graphics – Thinwire that Adaptive Display is disabled (see below screenshot) and that thinwire redirection is disabled by a policy. This means that you are leveraging the new codecs and not using Adaptive Display first generation.Adaptive_Display_OFF

When you look at Graphics – Thinwire Advanced you will notice that the Legacy Graphics mode is turned off with the Legacy Graphics mode policy (see below screenshot).

ThinWire_Advanced__HDX_Monitor_PolicyOk so this is the default, now when user density and scalability is more important than the mobile user experience it’s possible to revert back to Adaptive Display first generation by enabling the Legacy graphics mode policy. Please note that you also have to switch off Desktop composition redirection to make this work. When you have done that you can verify that Adaptive Display first generation is back in business again through HDX monitor :

Adaptive_Display_ON_LegacyYou will also notice that, when using Windows 7, Aero functionality is switched off when using legacy mode:


For further fine tuning the legacy graphics mode in XenDesktop 7, read my previous blogpost on Adaptive Display.

Option 3 : Use Graphics Processing Units (GPU)

Instead of rendering and encoding everything in CPU, you can also leverage a GPU to do the heavy lifting, after all this is where a GPU is built for. Moving the graphical load away from the CPU, means you have more resources available for your applications etc making the solution more scalable. In XenDesktop 7 you have the following options :

–          Leverage the GPU directly (Either physically or through the Hypervisor (GPU passthrough))
–          Leverage the GPU indirectly through GPU virtualization (Available by using Nvidia GRID\VGX)

Leveraging the GPU directly is available for a while now but since it’s a one-to-one solution (except when using hosted shared desktops, where you can share a GPU with multiple sessions on the same server OS) it’s not very scalable and mostly limited to be used for heavy graphical designers and alike use cases. VGX on the other hand will extend the use cases by delivering a one-to-many solution. Personally I think this is the future because it provides the best combination of scalability, bandwidth and user experience. Let’s dig a bit deeper in VGX.

When we open HDX monitor in a XenDesktop 7 session you will see the below message when VGX is not available :


Screen scraping vs Direct frame buffer access

When you have a GPU available graphics are first rendered on the GPU before they are (deeply) compressed in CPU and then send down the client, so first the output of the GPU (which would normally be send to the monitor attached to it) needs to be captured and after that compressed and tuned, this process is called screen scraping.

Screen scraping, while better than doing everything in CPU, consumes additional resources and this is where Nvidia VGX (formerly known as Monterey and now called NVIDIA GRID technology) comes to play, they provide an API which allows remote display protocols to access the frame buffer (the dedicated H.264 encoding engine of the GRID card) directly. The below picture shows how the GRID technology is integrated on the Hypervisor level :

VGX (Source Nvidia)

NVIDIA User Selectable Machines (USM) (Now called VGPU Profiles)

USM is the way Nvidia licenses the GRID technology, you can also translate the USM to use cases. There are 3 configurable USM’s :

Standard USM (bundled with the NVIDIA GRID card enabling a true PC experience for up to 100 task workers)
NVS USM (mission-critical professionals who use a variety of productivity and dedicated business applications)
Quadro USM (designers, artists, and scientists that require interactive 3D graphics and full compatibility)

So when you want to leverage the GRID virtualization technology you can do this for about 100 “normal” task users on a single GRID card (this can be less or more depending on the type of card and type of users), in this way you can already build a high scalable solution for general use cases. For more heavy graphical demands you need NVS USM or Quadro USM and this will cost additional licenses, good thing is you can mix and match the USM’s on a single GRID card. Of course the limits of the GRID card needs to be taken in to account. For more information about Nvidia GRID and the USM use cases click here.
XenServer will be the first hypervisor supporting GRID GPU virtualization, at this time of writing it’s not yet available but you can already order servers with GRID cards and leverage the onboard kepler GPU’s by using traditional GPU passthrough technology.

** Update **
1 October 2013, Citrix and NVIDIA released the GRID VGPU (Tech Preview) and made some changes in names and numbers :

– USM is now called VGPU Profiles, where K100 profile being the lowest which supports a maximum of 32 VGPU’s per board (K1 Card) and K260Q being the highest, which supports 4 Power Users (designers) on a K2 Card.
– In the following table you will find the maximum VPGU per card.


– Cannot find anything on licensing, it looks like the above hardware limits are the only limitation in the tech preview.


In this blogpost I described the new graphics options and choices you have in XenDesktop 7, remember that you don’t have to configure anything to get an awesome experience out of the box. The CPU based deep compression codec is really a giant leap forward compared to the first generation of Adaptive Display especially when it comes down to mobile user experience and WAN use cases. As more Citrix Receivers supports the new codecs it’s really a fluid experience across a broad range of devices. But keep in mind that you need additional resources on your host side compared to the “legacy display mode”.

Personally I had the best experience with the visual quaility set to Build to Lossless and disabling the desktop composition redirection feature, of course this depends on the use case, what I primary tested was server rendered video (youtube) and the look and feel of the desktop over a high speed WAN connection. What also amazed me was the look and feel of Windows 8 on the IPAD with receiver 5.8, they really made a big step forward making it a native mobile experience and playing video content really performed very well using the new codecs.

Can we safely say that Adaptive Display first generation and progressive display become absolete?
Yes I think so, but for now there is still a valid use case : for example, when you want to get high density numbers and you have primarily LAN users Adaptive Display first generation still gives you the most scalable solution, but as CPU’s become faster and when GPU’s with GRID technology become more mainstream (also for general use cases), I think we can say goodbye to the good old progressive display after all those years.

Please note that the information in this blog is provided as is without warranty of any kind, it is a mix of own research and information from the following sources :

Edocs (Optimize graphics and multimedia delivery in XD7)
Edocs (GPU acceleration for Windows Desktop OS)
– Blogs from Derek Thorslund (reinventing HDXHDX leaps ahead GPU sharing and Optimizations for W8\W2012)
– Nvidia (GRID Technology, GPU Virtualization)