The renowned App-V guru Tim Mangan has put together a 16-minute video on the numerous differences between the new Microsoft App-V 5 and the previous versions. The video was originally posted on Brian Madden’s website here

The video explains the main differences at the client and how this affects your ability to deploy certain applications. Microsoft calls these virtual application extension points, which can be confusing

Click here to view the video in HD

An article by Richard Khan from Citrix Blogs

Last year with version 5.1, VDI-in-a-Box introduced the ability to take advantage of two separate data stores, allowing VDI-in-a-Box to better leverage the direct attached storage of servers. When using the Hyper-V or ESX hypervisors, VDI-in-a-Box allows you to define a second datastore to separate the storage of golden images, and linked clones. Now with version 5.2 of VDI-in-a-Box we have introduced the option for a third datastore. In addition to the datastore options for golden images and desktops, there is now an option to store the personal vDisks associated with personal desktops on a separate datastore. Administrators now have the ability to store images, desktops, and personal disks separately or together on the datastore of their choosing. Best of all, this option is available on all supported hypervisors.

Upon initial configuration, the vdiManager uses a single datastore. This primary datastore contains all of the golden images, desktop instances, and the vDisks associated with Personal Desktops. Enabling the multiple datastore feature in vdiManager’s advanced properties makes it possible to separate these three types of data onto their own data stores.

The flexibility of multiple datastores can be leveraged by storing pooled desktops on an SSD datastore for improved IOPS performance. Since pooled desktops require much less space, better IOPS performance can be achieved by adding only small amounts of SSD drives to a server. Using SAS drives for the primary datastore will provide higher capacity storage for storing the larger golden images. Using both SAS and SSD storage in the servers allows VDI-in-a-Box to avoid being constrained by the IOPS limitations of SAS drives, or the small capacity of SSD drives. With this combination of IOPS and storage space, administrators can pack more desktops than ever on each server in the VDI-in-a-Box grid.

Read More

An article by David McGeough from Citrix Blogs

Let’s face it, virtualization technologies aren’t exactly ‘plug & play’.

Even the simplest virtualization deployment touches almost every IT discipline and department – from networking and security to data centers, desktops and storage.

That’s why smart, well-informed administrators are so important to the success of every Citrix deployment.

It’s also why we took aside some of our top support engineers and asked them to share their insider tips – little things that most administrators may not know about but that can really make your lives easier.

We got lots of excellent tips for a whole range of Citrix products. And we collected them in a free guide called Secrets of the Citrix Support Ninjas.

Here’s a taste of the kinds of things our support ninjas thought you’d benefit from:

For XenApp

“Use the Citrix Scout tool to collect logs and CDF traces from selected computers. Citrix Scout is also used in conjunction with Citrix Auto Support to help resolve known issues.”

David McGeough

“Wondering if that print driver will work with XenApp? Use StressPrinters to get the answer!”

Nicholas Vasille

For XenDesktop

“You can quickly and easily optimize the user experience on XenApp & XenDesktop with the help and recommendations of HDX Monitor.”

Michael Ryan

“To view successful and failed connections over the past 48 hours, try the tool Get-BrokerConnectionLog.”

Rene Alfonso

For NetScaler

“While taking a nstrace, set the packet size to zero to collect the complete payload.”

Durga Kiran Bolagani

“Learn to troubleshoot in the command-line interface.

You see more information as a result of one command instead of several clicks in the GUI.”

There are a lot more tips in the Secrets of the Citrix Support Ninjas eBook – so download it and take a look.

Read More

An article by Melvin Koh from Citrix Blogs

If you have been visiting the Citrix support KB websites, then I’m sure that you should have seen this popup on your browser:

So what is Citrix Auto Support? It is a website that anyone with a MyCitrix account can upload their Citrix logs for a quick health check. What is so fantastic about this website is that it will automatically analyze your log, and give you a report which includes known issues and best practice suggestions.

For example, I recently had some issues with a XenServer 5.5u2 at a customer site. Using XenCenter, I collected a server status report and uploaded it to the Auto Support. After it got uploaded and analyzed, straightaway it reported that 5 issues are detected:

Selecting that entry will give me a detail description of what are the issues and the resolutions. In the screenshot below, Auto Support is telling me that this XenServer has missing hotfix and configuration tips.

This is very useful for me as after a deployment, I can do an analysis on the environment to see if I can do more tuning or forgotten something. Not to mention that over time, this knowledge base will be updated with new tips and best practices.

Read More

An article by David Weck from Citrix Blogs

The SSL VPN offered by NetScaler Access Gateway utilizes the systems web browser for logon to the network. This brings certain advantages, for instance the possibility to logon can be made depending on the result of endpoint security checks, it offers a way to deploy the VPN client to users who haven’t installed it yet and allows for integration with NetScaler’s own or internal web portals to be displayed for users who successfully established a tunnel.

There are however circumstances where this feature isn’t necessary for a particular environment or use case. A while back I was approached by one of our customers to explain how the display of the native logon form can be displayed for all users per default or even deployed in that way automatically, without the web browser as user interface for the VPN client .

The below screenshot shows how it looks like. The displayed input fields can be altered, a combination of password and token authentication is possible the very same way as with the web browser being the user interface.

The configuration for this way of user logon is done in the VPN profile of the Secure Access Client. In the options of your VPN connection (check the tray icon) you have the possibility to change your profile. The setting responsible for the logon form, is on the “Options” tab. The checkbox titled “Use the Access Gateway Plug-in for logon” needs to be checked in order to have the native logon form coming up on the screen the next time you want to connect with the client.

While this isn’t very new to many of you and furthermore it’s documented already at other places, my client wanted something, which isn’t documented anywhere. He needed to auto-deploy the Access Gateway plug-in to new machines and didn’t want the users to go through the dialogues to change the default behavior on their own. Hence we needed to set the logon option manually to have the native logon form available from first use on.

Read More

An article by Prashant Batra from Citrix Blogs

Access Gateway is a secure remote access product and hence tends to be the entry point for corporate users, wanting to access their enterprise applications and desktops. Given this, it makes sense for corporates, to try and customize the logon experience on Access Gateway, to match their corporate look and feel.

Access Gateway has always allowed for this customization, though, it’s been somewhat of a tedious process. With the new 10.0.71.6014.e release, we are making an attempt to simplify this experience.

UI Customization on Access Gateway is a multi-step process:

1. Access the built in theme web pages and customize them, to match the corporate requirements
2. Apply the modified theme (collection of web pages) at the right location
3. Modify certain scripts to make this change persistent
4. Every time the firmware has to be upgraded, take a backup of the customized pages and scripts and re-apply the same after the upgrade.

A quick Google search will give you a number of helpful and very accurate blogs/articles, on how to tweak the web pages to customize and create your corporate look and feel. Some of my favorites are:

• http://blogs.citrix.com/2012/04/19/green-bubble-theme-for-citrix-netscaler/
• http://jariangibson.com/2012/04/16/apply-citrix-receiver-theme-to-netscaleraccess-gateway-10/

Read More

Andreas Groth, a Lead Virtualization and Cloud Architect for IBM’s Server and Technology Group in Europe has posted a really remarkable, interactive matrix on his website that compares the features of VMware, Microsoft, Red Hat and Citrix virtualization solutions. Andreas’ Virtualization Matrix is “… a unique vendor-agnostic reference matrix enabling you to quickly select and compare license-specific capabilities of the selected x86 server virtualization technologies”.

Click here to check out the Matrix!

An article by Paola Cornacchiola from virtualization.info

David Davis, Virtualization and Cloud savvy at TrainSignal, Author and vExpert, discusses the costs and business benefits of Virtual Desktops in a video posted in a Google+ Hangout

Davis explored the financial and technical benefits of desktop virtualization, still using the concept of cost saving as a trigger, he gave examples of how an organization can have centralized control and application consistency increasing security.

An article by Andy Baker from Citrix Blogs

In this blog series I’m taking a look at scalability considerations for XenApp 6.5, specifically:

1. How to estimate XenApp 6.5 Hosted Shared Desktop scalability
2. What’s the optimal XenApp 6.5 VM specification?
3. XenApp 6.5 Hosted Shared Desktop sizing example

My last post provided guidance on how to estimate XenApp density based on processor specification and user workload. In the second post of the series, I’m taking a look at the optimal specification for the XenApp virtual machines themselves.

In an ideal world, every project would include time for scalability testing so that the right number of optimally specified servers can be ordered. However, there are various reasons why this doesn’t always take place, including time and budgetary constraints. Architects are all too often asked for their best guess on the resources required. I’ve been in this situation myself and I know just how stressful it can be. If you over specify you’re going to cost your company money whilst under specifying reduces the number of users that can be supported, or even worse – impacts performance.

XenApp Server Virtual Machine Processor Specification

In most situations, testing has shown that optimal scalability is obtained when 4 virtual CPUs are assigned to each virtual machine. When hosting extremely resource intensive applications, such as computer aided design or software development applications, user density can sometimes be improved by assigning 6 or even 8 virtual CPUs to each virtual machine. However, in these situations consider using XenDesktop rather than XenApp so that you have a granular level of control over the resources that are assigned to each user.

Number of XenApp Servers per Virtualization Host

When determining the optimal number of virtual XenApp servers per virtualization host, divide the total number of virtual cores by the number of virtual processors assigned to each XenApp virtual machine (typically 4). For example, a server with 32 virtual cores should host 8 virtual XenApp servers (32 / 4 = 8). There is no need to remove server cores for the hypervisor because this overhead has been baked into the user density overheads discussed in the first blog.

One of the questions I get asked most is whether the total number of virtual cores includes hyper-threading or not. First, what is hyper-threading and what does it do?

The Citrix XenDesktop and XenApp Best Practices whitepaper states:

Hyper-threading is a technology developed by Intel that enables a single physical processor to appear as two logical processors. Hyper-threading has the potential to improve the performance of workloads by increasing user density per VM (XenApp only) or VM density per host (XenApp and XenDesktop). For other types of workloads, it is critical to test and compare the performance of workloads with Hyper-threading and without Hyper-threading. In addition, Hyper-threading should be configured in conjunction with the vendor-specific hypervisor tuning recommendations. It is highly recommended to use new generation server hardware and processors (e.g. Nehalem+) and the latest version of the hypervisors to evaluate the benefit of Hyper-threading. The use of hyper-threading will typically provide a performance boost of between 20-30%.

Testing has shown that optimal density is obtained when the total number of virtual cores includes hyper-threading. For example, a server with 16 physical cores should host 8 XenApp VMs – 32 virtual cores (16 physical cores x 2) / 4 virtual CPUs per XenApp virtual machine = 8 XenApp virtual machines.

A common mistake is to perform scalability testing with one virtual XenApp server and to multiply the results by the number of virtual machines that the host should be able to support. For example, scalability testing might show that a single XenApp server virtual machine can support 60 concurrent ‘Normal’ users. Therefore, a 16 physical core server with 8 XenApp server virtual machines should be able to support 480 concurrent users. This approach always overestimates user density because the number of users per virtual machine decreases with each additional XenApp VM hosted on the virtualization server. The optimal number of concurrent normal users for a 16 physical core server will be approximately 192 with around 24 users per virtual machine.

User Density per XenApp Server Virtual Machine:

The user density of each 4vCPU virtual XenApp server will vary according to the workloads that they support and the processor architecture of the virtualization host:

• Dual Socket Host: You should expect approximately 36 light users, 24 normal users or 12 heavy users per XenApp virtual machine.
• Quad Socket Host: You should expect approximately 30 light users, 20 normal users or 10 heavy users per XenApp virtual machine.

Depending on your worker group design, you may have a blend of light, normal and heavy users on each XenApp virtual machines. In these situations, adjust your density estimates based on the overhead of each workload type (light=1.5, normal = 1, heavy =0.5). For example:

Dual Socket Host -

• 30% light : (36 / 100) * 30 = 11
• 60% normal : (24 / 100) x 60 = 14 users
• 10% heavy : (12 / 100) * 10 = 1 user

Total number of users per XenApp virtual machine = 26

Memory Specification

The amount of memory assigned to each virtual machine varies according to the memory requirements of the workload(s) that they support. As a general rule of thumb, memory requirements should be calculated by multiplying the number of light users by 341MB, normal users by 512MB and heavy users by 1024MB (this number includes operating system overhead). Therefore, each virtual machine hosted on a dual socket host should typically be assigned 12GB of RAM and each virtual machine hosted on a quad socket host should be assigned 10GB of RAM.

The following table shows typical memory specifications for each processor specification:

Don’t forget to allocate memory for the Hypervisor. With XenServer, this is 752MB by default.

Read More

An article by Anurag Juneja [MSFT] from The Microsoft Application Virtualization Blog

written by – Ozge Yavuz, SDE

Introduction

App-V 5.0 “isolates” virtual applications from the operating system and other processes. This is done by hiding the application resources from everything else. One can imagine this as running the virtual application in a bubble that isolates the application from the outside world. Integration, on the other hand, can be thought of as tunnels punching through this bubble, exposing the virtual application capabilities to the native operating system and to the user in a controlled manner. This enables virtual applications to behave as native applications. Think about a shortcut of a virtual application residing on the user’s desktop. This shortcut is outside the virtual bubble and is not isolated since it is on user’s desktop. But this shortcut enables the user to launch the virtual application seamlessly as if it was a native application. This shortcut feature and some others make up the Integration component of App-V. Integration is a collection of subsystems that individually handle one specific integration area. The following is the list of integration subsystems currently available in App-V product:

· Shortcut Subsystem

· FTA Subsystem

· COM Subsystem

· Software Clients Subsystem

· Application Capabilities Subsystem

· URL Protocol Handler Subsystem

· App Path Subsystem

· Virtual Applications Subsystem

Extension Points

An extension point is a single integration unit such as a shortcut of a virtual application. Each integration subsystem can have one or more extension points (EPs). An example would be a virtual package having multiple shortcuts.

Integration Workflows

Integration has two separate work flows:

1. Sequencing: Capturing integration data from the application being sequenced

2. Publishing: Integrating the application to the native operating system during publishing of the package by using the data captured during sequencing

Sequencing

During sequencing of a package, integration subsystems are started after the target application is installed. These subsystems consume the application installation data that the installer lays down (e.g. shortcuts, FTAs, etc.) and then produce extension points (EPs) that end up in the package manifest.

Sample Package Manifest

Publishing

During publishing of an App-V package, Integration reads extension points from the package manifest, dynamic deployment configuration and dynamic user configuration files (if these configuration files are provided). Integration then merges EPs from all these sources and finally integrates these EPs to the native operating system.

Important:

Please note that throughout this blog entry, I will refer to publishing of a package as “integrating the package to the computer”. The reasoning behind that is integration of a package can be initiated externally by a publishing operation or internally when the package is already published to the user but not yet integrated. Further details are outside the scope of this article and will be discussed in a future blog entry.

Global vs. User Publishing

During publishing of an EP, App-V will automatically select where in the operating system the EP should be integrated based on how the package is published.

Global publishing

If the package is published globally (sometimes referred as machine publishing), the shortcuts will be created in public locations on the computer and other integration will happen in HKLM locations in the registry.

Examples:

o If a shortcut is to be created on the desktop, the location would be FOLDERID_PublicDesktop (%PUBLIC%\Desktop),

o If an FTA registration is to happen, it would be created under HKLM\Software\Classes

User publishing

This will place shortcuts in user locations and other integration to HKCU registry locations.

Examples:

o If a shortcut is to be created on the desktop, the location would be FOLDERID_Desktop (%USERPROFILE%\Desktop)

o If an FTA registration is to happen, it would be created under HKCU\Software\Classes

Backup, Restore and It’s Ownership

During integration, integration subsystems backup existing data of native applications that would be otherwise overwritten.

For example, if a native application is installed and has the .docx file type association, and a virtual application package with the .docx EP is being integrated, the file type association belonging to the native application is backed up first and then the EP is integrated. Also, when the package gets unpublished, the EP will be de-integrated first and the backed up .docx file type association will be restored.

App-V also tracks which package owns the backed up data and only restores it if the owner package gets de-integrated. This is to allow for two or more virtual application packages publishing the same EP (e.g. the same .docx file type association), the last published package should be the owner and if the first package gets unpublished first, we shouldn’t restore the backed up data so that we don’t overwrite the last package’s extension points.

· If two packages are competing for the same EP, the last package that is integrated takes ownership.

· If the first package gets unpublished, backed up data will NOT be restored since the package is no longer the owner of the backed up data.

· If the second package gets unpublished, backed up data will be restored.

This backup and restore process happens for each extension point, including shortcuts and registry-based subsystems.

Notifying Windows Shell of User Account

App-V client uses a separate process called AppVShNotify.exe during integration of a package to send notifications to the Windows Shell. For example, the Windows Shell requires applications (here, App-V Integration) to notify the Shell when a new shortcut on user’s desktop is created. When the Shell receives this notification, it refreshes the user’s desktop display. The AppVShNotify.exe process runs under the user account. It will be started when the first package for the user is published and will keep running until user logs out.

Dynamic Configuration Files

App-V uses dynamic configuration files to provide customizations to the virtual package since the package itself is not editable. These configuration files can be used to alter behavior of integration subsystems such as adding or editing a new shortcut.

These configuration files can be used to:

· Enable or disable integration subsystems. When a subsystem gets disabled, its EPs will not be integrated

· Provide extra configuration for integration subsystems (see COM subsystem below for an example)

· Replace EPs of subsystems

Important:

When a configuration file includes EPs of a subsystem, these extensions will replace all EPs defined in the package manifest. To edit or remove a single EP (e.g. a shortcut), all the EPs belonging to that subsystem should be copied first from the manifest and the EP in question edited or removed.

There are two types of configuration files:

· Dynamic User Configuration (DUC)

• Configure the package for an individual user
  • E.g. add a new shortcut specific to the user to whom the package is being published
• If a Dynamic Deployment Configuration (DDC) exist for the package, DUC replaces “User Configuration” section during integration

· Dynamic Deployment Configuration (DDC)

• Configure the package for global publishing or user publishingon that machine
  • E.g. add a new shortcut for all users that get the package

o Can have a “User Configuration” section which can be overridden by DUC

The App-V Sequencer generates sample DUC and DDC files for each package to ease creation or modification of these documents. It uses EPs from the package manifest to prepopulate them.

Example Integration Scenarios

Let’s examine the example scenarios below using sample files to understand what happens during publishing. First, let’s introduce sample files:

When package is published to a user

· If no DDC or DUC provided during publishing, Shortcut 1 and Shortcut 2 are integrated

· If DDC is provided, only Shortcut 3 is integrated

· If DUC is provided, only Shortcut 4 is integrated

· If both DDC and DUC are provided, only Shortcut 4 is integrated

When package is published globally

In global publishing a DUC cannot be provided. So the scenarios become simpler

· If no DDC provided during publishing, Shortcut 1 and Shortcut 2 are integrated

· If DDC is provided, only Shortcut 3 is integrated

App-V client PowerShell Cmdlets and Integration

Below are the PowerShell cmdlets that are relevant to integration. See App-V 5.0 Client PowerShell Deep Dive for further details.

Add-AppVClientPackage <path to package> [- DynamicDeploymentConfiguration <path to file>]

o No integration of the extension points from the package is done

o Dynamic Deployment Configuration is optional

Publish-AppVClientPackage [- DynamicUserConfigurationPath <path to file>] [-Global]

o Package gets integrated

o Dynamic User Configuration is optional

o If Dynamic Deployment Configuration was provided to Add-AppvClientPackage, and/or Dynamic User Configuration is provided to Publish-AppvClientPackage, they will be used during integration

Unpublish-AppVClientPackage [-Global]

o Package gets de-integrated

o If Dynamic Deployment Configuration and/or Dynamic User Configuration was provided, they will be used during de-integration

Remove-AppVClientPackage

o If package is published globally: The package gets de-integrated immediately if not de-integrated before (by an Unpublish-App-VClientPackage)

o If package is published for user: The package gets de-integrated immediately if the user is logged on or next time the user logs on

Repair-AppVClientPackage [- Extensions] [-Global]

o If “Extensions” flag is provided, or if “-UserState” not provided, the package gets re-integrated, effectively repairing all extension points

Integration Subsystems

Following are the integration subsystems currently supported by App-V as of 5.0.

Shortcut Subsystem

Shortcuts are one of the main mechanisms by which a user can launch an application. The Shortcuts subsystem captures shortcuts that were created during installation. During publishing of a package, these shortcuts are recreated.

Note: For information about shortcuts, Shell Links on MSDN.

This is the only file-based integration subsystem that exists in App-V 5.0.

Manifest Example:

FTA Subsystem

This subsystem allows file extensions to be associated with applications.

· FTAs usually associates a file extension to a ProgID

o Ex: .docx => Word.Document.12

· The ProgID for an FTA will usually have a shell command to execute

o Word.Document.12 \ shell \ Open \ command \ <Path to Winword.exe>

Notes:

1. As of App-V 5.0, the only supported shell extensions are:

a. Preview Handler

b. Icon Handler (partially)

2. For more information about FTAs, see File Types and File Associations on MSDN.

This is a registry-based integration subsystem.

Manifest Example

COM Subsystem

App-V has two subsystems to provide support for COM objects in a virtual application package.

· COM integration: Responsible for integration of COM objects, TypeLibs, etc. from the virtual application package to the native operating system. This is an integration subsystem and is covered in this document.

· COM virtualization: Isolation of COM objects when the virtual application is launched. This is a virtualization subsystem and is not covered in this document.

COM Integration

Com integration subsystem is responsible for integrating registration of COM objects from the App-V package. These registrations are captured during sequencing and are integrated during publishing.

Note: For more information about COM, see Component Object Model (COM) and COM Registry Keyson MSDN

This subsystem supports two types of registration:

· Out-of-process COM registration

· In-process COM registration

Note: Virtualization of In-process COM objects are not supported by the App-V 5.0 client and thus it is not guaranteed that such objects will function properly.

COM Modes

COM support in App-V can be configured using dynamic configuration files. These files provide a “COM Mode” setting that alters the behavior of the two COM subsystems (integration and virtualization)

The possible values for the “COM Mode” are:

· Off

· Isolated (default)

· Integrated

o Out-of-process registration (OOP)

o In-process registration (IP)

Renaming: Mechanism used by virtualization subsystems to “hide” named objects of the package (such as COM) from native applications by modifying the name of these objects

Sample Dynamic User Configuration

Software Clients Subsystem

Allows virtual applications register to the software client list of the native operating system. This in turn allows actual users of the virtual applications to set default programs for certain tasks.

To set the default programs, a user can follow these steps: Control Panel > Default Programs > Set program access and computer defaults

Used for the following types:

· Email (MAPI)

· Instant messenger

· Media player

· Virtual machine for Java

Note: For more information, see How to Register an Internet Browser or Email Client with the Windows Start Menu on MSDN

Manifest Example

 <SoftwareClients Enabled="true">

Application Capabilities Subsystem

This subsystem exposes the capabilities of virtual applications to the native operating system. Users can use these capabilities to set default programs by: Control Panel > Set Default Programs.

Notes:

1. As of App-V client 5.0 this subsystem is integrated only when package is published globally

2. For more information, see Set Program Access and Computer Defaults (SPAD) on MSDN

URL Protocol Handler Subsystem

This subsystem exposes the URL protocol handing capability (such as “mailto:”) of an application to native operating system

Note: For more information about URL protocol handlers, see Registering an Application to a URI Scheme on MSDN

Manifest Example

App Path Subsystem

This subsystem exposes the App Path registration of a virtual application to the native operating system. Using this registration, the operating system can find the application’s executable. This feature is usually used by an application to avoid modifying the system PATH environment variable.

For example: When this registration is done, the user can start an application by providing the application name. To launch Microsoft Office Word one can:

· Start “Run” dialog

· Type Winword

Note: For more information, see Application Registrationon MSDN

Manifest Example

Virtual Applications Subsystem

This subsystem provides a list of applications captured during sequencing. This list is usually consumed by other App-V components. Also, using dynamic configuration files, integration of EPs belonging to a particular application can be disabled. For example, if a package contains two applications, it is possible to disable all EPs belonging to one application, to only allow integration of EPs of the other application.

Manifest Example

</Applications>