Remote Display Analyzer for RDP

rdp-icon

Remote Display Analyzer for RDP \ RemoteFX

If you are reading about Remote Display Analyzer (RDA) for the first time, RDA is a real-time monitoring tool which helps you:

  • Better understand remote display protocol behaviour
  • Troubleshoot remote display issues
  • Analyze and compare workloads across different display modes
  • Decide which settings works best in your environment

Remote Display Analyzer runs as single executable (no installation required) and docks on the buttom right corner of your session. The first release of Remote Display Analyzer was targeted for Citrix HDX, you can read more about this release here.

Today I’m happy to announce the availability of Remote Display Analyzer for RDP. Below you will find a screenshot of RDA for RDP in action:

printscreenTo give a short introduction I will shortly describe the available information in Remote Display Analyzer (RDA) for RDP:

Display Mode
RDA will detect the active display mode (RemoteFX or legacy RDP) and which transport protocol is used for the connection. RDA will also show you the available bandwidth, this is the measured available bandwidth between the client and the RDS session host.

Real-Time Statistics
The real-time statistics gives you visibility in the real-time bandwidth consumption for both UDP and TCP, also the round trip latency for the active protocol is shown here. 

Package flow statistics
This statistics are primarily used for UDP based connections and will show you the Forward Error Correction (FEC) rate (recover from losses without retransmissions) and the package loss and retransmission rate.

Frame statistics
Frame statistics will show you the number of frames currently being sent to the client, also the frame quality is shown here. You will get a better understanding how RemoteFX is adjusting the frame quality when playing video content for example. Also in case of any skipped frames, you will see how many frames are skipped and the reason why they where skipped.

Total Statistics
The total statistics section will show you the total analytics during the runtime of RDA. For example here you can find the total number of frames that where send to the client and the total amount of bandwidth consumed for each protocol. Also the average bandwidth consumption is shown here. Just run your workload and see in real-time and in totals how the active display mode behaves in your environment. The total statistics can be reset with the little button just below the total section.

Comparision between RemoteFX in 2012R2 and 2016

Just to show you an example, I compared the difference between RemoteFX in 2012R2 and 2016. The following information is part of this comparision:

  • Same workload (play 30 seconds of the same video)
  • Same datacenter
  • Same hardware
  • Same available bandwidth
  • Same client (connected to a 50Mbit internet connection)
  • Latest RDP client (Windows 10)

Below you will find a screenshot of the results after running the test on 2012R2 :

2012r2

And below you will find the screenshot after running exact the same test on 2016:

2016

Conclusion and findings

  • As you can see in the RDA output from above screenshots the total frames send to the client are more or less the same
  • You can also see that the consumed bandwidth is much lower on the 2016 session host
  • Average bandwidth usage is also much lower on the 2016 session host
  • Frame quality is more adjusted on the 2016 session host while playing video, but this has no noticeable impact on the user experience
  • Much more pleasant to watch the video on the 2016 session host

Please keep in mind this results are tight to this given scenario, results may vary depending on the workload and available resources.

Availability
Remote Display Analyzer for RDP is now available on the Remote Display Analyzer website, where you can also find more information about the project.

Currently the roadmap for the next version of Remote Display Analyzer is to add support for VMware (so all major platforms are supported) and to add GPU related information. Also Remote Display Analyzer will be consolidated into a single version so you can run it cross platform by just using one executable.

Thanks for reading!

Remote Display Analyzer for HDX 1.4 released

Hi all,rda

I want to begin with a big thank you for all the positive feedback about Remote Display Analyzer (RDA) and also a very big thanks to the members in the sponsor program, this really helps to drive RDA forward and to help balance the amount of time spend in this project by giving something back to the family. So thank you very much for becoming a sponsor!

If you read about Remote Display Analyzer for HDX for the first time, this tool will help you decide which display settings are the best for your Citrix environment. RDA will help you:

  • Visualize Citrix HDX display modes, this will give you a better understanding of all the settings and what their effects are in real-time
  • Only show you settings that are applicable for the active display mode
  • Live switch between display modes and settings
  • Give insight in consumed resources (CPU, Memory, Bandwidth) and compare them to other display modes while running the same workload
  • Troubleshoot display issues

If you want to read more about previous released versions, please click here.

What’s new in Remote Display Analyzer for HDX 1.4

Below you will find a print screen of version 1.4:

1.4 printscreen

As you can see there is a new section added called Total Analytics. This will give you insight in the consumed resources after running a specific workload. For example you can run your graphic intense application, your business applications or play a video and measure the total consumed bandwidth and the total frames that are send to the client. The average bandwidth counter will give you an indication what the average bandwidth consumption (per second) was while running your workload.

RDA will now also show you the detected (available) bandwidth between the remote environment and your client, there is a reset button which you can use to reset the total analytics back to zero so you can start analysing just before running your workload.

The HDX policies are updated to reflect the changes made in XenApp\XenDesktop 7.9 and version 1.4 also contains numerous fixes and improvements.

Remote Display Analyzer for HDX 1.4 is now available on the website. All existing sponsors will receive a mail automatically containing their new sponsor unlock password. If you are a sponsor and didn’t receive this mail, please send a mail to info@rdanalyzer.com and we will take care of this as soon as possible. New sponsors will receive a personal unlock password automatically by filling in the sponsor form on the website, thanks for your support and feedback!

App-V Scheduler 2.4 released

Banner

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
  • Update packages while they are in use without rebooting the machine and while users are logged on
  • Real-Time (portable) remote management console (inventory, manage and central configuration)
  • No App-V full infra components needed (dramatically simplify your deployment)

For more information about the 2.4 release and about previous released versions, please visit the App-V Scheduler website and read the latest release blogpost.

Citrix Display modes: How to configure, what to configure, when to configure

graphics

It’s been a while since I wrote my last blogpost, so I thought it was about time to write a follow up regarding Citrix graphics!

Lets get back in time first, my previous 2 blog posts about Citrix display modes are still very relevant and will give you a good overview about :

A while ago I started to write part 3 : How to configure, what to configure, when to configure. The main goal for this blog post was to give an understanding about all the display modes and related settings.  Lets start with summarizing the available Citrix display modes we know today :

  • Legacy Graphics mode (this includes the first Adaptive Display generation and the older progressive display technology)
  • Thinwire Graphics mode (this includes the new H.264 video codecs (Pure H.264 and H.264 Optimized for text) and Thinwire plus, the latter is also known as Compatibility mode)
  • Desktop Composition Redirection (combination of Thinwire graphics and Aero\DWM remoting to offload DirectX commands to the client)
  • Framehawk (new graphics mode which is based on predicting technologies to optimize graphics for high latency connections (UDP based))

So the initial goal of this blogpost was to help understanding all of the policies and settings related to above display modes. When a specific setting applies and when not, etc.
In the meantime my colleague Barry Schiffer was also busy with this subject and had the idea to give a presentation  together at E2EVC about the various display modes. Our goal was to give insight in the consumed resources of every display mode and help you decide which configuration would be the best fit for your environment. This is where the idea was born to develop  a tool to show valuable information about the current display mode while running your remote workload in the background. This tool would be targeted to admins and not users.

When it comes down to configuring display settings one size doesn’t fit all, so I decided to stop writing the part 3 blog post and instead build out the tool so you can experience every display mode and settings for yourself. I think this tool will make you understand the display modes and its behavior even better then only reading about it!

Remote Display Analyzer

So this is how the Remote Display Analyzer project has started. The main goal of Remote Display Analyzer is to make the display modes understandable by showing only applicable information for the detected display mode. It helps you decide which configuration fits best in your environment and will help you detect miss configured settings and resource bottlenecks.

Imagine to take place behind your old thin client (which for example can’t be replaced because of tight budgets) and detect at which display configuration the user experience is optimal and in balance with the resource allocation. Or to check at which settings your branch office performance best, or just to get a better understanding about the behavior of a given display mode. Sounds great right?

Over time the project evolved in much more then only showing you real-time information that matters, Remote Display Analyzer is also able to show you which settings you can change and change them on the fly!
This makes it possible to run your remote workload in the background and flip settings to get a deeper understanding of what is happening in real-time without having to logoff and configure different policies by yourself etc. Because the naming of the settings are the same as you find in the policies it’s easy to replicate the optimal settings in your production environment.

Change display settings on the fly

Besides live switching through settings, Remote Display Analyzer is also able to switch between display modes. For example you can live switch between Thinwire and Framehawk and from Thinwire to Desktop Composition Redirection(DCR) and vice versa when your client and VDA supports it.

Change display mode on the fly

Enough talking try it for yourself, hopefully you like it!

Availability

Remote Display Analyzer is available in 2 editions :

  • Lite edition, which gives you the ability to view display settings and real-time analytics
  • Sponsored edition, which provides all the functionality of Remote Display Analyzer like changing settings on the fly and advanced settings

Of course I hope to welcome you as sponsor of the project to even add more functionality in the future and to keep Remote Display Analyzer up to date. For more information about sponsoring and downloading Remote Display Analyzer please visit the website : www.rdanalyzer.com.

Thanks for reading!

App-V Scheduler 2.3

What’s new in App-V Scheduler 2.3

Introduction
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

Availability
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?

Intro
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 :

Loading2
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.

Conclusion
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.

App-V-Scheduler22

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 :

CentralViewConsole

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.

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

App-V Scheduler now more powerful than ever

Introductionlogo
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!

Availability
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

Introduction
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 :

GUI_Version2

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 :

PendingTasks2

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.

VirtualProcesses

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.

PackageDetails

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

Package_details_service

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.

Central_Management_Console

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.

support1

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 :

RES_WM_Appv5_Integration

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 :

CommandLineHookSwitch

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 :

Receiverforweb_Timeout

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 :

NativeReceiver_tokenlifetime

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 :

Responder_Policy

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.

Conclusion
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.