I've had a great opportunity to travel the world this year and meet with a wide range of our customers and partners. I've been struck with the number of CIO's, IT Managers and Admin's who are consistent in their frustrations and questions around finding a better way to manage desktops. In one meeting with the IT team of a Japanese company with more than 100,000 employees, the CIO summarized this well with his comment, "We can't go on with the current desktop model as we need to reduce the overall cost of IT while continuing to deliver innovation to our businesses". I hear something similar to this in customers large and small across geographies and industries. This is a classic headache looking for aspirin IT challenge. The next part of the conversation generally turns into something like: "We know we have a problem, but how do we work our way out of this mess?".

VDI, What is all the fuss?

The cost and complexity of the current default model of: purchase personal computer's/laptop's, install standard operating environment, deploy with user, then patch/fix/secure & repeat is hitting the breaking point. Maybe this is just the edge of the pendulum swing between mainframe/dumb terminal to networked PC, but it's clear that there is a big "headache" today. Desktop Virtualization represents a new way forward that can be radically simpler than the current managed desktop model. The benefits of desktop virtualization are now within the reach of every organization. Customers deploying XenDesktop are seeing total cost of ownership per desktop reducing 10%-40% annually, time to value is pretty much instantaneous and information security is significantly increased.

After a recent customer event I had one IT manager ask me, "so for my 5,000 desktops I can use just one image of XP and manage 1 copy rather than 5,000? Wow, my management challenge just disappeared". With ah-ha moments like this, you can see why more and more organizations are making the move to centralized delivered desktops. The current economic headwind that businesses are facing is creating an opportunity for every company to take a look at current models and make large scale changes to emerge from this downturn in a stronger position. With this in mind here are a few principles and key points when considering Desktop Virtualization.

1) One size DOESN'T fit all

As we worked with customers to define and develop XenDesktop, we attacked the biggest pain point first -> the cost of delivering and managing desktops inside the company on the local area network. We partnered with a number of our hardware partners to build a new class of end user device called a Desktop Appliance - meeting a base level of capabilities to ensure a great user experience and options to increase capabilities over time. The Desktop Appliance combined with XenDesktop becomes the primary device for Office Workers and delivers a user experience better than a desktop PC.

Desktop virtualization can provide a user customized desktop for Office Workers; however it is an over-kill for task workers and does not address the needs of mobile workers. Task Workers include call center agents, retail clerks and shop floor workers, generally accessing a set of specific applications. A shared server based desktops (delivered by XenApp) combined with a traditional Thin Client device is the most secure and cost effective way to deliver applications to this group of users - 20 million task workers operate in this model every day. When you consider that a shared server can accommodate the needs to 300-400 users vs 30-50 virtual desktop users per server for VDI, the cost comparison is fairly straightforward. Mobile workers include sales execs, service personnel and executives who carry a laptop and need their applications with them on the road, both on and off the network. Application virtualization is the best solution for cutting down the cost of managing applications for mobile worker laptops. Citrix has a long history supporting mobile workers and now we have the only product, XenApp, that acts as a single application hub that can deliver line of business applications hosted from the data center and productivity applications like Microsoft Office streamed to run locally on the users laptop for offline use in locations like airplanes and at customer offices.

2) IAATHUX - It's All About the User Experience

I'm a virtual desktop (XenDesktop) user and it really is a fresh, personal & fast experience every time I log-in. My XenDesktop starts up faster than I can get a cup of coffee and absolutely screams when I launch and use applications throughout the day -> apps and data live close together on servers in the data center. Knowing there is no spinning hard drive or humming fans makes me feel good about reducing power and air conditioning in our offices. With anytime, secure remote access, I can work from home with my customized desktop when needed and not make unnecessary off-hours trips to the office. I have accessed my virtual desktop from all locations, broadband, our small regional sales offices, offshore during my international trips. With the EasyCall feature of XenDesktop set to make calls from the office, or the users cellphone or home telephone, I can be productive with voice and data access from anywhere - and see significant savings in my cellphone & telephone bills.

3) The Desktop: Just Another Datacenter Workload?

Server virtualization is primarily focused on the wringing efficiency from under-utilized servers. Virtualizing desktops, on the other hand, is more an end-to-end solution including servers, networks and client devices. Defining the desktop as Operating System + Applications + User Profiles is useful to highlight the key components. The dynamic assembly of these components and delivery as a service are critical to realize the cost advantages of desktop virtualization and improved user experience.

4) App Virtualization: Key to Succesful VDI

In much the same way that having a single copy of the operating system to be delivered to all users, application virtualization can deliver a single image of each application across a broad range of users. XenApp delivers applications on a hosted or streamed basis to virtual desktops (in addition to physical desktops). Keeping individual copies of applications for each user and maintaining these across users just doesn't make sense and destroys the cost benefits of desktop virtualization. Managing each application separately from the desktop image is the only way to make the virtual desktop projects cost effective.

5) Storage, storage and more storage - Why Storage is a Critical Factor

The first versions of early virtual desktop infrastructure seemed designed to increase IT's spend on back end storage. Virtualizing applications and managing them separately, as explained above, not only helps in cutting down the cost of desktop and application management but also becomes one of the key factors in reducing the storage requirements of the desktop images. In addition, this virtual desktop image along with applications should be dynamically assembled and provisioned into a virtual desktop on-demand at the time when a user logs on. XenDesktop has been architected to optimize storage requirements by dynamically assembling users' desktop at the time when they logon. The only unique storage required for each user is their profile and application data. This approach has unlocked the business case for Desktop Virtualization using any hypervisor - XenServer, Hyper-V or ESX.

6) Real distance, real networks

With the move to centralized data centers and more virtual workforces, the distance between users and their desktops and applications is increasing. Hence, the delivery of the virtual desktop is equally important regardless of where the end user is. Citrix has a long history with delivery applications over networks ranging from current high speed 1Gb networks with lots of bandwidth and low latency to the skinniest of networks with high latency and failure rates. Our larger customers operate with 10's of thousands of users operating across public and private networks built with wired and wireless network infrastructure from different network infrastructure vendors including Cisco, Juniper, Nortel and others. Since application and networking professionals have lots of hands on experience with Citrix traffic on their networks, we decided to have the same proven virtual delivery protocol, Citrix ICA, in both XenApp and XenDesktop.

7) Client Hypervisor - Fact vs. Fiction

Based on the strategy above, all task workers and office workers should have their desktops centrally hosted in the datacenter, enabling them to securely access their desktop from anywhere. For mobile workers, who need to work offline, I expect more innovation to come where IT can virtualize and stream full desktop images to laptops. Citrix is helping to make this a reality by working closely with the Xen.org, Xen Client Initiative (XCI) to create a fast and free embedded hypervisor for laptops, PC's and PDAs. XCI is an exciting and fast-moving initiative driven by all the biggest names in microprocessors, BIOS, PCs and laptop hardware. Because when it comes to client hypervisors, trying to build something proprietary and closed simply won't cut it. Anything that doesn't have broad, open and compatible implementation across the industry is likely to fail. An embedded client hypervisor will, of course, provide a foundation to deliver local virtual desktops. However, a client side hypervisor alone is not enough for IT to have a complete solution. At Citrix, we're working on a complete solution that integrates a client side hypervisor, application and desktop streaming, application and desktop hosting, and end user profile and context management - this complete solution will ensure that the mobile users can quickly get their personalized desktop and their applications available to them offline and IT can centrally manage the lifecycle of the desktop at lowest possible cost.

In our experience to date with XenDesktop in the market, I've been pleasantly surprised at both the level of interest and speed at which our customers are deploying virtual desktops. It seems that the headache with current desktop management crosses industries, geographies and customer size and that many of these organizations are reaching for the aspirin or already starting to breath a sigh of relief with their virtual desktops.

If you are interested in a third party evaluation of XenDesktop, check out this InfoWorld test by Paul Venezia:  http://www.infoworld.com/article/08/09/16/38TC-citrix-xendesktop_2.html

Gordon Payne,
Senior Vice President
Delivery Systems Division

I wanted to let everyone know that I'll be doing a Tech Talk on the new Streamed Plugin 1.2 soon.  The official title is Extend Application Delivery to More Users and Applications with Citrix XenApp 5. The agenda will cover how to extend the value of Citrix XenApp 5 to more users than ever before.

• Accelerate delivery of virtualized applications
• Extend the value of XenApp with client-side application virtualization
• Simplify packaging and reduce maintenance costs by 30% with linked profiles
• Fast and secure delivery to users outside corporate LAN with HTTP streaming
• Streamline management with self-healing applications and rapid updates
  

The date will be Thursday, October 2, 2008 at 10 am EDT and 2 pm EDT. Click here to read more and register for the whole series of upcoming XenApp 5 Tech Talk webcasts.

Hope to see you there.

XenApp and XenDesktop provide the means for users to access their Apps and Desktops from a wide variety of platforms and devices. At Citrix our vision is to create a world where anyone can work and play from anywhere. Mobility is not new to Citrix. There are XenApp clients available today for Windows Mobile and Symbian devices, but small form factor devices have had their challenges. Slow, unreliable wireless networks, small screens and awkward user input models have relegated hand held access to small and highly specialized market segments. But that's all about to change.

The latest generation of hand held devices with their large, high definition screens and the availability of high-speed wireless networks are changing the game in a big way! A hand held device such as an iphone connected to XenApp via a high-speed 3G network yields a remarkably usable experience.

While serious content creation might have to wait for an external keyboard and monitor, consuming content like reviewing a spreadsheet or a patients records and simple tasks like approving an expense report are quite frictionless. And because you're accessing your content via XenApp and XenDesktop your access is fast and reliable and you never need to worry about your valuable data being compromised if you misplace or loose your phone.

I've been fielding quite a few inquiries lately about our strategy and plans for the iPhone. I thought it was time to let everyone know where we are and where we're going. The guys on our Mac development team in Chalfont, UK have just recently finished porting the core XenApp engine over to the iPhone platform. This was a great deal of work and the guys have done a brilliant job.

As you can see, pretty cool, but we still have quite a bit of work to do. During the next stage of the project we will be crafting a user experience that provides a natural, transparent and effortless user interface in keeping with the high standards set by our friends at Apple.

It's tough to say at this stage when we would have something that we could share with you but I promise if you watch this space we will provide regular updates on our progress and schedules as they reveal themselves.

Its the continuous and enthusiastic feedback we have collected from you all that has helped get this project off the ground. If you haven't done so already please check out Chris Fleck's iPhone blog and cast your vote.

Al-

If you attended the live TechTalk, there were more questions than I could answer in the time allotted.  If you want, the recording of the webinar can be found here. Also, don't forget to check out the guides and reference architecture for the end-to-end virtual desktop solution:

• Implementation Guide
• Reference Architecture

But now it is time for the Q&A...

Q: So I have Presentation Server 4.0 and can publish desktops.  What does XenDesktop do differently?

A: An Excellent question and a great one to start this blog. One of the big differences between a XenApp (Presentation Server) desktop and a XenDesktop desktop is in XenDesktop you are essentially on your own workstation.  This means you can more easily allow your users to personalize and customize the applications to best suit their needs.  One of the major concerns I've seen and heard from numerous organizations using published desktops on XenApp was the desktop was static.  They couldn't change their backgrounds. They couldn't customize their applications. They couldn't do certain tasks because the XenApp server was locked down so tightly because that desktop is shared by many users.  In XenDesktop however, you can let your users modify the settings, customize the look and feel and try to better align the desktop with their job function.  On another aspect, there might be applications that just don't work on Terminal Services or XenApp for any number of reasons. However, XenDesktop is not built a multi-user operating system like Terminal Services. Is it meant for desktop operating systems like Vista and XP.  If the app works on your desktop, it should work on the virtual desktop.

Q: Can you please elaborate on the desktop receiver?  How different is it from an ICA client, and will it be available for a variety of thin client devices? 

A: In part, the desktop receiver is similar to the ICA client in that it allows ICA connections to XenApp and XenDesktop sessions.  The Desktop Receiver also includes visualization customization options through the use of a toolbar in the virtual desktop window.  If you just used the standard ICA client, a connection to XenDesktop would work, but you would be unable to fully customize the view.

A: Yes. The user will most likely experience a pause or slowness in their session (100-200ms) during a transfer. However, the session and the data will not be lost. In most instances, the user will be completely unaware of the pause unless they are staring at the monitor and interacting with the session.

Q: Roughly how many VMs can a controller handle?

A: I wish this was an easy question to answer, unfortunately it is not.  I can tell you that we have seen a single controller manage 1500 desktops without reaching a the breaking point (standard server hardware was used 2 processors, dual core, 2 GB RAM).  Because XenDesktop is based on a farm architecture, we can simply add another desktop controller when one becomes maxed out.  If you remember the processes that occurred during a virtual desktop startup, it essentially comes down to the virtual desktop registering itself with the controller and then the controller routing a user request to the virtual desktop.  These processes happen quickly with little impact to the server. Once the virtual desktop is up and running, very little activity is required by the controller except to verify the virtual desktop is still running.

Q: To provide high-availability for the AppHub, you used a NetScaler to load balance the requests. Do you need to load balance multiple NetScalers?

A: No.  There should be 2 NetScalers in the architecture though, setup in a HA Pair. The HA Pair will be in an Active-Passive mode. If the Active NetScaler were to fail, the Passive NetScaler would take over immediately.

Q: So where do you install the applications if you don't install on the virtual desktop?

A: It depends how you want to deliver the application.  The recommendation is to stream using XenApp and to host using XenApp. When the user is logged onto their virtual desktop, the Application Receiver (similar to PN Agent), will auto-logon with the user's credentials.  The App Receiver will show a list of applications for the user on the virtual desktop, start menu or system tray. Those applications are not installed, they are just icons.  When the user selects one icon they will

1.       Hosted: start a session on a remote XenApp server and execute the application from there

2.       Stream: have the application streamed to the virtual desktop on-the-fly.  The application will run from the virtual desktop. 

Both options are valid and appropriate for different circumstances.  That is a longer discussion, which I hope to extrapolate on in an upcoming blog post. Hmmm, did I just commit to something else? I gotta stop doing that.

Q: What impact would XenDesktop have on apps which are not Windows Terminal Server compliant?

A: They should work.  Terminal Services is a multi-user OS and we try to run single-user apps on top of it. Most applications work fine, but there are a handful which do not for some reason or another. XenApp has tried to overcome these challenges with technologies like AIE or virtual IP, but there are still some apps that don't play nicely on a multi-user OS.  With XenDesktop, you are using Vista or XP.  That desktop, for the duration of the session, belongs to a single user.  This should help to overcome many of the app challenges we have all experiences with a Terminal Services infrastructure.

Q: Does each XenDesktop instance take up a citrix license?

A: Yes. Each virtual desktop connection equates to a XenDesktop license.

Q: Do you have to have XenDesktop with XenApps?

A: No.  You can run XenDesktop without XenApp and it runs fine.  The integration of XenApp with XenDesktop allows for the reduction in the number OS images you must maintain because the applications have been removed. For example, your entire organization probably runs 1 or 2 desktop OS but you have more than 1 or 2 desktop images. Why? Probably because of the application set. 

Q: Do you have to buy separate licenses for each provisioning server?  Or do you get rights to configure a dev/test and production server when you buy the product.

A: Provisioning Server licensing is based on streamed desktop. So you can setup a Provisioning Server in Production and Test and they don't require a license until you stream desktops. Then each streamed desktop requires a license. If no license is available, the desktop will shut down after a few minutes.  

Q: How do the vm's continue to run if the host physically goes down in the case of a hypervisor failure?

A: If the host physically fails, the virtual machines go offline as well. Any unsaved data is lost. The virtual desktop will restart on another available XenServer.  The time required will be based on how long it takes for the virtual machine to boot. Think about this as well, if your physical desktop fails, power outage, etc, you also lose everything unsaved. 

Q: What do you do about applications that aren't supported in XenApp, do you then have to have an image that contains that app?

A: No. If the application doesn't work on XenApp, I would suggest trying to create an application profile for the app.  That profile will then stream down to the virtual desktop when the user requests the application.  The app will run ontop of XP or Vista and not XenApp.  This should help with those troublesome applications.

Q: Do we need to install the applications on all the desktops or only on the base OS

A: Ideally, you don't install the apps on the base OS.  The base OS is just the OS and some agents.  When the user logs on, they automatically get their applications from a XenApp backend.  When the user selects an app, the app is either launched remotely from a XenApp server or streamed down to the virtual desktop.  If you must update the app with a hotfix, you update the application profile once, and those updates are streamed down to all virtual desktops automatically.

Q: I have Presentation Server now. What are the migration steps for moving to XenDesktop?

A: If you already have your Presentation Server (XenApp) architecture, then your move to XenDesktop is fairly straight forward. You want to leverage your XenApp install to better delivery applications into the virtual desktop.  I would suggest looking at the Pilot Reference Architecture and the Implementation Guide to help you through the setup and integration.

Q: I use ISA to publish my internal URLs.  Is there a way in XenDesktop to use a different port for the URL that it gives out?

A: Many of the ports and addresses inside of XenDesktop are customizable. 

Q: Could one use Citrix Access Gateway or Netscaler for secure desktop delivery?

A: Yes.  That is the best integrated solution.  With Access Gateway or NetScaler, you can setup secure, remote desktop delivery without requiring users to open up a full VPN tunnel. They will instead be able to encapsulate ICA traffic inside of SSL so it is secure over the Internet. If you go with NetScaler, you have the option of using and integrating the high-availability options for XenDesktop like load balancing and global server load balancing. These materials (Reference Architecture and Implementation Guide) explain how this works for a XenApp environment, which would be similar to a XenDesktop environment.

Q: Is the app receiver like a PNAgent?

A: Yes, that is the best way to think of it for those familiar with PN Agent.

Q: When Hypervisor #1 goes down, how does Hypervisor #2 know about the #1 server's session's virtual memory and use it to run those sessions on Hypervisor #2?

A: It doesn't.  If the hypervisor fails, then the data is lost.  You can only move a running VM to another XenServer without losing data. If the XenServer physically fails, then the virtual machine can be automatically restarted on another virtual machine.

Q: What is the difference between the VD Receiver and the XenApp ICA client 10.2?

A: The main difference right now is that the Desktop Receiver contains the functionality for a toolbar allowing you to more easily customize the window of the virtual desktop. 

A: I would recommend taking a look at David Wagner's blogs on the UPM here:

http://community.citrix.com/pages/viewpage.action?pageId=34439480

http://community.citrix.com/pages/viewpage.action?pageId=35291139

http://community.citrix.com/pages/viewpage.action?pageId=33587458

Q: Can machines be added to the Desktop Broker that do not have the XD Client, but instead just use a traditional RDP or VNC connection?

A: At this time, the connections are through ICA and require the Virtual Desktop Agent installed on the virtual desktop. The agent is responsible for the ICA connection as well as registering with the XenDesktop controller.

Q: You said that XenDesktop is supported on Virtualization OS other than Citrix - Microsoft Hyper-V and VMWare ESX; is it supported on the Oracle VM also?

A: Not at this time. 

Q: Can this support multiple versions of the same software suite?  I.E. I have most of my users using Office 2003 Pro but I have a select group using Office 2007 Pro Plus, can this be done with XenDesktop?

A: Yes.  You can either have the apps available for different users (one user group gets 2003 and another gets 2007) or you can have both apps be available for all users simultaneously and be executed from the same virtual desktop when the applications are streamed with XenApp.  

Q: I have several users that need to use Adobe Acrobat Professional and at this time, Acrobat will not install on a Terminal server, this causes us to have to have local PCs for these users, does XenDesktop adress this issue and allow me to give my users, who need it, access to Acrobat Pro?

A: Yes.  You should first try to have a base virtual desktop image and stream Acrobat Pro down to the virtual desktop.  If the app streaming does not work, you can also create a Acrobat Pro virtual desktop where the application is installed and part of the base OS.  That base OS will be published to the appropriate users.

Q: Can you "publish" a virtual desktop from xenapp server?

A: Yes, but that virtual desktop is not the same as a XenDesktop virtual desktop. See the very first question.

Q: What thin client devices can this be used with?  Is there a thin client with Desktop Receiver? Does this work with Sun Ray's and Sun Secure Global Desktop

A: Take a look at the Citrix Ready site. There is a specific section focused on Desktop Appliances.

Q: Does this work with non x86 UNIX/Linux OS's

A: Currently it only works for XP and Vista.

Q: Can a user change clients without losing their virtual desktop.  i.e. can I disconnect form machine 1 go to machine 2 and reconnect and still have the original virtual desktop and continue with the original virtual desktop.  Also, does the system keep running while disconnected (i.e. a compile would continue)

A: Changing endpoints but going back to the same virtual desktop is possible with a feature called Workspace Control (it is part of XenDesktop).  As for running while disconnected, it can you if you want it to. 

A: Get an umbrella.  This is actually a very serious concern. If you try to boot up 1000 virtual desktops at once, you will most likely have some challenges on many fronts, just due to the impact on everything.  This will in turn result in users not getting to their virtual desktop or being required to wait a very, very, very long time.  XenDesktop allows you to set idle limits based on the time of day.  If the morning rush starts at 9AM, you will want XenDesktop to start prepping the environment around 7 or 8AM to make sure everything is ready for the rush.  You do this with the Idle limits shown in a previous picture.   

Q: Is the OS image hardware independent, or do you have to have a separate OS image for each hardware variant in your environment?

A: If you are running on XenServer, then all images have the same hardware footprint (the XenServer virtual space) even though the XenServer might be on different hardware.  You can use the same  OS image to stream to a XenServer virtual machine and a physical server by configuring a common image where drivers are incorporated into the base image.

Q: How would this be in a WAN env?

A: Pretty good. The protocol XenDesktop uses is Citrix's ICA protocol which has been used for years with XenApp (Presentation Server, MetaFrame).  This protocol only sends the screen updates down to the end point.  So when you are typing in Word, only the images of the letters get sent, if they changed.  ICA also has been enhanced greatly over the years to support audio, video and numerous other areas.  Truthfully, the only way to be certain it will work for you is to try it out by getting the free evaluation kit.

Q: Our env is highly integrated, we have found that streaming applications to be nearly impossible.

A: By highly integrated, I assume you mean many of your applications rely on each other.  App streaming is a great idea, but this was a huge problem. First, the background. When you stream, each app is in its own container.  Those containers are separate and do not interact.  That is a major problem for environments like yours.  What ends up happening is you have 2 different enterprise applications that each rely on Excel.  You create one profile for one enterprise app and include Excel. You then create another profile with the second enterprise app and Excel.  When you have updates to Excel. You have to update both profiles. This is hard to manage and maintain. 

Have you looked into XenApp 5, just released? It has major updates to XenApp streaming where these different containers can now talk to each other. So in the previous example, you would have 3 profiles, 1 for each of the two enterprise apps and another profile for Excel.  You configure the profiles to work with other profiles. This should help you overcome the major challenges you experienced in the past.

Q: Does this require an AD schema update?

A: No.  It does use AD, but it does not require Schema updates. (thank goodness).

Q: Streaming is overbilled it doesn't address application integration

A: I would love to hear more.  I agree in the past App streaming was a challenge because of communication limitations between applications, but with XenApp 5, those challenges are being mitigated with inter-isolation communication.

Q: Can you use a Microsoft load balancer to replace the NetScaler?

A: Yes. There are many differences that would take a lot of time to explain, but for simplicity, NetScaler has specific smart monitors and high-availability options for XenApp and XenDesktop that makes it easy to configure and setup.

Q: Is it possible to stream this over the internet at all? For example hosting the desktop at a datacenter

A: Well, the desktop and application stream would stay within the data center.  Users would connect to the virtual desktop in the data center with the Desktop Receiver, which relies on the ICA protocol.

Q: What happens if there is no controller available?

A: If all of your XenDesktop controllers fail, currently connected users will be fine. New connections will not be allowed.

Q: If the user count is small and all use same apps would it make sense to install all apps on provisioning server and by-pass streamed/hosted options.

A: It does make sense and is a possible option. 

Q: Does XenDesktop with installed apps optimize video/audio significantly more than a VMware VDI desktop?

A: Hosted, installed or streamed apps really don't make much of a difference when you talk about the optimization of video and audio t the endpoint.  What does play a major part is the delivery protocol.  The Citrix protocol, ICA, is used by millions of users who connect to XenApp published applications. That same protocol is used to delivery virtual desktops.  Truthfully, the only way you will be able to see is to try it out for yourself. 

Q: How do apps that are launched from other apps work - things like GoToWebinar or Flash, which are launched from a browser? What about plugins that require installation that are not on the gold desktop?

A: Plugins and flash and other items that were not part of the base OS image can be installed on the virtual desktop by the user.  However, that installation only impacts that particular virtual desktop. The changes made by the installation are contained in a write cache. When the user reboots the virtual desktop, that write cache is destroyed.  The next time the user connects to the virtual desktop, they would have to re-install the agent. This is a big reason for identifying the needs of the user. It allows us to identify the agents and plugins that are needed. But just because it is not part of the base image, doesn't mean the user can't add it on-the-fly.

Q: Is there a plan to provide a "Offline XenDesktop" in the future? (similar to VMwares OnDemand VDI)

A: I have heard people talk about it, but am not in the product group so I'm not certain what the roadmap looks like.

Q: what is best practice for managing XD workstation log files, taking into account that the log data is lost after every reboot? 

A: the log files would need to be stored on a network share that is persistent.   

Q: Does this support any Linux Desktops?

A: Not currently

Q: Do you absolutely need the Access Gateway?  I have WI with the CSG.

A: I believe you would be able to use Secure Gateway instead of Access Gateway.

Q: Will XenDesktop work with VIrtual Iron and XenApp?

A: right now XenDesktop only supports XenServer, Hyper-V and VMware ESX as the hypervisor.

Q: You had to mention NetScaler.  So what are all us normal or smaller companies going to use?  I hear that a NetScaler starts at $20K plus.

A: You can use software or hardware based load balancers.  NetScaler just includes integrated monitors and wizards to make configuration easier.  However, load balancers like Microsoft load balancing would work as well, you just want to make sure that the devices you are load balancing are being monitored intelligently (but even a Ping is better than nothing).  

Q: What happens when the Hypervisor fails and there are too many VMs moved to a single host?  Do some of the machines get put in stasis, are they shut down, or do all VMs suffer slowness?

A: With XenServer (Orlando) you can set priority levels for the virtual machines.  The ones with highest priority will be restarted on available XenServers, others will not. 

Q: What happens to data in the case of an Application Hub failure caused by a XenApp server crash?

A: This is the interesting thing with XenApp and application streaming. XenApp is needed to identify and start the stream, but once the desktop receives the stream instructions, the Xenapp server is removed from the equation.  So if I'm receiving my app stream, it is coming from the App Hub and the XenApp server is doing nothing.

Q:  In terms of client hardware would this work with WYSE thin clients?

A: You will want to look at the Citrix Readysite for desktop appliances.  Those devices that are not on the list might work, but you want to test.

Q: What are the differences in performance installing this on ESX server 3.5?

A: I haven't seen published stats on that scenario yet.  Until that time, you might want to try downloading the XenDesktop eval and trying it on both hypervisors.

Q: What's server cache??

A: The cache is for Provisioning Server (OS Streaming). Provisioning Server streams a base OS to hundreds of workstations.  Those workstations use a Standard Image (Read Only) to receive their desktop OS.  Any changes the user/desktop makes to that image are stored in a write cache. 

Q: This question is regarding licensing.  Do you utilize 2 different concurrent session licensing for any XenApp published applications running on Xendesktop?  please explain how it the licensing works.

A: Licensing is such a fun topic.  Citrix licensing for XenDesktop is concurrency for the virtual desktop and the app delivery.  With XenDesktop Enterprise and Platinum, you get XenDesktop, Provisioning Server and XenApp for Virtual Desktops. Each one is concurrency. So when you start 1 desktop and have applications, you use 1 XenDesktop, 1 Provisioning Server and 1 XenApp license. Of course when you purchase XenDesktop Enterprise or Platinum, the licenses are part of the package.  Take a look at the editions here. 

Q: I guess we need to have our own SSL solution. It is not part of XenDesk components, right?

A: With Standard, Advanced, Enterprise or Platinum edition, you get Access Gateway licenses which provide secure, remote access using SSL.

Q: Is XenDesktop the same as Desktop Broker?  We want to display a physical PC (a CAD workstation) across the WAN using ICA.

A: Sort of. XenDesktop replaced Desktop Broker.  Desktop Broker used an ICA server as a proxy to RDP to workstations. With XenDesktop, you get ICA from your end point to the virtual desktop.  Plus, XenDesktop incorporates many other technologies to make a more complete end-to-end solution. 

Q: Will Secure Gateway work or does it have to be the Access Gateway?

A: Secure Gateway will work.

Q: On average how many users can one XenDesktop and XenServer host?

A: XenServer is really going to be based on the amount of RAM.  Very few physical desktops utilize their CPU. If you are hosting Vista desktop on XenServer, the general recommendation for Vista is 1-2GB of RAM. If you have 64GB of RAM on XenServer, and you have 1GB RAM for each Vista desktop, you will end up with 60-62 virtual desktops (XenServer takes RAM too, which is why it isn't 64). However, the processor is the big question and the only way to really see that is to test it with real users and see how much they hit the processor.   

Q: What are some of the main differences between XenDesktop and Citrix Provisioning Server?

A: XenDesktop is the complete, end-to-end solution of virtual desktops.  Provisioning Server is a component of XenDesktop.  Provisioning Server allows a single OS image to be streamed to hundreds or thousands of devices across the network. This has advantages of only requiring administration of a single image for many desktops. 

Q: You mentioned Citrix User Profile manager is in Tech preview at the moment.... when can we expect this to be generally available? Will this be included with XenApp 5.0 which is due for release next month? 

A: I don't know the release dates for User Profile Manager and it isn't part of the XenApp 5 release either.

Q: Is this only for high-speed connections (local LAN) vs WAN as some of our sites are only 256MB frame relay?

A: No.  The remote delivery protocol that XenDesktop uses is Citrix ICA which has been used for numerous years by millions of users to remote connections.  I've seen organizations use ICA for any number of connections including dial-up and satellite. 

Q: Which of these products mentioned are extra to XenApp as we have Subscription Advantage and Enterprise Edition?

A: XenDesktop is a new product line different that the XenApp product line.  XenDesktop Enterprise does include a portion of XenApp, but it only allows application delivery to virtual desktops, where the XenApp product line allows application delivery to any end point. You will probably want to check out the product matrix.

Q: I'm looking for a VPN replacement.  Will you talk about the Remote user scenerio where I want to present a full desktop to a remote Work from Home user or newly aquired company where I need to provide a Desktop to them via citrix?

A: Access Gateway.  This will allow you to do just what you are looking for. You have two options on the configuration: Virtual desktop only or Full VPN. The Virtual desktop only option will only allow the user to have connection to the virtual desktop over ICA.  The user's endpoint won't technically be on the network, helping to protect the internal environment. With the full VPN configuration, the user will have a connection to the network. They can connect to a virtual desktop and browse the network from their end point.

Q: Is the streaming of virtual desktop accelerated over the network?  We have the Citrix WAN accelerators.  Does this work?

A: It might, I've never tried or it seen anyone try it.  As WANScaler works at the network stream and is not concerned with files or data, the Provisioning Server stream should show a lot of duplication as it goes from the central Provisioning Server to the numerous virtual desktops.

Q: What is the best way to run CadCam Civil 3D application for remote and internal networks? Can XenApps support and deliver CadCam Civil 3D Applications remotely? How much bandwidth is required?  Who can I call to assist me in setting up a Virtual desk top solution for CadCam Civil 3D

A: I unfortunately don't have experience with that particular application. You best bet would be to setup it up in a test environment and see how it functions.  Citrix's Consulting group can help with this type of testing, as they have done this with numerous organizations in the past. I should know as I used to be in Citrix Consulting. The Consulting information can be found here.  

Q: If I understood, we have the option to serve only the apps of the desktop to the user? Is there an installed client program on the client machine?

A: Yes, if the end point is going to get desktops, you want the desktop receiver. If the end point needs applications you use the Application Receiver.  They are very similar and can be used together. In most situations, you would have the Desktop Receiver on your end point and the Application Receiver on the virtual desktop.

Q: Can this solution work on a 10/100 MB network?

A: It all can, but you have to be concerned with the number of users and the number of desktops being streamed as the streaming is using the network. Now if your environment has your users on the 10/100 network and the infrastructure components (XenDesktop, XenServer and Provisioning Server) on a faster network, then that architecture easily works as the 10/100 network will just use the bandwidth associated with ICA protocol, which is minimal.   

Q: Can the desktop receiver be loaded on a thin client or desktop appliance?

A: Yes and it is, at least for the Desktop Appliances part of the Citrix Ready program.

Q: How is licensing addressed for the user, through Xen, if they need an application that requires Vista?  Is there a special license needed for this use on the Xen Server?

A: Each XenDesktop component is managed by Citrix licensing. For users who require a Vista desktop and application, those licenses are managed by the Microsoft and App vendor licensing agreement.   

Q: how does XenDesktop join to domain?

A: The base image is added to the domain.  Then that image is provisioned out to numerous other workstations. Those workstations are also added to the domain. As the desktops are managed by Provisioning Server, the Provisioning Server will keep the Active Directory and machine passwords in sync.   

BTW, I think this is the longest blog on the Citrix blog site. Thanks

Daniel

Homer Quote of Blog "I bet Einstein turned himself all sorts of colors before he invented the light bulb."

Dan Feller on my team contributed at least two posts on the topic of virtualizing XenApp servers on XenServer. Dan makes some excellent points and gives you plenty of business reasons why XA on XS is a good idea.

I am not going to re-iterate Dan's points here, but rather focus on another burning question in this context: How much of a scalability overhead can I really expect with my specific application? The typical consulting answer would be "it depends" and "we'll have to do a scalability / performance assessment to determine the specifics and best practices". So, we have done just that and used two popular enterprise class Applications: Siebel 8.0 and PeopleSoft 9.0. The Solution Center is one of the teams under the umbrella of Worldwide Consulting Solutions (Dan Feller's Integrated Solutions team is another) and focuses on these types of projects, which often involve third party applications and/or hardware platforms from our technology partners.
Recently, we looked at running the front-end of Oracle's PeopleSoft and Siebel applications on XenApp (both 32-bit and 64-bit platforms) and focused on comparing the user densities we could achieve on "bare metal" servers compared to running them on XenServer.
The results are published in two separate whitepapers (PeopleSoft, Siebel), which describe the test bed, test methodology, detailed results and interpretation. As Dan stated in his May 15th posting, the virtualization overhead can be as low as 6% for XenApp virtualization on XenServer, and our tests confirm this number. Of course, the numbers vary between the applications and platforms, and we describe all the details in the whitepapers.
Generally speaking, kernel memory limitations constitute the first bottleneck on 32-bit platforms, and our tests verified that behavior. Even with the popular /PAE switch, the kernel memory limitation remains at 2 GB. Therefore, you can expect a higher user density per physical server if you're running multiple 32-bit XenApp servers on a XenServer. You'd have to be cautious not to consume too many CPU cycles, which often become the next bottleneck once memory is no longer a major concern. Prices of multi-core, multi socket servers with plenty of RAM have come down significantly, so chances are that your latest servers have plenty of resources to run reliably in that configuration at a reasonable price:

According to this 1988 article, prices of 1 MB memory chips were as high as $60 (or $105 in today's money), while you can buy a barebones server with 64 GB of RAM for roughly $5,000 today. While I am on the topic of computer nostalgia: a 150 MB hard drive set you back over $8k in today's dollars way back when... 1988 was also the year Dan Feller was looking forward to seeing his favorite TV show getting its own slot in the line up and he is still enjoying it to this day, as you can see from the quotes in his postings on this site. But I am digressing...

The Solution Center also conducted detailed validation tests with Oracle to obtain validation status for running virtual images of the Web-, Application-, and Database servers of Siebel 8.0 , PeopleSoft 9.0, and Oracle E-Business Suite 12 on XenServer 4.1, so you can now be confident that the entire environment can be successfully virtualized on XenServer, allowing you to take advantage of XenMotion in case of hardware failure and other benefits.

The Streaming Profiler SDK just got better.  The XenApp 5.0 APIs are published!

Here's a link to the download site and official documentation for the 1.2 release of the Streaming Profiler SDK. 

Just to be clear, YES, the 1.2 Streaming Client/Profiler can be used on top of Presentation Server 4.5.  The 1.2 version of the Profiler and Client are on the XenApp 5.0 DVD, announced here.  The streaming components can install on top of PS 4.5 and are not tied to Windows Server 2008 - though that is one of the platforms the new client supports.

In a prior post, I outlined the foundations of the Streaming Profiler SDK.  For that background, read here.

Additional details and overview on the SDK update can be found here.

OKAY - What's new?

Enhancements at a glance, Streaming Profiler SDK version 1.2:

• New APIs - Support for Inter-Isolation Communication defined profiles
• Supports more languages; notably C++ where the prior supported only C# and probably VB.
• Actual sample source!  What a concept.
• The SDK files are better organized for easy navigation.

Enhancement 1: Support for C++
 
No, I do not make this stuff up.  The Profiler SDK is COM based and COM allows client programs to be written in numerous languages.  The Profiler back end code is written in CPP, so you would think it would be possible to write a client application in CPP.   This previously wasn't possible.   If you don't ship all the parts that are needed to compile the CPP code, then nobody will be successful using that language.  Neat!  With this release, we actually now include the TLB file with the SDK and this makes it possible to write COM client applications without the assistance of Visual Studio programming environment.  I'll note that the Visual Studio method is still easier and writing this stuff in C# rather flows together compared to the CPP methods. 
 
Enhancement 2: Actual sample code provided with the SDK
 
The Profiler SDK now includes actual sample code!  Super.  How useful is it?  Yes, very useful.   The prior had samples included with the help files, but a file on disk is more tangible and easier to use given it also comes with build procedures or Visual Studio build environment.  I wrote a sample for the SDK which is included in the official download.  Actually, I didn't so much write a sample; I wrote a utility that was needed and the SDK team shipped it.  That works.  The App Streaming Test team wrote some samples as well.  The existance of Hello World can take you a long way toward working code and this is a good addition in this SDK.
 
Enhancement 3: New APIs - Inter-Isolation Communication profiles
The New IRADEPackage2 classes include support for defining links between profiles.  Goodness.
 
What can you code now - call to action!
Here's my list of profiler SDK based utilities that are definitely needed, but that I don't have the time to code....
 
Volunteers to fill these gaps and publish their works will receive a kind plug on this blog.

1. RadeGUID       Feed it a GUID, it will search the profiles and tell you which profile on the server caused this entry to get populated into the cache.
2. RadePurge       Nuke RadeCache.  I mean really nuke it - not just the apps that are published.
3. RadePackage   Command line launch a profiling session and save the output with no user interaction.   Everything needed for this exists right now.

In the above, I throw some rocks at our own stuff.  I'm not sure that's the right political way to go about it, but I do like to get things going the right way.  Fortunately most of the rocks are self-directed so that makes it easier.  We're making good progress and the Citrix Product Management group is giving significant focus to SDKs and I think this will provide good benefits for years to come.

Joe Nord
Product Architect Application Streaming
Citrix Systems, Fort Lauderdale, FL

This post introduces the Streaming Profiler SDK, provides a description of what it does, how it works and how it can be a useful tool for managing your Application Streaming profiles.  The Profiler SDK has been around since the 1.1 release of the Streaming Client (PS 4.5 HRP 1) and the 1.2 update that accompanies XenApp 5.0 was recently announced.

Here's a link to the download site and the official documentation.

For a moment, put your programmer hat on and consider that the Streaming Profiler (the guts of it) have more than one client.  The "back end" supports the Streaming Profiler GUI (pkgr.exe), the Streaming Client itself (radesvc.exe) and the Citrix publishing system, aka the Access Management Console. 

Architecturally, the Streaming Profiler "back end" is the ONLY thing that is allowed to touch the .profile content.  Sure, others can and we haven't exactly HIDDEN the content, but in theory, the ONLY thing that knows the internals of how a .profile and .CAB are formatted is the profiler back end.  Notice that the backward / foreward compatibility stuff is at the API layer - not the disk content. 

Here's a picture...

This was the original layout of Application Streaming.  The separation of function said the GUI talented people do GUIs, the publishing people do publishing and the guts of how the streaming client works people do the back end and the service.   I was in this last group, had development responsibility for the back end and the above is rough description of how it all plugs together.  We decided on C++ as the interface between the pieces; shared header files loosly modeled on COM so it could be consumed.  It seemed to be a good balance at the time and we pushed on and built it.   There were some issues.  Being based on shared headers, the API is "per-build" dependent.  CPP doesn't meld well for portability.  C wasn't the right answer; too much state.  We let the header dependence go since - afterall - we are all building in the same build tree and it was a foregone given that all of the pieces would be updated every time we update the Streaming Client/Profiler.

Along came the real world

Customers, partners, ISVs also want to manage profiles and they want to do it from PROGRAM CODE.  The API is broke and the wisdom of the original developer who laid out the internal API rightly had rocks thrown at it.  I should have stuck with vanilla 'C' and all would be good - but that too had its own pitfalls.

The solution was a conversion of the private API from "something like COM" to "really COM" and this is the profiler SDK.  Picture below.

A vision to the future

Standard disclaimers and no promises, but the logical next step is to convert the internal components to use the external SDK.  The benefits are that we can be SURE that the SDK is a complete reflection of the internal API and that ... it works.  It will take some to get there - lots of time - but this is where I want it to go.

Joe Nord
Product Architect Application Streaming
Citrix Systems, Fort Lauderdale, FL

For those of you who attended the TechTalk on XenDesktop Technical Dive, I wanted to post the videos maintenance videos. 

Remember, a virtual desktop solution must be able to simplify maintenance or else you are simply moving the administrative problem from remote sites to the data center. The first video shows how easy it is to patch the Hypervisor (XenServer).  The running virtual machines are automatically moved to another available XenServer without impacting the users. 

XenServer Update Video:

The second video shows how thousands of users' desktops can be patched easily without requiring a significant amount of time or expense with the use of Provisioning Server. 

Provisioning Server OS Images Update Video:

These are just two examples of maintenance for XenDesktop. The incorporation of XenApp and application streaming greatly simplifies the maintenance of application delivery.  If you want to hear more, take a listen to the recording of the TechTalk which can be accessed from here.

Thanks

Daniel

Homer Simpson Quote of the Blog (What do we need a psychiatrist for? We know our kid is nuts.)

Provisioning Server offers you the ability maintain Active Directory machine account password synchronization for target devices. This ability is enabled on the Provisioning Server and is configured on a per virtual disk basis.
Private virtual disks do not need to maintain Active Directory machine account password synchronization, as they are a read write virtual disk, and have the ability to retain changes and store them to the virtual disk.
Standard virtual disks do need to maintain Active Directory machine account password synchronization, as they are read only, and do not have the ability to retain changes on the virtual disk.
There are some things to take into consideration when dealing with Provisioning Server and Active Directory Machine Account Password Synchronization for a successful implementation of this feature. The following are some guidelines and best practices to follow:


If the virtual disk image that is going to created is to be used by multiple target devices, in Standard Image mode, it is best practice, that before creating a virtual disk image, to run the Device Optimizer utility on the target device and apply the "Disable Machine Account Password Changes" setting If the virtual disk image that is going to created is to be only be used in Private Image mode and never Standard Image mode, the "Disable Machine Account Password Changes" setting does not need to be applied



When creating virtual disks that will ever be used as Standard virtual disks, it is best practice, to never create a target device that will have a device name of an existing machine account in Active Directory that is, has, or will ever be running off of local disks, and is ever going to be provisioned as a Standard Virtual Disk

When creating virtual disks, it is best practice, to ensure that the Active Directory setting for "Enable automatic password support" is configured on the Provisioning Servers

When creating virtual disks, it is best practice, to ensure that the "Enable Active Directory Machine Account Password Management" setting is configured on Standard Virtual Disks

Also, it is best practice to use an Active Directory Organizational Unit to manage machine accounts for target devices that will be provisioned, and that the Group Policy Object or Security Policy setting for the Organizational Unit is set to enable the "Disable Machine Account Password Changes" setting to disable Windows Active Directory automatic password re-negotiation.

And lastly, it is best practice to ensure that the Group Policy Object or Security policy setting for that Organizational Units "Maximum machine account password age" setting is compared to the Provisioning Server Active Directory setting for "Enable automatic password support" setting. The Provisioning Server Active Directory setting for "Enable automatic password support" number of days must be less than the Group Policy Object or Security policy setting for that Organizational Units "Maximum machine account password age" setting or you could end up in a scenario where the machine accounts would not able to log on to the domain due to this restriction being in place.

If you should ever encounter a situation where the active directoy machine passwords are out of sync, in provisioning server 4.x and below there is a command line utility for reseting machine accounts. In provisioning server 5.x this has been incorporated into the management console.

Following these best practices will help you keep synchronization between Active Directory Machine Accoutns and Provisioned Target Devices that are using a Standard Virtual Disk. With the use of Provisioning Server with XenServer and XenDesktop, these best practices are also applicable, as those technologies are also used to delivery devices that may need Active Directory Machine Account Password Synchronication.

Hello Mac Users

First I would like to thank all of you for downloading version 1.0 of our blogs widget. We currently have 1400+ downloads, and this goes to show that the Citrix community has indeed a large number of Mac users.

I also would like to thank those users who sent us their feedback, this version of the widget is here because of you, so keep sending your feedback and comments.

 Meet the Citrix Blogs Widget

 Version 1.0:

• The latest 30 Citrix Blog posts
• Adjust view from Full to Summary
• Collaborate with your comments
• Open posts on Safari or Firefox
• Spotlight Search (Instant search)
• Push updates (no refresh required)
• Watch blogged videos
• Check for updates
• Send feedback

 Version 1.2:

• Widget Resizing
• Bug Fixes

Requirements:

• Mac OS X 10.4 or greater

Download:

Citrix Blogs Widget

Running applications under isolation can solve many problems; the registry and file system no longer conflict with other applications.  Great.  What does it really mean to run an application isolated?  This post will bring some clarity and also provide insight into how the Application Streaming isolation system works. 

Let's start with the definition of a sandbox.  Call it a sandbox, call it a bubble, call it an isolation space, its all pretty much the same goal.  How can I run an application without it doing things that I don't want it to do.  How can I let that application do ANYTHING it wants to do, but have its bad behavior not really occur?  Answer: I let the application play and do anything it wants so long as it doesn't leave the isolation sandbox.  Play, play, but so long as you don't leave the confines of the sandbox, I know you're pretty safe.

Operating system theory 101:  What is a process?

A process is an entity that holds things associated with running some program.  Generally, this is a holder for allocated memory and allocated threads.  Memory is pretty easy.  A thread is a something that the operating system knows how to "run".  In more techno jargon, a thread is something that can be scheduled to run on the CPU.  A single process commonly has multiple threads and each thread can allocate memory.  Since the memory is technically tied to the PROCESS rather than the thread, all threads in that process can see any memory allocated by any of the threads.   Okay, booring - I know all that already.

What is a sandbox?

A sandbox is a layer of abstraction on top of a process.  A Sandbox is a collection of processes and a set of RULES which control what the kids are allowed to do in the sandbox.  Example, digging, okay.  Dumping your drink into the sand, okay, the carpet inside the home is safe.  Hitting your brother in the ear with a rock, NOT okay.  Oh wait, wrong sandbox.

A sandbox is the thing that the isolation space uses to keep track of all the ISOLATED processes on the machine.  We over-dramatize this.  An isolated process is just like a normal processes, except is isn't generally allowed out of the sandbox.  Put your file system programmer hat on for a moment.  A disk operation comes wondering by your code and this is the place were you do isolation stuff.  What do you do with this operation?

Questions you ask yourself:  Do I care about this disk operation?  The answer is almost always no.   How to decide?  Answer: Process ID.  Conveniently, it is a "given" with all disk activity.  Filtering code looks up the process ID in its list of sandboxes (an in memory B-Tree if anyone wants particulars).  Most of the time, none found and the disk operation proceeds along its merry way without being messed with.  Occasionally though - and always for the isolated process - the disk filter says WOW!  I got a live one and goes to work.  With a hit, it knows which "sandbox" this process is part of and with that, it knows what isolation rules govern the operation of this disk operation.  Notice that threads are not part of the equation.  It is the process membership that governs isolation.

What is a "rule"?

On receiving a disk operation that it wants to filter - the filtering code has to decide what to do with it.  Which isolation rule should be applied.  Here, the file/path or registry key/item is looked up in a list of rules that are part of the sandbox (more in memory B-Trees).   Eventually, the code identifies the "deepest" rule that effects this thing and then uses that to complete the disk/registry operation.  Technically, the isolation code doesn't complete anything, it just modifies the original file/reg request and sends it back down the path to work on places other than where it was to work before.

What kinds of rules are there?  

Isolate - They wanted to mess with \Windows; instead have them mess with \VerySafePlace\Windows.   Stay in the BOX!

Ignore - They wanted to mess with %TMP%.  I don't really care what they do to %TMP%.  Push it on with no modification.

Redirect - They wanted to mess with "\Documents and settings", instead send them to \Users.  Oh, wait, that's Vista.  Same stuff.

Strictly isolate - Clearly the neatest of all the rules. 

The Strictly Isolate rules are new to Application Streaming - didn't exist in AIE.  The application wanted to mess with "\Program Files\Co Name\App name" and that directory didn't exist at time profiling started, so from the view of the application at runtime, the only content that directory has is the stuff that the installation program added during profiling.  In the layers of glass analogy, the bottom layer (the physical layer) disappears.  These are added authomatically by the Streaming Profiler during that "finalizing your profile" step.  As the admin, you can add them too though this usually is not needed if the profiling machine was relatively clean at the start.

EVERYTHING ABOVE HAPPENS FOR THE REGISTRY TOO

Registry is a bit easier though - or harder - depends how you look at it.  The registrying hooking is all done at application level and here, the isolation system is only involved with isolated processes and always "knows" which set of rules effect it.  It is PART OF the isolated process, so looking things up is a given.

Who are your ancestors?

Among the neater things of managing sandboxes is keeping track of the process list.  Everyone is used to the idea that launching an application creates a process; what they are not used to is that the started process starts other processes; kills itself; the children then mingle with other processes and start new ones and they then wonder around the machine and try to get into trouble.  Managing the sandbox says that everyone in your ancestory tree is part of the sandbox and people who are members of the family are not allowed to leave just because they get pissed off at the processes next to them.

The part that makes this cool is that the Windows APIs that tell you about process "launch" and "terminate" tell you about the immediate parent - and that's it.  Once the parent dies, all history of who that parent was is gone!  It is up to the isolation code to keep track of the grandparents who may or may not be alive anymore and since they have cousins and since the cousins are part of the family, they are all part of the same isolation sandbox.

One of the very first things I did when the Application Streaming team took over the AIE code from Presentation Server 4.0 to use as the basis of Rade, was try to BREAK the process logic.  To my happiness - it was bullet proof.

Eventually, all of the processes that are part of the sandbox terminate - when they do, the isolation system declares the sandbox dead and starts tearing it down.  This is where post-exit scripts kick in and licenses are released. 

WHAT IS THE POINT OF THIS POST?

Isolated processes are just like regular processes.  Actually, they are regular processes, they just get "filtered" a bit as they execute.  Everything CPU wise happens "native speed" and everything about memory usage and other "process" things are same for isolated processes as they are for native processes.  A process is a process is a processs.  

Enjoy, 

Joe Nord

Product Architect - Application Streaming, Citrix Systems, Fort Lauderdale, FL

Back in april I stumbled upon and brought forward a nice finding on our internal showcase farm, an application named ICAPipe later renamed to Citrix Fast Launch.

I posted some demos and an interview with the creators of the tool, shortly after announced that we had the intent of releasing the app as a utility on CDN with forum support.

As you probably know, it's been 2 months and the utility has not being released, and the reason why, is very simple.

The demand this app has generated was tremendous, but despite of the community demand, many customers would not be able to take advantage of this app simply because it's not officially supported, therefore making it not suitable for production environments.

We were set with a dilemma, release the app anyways, assuming web support would suffice or review our release process and attempt to sneak CFL in the XenApp product roadmap.

I can tell you that in the meantime we've been putting the app thru many tests, while identifying the scenarios users could benefit from it, and at the same time, talking to our engineering group trying to lockdown a possible target for this application to be introduced as part of our product.

Of course, there is no guarantee Citrix Fast Launch will be included in the future, however one thing is certain, you as customers can influence these decisions, helping us identify where does faster launch times fit on your list of priorities.

With that been said, here are some questions for you...

Community Release vs. Product Integration?	Choose
I'm OK with a community release supported on CDN forums
Integrated is preferred but a community release is better than nothing
No rush, I can wait until it becomes officially part of XenApp
I cannot implement apps in production without official support

Would faster launching times impact your decision of deploying XenApp?	Choose
Yes
No

You will soon have this tool called "Inter-Isolation Communication".  Great!  What do I do with it?

Answer: You have less points of maintenance for Application Streaming while retaining isolation and centralized updates.

Example scenario: 1 Big app + 1 small addition = single thing you want to publish.

Lets call the big application "MS Office" because everyone knows that MS Office is big. Its also a convenient example because there are numerous add-on programs that install "on top of" the base application.  

Let's also assume that you have different "add-ons" to install for the different groups that you support.  Everyone uses "big app", but they all use it differently based on their job function.  To get this to show the power of single point of maintenance, we're going to say that you have a really big shop that has 10 different deriveratives of "big app" that you have to publish.  Back-step: I ran out of job titles, so we're gonig to use 5 different deriveratives!

The groups:

• Execs
• Sales
• Finance
• Accounting
• Programming

NOW - Each of these groups has different requirements for add-ons.  You as the administrator install the base "big app" and then install the add-on and then you store the application away where folks of that group can access it.  Before Isolation and Streaming, you create a MSI that gets pushed down to end user machines with the correct package set for that user.  With Isolation and Streaming, you still use the MSI, but you instead use it to create a centralized profile.

With Streaming, but before IIC, what did you have?

Answer: 5 different installation images for MS Office where each was really MS Office + some other installer. 

If you want to update the add-on installation, no problem, you update your profile and store it - the streaming system then kicks in to get the profile update out to all your users.  Great.  BUT!  What if you want to update "big app"?   In the App Streaming or (insert other streaming system here), you now have 5 points of maintenance compared to 1 when the application could be locally installed.  Notice that this is a univeral problem to all application isolation systems.  Streaming and Isolation are great!  Centralized publishing, isolation, resolution of DLL Hell and a variety of other good things. BUT if you have 5 points of maintenance on "big app", then that rather reduces the value of going to streaming.

Inter Isolation Communication gets Streaming back on the same maintenance foot print with locally installed.

With IIC, you have only 1 instance of "big app" and you also have 5 profiles of deriveratives of "big app".  Interestingly, the applications you are interested in running are all from "big app", but the profile you publish from will be "sales on top of big app.profile" and "execs on top of big app.profile".  Inter-Isolation Communication will RUNTIME MERGE the profile for big app with the deriverative profile and this is why it is so important.

A single update to "big app" will immediately benefit ALL of the derived profiles.  This makes maintenance just as easy as locally installed, while retaining isolation!  Great stuff.

A studious reader will notice that IIC to some degree also brings back some of the issues that isoaltion is intended to make go away.  True.  Its rather a balancing act.  In the first releases of Application Streaming, we had isoaltion on the brain and when no other decision exists, we isolate!  This isn't always what the administrator wants.  The admin wants to isolate the isolated application from the system and they want to isolate the isolated application from other applications, but they do not want to isolate "big app" from "addition to big app".   The later is "known to work" with big app and this is how the IIC subsystem runs the apps.  Big app and addition to big app run in the same isoaltion space - but they are still separetly cached and they are maintained in their separate profiles.  

Is DLL Hell back

Yes!  You can control it though.  Given that two profiles linked at runtime both have a single DLL and that the order of installation of the linked profiles MATTERS!  Then there exists a scenario where defining a link relationship between apps can expose a DLL Hell dependency.  The 1.2 Streaming Profiler allows control of this on the page where the relationship between linked profiles is defined.   Here's a picture.

Notice the "Move up" and "Move down" buttons on the right.  When a sub-profile is selected on the left, its position in the isolation stack can be adjusted.  Using the layers of glass analogy, the higher profile in the GUI is the highest layer of glass.  That means that IT WINS compared to lower profiles.  If DLL Hell is detected, you could just erase the offending file from a higher level profile and let the lower level shine through - you can also adjust the relative position of the isoaltion layers to have the same effect.  This GUI is where that configuration occurs.

IIC will be a powerful tool in the XenApp adminstrators toolbox.  I expect to be surprised at how it is put to use. 

Happy Streaming!

Joe Nord, Product Architect - Application Streaming, Citrix Systems

Wanting to eat our own dog food and wash it down with a big tumbler of kool-aid, my team recently held a meeting of nationally dispersed attendees and used the GoToMeeting VoIP features. I'm not kidding when I say I haven't heard that much reverb, distortion and echo since the last time I listened to "The Piper at the Gates of Dawn." As our first attempt, we spent quite a bit of time complaining to each other about the sound quality and asking each other to place our devices on mute. By the way, did you know that the default setting in the GoToMeeting preferences is to always save chat logs? The following is an extract of the recorded GoToMeeting chat that occurred. Names have been changed to protect the innocent.

B (to All - Entire Audience): the voice quality is terrible
K (to All - Entire Audience): you have a lot of reverb and I can't understand what you're saying
R (to All - Entire Audience): can someone mute their mic
R (to All - Entire Audience): massive echo
V (to All - Entire Audience): Click on the green mic icon and you can mute it
B (to All - Entire Audience): cant understand a word this other speaker is saying

I don't have specific stats yet as to how many people were on "regular" phones vs. using computer mics, but judging on the icons in the attendee list it was a nice enough mix of what one would probably reasonably encounter in this scenario at other companies.

Now, I'm used to using our stuff before it's released and dealing with the intricacies of things that don't quite work yet, but in this case it's not the application - it's the settings. In this case it's just a matter of understanding that one-size does not always fit all. Turns out if we had done a little pre-meeting training and all made some quick and easy settings adjustments to our individual GoToMeeting installations, we could have had a much more satisfactory experience.

When in doubt, read the friendly manual

If you've experienced similar issues or haven't tried this feature yet, there's a good article in the GoToMeeting online help to mitigate this -

GoToMeeting VoIP Audio Best Practices

First, what device are you planning to use? Check out the chart in the link above for recommendations. A USB headset connected to your computer will offer the best quality experience, while using your laptop's built-in microphone and speakers will give you a poor experience, especially if your mic is picking up what's coming out of your speakers - echo city.

And here's an additional excerpt that may help:
VoIP Audio Setup - PC

1. Right-click the GTM icon in the PC system tray and select Preferences.
2. Select Audio.
   Microphone Setup - It is recommended that you test your microphone. To test, select your microphone device from the drop-down menu and speak into your microphone; if it is connected correctly, the sound meter will light up green. If the green meter does not light up, select another device listed in the drop-down menu and repeat this test.
   Speakers Setup - It is recommended that you test your speakers. To test, select your speaker device from the drop-down menu and click Play Sound; if connected correctly, you will see the sound meter light up green and hear a soundtrack through your speaker device. If you do not hear sound after clicking Play Sound, select another device listed in the drop-down menu and repeat this test.
   Advanced - GoToMeeting automatically adjusts audio levels. We recommend you keep this checked. If you uncheck this selection, you must manually configure your audio settings through Windows Sounds and Audio Devices. If your attendees can't understand you because your voice is distorted, try unchecking "Microphone boost."
3. Click OK.
   
   

I strongly recommend that you read the rest of this article, consider using a USB headset and adjust your microphone and speakers settings before joining your next GoToMeeting VoIP call for a much better experience.

If all else fails, the meeting organizer can mute/unmute all participants by selecting *5

Have a happy meeting!

We have seen the materials, at a high-level, on how the XenDesktop solution fits together and the benefit it can provide.  Are you interested in understanding more detail of the end-to-end solution? 

In this 60 minute webinar, I will provide you with a very quick overview of the complete solution and then spend the majority of the time discussing the different components, what they are for, how they work and how virtual desktops are managed by the solution.  We will cover the integration of the following components: 

• Desktop Receiver
• Access Gateway
• XenDesktop Controller
• XenServer
• Provisioning Server
• XenApp
• Citrix User Profile Manager. 

It is sure to be a great time where we will all learn a lot.  And I might even explain to you on how XenDesktop relates to a Simpsons episode. 

By the end of the webinar, we will all be able to understand the following song:

Desktop Receiver connected to the Access Gateway, Access Gateway connected to the Web Interface, Web Interface connected to the XML Broker, XML Broker connected to the IMA Service, IMA service connected to the Data Collector, Data Collector connected to the Pool Service, Pool Service connected to the XenServer and that's how the whole thing works

See you there and don't forget to register here.

Daniel 

Like I said in the recent TechTalk on server virtualization for XenApp, because there were so many questions, i was going to post answers to them all in a blog.  And this is the blog. 

First, many of you wanted the addresses for the reference materials i identified in the webinar. Here they are:

• TechTalk Webinar Recording: 
• Reference Architecture
• Design Considerations
• Implementation Guide

http://xenserver.citrix.vivoconcepts.com/prg/form/Citrix_runningxenapponxenserver_080225.cfm 

Q: Is all this done on a Citrix appliance or is it all software based and we provide the hardware?

A: Running XenServer is all software based.  You install XenServer, which takes roughly 10 minutes, on a physical server.  From there you can split up the physical server into any number of virtual servers.  A free version of XenServer Express and an evaluation version of XenServer Enterprise can be downloaded here: http://www.citrix.com/site/SS/downloads/results.asp?productID=683148* *\\

Q: What is the best resource for researching the possibilities of XenApp?

A: With regards to virtualization and recommendations, I would suggest the following materials, which covers different types of configuration, practices, considerations, how to do it, and much more. 

• TechTalk Webinar Recording: 
• Reference Architecture
• Design Considerations
• Implementation Guide
• Optimizing XenApp Performance with XenServer 4.1.0 Enterprise Edition
• Performance Evaluation of XenApp with XenServer
• Benefits of Virtualizing XenApp with XenServer* *
  

Q: What about network utilization with regards to Provisioning Server?

A: Network utilization is important for Provisioning Server in that the operating system image is streamed down to the virtual server.  With a base Windows 2003 Server, the install size is roughly a few GB.  However, Provisioning Server does NOT stream that entire image to the virtual server.  Provisioning Server ONLY streams materials as needed.  In fact, booting a Windows 2003 Server only streams a fraction of the multi-GB actually used in the install.

Q: Is Network Storage iSCSI or Fiber connection?

A: When you virtualize the disk with Provisioning Server, you essentially do not have any storage assigned to the virtual server.  Yes, you read that right, you don't assign storage to the virtual server because the image is streamed on-the-fly.  It is actually pretty wild to think about. Provisioning Server should be on an enterprise storage solution like a NAS or a SAN for high-availability and high speed of delivery to the virtual server. 

I know the first time I had discussions about Provisioning Server I was like, what do you mean there is no disk.  But it is true.  If you stream to the physical server, you can completely unplug the hard drives. In the virtual server world, you just don't assign disks to the server. With this type of solution, you end up not having to worry about GBs and GBs of storage required for a virtualized XenApp solution.  In fact, I've seen customers use Provisioning Server to help them migrate to newer versions of XenApp.  Right now, let's say you are running XenApp 4.5 installed on physical servers. When the next release of XenApp arrives, you create your image with Provisioning Server and stream the image to the servers (physical or virtual).  If you run into challenges with the new version of XenApp, your fallback procedure is to use the hard drives again, which still contains the XenApp 4.5 installation. Pretty cool if you ask me. 

Q: Would XenServer bundle with P2V tool for free? Or we have to buy PlateSpin P2V tool?

A: The P2V tool, when it is released, will be free. You won't need to buy any third-party tools to do P2V conversions. 

Q: We have VMware ESX Enterprise already. Should we get XenServer for our XenApp farm? What are the advantages?

A: I'm not a Sales person so I don't recommend products just because it is what we sell. So when talking about virtualizing XenApp, first understand that XenApp is a unique beast.  It doesn't behave like other systems within the data center. It must support hundreds of users simultaneously.  This requires lots of memory, lots of context switching, lots of disk access. It is different than let's say Exchange or SQL Server.  Before XenServer 4.1, I would have been hard pressed to recommend XenServer as a viable solution for XenApp. In fact, most virtualization solutions would not have dealt with XenApp effeciently.  But look what happens when XenSource became part of Citrix.  Our engineers (XenApp and XenServer) worked together to re-architect the hypervisor to perform remarkably better for XenApp virtual machines as compared to the 4.0 version of XenServe. That being said, XenServer is optimized for the XenApp workload.   Instead of making you perform some low-level funky "tweaks" the hypervisor, we just have you select the type of workload the virtual server is doing.  In this case, you select XenApp. This option changes how XenServer deals with memory to align better with XenApp requirements. 

Now, when you look at XenServer Platinum the picture becomes even better with Provisioning Server.  Without Provisioning Server you must still manage each virtual server as if it was a physical server. This is regardless if you are using XenServer, Hyper-V or even VMware.  Provisioning Server lets you focus on the role and not the server.  There are fewer roles in the data center than there are servers. Easier to manage and maintain, a huge savings if you ask me.  And you did   But I did only touch on a two areas.  Take a look at the documents (especially the reference architecture) I put at the beginning of this blog for additional information.

Q: what were your server specs for your example?

A: The scalability testing completed with XenServer and XenApp were done on a Dell PowerEdge 1950 (1 Quad-core 1.6GHz, 8GB-16GB RAM). 

Q: What about users that are logged into an app, and the server is rebooted

A: A physical server, virtual server or a server receiving the image from Provisioning Server, those users are disconnected and their sessions are gone.  Now if the physical XenServer fails, the virtual XenApp servers can be moved to another XenServer, a feature we call XenMotion.  In this circumstance, a user might see a slight pause in their session, all depends on the current situation. But the point is in this situation, the users session and data is intact.

Q: You mentioned doing P2V of Citrix servers throughout your presentation.  Are there any items to be aware of when doing this?  Any resources to help with this process?

A: Well, the first is an upcoming P2V tool that will let you convert a physical server to a virtual server for XenServer.  If you only use XenServer and not Provisioning Server, the only other item is to set the optimization setting for the virtual server to Optimized for XenApp.  This was discussed earlier in this blog.  If you are also going to stream the system with Provisioning Server, you will want to build the "golden image" how you want it to be for each server. You then must run the integration utility, which will take care of all the other configuration items.  If you want instructions on how to do the Provisioning Server aspect, take a look at the Implementation Guide identified at the beginning of this blog.

Q: Did you use Provisioning Server w/ the test load, or just straight XenApp on XenServer?

A: The scalability testing was just XenApp on XenServer.  I can bet your next question will be what impact on scalability with Provisioning Server have.  And might I say it is a great question if I do say so myself.  Unfortunately, I'm not aware of any scalability testing that shows the impact to single server scalability with Provisioning Server. 

Q: How is XenApp rated on VMware ESX vs. on Provisioning Server on XenServer?

A: Unfortunately, due to VMware's end user license agreement, we are not able to publish scalability numbers for VMware ESX.  No one can except VMware.  We did tests against a number of virtualization vendors and found that XenServer allowed roughly 70% more users than others when running 64Bit XenApp.

Q: How large would a server image be with Provisioning Server?

A: The size of the Provisioning Server virtual disk, which I call a role, can be pretty much any size.  However, you don't want to go wild with the image size.  If you create a 10GB image and a 100GB image, the 100GB image will take a lot longer to build and optimize, plus it will waste space and we are all trying to conserver power, space, cooling, etc.

Q: What is the best client to use - PN, PNA or WI?

A: You tell me   It really depends on what you need.  Most administrators prefer PN as it allows them to make connections as they need to support the environment.  Users prefer PNA or WI.  PNA is great in that you don't have to go to a web page to get to your applications, so it is faster from a user perspective, but WI allows you to integrate the published resources in other pages like SharePoint. I personally use Web Interface and my favorite color is green.

Q: How can one discern how much RAM/CPU is being used on a daily basis?  Does Access Suite Console give that info?  (Am on PS 4.0 and use VMWare)

A: Within the XenApp Access Management Console, you can generate reports for your XenApp servers to give you all kinds of information about the overall utilization of the servers. The reports are in the Report Center. Also, you can use Resource Manager or EdgeSight to get even more detailed information.

Q: Is there a release date for the P2V tool?

A: All I can tell you is the beta is expected soon.  I would log onto MyCitrix and see if you can see it in the download section. Also, Roger Klorese has been blogging about the next version of XenServer (Project Orlando). I recommend taking a look at his blogs.

Q: Is there a guideline for application roles that are not suited for XenServer virtualization?

A: Hmmm, I'm trying to see if I can think of an application that is not suited for XenServer, but I'm having trouble.  Before XenServer 4.1, I would have probably said XenApp due to the overhead, but now that the overhead has been drastically reduced, I can't say that anymore. 

Q: What file system do you recommend for the storage partitions on a NAS or SAN?  (I think VMware has a proprietary clustered file system, Novell uses OCFSv2).

A: This is what I love about XenServer and Citrix.  You can use anything you want.  NAS, SAN, NFS, iSCSI.  If you already use something like NetApp, use it.  If you use a SAN solution, use it for XenServer. 

Q: Nice to see how memory issues can be addressed with virtualization. What about CPU, network, and disk I/O being the bottleneck?

A: Excellent question. 

• CPU:  Not sure what issues are around CPU in the XenApp world except for CPU underutilization because of memory bottlenecks and memory limits.  Virtualizing lets you completely use what you paid for. 
• Network: The networking aspect is interesting.  Because the physical server is now hosting multiple virtual servers, you want to make sure you have adequate bandwidth going into and out of the physical server. The network component is critical to XenApp, but the data transferred is fairly minimal due to the use of ICA.  Now on the backend, the XenApp applications require data from their source. And if Provisioning Server is being used to stream the operating system, more network bandwidth is required.  But these should still be within the limits of the current standard server hardware of 1GB NICs.  However, I would still recommend mulitple NICs to a single XenServer. You don't want a Homer Simpson tripping over a network cable and dropping all users from a XenServer.
• Disk I/O: In a enterprise design, I would recommend you use some type of fast storage like a NAS (regardless if you use Provisioning Server or just plain XenServer).  These devices are specialized hardware optimized for file sharing.  I have had customers tell me that their XenApp environments actually run faster because of XenServer and the integrated NAS/SAN.  

Q: is the benefit presented on this slide in the fact that Disaster recovery is improved by virtualizing?

A: Disaster recovery is improved. With XenServer you can move a running virtual server to another XenServer. Provisioning Server also helps in the DR scenario as you can quickly re-provision systems to take on a new workload with a simple reboot. 

Q: You don't have to have 32-bit apps to run on 64-bit OS.  That's where you get your scalability on XenApp

A: True, you can continue to run your 32bit apps on a 32bit OS like Windows 2003.  The problem is that you have a memory limit with 32bit OS.  In more cases than not, you will max your RAM before you get close to maximizing your CPU. 

Q: We have XenApp 4.5 running on a dev/test environment in VMware. Session connection times seem to be slow for an app to open up. What kind of things should I be looking at to find the source of the problem outside of adding hardware to the VM. thanks!

A: Well, first I would say try using XenServer  (I know, I had to say it)    But seriously, take a look at the storage situation with your VMware implementation. What performance numbers are you getting from the I/O system in your setup?  With XenServer, we recommend you use either a NAS or SAN type solution which provides the fastest possible disk performance.  The faster your disks run, the faster apps load because they are coming from disk.

Q: What technology are you using to determine user count?

A:  We are just performing scalability tests with tools like EdgeSight for Load Testing and then to get the metrics, we utilize perfmon counters and log files to analyze the results and make comparisons.

Q: I'm a bit new to XenApp but your numbers for concurrent users seemed very high. If your Visio app is using 1Gb of RAM just for you, doesn't' that mean that a max of 15 people could use Visio on a XenApp server?

A: In that example, yes.  However, it all depends on the apps.  For example, the scalability numbers I presented for roughly 300 concurrent users on a physical server were working with Excel only.  This was used to determine overhead. Your concurrency numbers will vary based on workloads. The scalability numbers are meant to give you an idea of the XenServer overhead.

Q: Another point is disk utilization... we are often disk bound

A: Yes, disks can be a problem. Sure you can implement array controllers, use 15K RPM drives, but you are still relying on the local system to manage the file system. When you integrate with a SAN or a NAS type solution, those devices are optimized for file hosting.  Optimization=Speed

Q: I have already heard that you can not clone XenApp servers... where can I learn more about this?

A: Read the Reference Architecture document identified at the beginning of this rather long blog. It talks about the Provisioning Server Integration Utility for XenApp.

Q: How do you get 200 users in 4GB of RAM?

A: By running Excel only.  This workload is used to show the overhead impact between 64bit physical, virtual and 32bit.  You workloads and your concurrency numbers will be different. This is to give you an idea of the expected overhead.  I've actually seen other people get their XenApp servers into the upper 100s by using bigger applications than Excel. It all depends on the apps and users. That is the main problem with scalability tests, they only reflect a single type of workload and do not represent your environment. They are only meant to give you an idea of what the overhead is and comparisions against other products.

Q: Any tool like ESX Ranger becoming available?

A: ESX Ranger has many different features.  I know you would be able to use something like Workflow Studio to help manage the environment from user-based, event-based or schedule-based triggers.  As this product is still in beta, it is hard to tell what functionality and integrated components will be available at release.

Q: Isn't XenServer only supported on 64-bit platforms?  How then would we virtualize a 32-bit Server with your scenarios?

A: XenServer is a 64bit hypervisor, but it can virtualize 32 and 64bit systems. 

Q: Did you reference a 32bit version of XenServer?

A: XenServer only exists as 64bit.  There is no 32bit code in the XenServer.

Q: What about PAE on 32-bit systems?  This allows more than 4gb of ram to be addressed. 

A: I wondered if someone was going to ask about that.  Congratulations.  You can use more than 4GB of RAM on a 32bit system, but there are a lot of things you must be aware of.  Instead of making this blog even longer, I created another entry that discuss the PAE setting, which can be found here:

Q: Why would you keep a backup data store if you can just motion it instead?

A: In the event the live data store is corrupted and is unrecoverable. If it is, I hope you have a backup. 

Q: What are your thoughts on virtualizing Provisioning Server?

A: The great answer, it depends.  Virtualizing Provisioning Server will induce latency into the stream as it must go through a virtual network and then onto the physical network to the device.  However, being able to hot-move the Provisioning Server to another server and easily add capacity makes virtualizing a very sound solution.  I haven't seen any numbers yet as to what virtualizing Provisioning Server would do to the scalability.

Q: Running published desktops. Can I virtualize these?

A: Published desktops on XenApp, yes you can.  If you are talking about XenDesktop, desktop virtualization, VDI, whatever else they call it these days, you can as well. In fact, Citrix XenDesktop is also based on the XenServer hypervisor.

Thanks

Daniel

Homer Simpson Quote of the Blog "If you really want something in this life, you have to work for it. Now quiet, they're about to annouce the lottery numbers!"

Memory is a big concern for XenApp on a 32bit operating system like Windows 2003 Server.  In the default state, Windows 2003 can only "see" 4GB of memory, which is split up into two equal parts: Kernel Memory (2GB) and User Memory (2GB). Kernel Memory is further broken down into 4 other parts:

• Paged Pool: Memory space used by the system and kernel level components that can be paged out of physical RAM and into the page file
• Non Paged Pool:  A section of memory guaranteed to always reside in physical RAM and is used by the operating system for certain kernel level processes
• System Page Table Entry : An index table that tells the operating system where the virtual memory actually resides in physical RAM or on the page file
• System Cache: Maps open files in memory for better performance. This is where the registry hives are located as well
  

Once the system has started, the different sections of kernel memory cannot be re-allocated. The system tries to allocate these 4 areas appropriately, but they might require "tweaking". However, the four areas cannot all be set to the maximum level as that would go over the 2GB limit of kernel memory.

Many of you are probably saying, "But I can use the PAE switch on Windows 2003 to go above the 4GB limit". You are correct, you can go above the 4GB limit, but are you aware of the consequences of this action?

1. You must be using Windows 2003 Enterprise or Data Center.  This setting does not function in Windows 2003 Standard.
2. The PAE Switch does NOT change the kernel memory limitations of 2GB
3. To use the extra RAM, more System Page Table Entry memory is used
4. If you have more System Page Table Entries, you will end up with less Paged Pool, System Cache and Non Paged Pool
   

Talk about being between a rock and a hard place. Adding more RAM and enabling the PAE switch "might" give you more scalability but at a great cost for a more expensive operating system, more RAM and special optimization configuration analysis and implementation. The reason I said "might" give you more scalability is because you will now likely run out of kernel memory before you run out of user memory. So you just bought a more expensive operating system and more RAM that will sit there wasted. 

Now I know some of you will add a comment saying something to the effect that you are using the PAE switch and ended up increasing single server scalability by 60, 70, 80 or even 90%.  All I can say is congratulations and I applaud you  . You are lucky as you have the right set of apps for this to work as well as it has.  But I want you to think about going down a completely different route.  Virtualization...

Keep using Windows 2003 Standard but virtualize it with XenServer. Upgrade the RAM on the physical servers so it can support 2-4+ virtual servers. In the end, you will end up with a system that is more flexible, scalable and easier to manage. 

If you interested in learning more about sever virtualization for XenApp, then take a look at the following:

• TechTalk Recording: Make Server Virtualization work for XenApp (http://www.citrix.com/English/NE/events/event.asp?eventID=1679445)
• White Papers
  • Reference Architecture
  • Implementation Guide
  • Design Considerations

Daniel

Homer Quote of the Blog: "To be loved, you have to be nice to others EVERYDAY! To be hated, you don't have to do squat."

Does anyone care about having high-availability for their XenApp farms?  I would envision many of you would say yes.  But what does HA for XenApp really mean?  On the server hosting side, you essentially have HA because you have load balancing at the application level. So if you lose a XenApp server, not too much of a concern as those users can simply restart their application and get load balanced to another server (of course they lose their previous session information, which can be annoying.)   But what other areas of critical to providing a more available XenApp environment?

I've been thinking about this a lot lately, which is probably because my manager has had a lot of meetings and I tend to space out and watch episodes of The Simpsons on my laptop.  Since my DVD player broke, I started to think about HA for XenApp during these meetings (at least I'm now doing work). I was able to come up with the following thoughts:

1. Smart Monitors:  First, I want to know that something has failed or has gone flakey.  I don't want a bunch of messages telling me everything is ok, I just want to know when something is about to go horribly wrong. For example, the XML Black Hole.  I've seen the black hole cause too many issues, so how do we detect it?  You create a smart monitor that does more than pings. It tries to make requests to the XML service. If the expected data comes back, we are good to go. If the request is never answered or the response is junk, then Homer, we have a problem.  
2. HA for the Critical Components: Now if we can detect a failure, DO SOMETHING ABOUT IT.  As we continue looking at the XML Black Hole, if we see there is an issue, then stop making requests to it. But this requires another XML Brokers to take over the responsibility of the failed one without requiring changes to the environment's configuration.   Sounds a lot like load balancing to me.
3. Business Continuity:  Essentially what I'm saying is that if my XenApp environment at one site fails, I  better have another site already waiting for connections without requiring me to make changes.  Many people have 2 data centers: a primary and a backup. Others have 2+ data centers that are all active.  For those organizations with 2 data centers (primary and backup), how do you fail users over to the backup in the event of a failure?  For those organizations that have 2+ active data centers, how do you tell your users data center is their preferred site?  That is really a trick question (Did I get anyone?).  You shouldn't have to tell your users anything about going to a primary, backup, tertiary site. It should happen automatically.  Users want their applications in the fastest possible means necessary, which could mean that one day it is from data center 1 and on another day it could be data center 2.
   

These three items are all part of NetScaler, and it is easy to setup.  For those of you who know me will notice that I've worked with the integration of NetScaler and XenApp for some time.  Well, the NetScaler product group is actually making my job easier because they are making this solution a lot easier.  I created and maintained a 40+ page document that showed you how to set all of these goodies up. Now that document is about 14 pages (with pictures for each step) because of the new NetScaler for XenApp wizards.  I'm just glad I don't get paid by the word.  Take a look at what I'm talking about. In about 5 minutes you will see me configure and integrate NetScaler with XenApp:

Watch this Video:

Also, take a look at recently released articles  that goes into more detail on this integrated solution: http://support.citrix.com/product/nsad/v8.1/consulting/

• Taking XenApp to the Next Level of Availability - Reference Architecture
• Taking XenApp to the Next Level of Availability - Implementation Gudie

I'm curious what other areas concern you when you are focused on HA for XenApp?   Let me know. Yes, my manager finally ended the meeting, I am outta here.

Daniel

(Homer Quote of the Blog "Kids, you've tried your best and failed miserably.  The lesson is, never try")

Welcome to the third installment of the Dynamic Delivery Center.  This time I will be showing you the Proof of Concept (PoC) we built to validate the DDC is possible.  If you haven't done so already, I encourage you to review the first two blogs so you understand our business and requirements.

• Part I - The Need
• Part II - The Analysis

Now, the PoC.  First, let me show you the architecture diagram we've used.  (Visio Stencils for this diagram are located here).

As you can see, it is fairly straightforward. I'm the type of person who prefers things simple. The whole purpose of the PoC is to see if we can use a web front end to dynamically deliver any number of "Test" environments to the users.  Now, as many of you reading this are techies, let's get to the good stuff...

• External Access: Every user will be remote. Even if you are sitting in the office next to the lab, you are considered a remote user (Ever hear of de-perimiterization?).   All users will connect through an HA Pair of NetScaler 7000s with the SSL-VPN functionality enabled in full VPN mode.  We are doing more than ICA so we need a full VPN connection.
• Web Front End: Users will be able to connect to the Web Frontend when they connect with Access Gateway Enterprise .  The Web Frontend will allow the user to request any number of systems from the lab. 
  
  
• XenServer Resource Pool: Currently, the XenServer Resource Pool contains a set of templates that users can request from the environment. Those templates are reflected in the Web Front End, allowing the user to customize their environment.
• XenServer Template Library: For the PoC, the library only includes Windows 2003 R2 servers, XenApp 4.5 servers, Windows Vista SP1 workstations and Windows XP SP2 workstations.  New virtual machines are created based on the templates, which should only take a few seconds.  The library will grow as new requests come in and new systems are required. The longer the DDC is running, the more complete the library will become.
• NetScaler: The NetScaler devices are setup to allow for either a one-arm or two-arm deployment (hence the reason for the two separate VLANs).  If the user only requires a one-arm setup, they just ignore the second connection.
• WANScaler: The WANScaler devices are setup to allow the user to test any number of backend optimizations across any simulated WAN connection with the Apposite WAN Emulator.  The backend contains another XenServer Resource Pool allowing the user to test WAN optimization against any number of resources including file servers, web servers, media servers and XenApp servers, just to name a few.
  

We have the architecture, but how does it work?  How does the Web Frontend do it all?  In the PoC, we chose not to look into Workflow Studio (Sorry WFS Team) as we want to wait for the next beta release. But the lessons learned in the PoC will help us properly develop our workflows in the design phase.  In the PoC, we used the SDKs extensively to do the following:

• Virtual Machines
  1. A user selects one or more templates on the Web Frontend and selects "Provision Servers".
  2. The Web Frontend code will search for a virtual machine resource in the database that has not been marked as in use. Once an open virtual machine is found, the database will be updated and marked as in use by the user for a period of 3 days.
  3. The Web Frontend will establish a session with the XenServer host using root credentials.  The template the user selected will be cloned.  Once the clones are created, they will be sent a start command.
  4. Once the virtual machines are running, the IP address will be obtained. This information is used to generate an automated email to the requester using the SMTP service running on the Web Frontend server.
  5. The user will use the IP address to make a Remote Desktop connection to the console of the server, which is waiting for the user to enter a name for the virtual machine as part of the SID generation process.

• NetScaler
  1. User selects "Provision NetScaler" from the Web Frontend
  2. The Web Frontend checks the database for an available NetScaler. Once one has been found, it is marked as in use by the particular user for a period of 3 days. In the event that all NetScalers are assigned, the user will receive an automated email.
  3. The Web Frontend will establish a session using XML API calls with the NetScaler using the "nsroot" credentials. The reset process involves using the XML API calls to get into the NetScaler shell to remove the ns.config file.  Simply deleting the NS.Conf will completely reset the NS config. That would be bad because that includes the IP Address.  We don't want to go into the lab and connect a serial port and configure the device.  To solve this challenge, we  copy a base ns.config (which includes the NS IP configuration) over the current one.  We also have the code go through and remove any extra files that the previous user might have created (certificates, configuration files, etc).
  4. The Web Frontend will send code that will clear the NetScaler configuration, while keeping the IP address constant, so it is accessible from the network.
  5. The user will receive an automated email from the Web Frontend using the SMTP service.  The email informs the user on the connection information for the NetScaler.

• WANScaler
  1. User selects "Provision WANScaler" from the Web Frontend
  2. The Web Frontend establishes an HTTP session with the WANScaler web console using the "admin" credentials.
  3. The Web Frontend sends a request to reset the WANScaler config back to factory defaults, while still preserving the IP address. Once the WANScaler has been set back to factory defaults, the WANScaler will be rebooted.
  4. The user will receive an automated email from the Web Frontend using the SMTP service.  The email informs the user on the connection information for the NetScaler.
     

Lessons Learned:

• The biggest thing is that it is possible!!  The tricky part of the project was resetting the NetScaler and WANScaler back to factory defaults without losing the IP address. 
• A more complete set of XenServer templates is required to anticipate any number of requests from the field
  

Next Steps:

• Create a more detailed design that identifies the templates required for the initial release
• Create a detailed set of workflows that are required to see how Workflow Studio can be leveraged to make this environment easier to build and maintain.
• Create a way to hide Simpsons "Surprises" within the lab like logging into the lab and receive a warm welcome from Homer saying "D'oh!"
  

Hope you enjoyed this one.

Daniel

Homer Quote for the Blog "Look, the thing about my family is there's five of us. Marge, Bart, Girl Bart, the one who doesn't talk, and the fat guy. How I loathe him."

It was a long time in the making but it's finally here! I think I've been seeing requests for how to do this since IE7 came out and up until now many people said it couldn't be done. Once again the "impossible" has been captured and documented. "Isolating Internet Explorer 7.0 for Safe Surfing" is now available in the Application Delivery Best Practices Wiki.

Here's an excerpt:
"You can use application isolation to isolate and publish Internet Explorer 7. You can create a rule that forces all downloaded files to reside in the user profile root. This provides users with the freedom to download files if they wish to do so, but it also prevents them from running downloaded executables on the enterprise network.

Administrators can enforce cleanup policies that delete all session artifacts when the user logs off. Application isolation also enables you to publish multiple instances of Internet Explorer with different configurations, which is very useful when you have users with different usage requirements."

The full article is publicly available here.

Instructions to isolate Internet Explorer 6.0 are available here