Remote Display Analyzer 2.0 released

Hi all,

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 are new to Remote Display Analyzer (RDA), this tool will help you understand your remote display configuration and it’s behavior, it will only show you relevant information and help you decide which setting is the best for your specific use case. It’s also very handy for troubleshooting remote display configurations. RDA is just a portable executable without any installation needed, just run it in your remote session and you will get all relevant statistics and settings right away.

There is a lot of new functionality in RDA 2.0, both under the hood as on the outside. I don’t want to make this a long article so I will just give you a short summary of the new features together with some print screens.

What’s new in version 2.0

  • Support for VMware Blast and PCoIP with also the possibility to change settings on the fly (please note that support for Blast and PCoIP is experimental in this release and not yet tested on different OS and VMware View versions)
  • GPU addon for all protocols: This addon will show basic GPU information and when Nvidia is detected RDA will show GPU usage and (v)GPU information
  • Support for the latest Citrix HDX features like H.265, also the RTT counter has been added and RDA will show you the YUV mode for the active video codec
  • RDA is now multi threaded which means that settings and real-time counters are retrieved on different threads making the tool more snappy and more real-time
  • Counter that indicates the run time of RDA with the option to reset the counter and the total statistics collected during  a specific run time. This is handy for analyzing and comparing workloads
  • Print screen option to easily generate a print screen of the RDA window
  • Multiple improvements for RDP & new statistics information
  • Transparent mode, this option makes the RDA window transparent as you can see in the below print screen

Below you will find some print screens of RDA 2.0

RDA running in transparent mode

RDA support for VMware

GPU addon (available for all protocols) and extended support for HDX

Remote Display Analyzer 2.0 is now available for free on the website where you can also find more information about the sponsor program. Existing sponsors should have received an automatic e-mail about this new release. If you didn’t receive the mail please send an e-mail to info@rdanalyzer.com. Thanks again for your support!

Advertisements

A comparison between display protocols and codecs

Please note this article has been updated.

Intro

18 November I did a presentation on E2Evc in Barcelona with Rasmus Raun-Nielsen (co-member of TeamRGE) about the differences between remote display protocols and codecs. The session was late in the afternoon so there was already some beers involved which made it a very fun presentation. We summarized the major remote display protocols available in the market. Rasmus then explained what NVENC is (a way to offload the display encoder process to the GPU) and which Nvidia cards supports this technology. I continued with an overview of the available codecs for each protocol and showed the latest Remote Display Analyzer (RDA) 2.0 version (which will be released soon!).

Before the presentation I performed some comparisons with RDA 2.0 in combination with the video codecs found in Microsoft RDP, Citrix HDX and VMware Blast. This blogpost is a small recap of the presentation. Please note that this comparison is an independent view and that conclusions are based on my own observations.

Before I continue: there is some fast progress being made in this space, so it’s important to include the version numbers which are used in this blogpost (I prefer to post updated blogs later instead of updating the same one). The versions used are in the table below:

Codecs used by this protocols

Basically all of the above display protocols consists of 2 types of codecs:

  • Bitmap codecs (JPG\PNG\BMP)
  • Video codecs (H.264\AVC & H.265)

While the bitmap codecs are great for text and static content, the video codecs are more efficient for the more graphic intense workloads. The video codec is based on the industry standard H.264 codec (which we also find in video streaming services like Netflix and YouTube). The use of this codec brings 2 other great advantages:

  • The fast majority of clients have video codec decoding capabilities
  • GPU can be used to accelerate and optimize the encoding process (like Nvidia NVENC)

This results in a very bandwidth efficient way to deliver remote display content to the client, but it comes with a down side: The video codec is by default not optimized for text, because it uses a 4:2:0 chroma subsampling algorithm. This breaks down the quality of text and users often perceive this as blurry (this depends on the user and type of workload, I have seen users working with it every day without complaining). But for text to become really sharp an optimization technique on top of 4:2:0 is needed or a codec operating in pure 4:4:4 mode. This is where the display protocols differentiate from each other like you can see in the below table:

RDP
With RDP you basically have one option when it comes down to the video codec and that is the AVC codec in 4:4:4 mode. It’s enabled by default in the latest Windows versions and you can switch back to the previous codec combination with policies. You can’t really configure this AVC 4:4:4 codec, for example you can’t switch to 4:2:0 mode or change quality levels manually. I must say that the latest RDP versions improved a lot compared to the older RDP versions found in previous Windows versions. While the protocol is still quite bandwidth intense, it offers a very good remote experience. The AVC 4:4:4 mode really delivers a very sharp (near local) experience. They don’t support hardware capabilities like NVENC for their video codec implementation, hopefully this will change in the near future as GPU’s are becoming more mainstream in remote display solutions. RDP together with RDSH (and the upcoming modern infrastructure) is a very cost effective remote display solution, especially with the latest RDP improvements.

Blast
Blast is a fairly new protocol compared to the others and it’s impressive to see how quick they are making progress with it. As you can see in the above table they do not yet offer a technique to achieve 4:4:4 quality for their video codec. They might be waiting for GPU’s to natively support 4:4:4 so they don’t have to build a software based optimization mechanism for this. They also have a bitmap encoder which you can switch on (Blast uses H.264 by default), but a combination of this codecs is not yet possible. Time will tell if they are focusing on a combination of codecs or optimizing their video codec for 4:4:4 quality. I think the latter makes more sense because currently their bitmap encoder isn’t that optimized compared to the others. Nevertheless I was impressed by the performance of their H.264 codec, as you can see in the comparison below.

HDX
As you can see in the above table HDX has 2 combinations available to address the H.264 4:2:0 limitation. 1: The video codec with a text optimization technique (which is software based and done in CPU). 2: A combination of the bitmap and video codec, this is also known as the “Use Video codec for active regions” setting. For Citrix this makes sense because their bitmap encoder is really optimized throughout the years. In this combination of codecs the video codec is only used for parts of the screen that are changing rapidly, like playing a video for example. I wrote about the differences between the display modes available in HDX here. But there are some limitations, for example you can’t use NVENC in combination with this optimization techniques as of today. I hope to see expanded support for this in the near future. In version 7.16 Citrix has added support for the H.265 codec, this codec is so awesome in many ways as it can massively reduce bandwidth consumption by leveraging a new intra prediction mechanism. This first implementation of H.265 is 4:2:0 only for now (and only when you have a supported GPU), but hope to see more available options in the near future.

All 3 protocols have ways to handle network congestion’s and changes in available bandwidth, they often refer to this with the term “adaptive transport”. They all standardized on UDP by now as the primary transport protocol for sending remote graphics down the wire.

Video codec comparison between RDP, HDX & Blast

Ok let’s continue with the comparison. As you might understand by reading the above it’s not easy to perform direct comparisons. You can just compare the default settings to each other and say how good one is and the other not or vice versa. But in my opinion a comparison only makes sense when you compare apples with apples. Because this comparison will only focus on the video codec I decided to compare the AVC\H.264 codecs to each other. In this comparison the H.264 codec is used for the entire screen and offloaded to the GPU (NVENC). There is one exception and that’s for RDP because we can’t turn off the AVC 4:4:4 mode. Please find the video codecs that are compared in the below table:

Important aspects of the test environment:

  • Agents on Windows 10 with identical specs running on the same hardware placed in a Datacenter in The Netherlands
  • Connection over internet directly to the agent (no connection brokers or gateways)
  • Connection from the same client with same internet conditions and latest client versions
  • All 3 protocols are UDP enabled
  • HDX and Blast use NVENC (Entire screen H.264)
  • Default encoder quality levels are used
  • Test is performed multiple times to verify results
  • Remote Display Analyzer is used to verify display settings and behavior

I separated the RDP comparison movie from the others to highlight even more that the operating mode is different between the video codecs (HDX\Blast operates in 4:2:0 mode in this comparison and RDP operates in 4:4:4 mode).

Please note that this video codec comparison was made for indication purposes only, it’s not reality that users play full screen videos often (while they can do this from time to time). The comparison is based on a manual testing approach while using screen recording software which will also do it’s own compression on the end result. This will affect the frame quality of the resulting movie. This is not comparable with a professional way of benchmarking with for example frame grabbers. For this type of benchmarks I recommend using REX Analytics (developed by co-members of TeamRGE). REX Analytics also leverages Remote Display Analyzer for remote display protocol insights.

The results of the above comparison is displayed below (please note that the Nvidia GPU utilization counter was turned off in this build of RDA, so that’s the reason it shows 0%. The total CPU time consumed is a cumulative of the %CPU usage of the encoder process).

 

My observations and conclusions from the HDX and Blast (pure H.264) video codec comparison:

  • The available bandwidth detected varies between the display protocols. It seems they use a different mechanism of calculating the available bandwidth. It’s interesting to dive deeper into this. This also made me think to add an average available bandwidth counter in RDA so there is an overall indication of the average available bandwidth during a specific run time
  • Observed higher frame compression while playing a full screen movie with HDX compared to Blast, this might be one of the reasons the lower bandwidth usage compared to Blast and the higher amount of frames send to the client (although the difference is not really shocking over a 1:30 minute during full screen movie)
  • With the default encoder quality settings, I observed a sharper frame quality with Blast. But at the cost of more bandwidth and CPU resources compared to HDX
  • Based on the above observations it’s key to compare frame quality to each other and also compare this with a local situation!

Below is an indication movie of the RDP AVC Video codec operating in 4:4:4 mode:

You can find the result below:

My observations and conclusions from the RDP video codec in the above test:

  • RDP can’t really be compared with the others in this video codec comparison because it operates in 4:4:4 mode by default. Perceived quality was very good but high bandwidth usage and some lagging was observed as you can see in the above movie
  • Really sharp images and text, perceived a near local experience with this video codec implementation. Great for office work with a lot of text reading
  • RDP leverages as much bandwidth as needed to achieve the best quality. Not sure what is best: A protocol that’s from itself as low on bandwidth as possible to give the user the best experience or a protocol that uses as much bandwidth needed to achieve the best experience. There should be some form of bandwidth limit or throttling per RDP session to prevent pipe exhaustion or noisy neighbors.  Scalability tests should point out, interesting topic for future testing

Overall conclusion

The above remote protocols aren’t build for remote streaming and remote gaming scenarios (while video and graphical content is increasing). They are build to accommodate a mix of different type of user profiles. That’s why I think it’s very important to have options based on this different type of users, because ones size doesn’t fit all. The display protocol is becoming more intelligent, it can switch codecs and settings by itself based on different content, it would be interesting to see if this will also happen based on the user type or even per application. Because this is not the case for now it’s good to have options!

For now I would say HDX has an advantage over the others because it has the most options available to accommodate a lot of different remote display scenarios. As you can see in the above results the difference between HDX and Blast is not that big when you compare the pure H.264 codec implementations to each other. They both performed really well in this test. The video codec implementation in RDP didn’t disappoint me either, well the bandwidth usage does but the experience was really good.

It’s very interesting to see how they all keep progressing in the near future, expecting to do more 4:4:4 mode comparisons in the future when this is becoming more mainstream. Remote Display protocols are still awesome technology with a lot of advantages, possibilities and use cases.

This blogpost comes without warranty of any kind and observations are based on my own interpretation. Always test and analyze by yourself with a workload that is similar to reality for your environment!

Comparison between display settings in Citrix HDX

Hi everybody,

Last Citrix Synergy (2017) in Orlando, Benny Tritsch and Ruben Spruijt presented the following session:

SYN303: Independent Citrix experts deep dive on Remote Graphics, user experience and GPUs.
This session was among the top 10 of most popular sessions of Synergy 2017, if you didn’t see the presentation you can watch it on-demand here.

In this presentation the new Remote Display Analyzer (RDA) version 1.6 was announced which will be released soon. This version includes numerous new features like a screen capture button and a GPU add-on (available for all display protocols Remote Display Analyzer supports). More about this new RDA version soon.

Also shown in this presentation where the results of a short comparison between 3 major display settings currently available in Citrix HDX. In this blogpost I will show you how this comparison was made together with some key findings. The display settings where evaluated in real-time by playing the exact same video three times while live switching between the following settings:

  • Video codec not in use
  • Video codec for the Entire screen
  • Video codec for Actively changing regions

You can watch the comparison here:

(Test video source: Aswanth Mohan (www.youtube.com/watch?v=668nUCeBHyY))

The result of each setting is shown below:

Some key findings from this short comparison:

  • The total send frames where nearly the same
  • During the test I noticed no big difference in user experience while playing this short 720p HD video
  • Video codec not in use has the lowest impact on CPU but as you can see the bandwidth consumption is higher then the other two
  • Video codec used for the entire screen (with text optimization) gives the best result on bandwidth consumption, but this comes with a higher CPU usage
  • Video codec used for Actively changing regions results in a very good balance between both CPU and bandwidth consumption

Disclaimer:
Please note that this results come without warranty of any kind and are my own interpretation based on above test. The results may vary based on factors like workload, bandwidth and the infrastructure you are using. Please always test settings in your own environment to decide which configuration fits best in your scenario.

Remote Display Analyzer 1.5 released

rda

Hi all,

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 the first time, please click here and here to read more about the project and previous releases of RDA.

What’s new in version 1.5

  • Remote Display Analyzer is now consolidated into one version, this means you can use the same executable for RDP and HDX. RDA will automatically detect which protocol and settings are in use, you don’t have to configure anything.
  • Support for the latest changes in HDX: Support for the latest video codec optimizations like actively changing regions (and ability to live switch between video codec settings), detect hardware encoding, support for 8-bit color depth, etc
  • Numerous fixes and improvements for both RDP and HDX

What’s coming

  • NVIDIA addon
  • VMware support (this means RDA supports all major display protocols within one consolidated version)
  • Further improving RDP and HDX functionality

Remote Display Analyzer 1.5 is now available on the website and sponsors should have received an automatic e-mail which contains more information. Thanks again for your support!

App-V Scheduler 2.5 released

Banner

Intro

If you are reading about App-V Scheduler for the first time: App-V Scheduler is a purpose build deployment tool for App-V 5 and provides features that allow you to perform all actions that are crucial in every application life cycle management process. 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.

What’s new in App-V Scheduler version 2.5

  • Full support for the embedded App-V client*
  • Performance improvements in the Central View console
  • New search and filtering options in the Central View console
  • New machine group funtionality for even better management and control over your deployment
  • Enhanced deployment method for large scale VDI environments
  • New publishing tasks features (adding packages on the fly and publish packages globally when no user publishing task exists feature)
  • Import package options directly from the content share

* Since Windows 10 anniversary update and Windows Server 2016 the App-V Client is embedded in the Operating System, this makes your application deployment even easier and more reliable as ever before! And to make it even more a no-brainer to leverage this application deployment method, App-V is now also free to use!

For more information about the above new features, please visit the App-V Scheduler website and read the latest release blogpost.
Thanks for reading.

By Bram Wolfs Posted in App-V

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!

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.