Consideration before XenApp6 installation

Unattended Installation and Configuration

Unattended installation can be performed using the following files:

• XENAPPSETUPCONSOLE.EXE
• XENAPPCONFIGCONSOLE.EXE

Hardware Requirements

Hardware requirements include:

• 64-bit CPU
• 512MB RAM (minimum)
• 32GB disk space (minimum)
• 6MB to 120MB for Web Interface plus 3.5MB for each site

Software Requirements

XenApp must be installed on a Windows Server 2008 R2 operating system (64-bit)

XenApp components such as the Delivery Services Console and Web Interface can be installed on additional operating systems

XenApp Configuration Options

During XenApp configuration, administrators select options for XenApp components and features

Which Farm or Zones Will Be Used in the  Environment?

A farm:

• Can be managed as a single entity
• Use a single data store database
• Can balance load among server in the farm Zones:
• Are a logical grouping of servers within a farm
• Are typically based on geographic location

Which License Server Will Be Used for the Server Farm?

A License Server:

• Can be installed before, during or after the XenApp installation
• Can be installed on a dedicated server or a server that provides additional functionality

Which Database Engine Will Be Used for the Data Store Database?

The following database software can be used for the XenApp data store:

• Microsoft SQL Server Express 2005
• Microsoft SQL Server Express 2008
• Microsoft SQL Server 2005
• Microsoft SQL Server 2008
• Oracle 11g R2

Will Shadowing Be Enabled?

Shadowing allows authorized users to view and interact with user sessions

• The default shadowing sessions are recommended for most farms
• If shadowing is prohibited during the XenApp installation, it cannot be enabled without reinstalling XenApp

On Which Port Will the Citrix XML Service Run?

The Citrix XML Service:

Communicates the least busy server and names of published resources

• Uses port 80, by default
• Can share port 80 with IIS
• Can be set to use a port other than port 80

When Will Users Be Added to the Local Remote Desktop Users Group?

Users can be added before or after XenApp installation.

Options include:

• Add the authenticated users
• Add the list of users from the Users group
• Add anonymous users

Which Pass-through Client Will Be Used in the Environment?

The pass-through client:

• Gives users of older, less feature-rich clients access to the features of the Citrix online plug-in
• Allows users to access their published applications through a XenApp Services site

Will Pass-through Authentication Be Used in the Environment?

Pass-through authentication:

• Authenticates a user to XenApp using the credentials used to log on to Windows
• Can be enabled during installation
• Requires the plug-in to be reinstalled on a server, if passthrough authentication is enabled after the XenApp installation

Will Information in the Data Store and Configuration Logging Databases Be Protected with IMA Encryption?

IMA encryption:

• Can encrypt the credentials of the data store and configuration logging databases
• Must be enabled on all XenApp servers if it will be used
• Can be enabled using the CTXKEYTOOL command 

          Eg:   ctxkeytool [generate | load | newkey | backup] filepath

                  ctxkeytool [enable | disable | query]

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.

Understanding How Memory is managed in VMware

How memory is allocated to a virtual machine?

When we create a new virtual machine through vsphere client the wizard asks us how much memory the virtual machine should have

The amount of memory we allocate on this screen is the amount of the guest operating system will see.

Example:. Assume we have given 1 GB of memory to virtual machine. the virtual machine will never able to use more than 1 GB.

Let us assume 4 GB of physical RAM avail to run the virtual machine.

Requirements: Need to create the 4 virtual machine with 1 GB RAM each.

First virtual machine will run with 1GB and leaving the 3GB to the other virtual machines

After  configured  3 more virtual machine with 1GB each. Upto now all the machines will run as normal.

What happens when we launch a fifth machine ? will it run ?  The answer is yes.

There are 3 technologies used to manage the memory.They are

• Idle page reclamation
• Transparent page sharing
• Balloon driver

Idle page reclamation:

Using this technology, ESX/ESXi will reclaim memory pages that are not being actively used by the virtual machine, clean-up the reclaimed pages and reallocate those memory pages to the other virtual machines.

Transparent page sharing:

In this technology, where the identical memory pages are shared among virtual machines to reduce the total number of memory pages need.

Balloon driver:

This driver will comes with VMware Tools. In this technology the driver forces a VM to use less memory than its configured maximum. The balloon driver requests memory from the guest operating system within virtual machine and then passes that memory back to the hyper-visor for use by other virtual machine

How Balloon driver works?

This driver is a part of the vmware Tools, It is a guest operating system specific driver, meaning that Linux VM’s would have a Linux-based balloon driver, Windows VMs would have a Windows-based balloon driver, and so.

When the ESX/ESXi host is running low on physical memory, the hyper-visor will signal the balloon driver to grow. To do this the balloon driver will request memory from the guest operating system. This causes the balloon driver’s memory footprint to grow. The memory that is granted to the balloon driver is then passed back to the hyper-visor. The hyper-visor can use these memory pages to  supply memory for the other virtual machines, which reducing the need to swap and minimizing the performance impact of the memory. When the memory pressure on the host get cleared, the balloon driver will return memory to the guest operating system.

Controlling Memory Allocation

ESX/ESXi provides some additional settings in the virtual machines configuration that affect memory allocation and memory management..On the Resources tab of a virtual machine’s properties dialog box we can see three options for controlling how a virtual machine uses the memory assigned to it.

• Reservation
• Limit
• Shares

The following are the steps to edit the reservation, limit,or shares of a virtual machine

•  Use the vSphere Client to connect to a vCenter Server or directly to an ESX/ESXi 
• Scroll down through the inventory to find the virtual machine to be edited 
• Right click the virtual machine, and select the Edit Settings option 

• Click Resources tab
• On the Resources tab, select the CPU or Memory options from the Settings list on the left
• Adjust the Shares, Reservation and Limit values as needed

The memory reservation is optional settings for each virtual machine. The memory reservation amount specified on the Resouces tab of the virtual machine settings is the amount of actual, real physical memory that the ESX/ESXi host provide to this virtual machine for the virtual machine to power on..

The default is 0MB. 0 MB means the ESX/ESXi host does not have to provide the virtual machine with any physical memory.

 A virtual machine with a reservation is guaranteed the amount of RAM configured in its Reservation settings.

If ESX/ESXi host is not required to provide actual RAM to the virtual machine, then how the virtual machine get its memory? The answer is that it provides swap, or more specifically something called VMkernel swap

VMkernel swap is a file created when a virtual machine is powered on  with a .vswp extension. The pre-virtual machine swap files created by the VMkernel reside by default in the same data store location as the virtual machine’s configuration file and virtual disk files. By default this file will be equal to the size of the RAM that you configured the virtual machine.

Note: If the virtual machine configured with a reservation or a limit, the VMkernel swap file could differ.

Here you may get doubt.  Does a virtual machine will get all of its memory from swap when ESX/ESXi host RAM is available? NO. ESX/ESXi will attempt to provide each virtual machine with all the memory it request, upto the maximum amount configured for the virtual machine.

Example: A virtual machine configured with only 1GB of RAM cannot request more than 1GB of RAM. However when an ESX/ESXi host does not have enough RAM available to satisfy the memory needs of the virtual machines it is hosting. The technologies such as transparent page sharing, idle page reclamation and the balloon driver aren’t enough, the VMkernel is forces to page some of each virtual machine’s memory out to the individual virtual machine’s memory out to the individual virtual machine’s VMkernel swap file.

Did we can control how much of an individual virtual machine’s memory allocation can provided by swap and how much must be provided by real physical RAM? Yes. This is where a memory reservation comes into picture. By default a virtual machine has a memory reservation of 0MB, which means that potentially all of the virtual machine has a memory pages out to the VMkernel swap file if necessary.

 

Citrix Execution files and system Files and their uses

XenApp Architecture:

Citrix System Architecture:

.Exe Files

EncSvc.exe (Citrix Encryption Service)

Enables secure communication with RC5 128-bit encryption between XenApp Plug-ins and XenApp. This service depend on Windows Management Instrumentation Driver Extensions.

SemsService.exe Citrix EUEM (End User Experienceing Monitoring)

Collects and collates end-user experience measurements.

Citrix Licensing (Performance – mflicperf.dll)

Performance counter DLL that must be registered for Perf Mon 

CtxSFOSvc.exe (Citrix Virtual Memory Optimization)

Dynamically optimizes applications running on a XenApp server to free up server memory.

HCAService.exe (CitrixHealthMon – Health Monitoring and Recovery)

Provides health monitoring and recovery services in the event problems occur.This service depend on Citrix Independent Management Architecture service, Terminal Services

CitrixICA (Performance – icaperf.dll)

Performance counter DLL that must be registered for Perf Mon

CtxWMISvc.exe (Citrix WMI Service)

Provides the Citrix WMI classes for information and management purposes.

This service depend on  the below listed services

• Citrix Independent Management Architecture service
• Citrix Services Manager service
• IPsec Policy Agent
• Remote Procedure Call (RPC)
• TCP/IP Protocol Driver
• Windows Management Instrumentation Driver Extensions

XTE.exe (Citrix XTE Server – Session Reliability)

Services network requests for session reliability and SSL from XenApp components.

CdfSvc.exe (Diagnostic Facility COM Server)

Manages and controls diagnostic trace sessions, which are used to diagnose problems on a XenApp server.This service depends on Remote Procedure Call (RPC)

Cpsvc.exe (Citrix Print Manager Service)

Manages the creation of printers and driver usage within XenApp sessions.

This service supports the Citrix Universal Printing features. This service depends on Print Spooler, Remote Procedure Call (RPC)

ctxcpubal.exe(Citrix CPU Utilization Mgmt/Resource Mgmt)
One of the services for the CPU Utilization Management feature.
Manages resource consumption to enforce entitlement policies. This service depends on RPC

RadeSvc..exe (Citrix Streaming Server)

Manages the XenApp Plug-in for Streamed Apps when streaming applications. This service depends on RPC

Ctxxmlss.exe ( Ctxhttp, XML Service)

Services XML data requests sent by XenApp components

ImaAdvanceServer.exe (Citrix Server Manager, interface to OS)

Provides XenApp with an interface to the operating system. Other services use this services to perform elevated operations.

Imasrv.exe (ImaService, management service)

Mfcom.exe (COM access to Citrix farm)

.Sys Files 

Ctxpidmn.sys (Sandbox Main Driver)

Ctxrmpn.sys (RM Process Notification Driver)

CtxSbx.sys (Sandbox Filter Driver)

Ctxsmcdrv.sys (SMC Support Driver – Session Monitoring and Control)

Icacdd.sys (ICA TW Miniport)

Icareduc.sys (ICA Reduction Driver)

Pdcomp.sys (Compression Protocol Driver)

Pdcrypt1.sys (Encryption Protocol Driver)

Pdcrypt2.sys (Encryption 128 bit Protocol Driver)

Pdrframe.sys (Frame Protocol Drv for Reliable Transport)

Twexport.sys (Thinwire Support Driver)

Wdica.sys (ICA WinStation Driver)

Ctxaltstr.sys (SFO Alternate Stream Driver)

Processes in all Sessions in a server

Session 0

• ImaAdvanceServer.exe
• Mfcom.exe
• Radesvc.exe
• Cdfsvc.exe (Diagnostic Facility COM Server)
• Cdmsvc.exe (Client Mapping)
• Encsvc.exe (Encryption)
• Hcaservice.exe (HCA)
• Cpsvc.exe (Client Printer)
• Ctxxmlss.exe (XML)
• Imasrv.exe (IMA)
• XTE.exe

Session 1

• Radeobj.exe (App Streaming)
• Pnamain.exe (PNA)
• Ssonsrv.exe (Pass-through Authentication)
• Wfshell.exe
• Java

Session n

• Wfshell.exe

Citirx Licensing Concepts

Licensing Communication

An administrator must perform the following tasks for a license server to accept connection and license requests:

• Add a license file to the license server
• Configure the farm to use a specific license server

License Communication Process

The following steps describe the licensing communication process for checking out a license for a client device:

1. A user connects to Farm A.
2. A server in Farm A requests a license from License Server 1.
3. License Server 1 grants the requests and checks out a license for the client device.
4. The same users connects to Farm B.
5. A server in Farm B requests a license from License Server 1.
6. License Server 1 grants the requests and uses the existing license for the client device.

License Types

XenApp uses concurrent user licenses, which are licenses that are not tied to specific users.

When a server requests a license, it is reserved for a specific client device/user combination. When the user logs off from the session, the license is returned to the license pool and made available for another user. Users connecting from multiple devices will consume multiple licenses.

Microsoft Remote Desktop Services

XenApp extends the functionality of Microsoft Remote Desktop Services (formerly Terminal Services), which is a presentation virtualization platform for Windows Server.

XenApp 6 leverages Windows Server 2008 R2 security enhancements and Remote Desktop Services architecture to add dimensions of flexibility, manageability, security and Performance.

Remote Desktop Licensing

Administrators must configure a Remote Desktop Licensing server in the environment to distribute Remote Desktop licenses.

To avoid adding the Remote Desktop Licensing server to each new Remote Desktop Services server that joins the domain, administrators can configure an Active Directory group policy to automatically assign the Remote Desktop Licensing server to each new server that joins the domain.

Additional Licensing Considerations

Include the following:

• Different connections can consume multiple licenses.
• Most application manufacturers require user licenses for their products 

License Administration Console

The License Administration Console is a required, web-based interface that allows an administrator to maintain the license server and manage license files for that license server.

The console can be used to perform the following actions:

• Tracking license usage
• Reporting on current license usage
• Configuring license alerts
• Configuring delegated administrators

Installing Licensing

It is a best practice to install the license server first. If licensing is installed after XenApp, a policy must be configured to point to the license server.

Licensing can exist on a separate server or can share a server with another component.

Uninstalling Licensing

An administrator may needto uninstall licensing for a variety of reasons, including moving the component to another system or renaming the system. Some of the files are not deleted, such as the license file.

When the license file is moved to a server with a different name from the current hostname, the license file must be returned to Citrix and exchanged for a license file that indicates the new server name.

License Server Considerations

Additional considerations include the following:

• XenApp does not need to be on the same system as the license server.

• For fewer than 200 product servers, a shared license server is recommended

License File Management

License files store the company license information in a plain text format with authenticated content. Each license file can store information for one or more licenses; a license server can store one or more license files.

The license file is stored on a license server in the

%PROGRAMFILES%\CITRIX\LICENSING\MYFILES\ Directory

Subscription Advantage

Citrix products include a one-year membership to Subscription Advantage. This membership provides major releases minor releases and product update downloads through the MyCitrix web site. The membership includes email notifications concerning the account and new items available for members. Members can view, update and obtain benefit information and privileges on MyCitrix at any time.

High Availability Considerations

A duplicate license server is one option for creating a backup license server. The backup license server must duplicate such essential information as the hostname and the server IP

address. This is especially important if the farm or servers are pointing to an IP address instead of the server name to resolve to the license server.

Additional License Server Processes

Additional License Server processes include:

• Enabling a replacement license server

• Connecting to a different license server

• Replacing the license server

License Server Clustering

Licensing provides administrators with a 30 day recovery grace period. To ensure high availability of the license server beyond the 30 day recovery grace period, licensing supports Microsoft clustering. Clustering the license server provides users with continuous access to applications in failure situations.