New Features in XenApp 6.5

Application streaming

The steaming client has been enhanced to allow VHD’s to be mounted directly as the RadeCache. This is specifically for the pooled desktop scenario where you don’t want users generating lots of write IOPS to your difference disk by launching streaming applications that then create the radecache (i.e. write traffic), which in turn gets redirected into the difference disk thus generating write IOPS.

Mounting the VHD directly into the filesystem (supported natively by the OS in Windows 7) means the RadeCache is “pre-populated” and thus makes no changes to the system image on first launch, generating no write IOPS to the difference disk, improving application launch time, and reducing load on the storage.

The VHD’s can be created at profiling time by a new version of the Streaming Profiler.

Load evaluators

Citrix have removed the ability to assign load evaluators directly to servers (and also the corresponding Set-XAServerLoadEvaluator Power Shell command). Load evaluators can now only be assigned to servers via a Worker Groups or OUs and applied by XenApp/AD group policy.

This has the advantage that newly provisions servers can automatically be assigned a non-default load evaluator based on it’s OU membership.

The biggest knock-on effect of this is that load evaluator changes will now be subject to the AD policy refresh period, as per all other XenApp policies, whereas previously they were picked up on the next LHC/datastore sync.

Multi-stream ICA

The single TCP Stream that used to run over port 1494 (or 2598 with session reliability) can now be split into four separate TCP streams if required. These can then be assigned different network-level QoS policies to prioritise certain kinds of ICA traffic over others. There is also a UDP audio stream for XenDesktop.

 

Desktop Director for XenApp

The Desktop Director web-based console shipped with XenDesktop has now been enhanced and includes XenApp sessions, and HDX monitor functionality.

Session pre-launch

Session pre-launch starts up a pre-defined application on the server at a specific event (either the user has logged into the client OS, or at a scheduled time). The user is not connected to their session until they actually launch the application via its usual shortcut, but they then only have to wait for a session reconnection (a few seconds) rather than a complete login (upto several minutes depending on your login script and profile size)

Things to bear in mind:

• It’s the client that issues the pre-launch, so you need the new v13 client to support this
• A CCU license is consumed as soon as the pre-launch session is active, so you might start consuming more CCU licenses
• Running many prelaunch sessions may require more XenApp server resources to cover sessions pre-launched but not yet in use. Remember the application is still running in a pre-launch session – just that the user is not yet connected to it.

Session linger

Normally when you close the last application in your session, you will be logged off the server and your session will close. Session linger allows that session to remain for a period determined by policy. The advantage of this is that if you then decide to launch the same, or another application, it will launch almost instantly, as it won’t have to perform all the login actions (logon scripts, loading your profile etc)

The disadvantages are that there are server resources being consumed by users who aren’t using any applications, and sessions that are lingering are still consuming a CCU license.

Data store configuration by policy

In XenApp 6, support was added to allow XenApp servers to be provisioned, however there were a few
leftovers of configuration that still had be to “baked into the image”. These were the Zone that the server was to be added, and the data store configuration.

Both these items can now be configured into an AD Group Policy Object (GPO) meaning servers will inherit their data store configuration and zone information based on the parent OU the server is added to. Note these policies are the only ones that can’t be stored in IMA as the server has no IMA connection at the time these policies are applied (i.e. server farm joining)

New “session-only” and “controller” roles

New Session-only role : no XML service, sync’s fewer data store tables to reduce data store replication when adding/removing servers from the farm

Controller role: Full XenApp functionality (akin to a XenApp 6.0 server). Can be used for Zone Data Collectors and XML Gateways.

These changes mainly impact larger farms only where adding/removing servers cause a large amount of datastore replication traffic, putting stress on the datastore and ZDCs.

Biggest impact to farm administrators will be that you won’t be able to run the AppCenter console (formerly Discovery Services Console) on any server in your farm and choose “localhost” in the discovery – you will have to point the console at a Controller server.

Power & Capacity Management

• Can now query and control VM power status using Hypervisors API
• Support for Hyper-V and ESX/vSphere added
• Can now use the new Logon control feature to drain users

Probably by the month of September Xenapp 6.5 will release.