By: Andy Paul One of the often overlooked features of XenApp is truly understanding the load evaluators. As a consultant, I commonly see environments using only the Default Load Evaluator. If I am lucky, they might be using the Advanced Load Evaluator. Rarely do I find organizations actively monitoring or customizing their load evaluators.
Load Evaluators have not changed much since Presentation Server days, but amazingly they are not commonly optimized. Every environment and every workload is different, so whichever load evaluator is implemented may vary, but they should be customized and monitored.
Here is a screen shot of the XenApp 6 Advanced Load Evaluator, which is now the default assignment. It creates a load based on CPU Utilization, Load Throttling, Memory Usage and Page Swaps. The Default Load Evaluator (assigned by default in XenApp 5 and prior versions) measures Server User Load.
I generally recommend creating a custom load evaluator based on resources, usually CPU Utilization, Load Throttling, Memory Usage and possibly Server User Load. This way, I can spread the load across servers based on number of users, resource loads and help prevent login storms.
Understanding Loads
But assigning a Load Evaluator is only part of the battle. You must also understand what and how that load is calculated. A simple QFARM /LOAD will show you server loads (or QFARM /LTLOAD to see the server resource load without calculating Load Throttling.) However, if you are using a load evaluator with multiple components, what is causing the load? The base algorithm for establishing actual load is Highest_Load + (Average_Other_Loads * .1).
Assuming you have a load evaluator monitoring CPU Utilization, Memory Usage and Load Throttling, and you see a server with a 7800 load value, it may be dangerously close to 10000 (Full Load) since that 7800 is not the aggregate of all loads, but reflective of the highest load, which could be close to reporting full. In this case, perhaps that server is running at 78% Memory Usage, with a cap set to 80% in the load evaluator… one more process may send it over the edge.
Detailed Load Monitoring
So what can you do about it? Knowing your environment is key, as is monitoring actual loads and adjusting evaluators or adding capacity as necessary. To this end, you can run real-time analysis of the various components of a load evaluator using the QUERYDS tool from Citrix. Additional information is available under CTX112082. These were originally published for Presentation Server 4.0, but are still valid for all editions, including XenApp 6. Please note, the output from QUERYDS will be hex values, and will need to be converted. Most applications include a Hex-Decimal conversion function, or you can use a free online converter such as http://easycalculation.com/hex-converter.php
The following table identifies the code values of the different load evaluator properties:
a -- Application User Load
2 -- Context Switches
1 -- CPU Utilization
7 -- Disk Data l/O
8 -- Disk Operations
9 -- IP Range
d -- Load Throttling
3 -- Memory Usage
4 -- Page Faults
6 -- Page Swaps
5 -- Scheduling
b -- Server User Load
Using this information, take the sample below; consisting of three servers:
Server TEST02 has a load of 1610 (HEX 64a). This load is comprised of:
Server User Load: 2 (b:2)
Load Throttling: 0 (d:0)
Memory Usage: 16 (3:10)
CPU Utilization: 0 (1:0)
These are percentages of 100, so a Memory Usage load of 16 is a load value of 1600. Load Throttling is not calculated since there is no current logon event. That leaves the average of Server User Load and CPU Utilization (200+0)/2*.1 = 10. This makes the total load value of 1610.
Conclusion
Now that you have a way to view the load components (QUERYDS) and an understanding on how to interpret the results, these values can be read and automated into a monitoring solution - either real-time or historical. Once a baseline is established, alerts can be generated as values approach full loads. Based on this information, you can then decide if you should modify your evaluators or add capacity.
By: David MerrellLast couple weeks I have been traveling back and forth to a client. During my trips I sat in the airport for several hours being bored and really did not want to break out the big 17 inch, 5 Pound laptop to get ahead of some work for a project I was working on. So I was needing something to help to accomplish this while waiting for my plane. The project I was working on was a XenDesktop, XenApp POC for a university in north Texas. My boss has an IPAD and was showing off the Citrix Receiver and Citrix Dazzle a few weeks earlier. I started thinking it would be nice to have a light weight easy to use tool to help me instead of the laptop. Next trip to Texas I picked up a 64 Gb IPAD. The sales guy was asking what I was going to use it for, I told him business mainly and of course he tried to sell me the 3G version. I figured I have an awesome HTC Touch Pro 2, Windows Mobile phone which acts as a wireless access point, so didn't need the 3G charge. Here is the scenario that I used the IPad as an administrator tool: I was able to remote into all the infrastructure servers using for the environment finish configuration using Desktop Connect. I was able to use the Citrix Receiver to connect to a published Citrix XenCenter to administer the XenServers. The Citrix Receiver also allowed me to test the published XenApp applications and desktops; it also allowed me to test the XenDestops. The IPad and the listed apps below is a great set of tools to allow me to provide better support to our customers and be more efficient on the projects I work on.
Here is a list of the apps and descriptions, I installed and use just for the purposes:
APP
Review
Desktop Connect
Desktop Connect is a fast, full-featured desktop viewer, optimized specifically for the IPad. View and control Windows, Mac OSX and Linux computers as if you were sitting in front of them, or observe others as if you were watching over their shoulder.
Desktop Connect is one of the best remote applications I have installed. As a systems administrator the RDP connection was easy to configure and use. The speed of the app is very efficient.
LogMeIn Ignition
One click on your iPad lets you remotely access one or more computers anywhere, anytime.
LogMeIn is a client based app that allows access to systems that may not have the ability to RDP or restricted by firewalls, I mainly use this app for my home network. This app provides another layer of security, it also was easy to setup and configure.
Citrix Receiver
Citrix Receiver for IPad is the perfect business solution for secure access to virtual desktops, applications and data.
As a Systems Engineer that works with XenDesktop, XenApp and XenServer setting up an administration group of apps and XenDesktop to support an environment the Citrix Receiver makes it easier to connect to tools such as the Citrix admin consoles.
Vtrace
Vtrace is a visual traceroute application that shows a list of the networks serves from your machine to a target ip address or hostname on a google map.
This application is a great visual traceroute program, it works well as a network troubleshooting app.
DNS Lookup Tool
DNS lookup tool to find A records, MX records, Name Servers and reverse DNS records for IP addresses and domains.
The description pretty much says it all. At the time of writing this article, this is only an IPhone up but works well with the IPad.
FreePing
FreePing is an ICMP Ping Application. It is designed to have a simple and intuitive user experience.
Again pretty much works as the description says, it also is only for the IPhone at the time of the writing.
Mocha Telnet Lite
Mocha Telnet provides access to servers via Telnet
This is a good tool to telnet to ports on servers to make sure all the necessary ports are accessible.
iXen
This App helps you administrate common tasks on virtual machines running on a Citrix XenServer.
The main functions of this app allow you to Boot, Shutdown, Suspend, Rest and Turn off virtual machines. This is a handy tool if you do not have access to the XenServer console.
By:Scott E. Lane
What exactly is application merchandising? It is a term that we will start hearing more and more about in the industry. Especially as desktop virtualization becomes more prevalent and application virtualization technologies continue to mature. We will also see more of a focus on this as companies start to leverage “bring your own PC initiatives”. This document is an overview of how Citrix and Microsoft are working together to enable easy, iTunes-like access to corporate issued applications that are delivered with different technologies. This News Article details a joint announcement between Citrix and Microsoft to extend the capabilities of Application Virtualization. This means that Citrix will add value to App-V in a similar manner to the way Citrix has for years added value to RDS or Terminal Services.
Overview
First off let me approach this from a very high level, and then I'll get specific about the moving pieces that make this all happen. Basically, you have three methods for placing applications inside of virtual desktops.
Install the applications directly onto the base vdisk image that comprises the virtual desktops. This is less attractive because each time an application requires updates, the vdisk requires updates. However, it does afford a very fast launch for the user when the application icon is clicked. We typically see this for core system apps like anti-virus and the Citrix Receiver Framework (more on that in a moment). We also see it sometimes for apps that everyone has, like Adobe Reader and the corporate MS Office Standard.
Stream the apps into the virtual desktop. This would be either XenApp streaming or MS App-V (hence the announcement). The bigger issue here is once we supply applications that aren't installed, how do we merchandise them to the users? I'll have more on that in a moment, but this is part of the bigger Citrix Microsoft partnership. The advantage of streaming these apps is that one vanilla desktop image can host a wide variety of applications for different user classes, depending upon who logs in. The application set dynamically assembles for the user upon logon to the VDI session. Additionally, even if you installed office into the base OS image, you can leverage streaming or application virtualization technologies for differing versions. For example, say you've standardized your company on Office 2007. But then someone says they have an old Access database on Office 97 and it won't convert. You can stream Access 97 to this user or group exclusively and it won't interfere with Office 07. This is true whether Office 07 is installed or streamed. We are able to do this because streaming, both in Citrix or MS App-V flavor places the application execution into isolation environments on the target. In this case the target being the virtual desktop. Management of streamed apps really helps with overall application delivery. That's because file shares, which Citrix calls App Hubs, hold single instance streaming profiles of each app to be delivered thru streaming. That means patching these apps doesn't require the VDI disk image to be modified. It also means that an app administrator can apply patches to the app image just once, replicate it to all "app hubs", and have the patch automatically be in place for all users. Application streaming can also enable offline usage of centralized apps. This is not pertinent to VDI approaches. But it is very useful for road warriors who carry laptops, and in the near future for our XenClient laptop hypervisor users.
XenApp hosted approach. You are most familiar with this one, as most Citrix customers deliver apps this way. Its the application running on a XenApp server and showing up on a target. But in VDI, the target for XenApp hosted application is the virtual desktop itself. The reasons why this is chosen for delivery in a VDI world are varied. One would be that you already have applications set up and tuned for delivery in this method, and that it makes sense to continue using XenApp infrastructures in this manner. Also, it depends on the data tier location. For example if the VDI infrastructure is in Kansas City but the application backend itself resides somewhere far away, it would make sense to deliver the application with a XenApp hosted infrastructure located at the remote location where the application resides. Additionally, there are sometimes resource intensive applications that will cut into your VDI session per hypervisor host scalability. These apps are sometimes better off being delivered from a XenApp server where their resource needs can be better managed while keeping balanced in the hypervisor silos.
Delivery Framework
Okay, now I've described 3, and really 4 methods for placing applications inside virtual desktops. The "install on vdisk" option is pretty self explanatory. But when we choose the other methods, we suddenly end up with a bunch of clients, client interfaces, and client updates. The user suddenly has different methods to get their apps depending on how they are delivered. That's where Citrix comes into a partnership again with Microsoft with two new technologies, Receiver and Dazzle.
Receiver is a client framework that you install on an endpoint, and in this case the base Vdisk of your VDI infrastructure. It is the "keeper of the clients" or what we now call plug-ins. Once receiver is in place it talks back to a virtual appliance, Merchandising Server.
Merchandising Server runs as a small footprint on a XenServer back in the datacenter. Administrators install the plug-ins there, and configure which plug-ins (versions) are to be used. When the user logs into their VDI session the Receiver checks with the Merchandising Server. If there is a newer version of say the ICA Client (now called the Plug-in for Hosted Apps), the new version is automatically downloaded and made available for the user in the VDI session. Same is true for the Citrix streaming client (now called the Citrix offline plug-in). We'll do other plug-ins too from the Citrix side including the Password Manager Agent and the Access Gateway Secure Access Client (which doesn't apply in VDI, but its great for laptop users again, and XenClient users in the future). But here's the MS and Citrix marriage again, we'll also deliver the App-V streaming client thru Receiver, so that it’s always kept up to date.
So now with of the plug-ins in place, we need one central place for users to get their apps. Typically users expect them to be on the Start Menu. But with so many varied ways to get applications into the virtual desktops, only the "hard installed into the vdisk" apps are showing in the Start menu. That's where Citrix Dazzle comes in. We call this delivery "merchandising" the applications, much like iTunes provides a self service store for music and video content. Dazzle is a self service store for application content.
Dazzle can be pushed out and managed thru, you guessed it, the Citrix Receiver and Merchandising Server. Once I open Dazzle, I can pick and choose from all of the apps being made available to me. The sources can be App-V, Citrix Streaming, or Citrix Hosted. If I'm a road warrior who uses a laptop or XenClient, I am told if the application is available for offline use, and I can choose appropriately. Once I select my apps, they appear in the start menu. The user can then put icons on the desktop if they wish. File type association works.
So there is one final piece to this simple puzzle. As you know, when I log off a VDI session, the pooled VM reboots and any changes made while the VM was running are thrown away. That means all of the icons for the apps that I selected, right? Not when profile management is in place. That's why Citrix has Profile Management. It’s a lot like roaming profiles, extending the base profile infrastructure that MS provides us. Profile Manager takes the user environment changes, like the desktop shortcuts and Start Menu changes, and migrates them off when the VDI session is logged off. When the user logs back in, perhaps to a completely different pooled VDI VM, the users profile settings are automatically applied. That means the icons are there for launch.
So what if I need a new app, and I go into Dazzle and can't find it? In future releases we will include application requesting. When a user requests an app it will set off a workflow to get the request reviewed, and ultimately fulfilled if appropriate.
So that's our vision, and after that explanation of how all of these pieces fit together, and what they do, where is Citrix with releasing these components. Here are the current releases, as of this writing, with the status of functionality.
Citrix Receiver
Currently available, version 1.1
App-V plug-in support is expected in future release
Receiver supports the following new plug-in releases:
Online plug-in 11.2 (XenApp Hosted)
Offline plug-in 5.2 (XenApp Streaming)
Service monitoring plug-in 5.1 (EdgeSight)
Secure access plug-in 4.6.1 (Access Gateway)
Dazzle Tech Preview
Communications plug-in 3.0 (EasyCall)
Profile Management plug-in 2.0
Citrix Merchandising Server
Currently available, version 1.2
Must run on a XenServer as a virtual appliance
Support for other hypervisor platforms expected in the future
Manages the setup of Citrix Receiver component that is running in VDI desktops and mobile endpoints
Enables "plug-ins" to support multiple types of delivery services
Centralizes management of all updates
Enables access to web-based user support services
Offers robust management reporting feature
Citrix Dazzle
Currently available, version 1.1
This is basically a Tech Preview version, I have noticed the following issues/workarounds:
This version is English only
Launching Dazzle invokes an animated splash screen which requires Windows Media. For quicker launches, especially in VDI situations, this splash screen can be disabled by simply renaming the windows media source file
This release doesn't inform users when certain streamed apps are not configured for their OS
Pass thru authentication is not available yet. However, users can choose to have their credentials saved for subsequent launches.
Receiver does not yet officially support App-V plug-ins, however, there is a documented way to deploy App-V plugins with the Merchandising Server. It is in tech preview right now. Dazzle can merchandise App-V apps, this being done as published content thru XenApp or a published app (which pulls the App-V package to the XenApp server and connects the user thru ICA). We will probably see more App-V options within the XenApp console itself in coming releases/feature packs.
Availability
So to answer a question you probably have by now, are we there yet? Well no, not quite. But I expect in the very near term we will have new releases. This announcement is nearly 7 months old now. I know we have made significant progress in these areas, as it is a VERY high priority. I also know that internally at Citrix we have all of this working. Check out the attached video; My colleague at Citrix proves this is not vaporware, and note this video was recorded 7 months ago.
Following Kurt’s steps, I have actually pieced it together in a lab. Nothing official here, but we could see a full release of Dazzle with XenApp6 (Project Parra). Who knows? We may see more details on App V delivery. I honestly don’t know myself, as I’m not in Product Management. But I can assure you this tight Microsoft integration is a very high priority for Citrix, and we can expect the missing pieces to be in place very quickly.
By:Andy Paul Overview
A growing trend in technology firms is Bring Your Own Computer (BYOC or BYOPC). Of course organizations such as Microsoft, Google, Citrix and Cisco are embracing this -- which is to be expected. However, as workforces become increasingly mobile, and virtualization methodologies are further adapted in enterprises, BYOC will inevitably grow.
In the simplest terms, Virtualization is about decoupling. In server virtualization (vSphere, XenServer, HyperV), we decouple the server OS from the server hardware. With application virtualization (XenApp, AppV), we decouple software programs from the OS. With SAN and NAS storage, we long ago decoupled data storage from operating machines. With the advent of client hypervisors, we will being doing the same with PCs. All of these pieces are decoupled to create a more robust and flexible infrastructure. It is only logical, then, to decouple the enterprise organization from the desktop machine itself.
How it Works: Although the exact details will vary for each organization, the policy should detail minimum requirements (supported Operating Systems, anti-virus, support, etc) in exchange for a set IT budget or allowance. Beyond the basic standards, the employees are then free to buy or upgrade a system of their choosing. Citrix's BYOC pilot program provides for a $2,100 stipend every 3 years with certain constraints. A link to their case study is provided at the end of this article.
Benefits
Employee Empowerment - Allowing users to select their own systems gives a sense of ownership. This aids in usability, support, and overall happiness. I know many IT employees who have better units at home than at the office and are sometimes frustrated by this. I've been in more than one environment where employees use their own equipment in addition, and sometimes in lieu of, corporate machines. This can support more than just power users, too. Apple enthusiasts can bring their MacBook Pro, Linux guys can get their Ubuntu on, even casual users can splurge on a new laptop bundle from Dell or HP. This allowance can also serve as an enticement for recruiting and retention.
Reduced Costs - By giving users their OWN systems, the users are more likely to understand and support their own equipment. With OEM provided service and warranties, it also effectively out sources desktop support. This allows the organization to focus on items such as infrastructure and security, less on daily break/fix and maintenance.
Flexibility - Users now have maximum flexibility for both professional and personal computing since they are one and the same. Being able to support BYOC also means being able to support a mobile workforce, so if someone is sick, they may be able to work effectively from home, thus maintaining company productivity.
Why Support BYOC Along with the benefits previously listed, BYOC may be necessary to support the following scenarios:
Mobile Workforce - due to the nature of a global economy and the current economic slowdowns, companies have benefited from a mobile workforce. This can reduce travel, relocation, and office expenses. It can also provide flexibility for the road warriors who are in the field or on client sites. Embracing this mobility creates an agile workforce.
Re-purpose old equipment - a common cost savings point for VDI in general is the ability to re-use or re-purpose aging and obsolete hardware. Maybe that old P3 with 1gb RAM won't run Windows 7 effectively. However, as long as it can run the necessary client-side tools, you can connect to a virtual image and upgrade without changing the client hardware.
Thin Client computing - other environments are ideal for thin client systems. Education, health care, manufacturing, to name a few industries, have already adopted thin clients as a way to reduce costs and standardize computing. These are commonly used for task workstations.
The infrastructure investment for BYOC supports these scenarios as well, allowing corporations to mix-and-match the end-points while maintaining a consistent computing environment. There's that flexibility again....
How to Do It There are multiple ways to provide that flexible, agile, decoupled delivery as part of a BYOC adoption. Here are the most common ways, no one method is necessarily better than another. It greatly depends on each environment, and most environments will provided multiple options.
Application Hosting - this is your basic Citrix XenApp (Presentation Server) or Terminal Services hosted application. The Applications run on central servers in a multi-user environment. This provides the greatest user-density and centralized administration but requires real-time connectivity.
Application Streaming - common with XenApp, AppV, and a myriad of other providers; application streaming allows deployment of applications from centralized reposity. Depending on the methods used, this may be available both online (connected) and offline (disconnected). This decentralized the operations but maintains a central point of administration.
Remote Desktop Services - is your classic Citrix or Terminal Services desktop. Instead of providing individual applications, an connection is made to the server desktop. From that central point, all availale applications can be accessed. This is generally used in a multi-user environment.
Virtual Desktop - similar to Remote Desktops, except Virtual Desktops are typically used on a one user per machine basis and is a common way to deploy Windows 7 or other PC-based operating systems from a common image. Applications can be locally installed or streamed to the desktop image.
Client-side Hypervisor - is a Type 1 or bare-metal hypervisor (such as VMware ESX or XenServer), but running on the client PC instead of a server. The advantage is to not only run multiple operating system, or even to have a personal and a work persona. The biggest advantage, in my mind, is to have a standard corporate image(s) which can be deployed and run locally.
Drawbacks Obviously, there are drawbacks, or everyone would have adopted this a long time ago! Some of the issues to address are:
Supporting Home Systems - once you allow users to buy/use their own systems, you are on the hook to support them. It will not matter if they have a 3 year, 24x7 4 Hour support contract, they will still expect YOU to solve their problems. Of course, instead of one manufacture/model/OS to support, you now are faced with hundreds. Policy may dictate they contact the OEM, but most likely, you will get called first. On top of that, what happens when they can't work at home... it become IT Support's problem.
Cost of Infrastructure - this is biggest hurdle most companies will face. A solid BYOC program requires that you can support and enforce whatever standards (such as anti-virus) have been put in place as well as being able to maintain the delivery architecture (secure remote access, application delivery, etc).
Security - the biggest risk is security. Not only anti-virus, but information security. Making sure that sensitive information and corporate secrets say secure. Granted, this is a concern for a normal network infrastructure, but even more so when you hand local system control to the end users. Nothing is 100% secure, but you better make sure your policies are clear and enforced.
By:Andy Paul
There are numerous benefits for running Citrix XenApp on XenServer; including single vendor support, built-in optimizations, and integration features. However, what if you are working in a VMWare ESX environment? As a consultant or an internal engineer, you cannot always dictate the virtualization environment. The following are some tried and true best practices for optimizing XenApp on VMWare ESX.
The key is Memory Sharing and how VMWare allows overallocation of resources as opposed to XenServer. A key to optimizing performance is to NOT over-allocate RAM, which will reduce memory sharing between guests. The memory sharing/de-duplication is a great feature for infrastructure servers, but application/terminal services can suffer faults from the shared memory. Of course, if it were that simple, everyone would do it. Along with avoiding overallocation, the OS and services should be optimized. Finally, you should consolidate/isolate your Terminal Services workloads to common hosts -- in other words, dedicate ESX Hosts to run only XenApp. This will optimize VMWare's native memory sharing as well as streamlining I/O.
OS Optimization
Create a master VMWare TEMPLATE for each flavor of OS and XenApp you plan to install
Align the drives - use DISKPART to create a 64k Partition, formatted using 32k allocation unit sizes
1 vCPU - assuming your application can run effectively in single CPU mode. Although there are many valid reasons to NOT do this, I recommend it because this reduces CPU %READY and CPU scheduling requirements by single threading the OS. Of course, if your app set requires multiple processors, or you risk pegging the single CPU, then this may not be an option.
2 GB RAM - this is a good starting point for baseline testing. Depending on the Host RAM and the app requirements, you may need to move this up or down accordingly.
Set Page File Min and Max at 1.5 x RAM
Installed latest VMTools, including the Memory Manager (aka the Balloon Driver)
Please note, there are a lot of recommendation to disable this, but I believe that to be a fallacy:
a lot of the information and recommendation out there is still based on ESX 2.x
The Balloon Driver is a safety net, which should not be normally called on when designed properly
when in doubt, and until proven otherwise, go with the standard package
Disconnect/Disable the CD Rom - Windows guests poll CD devices quite frequently. When multiple guests try to access the same physical CD drive, performance suffers. Disabling CD devices in virtual machines when they are not needed alleviates this.
Adjust the Disk timeout valie to the storage vendor's recommended: HKLM/SYSTEM/CurrentControlSet/Services/Disk/TimeoutValue = REG_DWORD Hex value 3c (60)
Disable Last Time Access Atrribute for NTFS, this setting that keeps track of the last time a file was accessed. Removing the necessity for the system to keep reading and writing this information may speed up performance. The command is: fsutil behavior set disablelastaccess 1
Services Optimization
Any and all services which are not needed should be DISABLED. These services consume Memory and CPU cycles, which are not usually noticeable on physical hardware, but are exacerbate in virtual environments.
Citrix ActiveSync Service
Citrix XML Service - enable this on your ZDCs, disable on your production app servers
DHCP Client - if you are using static IP addresses
Distributed File System
Help and Support
Human Interface Device Access
Indexing Service
Messenger
Netmeeting Remote Desktop Sharing
WebClient
Windows Audio - unless, ofcourse, you truely need sound for your apps
Wireless Zero Configuration
For more information on Windows 2003 Services, see TechNet.
Scaling Out
When virtualizing, it is key to remember to scale out, not up. Sure, 2 CPU and 4 GB RAM physical machine has more horse power than a 1 CPU / 2 GB RAM VM, but when you can fit 10 of those VMs on a single host, you get a much greater density while spreading the load around. This is a larger hurdle with any virtualization project, to move past large amounts of CPU and RAM. Once you can accept that smaller may be better, you see the value of scaling out (more units) instead of up (larger units).
I have found 3gb is a nice "sweet spot," depending on your specific application requirements. If you are running on a physical Host of 48 GB, this could allow you to run 10-12 VMs, consuming 30-36 GB, leaving plenty of resources for the host, VMotion, and axillary servers if necessary. My Rule of Thumb: 2 Citrix VMs = 1 Physical Citrix Server. Obviously, this will vary based upon the actual workloads and application demands. For the aforementioned 3gb Guest on a 48gb Host, you could replace 6 1U servers with a single host - saving 5U of valuable space (as well as power and cooling).
You will need to design your Load Evaluators according to your design. Because performance counters are abstracted in a virtual environment, I recommend using us custom evaluator based on Memory Utilization, CPU Utilization, Session Load, and Load Throttling.
Combine this design with the use of VMWare Templates, XenAppPrep, and/or Provisioning Services for rapid deployment and you will have a robust, efficient, and highly flexible VMWare environment for running XenApp.
I've loved Provisioning Server for a long time now, and Citrix has been doing a great job of moving forward with additional features and functionality. They have also provided a very thorough job of documenting the many possible configurations of PVS in an HA configuration. One that has been possible for a while, but has not made it into the white papers is local disk HA. (Explained in this article and also detailed by Jarian Gibson on his blog here).
This local disk HA option is a perfect example of the trade-off we often have to make between a low upfront cost and easy operations in the future. I've run into many great PVS prospect customers who do not own a SAN, but still require high-availability from PVS because so many of their users rely on it for XenApp server or VDI machines. It does however increase operating expenses to deploy it this way because you have to copy multi-gigabyte files around multiple times throughout a single versioning of a vDisk. Compare this to using a shared LUN ($) (with a cluster file system ($)) where you only have to copy the file once.
So when choosing a HA method for PVS, be sure to take into account where the best place to make that investment is. Lower initial cost or easier operations, which one is worth more?
In a future blog post I will explore an undocumented method for managing vDisks that can be even quicker and easier than using a regular shared LUN or folder, on the right kind of storage. More Recomended Reading More information on Provisioning Server
Question: Does NetScalers XML Broker health monitoring and load balancing protect intra-zone IMA communication?
Protection for Web Interface
When a user launches web applications from a XenApp Web Interface (WI) server, the WI connects to a member server in order to retrieve a list of available applications and to find the least loaded server for the user to use. It uses an XML Broker query for this communication. Getting this information is critical for application launch success and if the member server has a process failure of the XML or IMA service, this communication will fail. Since the WI can be given a list of member servers to try to reach (and it can move to other servers if no response is received) a member server process failure may result in just a delayed WI response as it tries to communication with another member server. Which could take several seconds or minutes depending on how many servers are afflicted. And in the worst cases, where just the IMA service fails, a null list of information is returned to WI and the application launch process fails completely. This is the dreaded "black hole" which is nasty because it's so hard to diagnose. Users may experience any of 3 different symptoms, most of which make administrators think they're dealing with a permissions issue.
If the “black hole” occurs on the first server (or the only server listed in the WI’s list of Brokers) the application availability will be 0.0%. This problem gets particularly nasty when it occurs on another server and results in intermittent failures which can be almost impossible to diagnose. Or when a process monitor is constantly restarting the IMA service. (out of desperation, administrators who experience this tend to resort to rebooting every server in the zone) These are the reasons we need the NetScaler; which acts as a 3rd party manager (“traffic cop”) of this communication. By using the built-in XenApp monitors, the NetScaler can detect XML and IMA process failures, alert administrators, and automatically direct the WI servers to working member servers.
Protection for the Zone Data Collector
The XenApp server which receives the WI’s request will contact the Zone Data Collector (ZDC). It does this because only the ZDC knows which member servers in the zone has the least resource utilization and can support the next application launch request. This intra-zone communication also needs to be protected, and it is, through heartbeats and scheduled events which occur on the ZDC. If a ZDC does not receive an IMA based update from a member server every 1 minute (tunable) it becomes concerned and sends a ping (IMAPing) to the member server in question. Should the ping fail, the “lost” member server will not be ping’d again for 5 minutes (tunable) and will not be included in the load distribution response sent to the XenApp server that posed the question on behalf of the WI. Likewise, the ZDC’s communication itself is protected though an election process which operates based on the same mechanism as the member server reporting.
Summary
Both the NetScaler and ZDC health monitoring are needed to achieve five nines (99.999%) uptime for XenApp delivery. With these monitors in place, XML and IMA process failures can be detected, alerted on, and automatically healed around within 60 seconds.
By:Rick RohneDo to the changes to WinLogon and the LogonUI in Windows Server 2008, XENapp 5.0 clients display the Logoff UI in XENAPP seamless sessions.. Find out how to make it go away.
This only happens after exiting out of the last application in a session, but end users generally have little or no sympothy when they notice changes in their day to day life. To resolve this, simply create a new GPO (applied to the TS Servers with loopback processing enabled) with a logoff script that includes the following command:
tsdiscon %SESSIONNAME%
Once you have implemented the script, the terminal server will disconnect the session when the user logs off (Which simply hides the UI from the end user. If you do create this logoff script, be sure to ensure that your logoffs are happening clean, in some scenarios, a hung process will keep the session open without giving any notification to the user. More information: http://support.microsoft.com/kb/321705
Well, it's about time I tell you... Citrix made a little announcement last week about VM hosted applications, a new feature that will be introduced in Q3 of 2009 as part of Feature Pack 2 for XENApp.
What is it?
VM Hosted Apps is just another way of hosting published applications (Just like XENApp) only running on a Windows XP, Vista, or Windows 7 PC. The PC would most likely be virtualized and placed in a pool of virtual PC's.
You might ask why?
Well, those that have been working with Server based computing for the last um-teen years are probably snickering right now. The fact is, not all applications run well, are supported, (or run at all) in a multi-user environment. With VM hosted Apps, the application is served seamlessly from a dedicated virtual desktop where the processor and memory can still be shared at the hypervisor level, however the operating system is dedicated.
Other uses could be related to processor intensive applications that might run on a blade PC, or graphically intense apps that may require one graphics processing unit per user.You may even want some sort of backwards compatibility for a Windows XP application that is not supported on Windows 7.
Licensing?
What I've seen so far is that each user will have a one to one mapping to their VM hosted app, however, this will change shortly after the initial release to enable multiple published apps per user. Citrix plans on releasing the VM Hosted Apps with XENApp Enterprise or Platinum Feature Pack 2. You will also need a Microsoft VECD license to stay in compliance with hosting Microsoft virtual desktop Operating systems.
End User Experience?
So far, it looks like the hosted apps will have to run in their own farm. For those that are using Web Interface or PNAgent, well good for you because it will integrate into your existing farm seamlessly. As for Management, there will be an MMC plug in directly to the AMC. I'm sure Printing and Citrix Policies will come into play here, but at this time I've not seen anything yet.
Let it all out! Rejoice!
OK, maybe it's not that exciting... Well, yea it is! This is one step closer to Citrix's goal to be able to deliver "every" application to every user in any location. It's not a replacement to XENApp, but instead an enhancement to the delivery center...
In all the years of working with Citrix products, I can assure you that one of the biggest thorns in my side has been related to client delivery. The process of getting a XENApp, or Access Gateway Client installed on an end users’ machine not knowing anything about the end users’ operating system was a subject that I would easily avoid if given the chance. Until Now... It’s no surprise that Microsoft wants to use this technology to deliver its own Application Streaming client.
Citrix Receiver is a lightweight, auto-updating client that enables easy, secure access to applications and desktops from any device. Yes, any device! PCs, Macs, smartphones and thin clients. It provides a client framework, with a plug-in architecture that transparently controls the management of functional plug-ins, including updates and user notifications.
The user experience is simple; the end user just visits the Citrix Receiver home page hosted in your corporate office, agree to the terms, download and install the receiver. Once the receiver is installed, an administrator can control all the available plug-ins that will be downloaded to that user. The Administration is provided by Citrix Merchandising Server, an easy to use virtual appliance that provides centralized management of plug-ins while also keeping them up to date. Since Merchandising Server is a virtual appliance, it’s easy to provision in any environment. Merchandising Server also includes tools for migrating existing Citrix customers from legacy implementations of Citrix software clients such as Citrix Program Neighborhood, PN Agent, and Web Interface.
XenApp, XenDesktop, CitrixAccess Gateway and Branch Repeater plugins are all available to the Citrix Receiver right now. Citrix Receiver is free and is available for any Windows-based device, including PCs, laptops, netbooks and even thin clients. Citrix Receiver forApple`s iPhone is also available as a free download from the AppleApp Store. Citrix Merchandising Server is also available free charge.
If you've experienced the pain like I have, it's worth your time to take a look. You will be glad you did.
By: Jarian Gibson Since the release of Citrix Presentation Server 4.5, I have had the pleasure of working with Application Streaming in many different customer environments. Here are some of the things I have learned from those engagements. Application Streaming Profiler A lot of questions I get when going to a customer site is where to install the Application Streaming Profiler. I like to use virtualization technology. Use the product of your preference. Setup and install the profiler on a clean operating system and create a snapshot. Every time you create and save a profile, revert back to your clean snapshot. This way you know you are starting with a clean operating system and nothing is left over from the previous profiling process.
Install the Application Streaming Profiler on the same operating system you are deploying to. If you are going to use the same profile on multiple operating systems, then open the profile on each operating systems profiler and add a target for that operating system. An example would be using the same profile to deploy to Windows Server 2008 for streaming to server and Windows XP for streaming to client. Create the profile and target for Windows Server 2008 on the Windows Server 2008 profiler and save it your profile share repository. Open the profile on your Windows XPprofiler, add a target for Windows XP, and save it your profile share repository. Now you can publish the same profile for Windows 2008 to stream to server and for Windows XP to stream to client. The same process works for creating a target for both 32-bit and 64-bit operating systems in the same profile.
Profiling Process When I profile I always like to use the Advanced Install option. I have come across several applications that put stuff in the users profile that is creating the Application Streaming Profile. Whatever gets copied into the users profile is ignored and doesn't get saved into the Application Streaming Profile. Once the install process is done, I like to go and use Select Files and Folders install method to see if anything has been copied into my profile. If something has, I copy it to the same directory in the All Users profile.
When installing an application I either select installed or not installed. I never use install on first use. This only causes issues with Windows Installer and generates errors when the user launches the application and tries to use that feature.
I always like to just have a single partition for my installs and try not to split things between C, D, M, N, etc. When I profile, everything goes to the system drive. As a frequent user of the Citrix support forums, I have come across some posts stating that any drive other than the system drive gets ignored and not saved during the profiling process. I have not come across this issue myself since I always stick to a single partition.
For ODBC connections, these can be added from the Edit Registry install method or use the Select Files and Folders install method. Using the Select Files and Folders install method, I copy over ODBC files into the profile. On the Run Application screen I add the ODBC executable, launch it, and add System DSN entries for ODBC connections.
Some profiles can be very large in size. Up to 1GB or more. To reduce the profile size I delete any application install cache. A good example of this would Microsoft Office 2007. After installing Office 2007 use the Select Files and Folders install method to delete the MSOCache folder on the system drive. This can reduce the profile size from over 1GB to under 800MB.
Profile Share/Deployment For the location of the profiles I like to use DFS shares. Using DFS shares enables you to move the profiles without having to modify all of your published applications. DFS shares also allows you to have a single path to all of your profiles if you have a multi zone/multi site farm setup. Depending on your Active Directory sites configuration, DFS shares will provide profile access from the share in the local Active Directory site.
When coming across profiles that are very large in size, I like to predeploy them during off peak hours. Predeploying larger profiles allows for faster application launch and reduces any errors users may get when the application is loading. This also helps prevent your file servers and network from being overloaded during peak hours. For information on predeploying applications, see Application Streaming Utilities and look for the radedeploy command.
Troubleshooting Application Streaming Issues There are several things to look at when troubleshooting Application Streaming issues. First thing I do is launch the application during the profiling process to make sure there are no issues from the installation process. The second thing I do is launch the application manually on the XenApp server or client machine. This can be done following the steps in How to Use RadeRun to Manually Stream an Application or by using the RadeRun Gui. The RadeRun Gui can be found in the Citrix Support Forums by searching for RadeRun Gui. Another thing to check is the permissions for the Streaming Service. I have come across this in a few environments where security policies have removed rights for the Streaming Service. For the permissions required to run the Streaming Serivce see Required Permissions to Run the Citrix Streaming Service. One other thing I like to do is stop the Streaming Service, manually delete the client cache (default directory System Root\Program Files\Citrix\RadeCache), and restart the Streaming Service. Another good article to look at when troubleshooting Application Streaming issues is Troubleshooting Application Streaming Issues.
Gaining High availability for XENAPP across geographically separated sites has always been a challenge, especially when you are talking about connecting over the Internet and you have little control. Citrix Netscaler offers the GSLB option which helps overcome these challenges.
Overview Daniel Feller from Citrix has written a great article explaining the differences between the different physical and logical site layouts in a XENAPP Environment. I encourage you to read it if you are considering deploying XENAPP or AGEE with Multiple Site redundancy. Click here to read the article. I wanted to take just a minute to point out some things you shoud consider in a multi-site configuration.
Active/Passive GSLB with ICA Proxy An Active/Passive ica proxy configuration is very straight forward. All users are directed at one site, while the other site sits and waits until the primary site goes down. This is by far the easiest configuration to go with. You should still consider having dedicated Web Interface Servers at each site and if possible, have a XENAPP Site configured for both locations.
Active/Active GSLB with ICA Proxy
Active/Active is the second option. This configuration makes both sites hot and relies on DNS queries to equally load users to both sites. Once the user is connected, the source IP persistence is used to keep the connection stuck to the site the user first came in on.
While Active/Active GSLB is desired, there are some challenges. For instance, when we discuss typical GSLB, we are usually talking about Web Browsers. Web Browsers have the tendency to cache the DNS names which really makes GSLB persistency a piece of cake (And failover a night mare). The ICA protocol and most every other application in the world honors DNS, so if the IP address changes mid stream, then the protocol will automatically begin connections to the new IP address. In many scenarios this breaks the ICA connection and really ticks off end users.
To work around this, consider using Wild Card certificates with a user FQDN and two site based FQDN's all matching the wildcard certificate.
example:
Certificate = *.GSLB.com
AGEE Site = AGEE.GSLB.com / IP = balanced between 1.1.1.1 or 1.2.1.1
SiteA = siteA.GSLB.com / IP = 1.1.1.1
SiteB = siteB.GSLB.com / IP = 1.2.1.1
While the Browser access the main site AGEE.GSLB.com, each web interface in their respective site should be configured with ICA proxy settings to their respective site. This ensures that ica proxy always stays connected to the same site even if the client resolves a different AGEE IP address.
Site Dedicated Web Interface Servers for AAC mode
Each site needs to have it's own Web Interface servers if you are using Access Gateway Enterprise Edition with Advanced Access Control Authentication. This is because the Web Interface server must "Always" communicate back to the same AGEE Vserver that the user first came in on. I generally control this by configuring hosts files on the WI servers to always resolve the local site AGEE VServer.
Use Netscaler Monitors Netscaler and AGEE come with default monitors that can monitor your XENAPP, XENDESKTOP, or Web Interface servers. These monitors should be configured at the Load Balancing Service level and the GSLB Service level. Using real monitors allows your Netscaler configuration to be a little smarter and can determine a server outage, or even a site outage.
Use DNS Views
DNS views can be configured to provide the correct DNS answer for internal vs. external communication. DNS views are DNS policies that simply look at the source IP of the DNS server that is making the query. If the query is coming from the internal network, the Netscaler will answer with an Internal IP address. if it's coming from anything else, it answers with the external IP address. DNS views are a great way to allow for the XENAPP plugin to connect direct when laptops are local, but connect Gateway Direct when users are on the Internet.
Use Static Proximity
Static Proximity is a configuration in the Netscaler that looks at the source address of the client DNS server and forces the client to the appropriate site. This is great when you have multiple XENAPP sites and you would like to limit the distance from the client to the correct site.
Summary
In summary, GSLB is a great tool to add value and high availability to your XENAPP or XENDESKTOP farm. There is a lot of information out on the net that can help build a sound environment.
By: Rick Rohne I've had a lot of requests to explain the Citrix XML Black hole and how CitrixNetscaler can resolve these issues by load balancing the XML Broker service. This document will help explain the issues and explain how to resolve them using CitrixNetscaler. Problem When XENAPP servers become highly utilized, the XML service stops responding and ultimately, application enumeration stops working until the servers utilization returns to normal or the server is rebooted. Overview The XML Black hole was a phrase coined a few years back to describe the following scenario:
An XML Broker, IMA, or Termsrv error occurs on the XML Broker (XENAPP Server)
Web Interface is Able to Query the XML broker
The XML service is not able to query the IMA
The result is the Web Interface receives valid XML data without any published applications for the user. Web Interface treats this scenario as a success and does not remove the server from load balancing. Users that logon to Web Interface may or may not receive published applications in their list.
Solution
Using Health Monitoring and recovery is known to help resolve these issues, especially in smaller farms. Larger farms should consider using CitrixNetscaler to load balance and monitor the XML Broker service.
Implementation
The first step is to create a new published application in the farm. This application will be used by the netscaler to monitor and verify that the application is properly resolved.. I usually publish Notepad.exe and name the published application XML-Service.
You must ensure that at least one user has rights to see the application. Usually a service account is sufficient (Thereby keeping the application from actually being used by end users).
You should also ensure that the published applications has all servers in the farm listed.
On the Netscaler, add a server entity for each XML Broker.
Next define a Service for each server or Service Group using http and the port number of the XML Broker services. Bind the servers to the services.
Create a new http Vserver using a new IP address and the port of the XML Broker. Bind your services.
Verify that the services are up, then create a new monitor. For type, select CITRIX-XML-BROKER.
Leave the Interval, RTO and Down Time as it's defaults, then click on Special Parameters and add the name of the published application in the Application Name section, i.e. XML-Service.
Next, bind the monitor to the services or service group and verify that the services are still alive.
Using the AMC on the Web Interface server, go to manage server farms and remove the servers listed, then add the IP address of the VServer.
NOTE: I've noticed that in larger farms, the enumeration process can slow down, this is due to Web Interface trying to send a NetBios Packet to the Vserver. To resolve this, simply go into the NIC card properties and disable NetBios over TCP/IP.That's it... The Netscaler will then poll the XML Broker services every 5 seconds. If the XML service does not respond with the Published Application, the Service will be taken out of load balance.
NOTE: While I've seen this solution have great success for many companies, it is important to test this out before implementing it. Create a new Web Interface site etc. before going into full production.
I recently had the pleasure of doing a pretty large XENAPP 5.0 on Server 2008 using XENServer and Provisioning Server. I thought it was an extremely successful project, and decided to share some of my experiences.
Objective
The objective of the project was to migrate from using a traditional Presentation Server 4.0 farm with published desktops to a more dynamic farm that could use both published desktops and published applications seamlessly.
Some of the challenges that were faced in the "old" farm were:
Servers were identical and imaged using Altiris. Although the solution was sound, the amount of time it took to install new applications and re-image all the 30+ servers took 2 to three weeks for image times.
Server hardware in the old farm was running on Blade technology, and the server sprawl was getting out of control and the data center power consumption was at peak.
Application short cutting for published desktops was also difficult to maintain. A short term solution was to use group policy, but as the organization grew, so did the complexity of shart menu short cuts and permissions.
The server hardware was leased, and as technology changed, so did the complexity of running multiple images for different hardware platforms.
Introduce the XENApp Plugin (Formerly known as PNAgent) for laptops and PC's on the network while still keeping published desktops available for thin clients.
Design solution
The first discussion was to move the customer to XENAPP 5.0 on 64 bit hardware. While this would satisfy the requirements to eliminate server sprawl, it also introduced new issues, such as 64 bit Print drivers (Yes, the organization was using published desktops with thin clients, so printing actually used print drivers instead of the universal print driver).
Instead of moving to 64 bit servers, I took a more modern approach using 32 bit XENAPP running on XENServer. This would allow the organization to run approximately 4 – 5 VM's per physical box. It would also remove the complexity of migrating between different hardware platforms.
To handle the imaging of the servers, I decided to go with Provisioning Server. After all, it's included with XENServer Enterprise or XENAPP Platinum edition.
To handle the short cutting I decided to introduce XENApp Plugin on both the server desktops and the client PC and laptops.
Profile management would be handled using Citrix Profile manager and a central CIFS share.
XENServer 5.0 The servers that were provided were DELL Dual-quad core servers running XENServer 5.0 embedded edition with local RAID 5 storage. Hyper-threading was enabled, a quantity of 8 NIC cards, and we had 24 GB or RAM to play with.
My first instinct was to limit the amount of VM guests to 4, this allowed me to subscribe up to 4 virtual CPU's to each host and allocate 4 GB of RAM to each host and have plenty of room for adding additional VM's if the capacity was available.
I used local storage instead of shared storage, not that I didn't want to, but simply because it was a convenient choice due to the organizations capacity and performance limitations on their SAN infrastructure.
I allocated 30GB to the first server that was built. Since this server was actually going to be delivered using provisioning server, I decided to get that part out of the way before even considering installing any applications or installing XENApp. (More on that experience later).
Each VM that would be running XENAPP would be allocated a 10 GB virtual local hard drive. Of course this drive has to be pre-formatted with NTFS, so I created a copy from a template VM that had already had it's drive formatted. Finally, I configured the VM for Network boot and optimized each VM for Citrix XENApp. (See Images Below)
Provisioning Server 5.0
I installed Provisioning Server on two Server 2008 Enterprise Edition 64 bit servers with high availability enabled. If you haven't implemented Provisioning server yet, what are you waiting for? The installation was terrific, and in less than 20 minutes, I was already performing a disk import of the first server.
After importing my first image, I was able to assign the MAC addresses of each of the VM copies and add their names to Active Directory using the PVS management console. A couple notes to remember when using XENServer with PVS.
The option to boot the VM's from PVS will not work, this is because XENServer does not support WAKE-on LAN.
The MAC addresses need to be static, (Do not let XENServer dynamically change the MAC address on boot; otherwise your servers will no longer be associated to PVS).
Don't install Citrix User Profile manager before the disk image, this causes the services to break but a simple re-install will fix it if you did accidentally install UPM beforehand.
Basically placed one of the VM's in private image mode and allowed it to boot from the master image. From there installed XENApp, UPM, and the XENApp Prep tool. The XENApp prep tool is a new service that Citrix introduced that works great with Provisioning server. It basically takes care of all of that scripting that we old guys had to do when we decided to image our PVS servers. It works with PVS as well as any other imaging software.
Since all the servers were virtual and provisioned, I decided to do a little performance tuning on the image. Any time I have a local disk to use on the PVS guest, I like to redirect the Print spooler and the Page file to that disk. This seems to increase performance because the PVS client does not have to proxy the temporary writes to the cache file. Of course, this is XENApp, so the typical XENApp server performance tuning steps are still in play.
XENAPP 5.0 on Server 2008 The final step to the project was designing a good XENApp farm that would accommodate a similar experience for thin client users and PC/laptop users. To accomplish this, I decided to use the XENapp plugin.
The first step after installing all the applications was to remove all the start menu short cuts completely from the system. This allowed me to publish shortcuts using the XENApp plugin and manage security to the applications directly from XENApp. The beautiful thing about this configuration is that if a user receives a published desktop, their short cuts launch the application in a seamless window without waiting on the connection bar (As long as the application was installed on the same server that the user is logged onto).
There was a little trick that I ran into on Serer 2008, however. For some reason, Server 2008 does not allow the PNAgent Pass-through authentication process (ssosrv.exe) to run so pass-through authentication did not work at first. After monkeying around with that for about 8 hours, I called Citrix and they basically told me that I had to use Kerberos for pass-through authentication to work on Server 2008. Simple enough, I changed to Kerberos, (set xml name resolution and trust delegation on the XENapp Servers) and it worked perfectly.
Because users on desktops and laptops usually have applications already installed, I created a second PNAgent site that would create a sub-folder in their start menu called Corporate Applications. This way, they could have the option to use locally installed applications or Citrix Applications without disrupting their start menu.
Summary All in all, the project was a success. We were able to get a mixture of Published application users and desktop users running on the same set of servers. This reduced the overall footprint in the data center, reduced server sprawl and power consumption, reduced management of applications and published desktops, minimized the amount of images needed for the XENApp farm, and allowed for quick hardware independent XENApp server provisioning.
The views and opinions of this site and its contributors are the personal views of these individuals and in no way reflect the views, opinions, or recommendations from any organization.
The result is the Web Interface receives valid XML data without any published 
NOTE: I've noticed that in larger farms, the enumeration process can slow down, this is due to Web Interface trying to send a 
That's it... The 
