Symptoms

When shadowing a published desktop with a resolution greater than or equal to 1280×1024, the session of the user who is shadowing might terminate when the ICA session Window is resized. A dialog box stating “Virtual Driver error” error message might also be displayed to the user.

Cause

The client disconnects because it cannot accept the value of Thinwire Cache Power proposed by the server because the value exceeds the default limits of the client.

Resolution

You need to increase the value for the Thinwire Cache Power.

Warning!!!: Using the Registry Editor incorrectly can cause serious issues with the operating system that might require you to reinstall the operating system. Citrix does not guarantee that the issues resulting from the incorrect use of Registry Editor can be resolved. Use the Registry Editor at your own risk. Ensure that you make a backup of the registry before you edit it.

On the endpoint of the user who is shadowing, create the Tw2CachePower value under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Thinwire3.0

The following are the details of the registry key:

Even though the maximum value specified for Tw2CachePower is 25, a value of 24 covers most scenarios. The client device must be able to allocate the memory of 2^24 bytes, if cache power of 24 is used.

If you are shadowing from a XenApp 6 published Desktop, then you need to add the Tw2CachePower value under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Thinwire3.0

Citrix have released Virtual Driver Channel tool for XenApp and XenDesktop environments.

Description

This tool provides the ability to pass the end client information to a XenApp application in XenApp / XenDesktop environments. The tool creates a virtual channel between a XenDesktop VDA and a XenApp server session. The virtual channel driver on the VDA monitors the status of client connections and sends notifications when a client connects or disconnects to the VDA. XenApp applications can use provided APIs to collect end client information or status.

Prerequisites

Install an ICA client before installing VDCLNTINFO.msi on the XenDesktop client. The current release of the vdclntinfo setup does not have dependency checking, and requires the ICA client to be installed first.

Installing Virtual Driver Channel

Install an ICA client before installing VDCLNTINFO.msi. Install VDCLNTINFO.msi. Kill wfcrun32.exe if it is running.

How to Test Virtual Driver Channel

To Verify that it is working: Copy ctxclntinfo.exe to a XenApp Server. Connect to a XenDesktop that has VDCLNTINO.msi installed. Launch a XenApp CMD session or a published desktop from the XenDesktop VDA. Run ctxclntinfo.exe. It should output the client name and IP address. Run ctxclntinfo.exe /loop. It will wait on client connect/disconnect notifications. You can now disconnect from the VDA and reconnect to the VDA from a different client. The demo application outputs the new client information.

How To Use Virtual Driver Channel

See README.pdf for APIs associated with the tool.

Source

Download Virtual Driver Channel here

The long waited Citrix Branch Repeater 6.0 is out for download. Here is whats new in this release.

Release 6.0 is a major software release for the Citrix Branch Repeater. This release contains a number of new features along with bug fixes.

Release 6.0 is the first production release of the Branch Repeater 6.x software, which introduces traffic shaping, enhanced reporting, improved Windows Filesystem and Outlook/Exchange acceleration, and many other features.

Release Highlights

This major release of Repeater and Branch includes a significant number of new features, including:

• Smart Acceleration
  Now traffic can be prioritized based on a variety of different parameters including service class, protocol, QoS parameters, IP address or range, port, etc.  Applications are automatically detected and QoS features can be applied to all traffic including unaccelerated protocols like UDP.

• Extensive Reporting on WAN Bandwidth Utilization
  Repeater administrators will have a vastly improved view into WAN operations and bandwidth utilization with several new dashboards and graphs.
• ICA Prioritization based on Desktop Group or Published Apps
  XenDesktop and XenApp administrators can prioritize traffic on a WAN link based on an individual’s desktop group or a specific XenApp published application.
• Over 500 Pre-Defined Service Classes
  Repeater and Branch Repeater 6.0 includes and automatically detects over 500 pre-defined applications on the WAN.  Priorities can be assigned to the pre-defined service classes so unintended traffic like games can be given very low priority or blocked.
• And Many More Features
  Support for new features in the next releases of XenDesktop and XenApp, new printing acceleration enhancements, SMB2 and encrypted MAPI acceleration, acceleration for Outlook and Exchange 2010 and support for the Citrix License Server.

New Features in Release 6.0

• Traffic shaping which expedites WAN traffic according to user-selectable policies. Both accelerated and non-accelerated traffic are shaped to give full control over the link. Traffic shaping replaces the “Repeater QoS” feature.
• Traffic classification and reporting give greater visibility into WAN traffic. • Multi-stream ICA support provides a better user experience for XenApp and XenDesktop by combining acceleration with enhanced traffic shaping.
• Vista/Windows 7/Windows Server 2008 Filesystem acceleration. New SMB2 accel- eration features increase remote filesystem performance.
• Windows filesystem acceleration. Signed SMB can now be accelerated.
• Enhanced MAPI Acceleration. Encrypted connections between Outlook and Exchange Server can now be accelerated.
• Support for multiple links. In previous releases, Branch Repeater had a single-link model. Release 6.0 supports up to ten independent links, each with its own link speed, so traffic can be shaped precisely on every link.
• Remote license server support. Release 6.0 allows a remote network license server to supply the Branch Repeater licenses, simplifying deployment.
• Dashboard page provides a quick view of current system status.
• “Features” page. The product’s enable/disable toggles have been combined on a single page.
• Simplified menu structure. The number of top-level menu categories has been reduced. Entries within a category are now alphabetized. Similar functions have been combined into a single page, such as “Advanced Deployments,” which con- tains the functionality of the old high-availability, WCCP, group-mode, and proxy-mode pages.

Compatibility

Note: The Repeater Plug-in is not included with release 6.0 Plug-ins from prior releases will interoperate with Appliances running release 6.0

Note: Branch Repeater with Windows Server is not included in release 6.0 Branch Repeater with Windows Server Appliances from prior releases will interoperate with Appliances running release 6.0

Supported Products

Bellowed figure shows supported products and platforms for Citrix Branch Repeater

Supported Branch Repeater VPX Configurations

Release 6.0 is supported on Branch Repeater VPX running on both XenServer (5.5 and 5.6, but not 5.6 FP1) and VMware vSphere ESX/ESXi 4.1 hypervisors.

Note: The User’s Guide incorrectly states that VMware vSphere ESX 4.0 is supported. The correct list is “ESX 4.1 and ESXi 4.1.”

Note: The User’s Guide incorrectly states that the “Enable Bridging” feature is on the “System Status” page, when it is on the “Features” page.

RAM and vCPU requirements have increased with this release. See Figure 2 and Figure 3.

Licensing

Release 6.0 supports both remote license servers and locally installed licenses. If you are upgrading an existing system with a local license, it will continue to work.

Branch Repeater VPX supports two license types: remote and local licenses

• Production licenses use remote licenses hosted on a Citrix license server. Production licenses include retail, CSP, and annual licenses
• Non-production licenses (such as VPX Express and Eval licenses) are installed locally on the Branch Repeater VPX virtual appliance
• Annual and CSP licenses need to be installed on your license server

Sources (require MyCitrix ID)

Download Release notes for Citrix Branch Repeater 6.0 here

Download Quick Installation Guide for Citrix Branch Repeater 6.0 here

Download User Guide for Citrix Branch Repeater 6.0 here

Download Branch Repeater VPX for Citrix XenServer and VMware vSphere Software Release 6.0 here

Download Citrix Branch Repeater Appliance Software Release 6.0 here

Daniel Feller, Lead Architect at Citrix Systems and Dimitrios Samorgiannidis, Principal Consultant have created this great whitepaper – XenApp Planning Guide – Virtualization Best Practise.

Overview

Desktop virtualization comprises of many different types of virtual desktops. One option is to use a Hosted Shared Desktop model, which consists of a published desktop running on a Citrix XenApp server.

One of the goals when creating a design for Hosted Shared Desktops is to try and maximize scalability while still providing an adequate use experience. Hosted Shared Desktops provide an advantage over other desktop virtualization techniques by only requiring the use of a single operating system, which significantly reduces user resource requirements and helps improve scalability numbers.

However, in order to get the most users, making correct design decisions as to the resource allocation is important. Creating too many virtual machines or too few might negatively impact scalability.

This planning guide provides resource allocation recommendations for users running on a Hosted Shared Desktop on either Windows Server 2003 or Windows Server 2008.

Note: Even though these best practices are based on the Hosted Shared Desktop model, they are still relevant in a non-desktop model where users only connect to published applications without the desktop interface.

Guidelines

In general, when making the decision to virtualize XenApp servers, the main goal is to support the most number of users on a piece of hardware. However, other guidelines can also come into play that might not follow the approach that gives one the best scalability. Business structure, costs and operational items can also play an important role in selecting the most appropriate virtualization strategy for XenApp.

Operating System Scalability

Physical servers have continued to expand with more processor cores and RAM, but many older operating systems, like Windows Server 2003, are not able to take full advantage of these improvements. There are some options that can be used to try and extend the scalability of the system, like using the /PAE option for Windows 2003. Although these options do help increase scalability of a single server, they often do not provide enough value to fully utilize a server.

Virtualizing Windows Server 2003 with XenApp will often allow a greater number of user sessions on the hardware. However, creating too many virtual servers requires more operating system installations, which uses system resources while creating too few virtual servers could also result in wasted resources as the operating system is unable to scale.

In order to create a proper, scalable, virtualized XenApp solution, there must be a balance between the number of virtual machines and virtual machine specifications.

Operations

More virtual servers often mean more management activities. This can be a deciding factor when determining if more or less virtual machines are needed. For example, if ten servers are to host six virtual servers instead of four, that yields 20 more servers to manage, maintain, troubleshoot and support.

However, if single image management solutions, like Citrix Provisioning Services, are used, the operational aspects of managing more virtual server instances becomes irrelevant as all of the virtual servers are based on a single master image.

Application Requirements

Applications influence how a server should be virtualized based on the application characteristics and user activity.

• Resource Requirements: Certain applications have a bigger impact on CPU while other on RAM. The application characteristics plays an important role when determining how many vCPUs to allocate or how much RAM to assign, assuming these requirements don’t go beyond the maximum limitations of the operating system.
• User Activity: In many implementations, organizations silo or create separate XenApp servers to host different applications. Silos have a direct impact on resources allocated to a virtual server. If the server contains a set of applications that are rarely utilized, it would make sense to create smaller virtual machines as opposed to a virtual server instance expected to host many more users.

The virtual machine specifications must align with the requirements of the application set and expected usage.

Flexibility

Many organizations virtualizing XenApp servers opt for live migration functionality, where a virtual machine can jump from one host to another without impacting active user sessions. This is especially useful when scheduled maintenance is needed on a host or an organization wishes to reduce power consumption by shutting down hosts after hours. Simply shutting down the virtual machine will most likely impact the few remaining XenApp sessions still active, which is why some organizations utilize live migration capabilities. However, the size of a virtual machine can potentially limit flexibility.

When all things are equal, smaller virtual machines provide greater levels of flexibility, especially from a virtual machine placement perspective. For example, it is often easier to move 4 virtual servers (4 vCPU and 8GB of RAM each) than it is to move a single, large virtual machine (16 vCPUs with 32 GB of RAM). In order to successfully migrate a virtual server, the new host must have enough available resources to support the virtual machine. This is much easier when the virtual machine resource allocations are smaller.

When looking at large footprint virtual machines, smaller provides greater flexibility. If this level of flexibility is not required, larger virtual machines are optimal as fewer resources are used for additional operating systems.

Licensing Costs

Microsoft licensing is very explicit in stating how many licenses are required for physical/virtual servers

• Windows Server 2003/2008 Standard: Each license provides one physical server and one virtual server, although standard is limited to four physical processors.
• Windows Server 2003/2008 Enterprise: Each license provides one physical server and four virtual servers, although Enterprise is limited to eight physical processors.
• Windows Server 2003/2008 Datacenter: A Datacenter license is required for every processor on the physical server, and allows for any number of virtual servers.

The costs associated with licensing the Windows Server operating system can play a role in determining how many virtual machines are created. As an example, would it be better, from a licensing standpoint, to create 4 virtual machines with 6 vCPU or 6 virtual machines with 4 vCPU assuming scalability is similar? The four virtual machine model would result in fewer required Microsoft licenses, which will help keep the costs lower.

In addition, using a feature like XenMotion, Live Migration or vMotion can also impact licensing. The Standard and Enterprise licenses for virtual machines are tied to the physical server. If the virtual machine on one Enterprise server is migrated to another physical server, the new physical server must have enough licenses to support another VM as well as its current virtual machine load.

Note: Calculating licensing costs and requirements can be done by utilizing the Windows Server Virtualization Calculators (http://www.microsoft.com/windowsserver2008/en/us/hyperv-calculators.aspx).

Planning

For most organizations, the overall goal is to get the greatest user density from a physical hardware configuration without impacting the user experience. Based on production deployments, numerous case studies and taking into account the guidelines mentioned earlier within this document, the following are the initial recommendations for virtual machine configuration for XenApp.

Note 1: For the Windows 2003 (32bit) configuration, additional VMs with fewer vCPUs should be utilized if RAM reaches a bottleneck before vCPU.

Note 2: The 32-bit operating system can utilize more than 4GB of RAM if the /PAE option is invoked. This can potentially reduce the number of virtual machines, but results are mixed.

Note 3: Page file estimates are typically either 1X or 1.5X RAM for 32bit servers. For 64bit, the same formula can be used, but this will most likely result in an excessively large pagefile size. For 64bit servers, it is best to monitor the server and following Microsoft page file recommendations (http://support.microsoft.com/kb/2021748/en- us?sd=rss&spid=12925).

Note 4: The 64-bit operating system specifications assume there is a need for flexibility with live migration capabilities. Larger virtual machines are also valid if flexibility is not a requirement.

Regardless of the VM allocation decisions made, the following are general recommendations that are almost always advisable when virtualizing XenApp servers

Note this document apply to XenApp 6.5, 6, 5, 4.5

Citrix have released a new cool tool thats is called KeepMeLoggedIn Tool

Description

KeepMeLoggedIn allows a user to quickly open published applications by leveraging session sharing. KeepMeLoggedIn keeps a user session opened after the last user process exits; it then exits when the timeout value expires causing the user session to close.

If a new application launches while KeepMeLoggedIn is still running, session sharing kicks in and the launched application should open quickly on the client machine (by avoiding opening a new session and re-using the existing user session).

KeepMeLoggedIn does not have any visible window and only works for ICA seamless sessions. It exits automatically if the session is an ICA published desktop or an RDP session.

Prerequisites

Microsoft Visual C++ 2010 Redistributable Package (x86) must be installed on the XenApp server prior to using KeepMeLoggedIn:http://www.microsoft.com/downloads/en/details.aspx?familyid=A7B7A05E-6DE6-4D3A-A423-37BF0912DB84&displaylang=en.

Installing KeepMeLoggedIn

For Windows 2008 and Windows 2008 R2:

Copy KeepMeLoggedIn.exe to C:\Users\Public\ and modify the registry key below as follows:

Caution! This fix requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use the Registry Editor at your own risk. Be sure to back up the registry before you edit it.

Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Type: REG_SZ
Value: Userinit = C:\Windows\system32\userinit.exe,c:\Users\Public\KeepMeLoggedIn.exe

For Windows 2003:

Copy KeepMeLoggedIn.exe to C:\Document and Settings\ All Users\ and modify the registry key below as follows:

Caution! This fix requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use the Registry Editor at your own risk. Be sure to back up the registry before you edit it.

Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Type: REG_SZ
Value: Userinit = C:\Windows\system32\userinit.exe,”C:\Document and Settings\ All Users\KeepMeLoggedIn.exe”

How to use KeepMeLoggedIn

KeepMeLoggedIn has a default timeout value of 120 seconds, that is, it exits two minutes after the last process in the user session was closed.

A local administrator of the XenApp server can configure this timeout value by setting the following registry key:

Caution! This fix requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use the Registry Editor at your own risk. Be sure to back up the registry before you edit it.

For 32bit:

Name: HKEY_LOCAL_MACHINE\Software\Citrix\KeepMeLoggedIn
Type: REG_DWORD
Value: Timeout = time in seconds (decimal value)

For 64bit:

Name: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\KeepMeLoggedIn
Type: REG_DWORD
Value: Timeout = time in seconds (decimal value)

For example, a timeout value of 3600 (decimal) keeps the session open for one hour after the last process was closed by the user.

KeepMeLoggedIn also supports the LogoffCheckSysModules registry key described in CTX891671 – Graceful Logoff from a Published Application Renders the Session in Active State in order to exclude some processes from being monitored.

Follow the guidelines in the above article while adding a process to this list.

Note: Do not rename KeepMeLoggedIn.exe or if you do, add the new executable name to the LogoffCheckSysModules registry key described above.

Download KeepMeLoggedIn
You can download KeepMeLoggedIn Tool by clicking here